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
Tellstick extended command problem
Moderator: Telldus
Re: Tellstick extended command problem
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.
Nevertheless it also seems there is another bug lurking here.. most likely an issue with signed versus unsigned data storage.
Re: Tellstick extended command problem
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.
-
- Posts: 3
- Joined: Fri Mar 17, 2023 9:45 am
Re: Tellstick extended command problem
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
Carlos
Re: Tellstick extended command problem
* 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
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.
*
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
Last edited by c0rner on Wed Nov 28, 2012 5:51 pm, edited 1 time in total.
-
- Posts: 3
- Joined: Fri Mar 17, 2023 9:45 am
Re: Tellstick extended command problem
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
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
Re: Tellstick extended command problem
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..
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..
Re: Tellstick extended command problem
Why not just use the domainsockets that goes directly into telldusd ?
Re: Tellstick extended command problem
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.Zapper wrote:Why not just use the domainsockets that goes directly into telldusd ?
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.