Using virtual GAs (flags)

I'm using virtual GAs, ones that aren't connected to any dimmers or relays, to work as an interface between the Wiser2 and an external controller that is watching the network and also updating GAs itself. The GAs are working as flags between the two controllers.

The plan is for the external controller to switch on a GA, the Wiser2 sees that the GA has gone on, and it then sets a scene.

Similarly, something on the c-bus network, perhaps an eDLT, will switch on a GA, the external controller will see that the GA has turned on, and it will do a whole bunch of things.

This all seems to be working, but there are occasional glitches that concern me. Somewhere I'd heard that all GAs should be attached to a physical dimmer or relay unit, if this is true, then I'd have to spend £2,500 buying some 8-channel dimmers that don't have any lights attached.

What is the reality on these virtual devices, do they have to be retained on a dimmer?

 

When a Cbus device sends a message it just broadcast it on the bus. It can tell if it collides with a another message and try again, but there is no acknowledgement that it is received by all devices that are interested in the message. As a result, it is possible for messages to be missed. In general this should only occur on flaky or very busy networks. If a message is missed, devices will end up with different states for the same group address.

To correct these errors Cbus uses MMI messages. These are sent regularly (generally every 3 seconds) by output units and contain the current state of all ga's in that particular output unit. Other devices listen to these messages and update their internal states to match the output units.

In your case, since the ga's you are using do not appear in any output unit, they will not be included in any MMI message and so will not be updated if they get out of sync.

You do not need to assign you ga's to a dimmer (or relay) output channel. They just have to appear anywhere in the output unit. Generally the best place to put these are in an unused logic channel as it is rare to use a 4 logic operations. Note that you only need to select your ga in any unused logic channel. You don't need the logic to actually do anything.

That being said, you probably need to define what you mean by occasional glitches. I use lots of virtual ga's and rarely put them in output units and have no problems with them.

A common error when using ga's as flags in a switch is to set it up as a bell press and them expect logic in the wiser to always detect it. As the logic only runs every 200mS it is surprisingly easy to miss a bell press if the user presses and release the button quickly. The best way to use ga's as flags is for the source device to set it, and the target device to clear it once it has actioned the request. If you want perfect reliability, you can get the source device to monitor the ga when it sets it, and if it is not reset (by the target) in a short period of time you can repeat the command.

If you are getting lots of glitches you need to investigate your network further. Sometimes poorly written logic can be continuously sending out commands which can result in frequent errors. The Cbus diagnostic utility has a reliability test mode that is useful in these situations.

 

Thank you for this very clear and comprehensive response. The idea of using logic channels is brilliant, I have dozens of those spare. And I can see that none of my virtual devices are getting their status broadcast on the regular 3 second updates. My mouse is going to be busy for the next few hours!

My use of the flags follows best practice as you've described, the external controller will set a flag, the Wiser will pick that up and trigger a scene, as part of that scene the flag will be unset.

The glitches I get happen when, for example, the external controller sets a flag and the scene doesn't happen. It doesn't happen very often, but C-Bus stuff is so massively reliable that anything that doesn't immediately work as expected is noticeable. The most likely cause is that the unsetting of the flag gets lost somewhere on its way back to my external controller, in amongst all the traffic initiated by the scene, so the flag is remaining set, so next time the external controller tries to set it, nothing changes.

 

Cbus can use what are called concatenated commands where multiple ga's (on a given application) can be set in a single command. Scenes do this all the time. Some third party devices have been known to handle concatenated commands poorly. What is your external controller?

 

I doubt if concatenated commands can be sent by my external controller, its definitely not an off-the-shelf setup.

There is a PCI connected to a bespoke hardware interface that issues xAP messages over ethernet to a plug-in running on a Windows10 PC, that plug-in translates xAP messages into device updates that are managed by HomeSeer3. Any GA messages from C-Bus become changes to the HomeSeer devices, similarly, any changes to HomeSeer devices pass through into C-Bus2 GA changes.

Despite being such a lengthy chain of software and hardware components, it has been working really well for many years (7 or so?)

I don't know how robust this is when there is a blizzard of changes going through, but I learnt early on not to send through too many simultaneous changes from HomeSeer to C-Bus, I always do a few then pause then send some more and continue like that. If I have a lot to do, such as an all lights off, then I send a flag to the Wiser2 and it will trigger a scene.

Whilst I can manage the rate of changes going into C-Bus, I don't have much control over what comes back, and I think this is probably when I lose a flag status. But once I get everything identified on logic channels the 3-secondly updates should get everything back in sync.

 

This does assume your external controller can handle MMI messages. A lot of them don't.

 

Just been looking at the message viewer and it seems to send the first 75, then reach its limit. I have 144 GAs in use.

I think I'll consider writing something on the Wiser to slowly read through all the devices and send an ON to the ones that are ON, and an OFF to the OFF ones. That should realign everything, but I'm sure it will be more complex than that once I've thought it all through.

 

Hi Michael
Not sure why you would really need to read all you GA's and then re-issue the commands, but if it solves you problem then look at creating a few scenes with say 40 of your GA's in each one, then using thelogic command 'storescene' (see piced logic help) to record these GA levels and then trigger the said scene to re-issue the commands.
Colin

 

Thanks Wonkey, that does make it so much easier.