Tellstick extended command problem

[karloxloma]

Hello:

I'm trying to configure the Tellstick classic device to work with the D-IO family of products. As far as i know this products are manufactured by Chacon (Belgium)

While I'm trying to send this extended command:

echo -e "T \x01\x6D\x16\x7F\x26\x47\x32\x73\x27\x32\x73\x27\x32\x73\x27\x27\x32\x73\x32\x72\x73\x32\x72\x73\x32\x72\x73\x27\x32\x73\x27\x32\x73\x32\x72\x73\x27\x32\x73\x27\x32\x73\x32\x73\x27\x32\x72\x73\x27\x33\x27\x32\x72\x73+" | tdtool --raw -

The field of "number of pulses" in the previous command is "\x7F" and with this value (Curiously = 127) everythigs is sent out OK.

If I try to increase (As needed) this field with grater values (Example "\xC8" = 200 in Dec) the packets are not well sent. I´ve realized because I´ve recording the packets with a scope

Is there a bug or a limit in this field?. The thing is that, whenever I use values greater than [127] in Decimal in every field of the packet, I experience problems of the pulses not well formed.

Thanks in advance

Carlos

[c0rner]

Seems to me you are missing a pulse index in the extended command. It should be 'T',a,b,c,d,e where a-d is a pulse width and e is pulse count. 0x7F is set to pulse width index 4 in your command.

Nevertheless it also seems there is another bug lurking here.. most likely an issue with signed versus unsigned data storage.

[Zaman]

The extra space between T and \x01 will be interpreted as the first pulse width (space = \x32), \x7F will therefore be interpreted as the size of the message.

[karloxloma]

Yes, that's right. There is an space character that is the first "pulse width". It has to be a bug in the code. Everything above \x7F everywhere in the packets doesn't work.

Carlos

[c0rner]

* EDITED *

Well spotted! I missed that space character. As I doubt the bug is in the device itself I took a quick look at tdtool and it is completely broken in this regard.

* You can only send raw commands that are 100 bytes or less. Probably not relevant as a extended command can never be more than 70 bytes. It might however be a problem if the end-of-command '+' character is truncated.
http://developer.telldus.com/browser/te ... n.cpp#L375

* If your extended command contains a '0' byte, which they can do, it will get truncated
http://developer.telldus.com/browser/te ... .cpp#L1048


If you want to try your command out take a look at my project sticktools which has a working daemon with direct socket communication with your stick.
https://gitorious.org/sticktools

[karloxloma]

Thanks!

Downloaded and trying:

Scanning usb devices ..
Discovered 1 usb device(s)
Opening TellStick [1781:0c30:A900I8B0]
S$k$k$k$k$k$k$k$k$k$k$k$k$k$k$k$k$k$k$kk$$kk$$kk$$}+
S$k$k$k$k$k$k$k$k$k$k$k$k$k$k$k$k$k$k$kk$$kk$$kk$$}+
S$k$k$k$k$k$k$k$k$k$k$k$k$k$k$k$k$k$k$kk$$kk$$kk$$}+
^CShutting down..

No packet sent!

How is the procedure to send the packets?

Sorry for the inconvenience!

Carlos

[c0rner]

No problem, I understand the documentation is lacking here. The daemon itself will open a unix stream socket in '/var/tmp/derpstick.sock'. This is where you should direct our message, preferably using 'nc' (netcat).

Example.
$ echo "my_tellstick_command" | nc -U /var/tmp/derpstick.sock

If you want to "spy" on the messages sent by the tellstick(s) you could run 'nc -U /var/tmp/derpstick.sock' in a separate terminal, there is no limit on the number of connected clients.

Remember that this is raw communication so you will not get pretty-print messages back from the device.

Anyway, if you get your message working at least we know the bug most likely is in telldus-core which is good I suppose..

[Zapper]

Why not just use the domainsockets that goes directly into telldusd ?

[c0rner]

Why not just use the domainsockets that goes directly into telldusd ?

Not sure if this was directed at me but.. anyway without getting technical I have my reasons. To be fair I had initially intended to skip using libftdi and use libusb directly to get rid of extra dependencies, for now it's ok though.

Also, I do not like the use of threads in telldus-core. I suppose with a shared code-base windows/linux it might make sense but I wouldn't really know.