{9} Active Tickets (Full Description) (63 matches)

If TellStick Net has an interface for local control, without Telldus Live! it will be possible to use the device as a TellStick Duo.

Allow the user to configure "one-time schedules" in the scheduler. Whenever a schedule has been executed, it should be removed.

This would allow developers to build "timers" in their applications, webservices etc, "Turn off light in 15 minutes". A schedule is set for time + 15 minutes, and deleted after execution.

Releasing the source code of the Live! backend would enable users to start their own Live! backend instances locally without being dependant on Telldus services for their solution to function. Already existing Live! clients could support these local backend instances with presumably little effort as long as the API is identical. The local Live! instance would typically talk telldus-core with the devices. Perhaps we need to extend the API so that clients can ask the backend which calls are supported (e.g. a Telldus "Classic" does not support Sensors).

Forum thread:  http://www.telldus.com/forum/viewtopic.php?f=1&t=1782

Since statevalue in the API depends on the current state of the device it would be good to have the values "normalized".

For instance, it the state is TELLSTICK_DIM the returned data could have a value "dimvalue" that is guaranteed to be an int.

If the parameter protocol in /etc/tellstick.conf if not configured properly telldus-core reports "Unknown error". A better error message explaining the issue would be helpful.

Interrupt "std::wstring clientMessage = d->eventSocket.read(5000);" when stopping Client thread.

That's why for example tdtool now takes up to 5 seconds to finish in Linux (tdClose). See if Windows is affected.

Multiple repeated identical received signals for configured devices should be output as only one device event callback. Sensors too.

We need functions to list the connected controllers.

Add support for receiving signals from EV1527 chips such as projector screens, smoke alarms and such.

Request a feature to use TelldusControl on a standalone headless linux server.

There is a common use case to have a tellstick that is connected to an linux server that doesn't have X installed due to minimized hw/sw setup.

It would be a great advantage to be able to run TelldusControl on this setup as well. With it the customer can benfit from the TelldusLive service for remote internet control of devices as well as simplified device management.

Idea 1 TelldusControl for headless linux servers could be controlled via a web interface, prerequsite to have i.e. apache web server installed with xx modules.

Idea 2 Add basic functionallity for communication between a TelldusControl service and TelldusLive, open API's. All setup and configuration could be done via conf files with descriptive log messages in the service deamon. API function for TellstickDuo so that i.e. temperature or sensor data can be used to program own control of devices.

Confirm this. Mac? Linux? Perhaps fix with autodetect after TellStick not found?

Old version is using TellUsbD101.dll, which is not included in TelldusCenter 2.1.0.

Both signals seems to be "lost".

Source:  http://www.telldus.se/forum/viewtopic.php?t=1582&p=9686

The recent qml parts of TelldusCenter don't have support for different languages. At the moment the "File"-menu may be called "Arkiv" if using swedish language settings, but for example all headlines and messages in the Sensor module are in english.

More info:
 http://electrohome.pbworks.com/w/page/34379858/Efergy-Elite-Wireless-Meter-Hack[[BR]]  http://www.ukha-archive.com/ml/ukhad/2007-jan/msg00653.html

The scheduler is almost done, but need graphic touch up and some more testing on different platforms.

Show information about current status of services, planned maintenance etc easily accessible on homepage.

To compile on ReadyNAS Duo some compiler warnings needs to be fixed as mentioned here:

 http://www.telldus.se/forum/viewtopic.php?t=915&p=8190#p8190

The width of the state-column is to small when a device has been dimmed, the width should be dynamic or static but wider.

To ease up the development of scripts reacting on events from a TellStick Duo it would be nice if telldusd could execute scripts on all events.

Ability to sort devices. Or change the way they are returned from telldus-core. Now it's by deviceId, with 10-19 being lesser than 2 etc

Attached is a demo-implementation in .Net.

The API should be exposing function for controlling devices which is not setup using TelldusSetup. For some software TelldusSetup is not a good solution and must be provided with "raw" access to TellStick.

Both sending raw-strings and wrapper functions such as devNexaTurnOn(char house, char unit) should be in the public API. This also makes software depending on rfcmd able to use the API directly and not use ugly wrappers to rfcmd.

rfcmd could also rely on the API and not calculate the data itself and then support all the devices the main API supports.

Add support for more Nexa door bells, such as: 18600, 18601, 18602, 18603, 18604, 18605.

Add support for more Kjell & Compant door bells, such as: 50-106, 50-115, 50-116, 50-254

I would like a new method that returns a timestamp for a given device, the time when a command/value was last sent.

Requested (java syntax): public long tdTimestampLastSent(int intDeviceId); Existing (java syntax): public int tdLastSentCommand(int intDeviceId, int methodsSupported); public String tdLastSentValue(int intDeviceId);

The timestamp could be number of milliseconds since Jan 1, 1970.

Some way to update status of a device with several different remote codes. A single device may react to many signals, for example group/single. This is not reflected in TelldusCenter. Perhaps implement with pseudo-devices.

Complete protocol:  http://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf

Right now a DHCP server is required. Some brands seems to have problems leasing ip addresses to TellStick Net.

Sniff the transmitter for data/protocol and try to resend it with TellStick, then (if possible) implement as a device in the driver.

Clicking "Diff" in Trac "Description modified" leads to error: Trac detected an internal error: KeyError: 'fields'