If you are developing anything using Telldus Live!-API please read this.

We are doing two API changes so that we are following standars correctly.
Issue 1: Ticket #244, DotNetOpenAuth incompatible with oauth-php,

When requesting a request token from our servers you get a response back with the parameter oauth_callback_confirmed set to "1". According to the RFC this should be "true" instead.

Issue 2: Ticket #269, Return content type as "application/json" when it should

All API calls that returns json data should have the content type header set to "application/json". This is currently not the case.

You need to check that your applications are compatible with these changes (they probably are already, if not the application may stop working completely). If not, and you need more time to implement fixes, let us know and we'll postpone the API-changes.

If no issues have been raised April 16th, we will implement these changes system wide.

Edit: These changes have now been implemented.

UPDATE: We are now evaluating a solution that seems to work. Thanks for you interest.

We are constantly trying to add new protocols to allow TellStick Net to control more devices. Sometimes it's a bit harder to figure out how a protocol works. That is the case with this protocol. We have been supporting blinds from Hasta for a while now (recently we improved the control part quite a bit, if you have problems where it only works every other time, let us know and you can try our beta firmware), but the motors that are currently sold have a different way of communication.

Even if you don't use blinds yourself you should help us solve it anyway, so we'll be able to focus on other stuff, like adding other cool functions for TellStick! And if helping mankind in this way isn't reward enough for you, we're also offering a TellStick Net AND a Hasta motor to the first person that email us the correct, working solution! Send your answer to sp@… (log in to see whole address). We are now evaluating a solution that seems to be correct.

If this is successful we'll probably post more protocols here. It's often rather easy for us to scan them, but we're not always very good at figuring out checksums, and we think that some of you are really good at this stuff. For the rest of you, it might be interesting to see how a protocol may work.

This is what we know: A signal consists of 40 bits. The first 16 bits are the house code/ID. Bits 17-20 are the Unit code, and the next 4 bits contains information about what function should be performed. Next comes 8 bits that seems to always be the same. After that comes the last 8 bits that contains the checksum and are dependent of the rest of the data. It's how this checksum is calculated that we need help with.

If you need more data, let us know. Also note, there MAY be some scanning error, but we've really tried to avoid that.

0000000000000000 1000 0011 10000000 11111100 		Hasta, unit 1, Down, ID: 0000
0000000010000000 1000 0011 10000000 01111100 		Hasta, unit 1, Down, ID: 0001
0000000001000000 1000 0011 10000000 10111100 		Hasta, unit 1, Down, ID: 0002
0000000011000000 1000 0011 10000000 00111100 		Hasta, unit 1, Down, ID: 0003
0000000000100000 1000 0011 10000000 11011100 		Hasta, unit 1, Down, ID: 0004
0000000011111111 1000 0011 10000000 00000010 		Hasta, unit 1, Down, ID: 00FF

1000000000000000 1000 0011 10000000 01111100 		Hasta, unit 1, Down, ID: 0100
1111111100000000 1000 0011 10000000 00000010 		Hasta, unit 1, Down, ID: FF00
1111111111111111 1000 0011 10000000 10000010 		Hasta, unit 1, Down, ID: FFFF

0000000000000000 0000 0011 10000000 00000010 		Hasta, unit 0 (ALL), Down, ID: 0000
0000000000000000 1000 0011 10000000 11111100 		Hasta, unit 1, Down, ID: 0000
0000000000000000 0100 0011 10000000 01111100 		Hasta, unit 2, Down, ID: 0000
0000000000000000 1100 0011 10000000 10111100 		Hasta, unit 3, Down, ID: 0000
0000000000000000 0010 0011 10000000 00111100 		Hasta, unit 4, Down, ID: 0000

0000000000000000 1111 0011 10000000 10001100 		Hasta, unit 15, Down, ID: 0000

1111111111111111 1111 0011 10000000 11001100 		Hasta, unit 15, Down, ID: FFFF
1111111111111111 1111 1000 10000000 11000111 		Hasta, unit 15, Up, ID: FFFF
1111111111111111 1111 1010 10000000 11000101 		Hasta, unit 15, Stop, ID: FFFF
1111111111111111 1111 0010 10000000 11001101 		Hasta, unit 15, Confirm, ID: FFFF

0101010101010101 0000 0011 10000000 00110111 		AA AA All Down
0101010101010101 1000 0011 10000000 11010111 		AA AA 1 Down
0101010101010101 0100 0011 10000000 01010111 		AA AA 2 Down
0101010101010101 1100 0011 10000000 10010111 		AA AA 3 Down
0101010101010101 0010 0011 10000000 00010111 		AA AA 4 Down
0101010101010101 1010 0011 10000000 11100111 		AA AA 5 Down
0101010101010101 0110 0011 10000000 01100111 		AA AA 6 Down
0101010101010101 1110 0011 10000000 10100111 		AA AA 7 Down
0101010101010101 0111 0011 10000000 01111011 		AA AA 14 Down
0101010101010101 1111 0011 10000000 10111011 		AA AA 15 Down

Random scanned remotes:
0011001010010001 1000 1010 10000000 01011011		Unit 1, Stop
0011001010010001 1000 0011 10000000 01010110		Unit 1, Up
0011001010010001 1000 1000 10000000 01011000		Unit 1, Down
0011001010010001 1000 0010 10000000 01010111		Unit 1, Confirm
0011001010010001 1000 0100 10000000 01010000		Unit 1, Limit
0011001010010001 0100 1010 10000000 10011011		Unit 2, Stop
0011001010010001 0100 0011 10000000 10010110		Unit 2, Up
0011001010010001 0100 1000 10000000 10011000		Unit 2, Down
0011001010010001 1100 1010 10000000 00011011		Unit 3, Stop
0011001010010001 0010 1010 10000000 11101011		Unit 4, Stop
0011001010010001 0001 1010 10000000 11001011		Unit 8, Stop
0011001010010001 1111 1010 10000000 00110011		Unit 0 (All), Stop

1001101111110001 1111 1010 10000000 10011100		Remote 2, Unit 0 (All), Stop
1001101111110001 1000 1010 10000000 11100010		Remote 2, Unit 1, Stop
1001101111110001 1000 0010 10000000 11101010		Remote 2, Unit 1, Confirm