daliserver
daliserver copied to clipboard
Not handling unknown message type 0x77
I'm writing a script that finds ballasts on a DALI network using INITIALISE / RANDOMISE / COMPARE / WITHDRAW / TERMINATE etc. as a test case for a library I'm writing. See https://github.com/sde1000/python-dali - the script in question is "find-ballasts.py".
When the COMPARE command causes several ballasts to reply YES (0xff) simultaneously, daliserver logs the message "Not handling unknown message type 0x77" and then a second later "ERROR Error sending DALI message: Receive timeout". It returns status code 255 over the network.
If I hack my script to interpret status code 255 as "YES" then the script runs as expected.
I believe message type 0x77 is the hardware indicating "response present but garbled". It would be useful to handle this and return some appropriate status code over the network.
Back when we reverse engineered the protocol, we were not sure what the 0x77 messages meant exactly. They were not relevant for basic operation anyway, so we did not pursue them further.
It might be a good idea to contact the manufacturer and ask for technical documentation. Tridonic offers some for their RS-232 based DALI interface, but not for the USB version. I don't think they would mind, as they still only offer software for Microsoft Windows.
I believe Tridonic are resellers of these devices; the original manufacturer appears to be Lunatone.
Contacting them can't hurt, but I strongly suspect I will be ignored. I haven't found a single manufacturer of DALI kit so far that gives out anything beyond a bare minimum of technical information on their products.
Further experimenting with the Tridonic software shows that the 0x77 messages are indeed "Framing error in response", which is to be expected when you issue a yes/no query to more than one device at once. These could be treated as a simple "YES" response, or the network protocol could be extended to be able to express "Framing error".
Thanks for investigating. Did you find out anything else about the message content? Or alternatively, can you send me sample packets?
I will add a "Invalid packet received" message type to the protocol, then.
I've figured out some more information about message type 0x77. It means something along the lines of "bus status". It can be received either unsolicited (packet type 0x11) or as a response to a transmission (packet type 0x12).
Here are some examples:
166 1494.055413 host 1.10.2 120400030000ff9000 Query FF90 Bcast QUERY STATUS
168 1494.073283 1.10.1 host 12730000ff90033c04 ... transmission report
170 1494.083287 1.10.1 host 127700000003003e04 Error framing error (received)
19 34.395455 1.10.1 host 117700000005ffff00 "switch to DSI mode"
21 34.887455 1.10.1 host 117700000002ffff00 "bus short" (I turned the bus power off)
9 5.045834 1.10.1 host 117700000006006100 "switch to DALI mode"
11 5.137824 1.10.1 host 11770000000404b100 "bus voltage OK"
13 127.210069 1.10.1 host 117700000005ffff00 "switch to DSI mode"
15 127.701023 1.10.1 host 117700000002ffff00 "bus short" (I turned the bus power off again)
17 135.325249 host 1.10.2 125600030000ff0000 IAP FF00 Bcast OFF
19 151.927529 host 1.10.2 125700030000ff0000 IAP FF00 Bcast OFF
21 158.951875 host 1.10.2 125830030000ff2c55 DTR0=0x55 followed by SET SYSTEM FAILURE LEVEL (DTR0) (twice)
about 12s later I turned the bus power back on
23 181.991277 1.10.1 host 117700000006006100 "switch to DALI mode"
25 182.018264 1.10.1 host 12730000ff0000e456 ... transmission report for first OFF command
27 182.028265 1.10.1 host 127100000000008a56 ... no response to first OFF command
29 182.045273 1.10.1 host 12730000ff00009257 ... transmission report for second OFF command
31 182.055257 1.10.1 host 127100000000008a57 ... no response to second OFF command
33 182.071276 1.10.1 host 12730000a355009258 ... transmission report for DTR0=0x55
35 182.097240 1.10.1 host 12730000ff2c009158 ... transmission report for first SET SYSTEM FAILURE LEVEL
37 182.124240 1.10.1 host 12730000ff2c009158 ... transmission report for second SET SYSTEM FAILURE LEVEL
39 182.127232 1.10.1 host 127700000004003858 "bus voltage OK" - note it still has the 0x58 serial number
So, if received byte 1 contains 0x77 then received byte 5 contains a status code:
- 0x02: bus short / no bus power
- 0x03: received framing error (eg. overlapping transmissions by devices)
- 0x04: bus voltage OK
- 0x05: "switch to DSI mode"
- 0x06: "switch to DALI mode"
Note that in the second half of this example, I issued the two "OFF" commands and the "SET SYSTEM FAILURE LEVEL" command while the bus power was off. The DALI USB device queued them, and returned the transmission reports (byte 1==0x73) all in one go after bus power was restored, followed by the "bus voltage OK" message with the serial number of the SET SYSTEM FAILURE LEVEL command.