Adding as a seperate answer because the new question is different from the original:
Your Manchester decoding is correct but the bit order is b8-b7 etc to b0 so you have the bit decoding backwards. The set bits are b2 = arc power ON and b4 = Fade is running. These make sense as you have sent broadcast DAPC to level 0xA0 and have set a long fade time (5.6 seconds.
There are multiple errors in your command listing
- msg 5 0xA370 would store 0x70 in DTR, presume you mean 0xA307
- msg 8 0x072E stores DTR as fade time in gear with short address 3. DTR 7 means fade time is 5.6 seconds. If you want 16s, DTR should be 10 = 0x0A.
- msg 3 & 4 & 10 Intialise and Terminate are only needed for the programming the short address commands (the randomise and binary search), not for setting configuration values like fade time and group addresses.
- msg 12 queries status of gear at short address 3.
I'd get rid of the extra messages, have one gear on the bus, use broadcast messages and command 146 so you don't even have to interpret bits, it's either responding or not. Frankly, the number of errors made in your amended question doesn't give me confidence in your code. However, since the gear is reporting to be on, a missing lamp should give you a lamp fail. It doesn't matter when the lamp was removed. There are many electronics causes for lamp fail to be reported, depending on the lamp technology. For fluorescent lamps it is not just current from one end to the other, it can be broken heater wires at one end or failure to start up after a defined strike period, or some other reason found when monitoring the currents and voltages of the tube.
Edit: now that the question is specifically about LEDs, IEC6236-207 is applicable.
Command 240 Query Features tells you if the gear supports such things as open circuit detection, load decrease detection, thermal shut down, current protection etc. If your gear tells you it doesn't detect open circuit or detection of load decrease (bits 1 and 2) then you are not going to get lamp fail detection from this gear. But if it does, you could determine which type of lamp failure had occurred with Command 251, Query Failure Status which responds with bit 1 for open circuit and bit 2 for load decrease.
Note that commands above 236 are Application Exended Query Commands which mean they need preceeding by Command 272 Enable Device Type with data 6 (for LEDs).
The response to Command 146 Query Lamp failure, and bit 1 in the response to Command 144 Query Status are the result of an OR operation on the bits 0 to 4 in the Failure Status reported in Command 241 Query Failure Status.
In summary, I think this particular gear does not detect lamp failure as an open circuit condition, and it probably doesn't detect lamp failure as other conditions either; you're query is correct but just not supported by the gear.
There is no "work around" for the case of multiple responses to query, you just have to handle all possible outcomes. DALI is designed to allow for collisions which can occur when multiple gear respond to the same query, so you have to handle this in your master software. The slaves must not attempt to avoid collisions with each other - just wait the required time after the query and respond (unless your response is a NO, which is No Response).
There are various cases you have to handle in master software when you expect a response:
No response within the timeout period. All gear that were addressed
have answered NO or were not powered up.
A collision occurs when multiple responses overlap, usually resulting
in bit timing errors. When you only have 2 or 3 gear responding, the
usual case is that the low bits overlap and you end with shortened
high bits, significantly less than the minimum pulse time.
It is possible but rare to have a multiple gear respond with the same
data at exactly the same time and not have any bit timing errors. In
this case you would not know the difference between the response
being from one gear or several. Maybe you can design the system so that you don't care.
It is also possible but rare to have multiple responses align so that
no bit timing errors occur but the response frame is longer than 8 bits. Some gear actually do this by design if they are one hardware unit with several logical short addresses, but the Edition 2 requirement is for this type of design to respond in this case with an extended length low pulse. You should treat either of these as a collision since it is also an invalid frame in terms of what is allowable as a valid response.
As a gear designer, you are encouraged to use the some randomness inside the response timing window so that the rare cases occur as rarely as possible. It has been clarified in Edition 2 that you must not use collision avoidance for the response.
As a control device designer, you need to choose your queries and addressing modes carefully so that you can cope with what the responses might be. For example, if you require the QUERY STATUS bits from several gear, you would query each using its (previously uniquely allocated) short address in turn, rather than using broadcast or group. Alternatively, if you only want to know lamp failure status, a broadcast QUERY LAMP FAIL has the advantage that only gear whose lamp has failed will reply at all, so you might be able to design your logic to deal with a single YES or a collision since that tells you that at least one lamp has failed.
Best Answer
After randomising the ballasts, the controller searches for the ballast with the lowest random number. It does this by issuing search address commands which contain the address that it is looking for, and compare commands which are queries, which get replies from all the ballasts that have that search address or lower as their random address.
Once the controller gets no replies, it backtracks one step to check the one ballast with that random address, then it assigns it a short address using a special program command which only takes effect in the ballast whose random address equals the search address. (This is technically called the "selected" state). Then the controller tells that ballast to withdraw from the process so it doesn't respond to further compares this time round, and the search can continue for the next highest ballast.
The standards don't actually dictate that binary search is the algorithm used, but it is assumed that this the best method. Note that some people use the term "long address" but this is not the correct name, there is only the random address and the search address (the current value guessed by the controller), and that the random address is not really an address mode of the commands (which are too short to contain it anyway). There is only 267 Program Short Address and 269 Query Short address commands that use the random/search address as the defining factor as to whether the command applies to them, and these are only valid between Initialise and Terminate.
There are many small details to this process which I have omitted for simpilicity, like dealing with duplicate random addresses, but this gives you the general idea.
Once the controller has identified one ballast by search address, it is free to chose a short address. Some controllers do this automatically, others allow the user to enter the number they would like to use. It is usual at this point to identify which ballast has been found by means of flashing the lamps, using the short address.