It is something to look into as with bridges C-Bus groups can (and often need) to be linked across them. I have found in operation on my C-Bus network they occasionally don’t stay in synch.
K
Ok cool. Thanks for the heads up. Will try run past the cbus guy.
What would be the ideal solution would be to allow your user to create groups in HA but then pass that ‘group’ information to C-Bus via C-Gate so that the ‘group’ can be triggered with one command. I am not sure if that is even possible (within C-Gate capabilities).
I use a different direct to C-Bus implementation (not via C-Gate) and so it is I think possible with that - although I’ve never tried to do it.
Another alternative (which you’re probably not going to like) is for the user to add a C-Bus Wiser unit to their system. This gives them a nice web based UI where they can (I believe) manage ‘scenes’.
Thanks @xAPPO. You mention you use a direct to CBUS implementation. Do you have any info on that? At the moment I am using CBus<->CGate<->CGateWeb<->MQTT<->HA. If there is an easier or alternative way, I’d be interested…
BTW - organised with the Client to go around this evening and do some proper testing. Hoping to isolate which integration is causing the problem and go from there.
hey @xAPPO - did some testing tonight and I think I have isolated it down to cgate/cgateweb, most likely cgateweb. I have raised as an issue with the author to see if he can help. More information here: https://github.com/the1laz/cgateweb/issues/20
Thought you might be interested and interested in any thoughts on what you think might be the problem.
Thanks.
Also - I experimented with the using groups in HA and the problem still existed turning HA groups on/off - wasn’t a Homekit thing…
The groups you need to create are on C-Bus aka ‘Scenes’ (groups as used on C-Bus refers to one endpoint like a light - confusingly) - this then allows you to send just one command to C-Gate to activate or trigger the scene (and to press just one key on a C-Bus switch to control the scene).
You didn’t mention if there are hardware C-Bus bridges installed on the network ?
The ‘direct to C-Bus’ was a solution I created that is my own own design. It is a $150/200 hardware board with a C-Bus interface, RS232/485 and Ethernet. It can connect directly onto C-Bus or, at lower cost, to a C-Bus CNI (Ethernet) or C-Bus PCI (RS232). It only supports C-Bus lighting and compatible applications and doesn’t use C-Gate at all instead directly decoding the C-Bus wire protocol. You can control and track all C-Bus groups realtime via Ethernet and it also supports a couple of HA controllers via serial links - like HomeVision and IHC. HV and xAP were my chosen HA protocols and controller at that time, hence the project. (I am a C-Bus Enabled partner).
I made up a couple of hundred units but have sold them all in dribs and drabs over the past 10 years I guess. I have no more left unfortunately and can’t economically do a re-run unless there’s 50+ (there’s about 20 takers atm). So order 30 and you’re all set to go !
Kevin
PS I think I’ve seen another C-Bus solution on here ??? If so, and if it was a cgateWeb issue, then that might work ? I may be wrong it might have been on the OH forum.
Ok cool thanks Kevin. I just called the CBUS guy and he confirmed there is some bridges but they only relate to the blinds which may or may not have issues but I am just seeing it in the lights at the moment.
He did however give me a few suggestions with how I call the commands. He suggested that I only use the levels not on/off commands. So set to 0 for off and 255 (or 100 with cgateweb) for on. So I will try that next. He also suggested that Cbus is not a high bandwidth network (which I already guessed) and that the network might just be getting confused being hit with so many commands at once. He is suggesting putting some millisecond delays between commands which I’m not sure I can do but perhaps the author of cgateweb can. Will see what he says.
I’m going to try that avenue first but if I have no success I will ask the CBus guy to setup a scene or two for me to test with as you suggest.
Thanks!
This shouldn’t be an issue. It is true C-Bus is low bandwidth and can be overwhelmed easily. But you are not sending commands to C-Bus you are sending them to C-Gate via MQTT. However MQTT can not pace changes at all.
C-Gate has an inbuilt queue and C-Bus has ‘pacing’ ‘ack’ signals that it sends back so all commands sent to C-Gate should make it to C-Bus intact and in order. Whether CGateWeb could somehow introduce a behaviour that overflows messages I am not sure. I don’t know if C-Gate has an ability to ask a client to ‘back off’ for a minute if it’s having trouble passing the commands onto C-Bus but as it’s a TCP connection it can create it’s own pacing for received data.
The issue is more likely that MQTT topics are changing but not all those changes are being passed to C-Gate. Whether this is a code issue or a buffer overflow within C-GateWeb I am not sure. MQTT will not pace reporting changes (except by inherent TCP flow control) , something must accept and queue them when presented.
PS Just to mention there are some C-Bus applications like MRA (audio) and Thermostats that generate a lot of continual C-Bus traffic which can quickly swamp a badly designed C-Bus network. Bridges are often used to segment this traffic from the lighting application , regaining bandwidth.
Hi @xAPPO - did some more testing last night and have had some progress. I changed the client’s MQTT config to optimistic mode: true and it seems to have fixed all lights going on and off with Homekit as it doesn’t rely on the dodgy response it is getting back from cgate as to whether it was on or off. However I am not certain it is a good fix and lights are still a bit off on one of the two instances of HA I am running (see my OP) so I need to do some more research on the MQTT confirm in HA to see if there are any other settings that can help fix/mask the problem.
I was wondering however, are you able to post how you have configured your MQTT/HA so that I can see if I have mine right/wrong? Would really be helpful even if it just supports what I have already in place.
Thanks for your help on this.
Sorry I also forgot to mention - as mentioned above, the CBUS guy suggested I use levels instead of state so I got the client to first up (before optimistic mode fix) to try asking SIRI to turn lights to 0% or 100% instead of on/off. He reported back that this worked except for some lights that are non-dimmable which would make sense. Not sure why that made a difference, but thought I’d pass it on.
Thanks.
All C-Bus lighting groups support a level and on/off so setting a level to 255 (100%) should make a relay go from off to on. The transition point is programmable on relays. However the behaviour for on/off and level can be awkward.
There is no definite agreement that a light at 0 must be OFF or that a light at say 60% should be on.
C-Bus does enforce off at 0 and on usually at any other value. However in my controller they are independent so I can set a light to 60% and turn it off. If I turn it on again it will be at 60% still (retained last on). In this OFF state it still reports level 60. I can also turn a light off to 0% and then still OFF but chnage level to 70% to preset the next on brightness. This suits me.
I am not sure of the ramifications of using Siri to set level on C-Bus cf on/off but I would expect relays to work too. Unless maybe of course they aren’t identified by Siri as lights in the first place.
My HA integration won’t help you as my treatment is different (I don’t use the read and write topics instead appending a /set topic) but you should ensure you always update both level and state/switch and that the level sent to MQTT write topic must be in the 0-100 range. (Not 0-255)
Hi Kevin - quick update - got the following from the author of cgateweb:
Sorry Locky, I haven’t had a chance to have a good look at this but I’m sure it won’t be too hard to solve. I didn’t really consider sending multiple commands at once when I put this together, so I’m not surprised that it’s not working. I’ll have a look this weekend.
So looking promising for a resolution. Will let you know how we go. I love the help everyone gives each other in the open source community.
In the meantime I have set the client’s lights to optimistic mode which seems to fix HA not getting the right response from cgateweb and makes Homekit work but has problems with using 2 copies of HA so not a proper fix.
Thanks!
Really that shouldn’t work. Optimistic sets the device to what you request rather than what the device reports back. However when (and if) MQTT reports the state change it will alter the device state again. This is often seen as you turn a device ON and the switch changes but about 3 seconds later it turns off again in the UI. ( assuming the command didn’t work or the state is not being updated on MQTT correctly).
The authors help sounds like it might provide a solution…
Yes that’s is how I understood optimistic mode too - really for dumb, stateless devices. But it works, so all I can think is that the response is coming back to HA before the optimistic does its thing? Dunno. But yes, hopefully the new code sorts it out good!
Thanks for your help Kevin.
How did this go in the end? I have c-bus and have installed home assistant though mqtt and have had the lights unresponsive to commands sometimes.
Good I think. Been a long time since I did this. My client has been using for a few years without issue so the changes the author of cgateweb made seems to have fixed it.
Which step is failing? Mine has worked reliably for years although I don’t address huge numbers of lights all at once, or if I do I use a scene trigger.
Just FYI -
I have made a major refactor on the cgateweb implemention, and published the solution as 3 containers to isloate the parts.
Specifically for the C-Bus to MQTT setup, this now uses the C-Bus project file, to ensure discover of Dimmer, Relay and Phantom groups, and I also enabled Trigger Application with MQTT Events entity!