Closed klues closed 6 years ago
with @benjaminaigner we tried to reverse engineer the serial protocol the IrTrans is using - with succes (at least for an Luminea infrared bulb) - see test file, which contains the HEX codes we sent to IrTrans using a serial console (baud 115200): IRTrans_bytestream_WORKING.txt
However I did not manage to open a serial connection to the IrTrans on Windows until now, I dont know why. It is not listed in the available COM ports.
I tried to use the same preceding sequence for the August IR controlled radio, does not work.
Bytestream (ASCII) of receiving a command has the same length & structure: "S00000000111111110000000011111111320" of August radio vs: "S00000000111101111100000000111111320" Luminea "On".
The sent prefix of the Luminea bulb is (HEX)
506e0600ffff24260138024700d100200103140000000000005e0446004a005d044a00000000000000000100
vs prefix for an August radio:
509b0600ffff2426012d024d00d5001901441300000000000067044000400062044000000000000000000100
A successful command consists of this prefix, the ASCII of the command and alternating 7d/7c at the end. The last byte seems to be some kind of counter, but it works if it is alternated (found 0x7F-0x81 as well).
Captured with wireshark, set filter to "frame.len > 66" for filtering relevant packages.
May be there is some kind of checksum hidden in prefix?
ok, thanks for your further tests! I think the prefix is some kind of timing information for the command. For the Luminea (same remote control) it seems to be the same, but for another remote control not... hmm, so this prefix is also received over the serial interface or it is not?
Interestingly, the prefix is NOT sent on receiving.
It is also interesting, that the Luminea and August remotes use the same IR codes (one button sends a command for both devices) but they have a different prefix.
here on page 6 http://www.irtrans.de/download/Docs/IRTrans%20TCP%20ASCII%20Interface_EN.pdf you can see how to learn a command using the ascii interface of irtrans server.
the result there is much longer than the codes we got at our tests, e.g.:
3A00000000000E24040000000000000000000000000000000000000000000000 0000000000000000000002573131303030303030303031313031
I guess that this code somehow also includes the prefix. So maybe we should capture the command irserver is sending to irtrans at the command "Alearn" - and the data that comes back at the next time receiving a command maybe includes more data?!
however, how did you get the prefix now if it is not sent on receiving?
this is the learned longer command for Luminea ON:
5001000000002426010238004E00D80120140B000000000000045D003F0043045C0042000000000000050100533030303030303030313131313031313131313030303030303030313131313131333230
included drivers for windows and irserver.exe
with https://github.com/asterics/AsTeRICS-Ergo/pull/143
after merging of https://github.com/asterics/AsTeRICS/pull/247 a new release can be made and this issue can be closed.
According to user evaluations done by @stefaniehoechtl the biggest challenge for users on using AsTeRICS Ergo is the installation of IrTrans. Therefore it would be great to make this process easier.
I've compiled the IrTrans Server for Windows, see https://github.com/asterics/IRTrans-Server/releases/tag/1.0.1 Additionally there is there is this folder from the installed version of IrTrans, which contails the driver for IrTrans USB for Windows: IrTrans driver.zip
I made the follwing test:
DPInstx64.exe
from the driver .zip installs the drivers for Windows without any user inputirserver.exe
from the linked release above afterwards makes IrTrans available for AsTeRICS ErgoSo in sum it would be possible to automatically start driver installation and irserver.exe from AsTeRICS Ergo and therefore make the installation process much easier for users. On Linux no driver installation is needed, but the autostart of irserver could also be automated.