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