Send Extended --raw

[ace]

In my tellstick.conf i have a device added and it works by using
tdtool -n 1
and -f

So far so good

But Im trying to do this now thrue the send extended S/T

So for ex i have House 1629211 (selflearning-nexa) unit 1
Thru checking in
http://developer.telldus.com/doxygen/TellStick.html and then
http://developer.telldus.com/browser/te ... olNexa.cpp | getStringSelflearningForCode()
Converted this function to php and it gives me about this for "on"

Code: Select all

100110101000101010001010100010101000101010001000101010001010101010001010100010101000100010101000101010101000100010101000101010001010101010001010100010101000101010001010100010001010100010101010100010001010100010101010100010001010101010001010100010101000100010101000

Im then converting this to hex.

Code: Select all

\x54\x7F\xFF\x18\x01\x00\x9A\x8A\x8A\x8A\x8A\x88\xA8\xAA\x8A\x8A\x88\xA8\xAA\x88\xA8\xA8\xAA\x8A\x8A\x8A\x8A\x88\xA8\xAA\x88\xA8\xAA\x88\xAA\x8A\x8A\x88\xA8\x2B

And Trying to send it with

Code: Select all

echo -ne '\x54\x7F\xFF\x18\x01\x00\x9A\x8A\x8A\x8A\x8A\x88\xA8\xAA\x8A\x8A\x88\xA8\xAA\x88\xA8\xA8\xAA\x8A\x8A\x8A\x8A\x88\xA8\xAA\x88\xA8\xAA\x88\xAA\x8A\x8A\x88\xA8\x2B' | tdtool --raw -

Sometimes i get success and some times i just get "Sending raw command: An error occurred while communicating with TellStick"

But nothing happens.

i have also in desp tried

Code: Select all

S$k$k$k$k$k$k$k$k$k$k$kk$$kk$$k$k$k$k$k$k$kk$$kk$$k$k$kk$$kk$$kk$$k$k$k$k$k$k$k$k$k$k$kk$$kk$$k$k$kk$$kk$$k$k$kk$$k$k$k$k$k$k$kk$+

where the binary parts are converted to the codeswith simple send way.

Also tried to generate and use these

Code: Select all

['S'][24][255][24][127][24][127]['+'] | [S][132][154][138][136][168][170][+]

and sending that but nothing seems to work.
And i tried to create and send it thru text

Code: Select all

Tÿ������¨ª���¨ª�¨¨ª�����¨ª�¨ª�ª���¨+

no idea.. just trying it all

Running Tellstick Duo and RPI.

What is the best way to send to selflearning units using raw..

Would love some help on this.
//MP

[rogerj]

Hi,

I'm trying to do the same thing, please refer to my other post:

https://www.telldus.com/forum/viewtopic.php?f=11&t=5937

This post includes an attempt to a Python implementation of a Raw string generator, and I believe the strings it generates are correct. When I send them using either Python/Tellcore send_raw_command or tdtool --raw, neither works.

Any help is appreciated, and consider my post above as a (hopefully) step towards a solution.

Regards,
Roger

[plastbox]

Just wanted to lend a voice to this issue. I cannot fathom why I need the tellstick.conf file when..
- ..the rawdeviceevent manages to give me decoded data about devices when they aren't registred.
- ..there is (according to documentation) a couple of ways to send raw commands to unconfigured devices by specifying timings and such manually.

All we're asking is for the functionality in the Protocol-classes to be made available.

An example of data from a button press on a Nexa remote is:

Code: Select all

class:command;protocol:arctech;model:selflearning;house:15402826;unit:11;group:0;method:turnon;

This string contains all the data we need to add to tellstick.conf and thus all the data which is available to the telldus service when you call tdTurnOn(id). Logically, then, sending an RF-packet based on the above data without adding anything to some config file and restarting a service is possible.

Pretty, pretty please?

Honestly, I'm a bit disappointed. You guys had such an awesome product. Then, delays. More delays. Delays upon delays. When I finally got my hands on a Tellstick Duo and started programming against it, I noticed that not only was the default antenna rather less than awesome, the antenna connector is the wrong type/gender for connecting pretty much all other 433 MHz antennas out there. I fixed it though, buying extra antennas, hacking female-female "genderchangers", sharing info with people online.

As lines of code were written, it dawned on me that you fell between two chairs as one might say; Your documentation and tone when replying to interested developers in the forum are lackluster at best, and your user software is far to shallow and simple (not to be confused with easy, which it isn't) to cater to the average consumer. Thus, in not providing developers with technical data you deprive yourselves of our business and of the improvements we could bring to your software, which could help you make a product that would actually... you know, appeal to a freaggin' shitload of people.