Additional information about commands
MarcG046 opened this issue · comments
(creating an issue, because I do not another way to communicate.)
Thanks for the information and the code on your page.
I have also been trying to decode the communications between the app and the Timebox.
Below some of my findings that might be interesting.
command structure
- After removal of the 0x01 head and 0x02 tail and checksum and after unmasking, the bare command remains.
- All commands (both to and from the Timebox) start with the command length, coded in two bytes, LSB first. For example, in the command to view the clock: 04 00 45 00, The initial bytes 04 00 indicate the command length (4)
- The command length is followed by one byte indicating the actual command (45, switch view in the example)
- The remainder of the command depends on the main command (00=clock in the example) and sometimes has optional extensions (such as specifying the color of the clock)
- The responses from the Timebox have a similar structure. They start with the two byte command length. The third byte has as far as I have observed always the value 0x04. The fourth byte is the command number. The fifth byte seems always 0x55, command dependent data follows after the fifth byte
- Responses are typically returned after commands to the Timebox with the same command, followed by 55, possibly followed by additional information. For instance, when some information was requested from the Timebox such as the current radio frequency. Or without additional information as an acknowledgement.
- The response to a malformed command is a negative acknowledgement of the form XX AA, where XX is the command number that was erroneous.
- The initial communication from the Timebox does not follow the usual structure. It is always 00 05 48 45 4C 4C 4F 00 (which spells 'HELLO')
command list
Some of the known commands:
- 0x05 Turn radio on/off
Followed by 0x00 = off, or 0x01 = on. - 0x08 Set volume
Followed by the volume between 0x00 and 0x10. - 0x09 Get current volume
- 0x0a Set mute state
Followed by 0x00 = mute, or 0x01 = unmute. - 0x0b Get mute state
- 0x18 Set date and time
Followed by year (last two digits), year (first two digits), month, day, hours, minutes, seconds, and another number hundredths? - 0x44 Set static image
- 0x45 Set view
- 0x49 Set image in an animation
- 0x59 Get temperature
- 0x60 Get current radio frequency
Returns two bytes XX YY, which represent the frequency YX.X MHz, for instance, 0x03 0x0a represents 100.3Mhz. - 0x61 Set radio frequency
Uses the same encoding of the frequency
Hi,
thank you very much for the Information, this definitly saves some time :) I'll implement this as soon as possible !
Fell free to fork and contribute, a documentation of the "protocol" would be neat for instance but of course also code ;).
MarcG046, thanks for your protocol documentation.
I tried to send "01 05 00 45 00 03 04 4B 00 02" from a BT terminal and I received the response "01 AA AA 02". What have I done wrong?
Sorry, it was my Android app. I tried to send the message with another app. It works perfectly :-)
Thanks for your great findings. Please keep us posted.
No problem!
Hello,
could you explain how to send raw data through command line ?
Here are some videos using an Android phone:
https://www.youtube.com/watch?v=AxLrxUsjFd8&index=4&list=PLq47UUwc4xVlnbMmUfIOsWvHgIruN_hCf&t=0s
Thanks a lot for your link.
I've made a fork to be able to set the time.
@vosmont
I adapted your changes and put it as settime command into the cli. The date can be set by giving any datestring parseable by dateutil.parse or "now" for the current local system time. Thx.
You can send raw commands using ./timebox.py raw "hexstring" the latest commit fixed a bug with this command
Thanks a lot ! It works very well and the debug mode is much better.
I had to install "python-dateutil" and not "dateutil"