The third party developer Jonas Karlsson has just uploaded the first public version of his application Gleam.

Gleam is an application for Windows Phone 7.5 that connects to your Telldus Live! account. In this first release the application includes functionality to

• Turn on/off/dim devices
• Read sensor data
• Logging of sensor data. Displayed in charts in predefined time periods (24h, Week, Month). Maximum 30 days.
• Average temperature of the sensor for the selected time period.
• Pin sensors to start. Live tiles with sensor data. Updated every half an hour.
• Rename devices/sensors
• Ignore sensors
• Reset sensordata

Gleam will also soon be available as a Windows Phone 8 app and Windows 8 app.

Get it from ​Windows Marketplace

If you have tried to script tasks for TellStick and TellStick Duo you know it is very easy using tdtool. But tdtool is limited to only transmitting signals. What if you want to react on incoming signals from TellStick Duo?

If you want to script execution on incoming signals you either need to script in a third party application such as NexaHome or EventGhost or you need to write your own deamon and listen for callback. Both variants has it quirks. For example you need Windows for EventGhost.

What do you do if you have an headless Linux computer? Or you just don't want the complicated setup with callbacks?

From version 2.1.2 we have added the possibility to add a script to a predefined directory. Any executable script found in those folders will be executed and the parameters are sent as environmental variables. Let's first show an example. Create the file /usr/local/share/telldus/scripts/sensorevent/myscript.sh with the following content and make it executable.

#!/bin/bash
if [ "${DATATYPE}" -eq 1 ]; then
        notify-send --expire-time 3000 "Temperature ${VALUE}°C"
fi

When a sensor is detected the currently temperature will be shown as a popup in my KDE environment.

All callbacks from the C API are available.

/usr/local/share/telldus/scripts/deviceevent/
Environmental variables: DEVICEID, METHOD, METHODDATA
C API equivalent: TDDeviceEvent

/usr/local/share/telldus/scripts/devicechangeevent/
Environmental variables: DEVICEID, CHANGEEVENT, CHANGETYPE
C API equivalent: TDDeviceChangeEvent

/usr/local/share/telldus/scripts/rawdeviceevent/
Environmental variables: RAWDATA, CONTROLLERID
C API equivalent: TDRawDeviceEvent

/usr/local/share/telldus/scripts/sensorevent/
Environmental variables: PROTOCOL, MODEL, SENSORID, DATATYPE, VALUE, TIMESTAMP
C API equivalent: TDSensorEvent

/usr/local/share/telldus/scripts/controllerevent/
Environmental variables: CONTROLLERID, CHANGEEVENT, CHANGETYPE, VALUE
C API equivalent: TDControllerEvent

After adding or removing a script you need to restart telldusd.

For now, this is a Linux only feature. Patches are welcome for other platforms.

A while ago we released the source code for TellStick Net. We have now also released it for TellStick Duo.

It is released from our servers as well as GitHub and Gitorious.
TellStick Duo
​https://github.com/telldus/tellstick-duo
​https://gitorious.org/telldus/tellstick-duo

For installation instructions see the README

For more than a week now we have been having big problems with delays during peak load. This was something that happened very suddenly and didn't follow the predicted capacity needs curves. Most of you will have noticed this when trying to control devices and have had to wait for several seconds, sometimes for up to a minute. Worse than that, on a few occasions the whole database system failed to respond to new requests and had to be restarted manually.

During last week, several attempts were made to stabilize the situation and more servers were added. It became evident this weekend that it didn't help.

One big problem was found today in the database connections between our servers. The servers were automatically updated with a security fix a while ago. This fix had a side effect which led to that a simple question to the database could take up to ten seconds. We currently send 140 000 000 sensor values to the database each month, not including duplicates. When each of these values take a couple of seconds to parse it starts to clog up the servers fast!

Our servers are queue based. When all available threads are busy inserting sensor values, other tasks are quickly piling up in the queue, especially during high load.

Another effect is that if a TellStick Net does not acknowledged back to the server that a message has been received within two seconds, the server tries to send the message again. This adds even more tasks to the queue, and it can be recognized by that TellStick Net lights up and sends a message more than once, even if only one command has been sent to it. This may be a problem with for example blinds that starts and stops with the same command.

We are implementing measures to make sure commands will execute in a normal fashion again, even during high load, and are currently rolling out the first series of fixes. In the next couple of days we will roll out even more updates to make sure the service is smoother than before.

The issue with the database which requires a manual restart of them is also triggered by this high load, but is a different problem. During the weekend we planned a fix that has been implemented this morning which should solve this.

We are truly sorry for all trouble this may have caused you.