DALI application (0x5f) MMI messages

Simple answer to all this: You can't.

Long answer:

Firstly, DALI has no persistant state. This means you can't interrogate a thing somewhere in DALI-land and get the state of everything. You can visit every ballast / driver and get its current level, but this is very slow and tedious.

Secondly, DALI has non-deterministic group / scene / address mapping. That is, (for example), you can make dali group 1 contain short addresses 1, 2, 3. Then you can make dali group 2 contain short addresses 1, 2 (but not 3). Then you can do control by short address, or group (or scene just to add even more complexity). So to find the state of something, do you ask for the group state (oops, thats broken if I control a short address), or the short address state (but I can't get that w/o interrogating every ballast if I do control by groups or scenes).

The C-Bus / DALI gateway treats a DALI line as a big fat 64 channel dimmer. It converts C-Bus groups to DALI short addresses, and pushes the appropriate DALI messages out the other side.

The C-Bus / DALI gateway does not response to MMI requests, and can't model the DALI line(s) - because as above the way DALI works is close on orthogonal to how C-Bus works. Doubly so when there are other control devices pushing DALI control messages out which the DALI gateway *could* see and partially model.... but this just makes it far more complex and error-prone (so it does not).

C-Bus allows symmetric setup, monitoring, control, and easy interrogation. C-Bus has persistent and guaranteed consistent state information scattered through the network. DALI is essentially a stateless lump of write-only memory. Mapping C-Bus -> DALI is fairly straightforward, because you can make a 1:1 mapping. But mapping DALI -> C-Bus is very difficult because DALI allows 1:N control from single commands, and mapping N:1 back to C-Bus is damn near impossible.

The only solution if you are lucky enough to have C-Bus present is:

- Have a device on the C-Bus network which monitors the communication and builds a state model
- Have your mobile device interrogate that C-Bus connected device to get its view the universe, built from the state model.

Now, before you go "oh you are a bunch of dumb clucks for not solving this", consider that during design this single issue caused untold hours of discussion, meetings, drawing pictures on whiteboards, and suggestions of possible (sucky) solutions. It was not ignored, it was considered. Rather a lot.

The problem with sucky solutions that might work some of the time is that nobody reads all the qualifications and caveats that you need in order to say "here is something you might do, it works 15% of the time, the rest of the time stuff will happen but it will be the wrong stuff and when that happens don't complain because we warned you." What happens is that the warning is ignored, bad stuff happens, and there is much wailing and gnashing of teeth. So this then becomes "but why did you not stop me doing bad stuff", and the answer is: we did. That's why you can't do things using the DALI gateway that are bad.

 

Sounds like you have done everything right, unfortunately the reason you are not seeing any MMIs on the DALI application is because there aren't any!

There are 2 things required for an MMI to work

1) You need key input units set to that application. These are what initiate (and listen to) the MMI.

2) You need an output unit that is controlling groups on that application. IT is the output units that are the keepers of the group state.

Unfortunately for you, the DALI gateway is not an output unit (it's just a gateway to DALI), and there's no way to quickly interrogate the state of the DALI side.

There is a roundabout way to get the state using the Error Reporting feature of the DALI gateway, as the on/off state is included in the error report data, however this report takes some time to complete, so it's not really suitable for a mobile client that needs to get state quickly, and the client would also need to know the C-Bus group to DALI ballast mapping.

Nick

 

The 50 ms loop is there so that regular updates can be run.

This gives the following:

- it keeps the internal models of the C-Bus Module up-to-date (example: C-Bus ramp commands initiate a ramp, but then every unit that has an interest in that group and the running ramp run their own independent models, this requires regular timers to run updates so that the internal level model can be updated)

- it is used to form a timeout / health check for the connectivity to the C-Bus PCI or CNI. The reason here is that otherwise there is no way to know the connection is down until you come to use it. Often this is not a problem - but people like to know the connection is down, when its down (or very soon thereafter) and for a serial PCI this allows a determination of an interface failure within about 4 seconds [on a CNI, TCP will be a determining factor and a detection period of about 90 seconds should be expected].

There are also numerous other places where the regular timer ticks are used, so just turning it off *may* be problematic.

-----------

The approach you propose for trying to find state is still going to be prone to error. The reason being that the state information which is populated into MMI's (be they state MMIs that only contain on/off, or Level MMIs) comes from C-Bus output units only. Input units, eg switches, will perform reconciliation of state error, and they arbitrate amongst themselves to determine who will initiate MMIs. But input units don't have any state that can be interrogated using MMIs.

The fundamental problem you face when using the DALI gateway is that the mapping from C-Bus groups to DALI Short Addresses is done in the gateway, making "stuff" happen in DALI. But there is no C-Bus output unit which stores the levels, has the state, and populates the MMI. You can run MMI's, but there won't be anything to drop the information into the MMI for you*.

A Client/server approach using 2 devices (one permanently attached, the other mobile) WILL work, provided the fixed device watches all the network traffic and builds its own internal state model by watching the changes as they whiz by on the network. This device will still suffer the problem of finding the initial state because on power up, the groups + DALI short address + state model will all be unsynchronised - and there is no way of forcing them to become synchronised.

I might add: The Wiser product does all this, there's a reason Wiser is the way it is Wiser actually uses the C-Bus Module to build the state model.

----

* Nitpickers corner: If you have a C-Bus group, and an relay or dimmer unit which uses that group, and that group is also shared with and used in the DALI gateway, then there will be a source of information to populate the MMI. However, this is not the case which you described so it very likely does not apply.

 

1) In cbus_config.h, ensure CBUS_USE_ERROR_REPORTING_APPLICATION is defined
2) Register a handler for error reporting messages
3) Configure your DALI gateway with a trigger group/action selector to trigger error reports
4) Send the trigger message to kick off the error reports.
5) Wait for 128 error reports to trickle in

Note that in the DALI gateway, when error reporting is enabled, the ballast status is polled as a background task. This takes several minutes to complete all 128 possible ballast addresses.

When you trigger an error report, it starts sending the error reports with the most up to date value it has retireved from the DALI network. Because these two processes are asynchronous, you may not always see the result of a state change until the latest error report (for example if the state change happened just after the ballast was polled, you will not see the result until it is polled the next time).

Nick

You should then receive a

 

The DMX Gateway does actually contribute to MMIs (as does the DSI Gateway.. for the record). I guess my assertion that the DALI GAteway didn't because it was a gateway was a bit misleading

Nick

 

Ah.. good point. You will need the Error Reporting Application documenation.

You can get this here.

AS far as the parameters, you are really only interested in the System Category (to check the message is actually from a DALI Gateway), the Device ID (which tels you which DALI Gateway), and then the Error Data bytes. The protocol doco will tell you what each of these mean.

Nick

 

You can't.

Keys emit messages on either the unit primary or secondary application, depending on how the unit has been set up.

You can discover devices on the network, and the status (on/off) or level of groups.

Group status and level comes from output units (only).

All units can report their presence for determining if they exist.

You can't delve deeper than that in the programming of key units. Doing that requires the non-published commands used for commissioning.