Not handling unknown message type 0x77

[sde1000]

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.

[onitake]

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.

[sde1000]

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.

[sde1000]

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".

[onitake]

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.

[sde1000]

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.