I’m not sure I can do that (easily) - it’s a matter of ordering. The channels are detected, then the bulb is initialised. I don’t think I can change the channel configuration (ie veto) after it has been created.
I might implement my own update system - if there is no update from the bulb after “x” seconds following a command, and assuming the command itself is acked, then do an update anyway.
This idea (I think) is the best of both worlds. There’s no “auto update” rubbish - the binding knows if the channel is updated, and also if the command was acked by the device, so I think this is quite a solid approach.
Thinking about this statement some more - I wonder if it is really correct? Maybe this issue was simply masked by the auto update, and when this was changed to veto (a month or two ago) it possibly exposed this issue? What do you think?
Give me a week or two and then let’s see what we can do. I’ve got stuff I need to finish off before I spend too much time looking at this, but I already have a PR coded that can easily be extended to provide this functionality. The PR currently monitors responses from devices, and if the response is timeout it sets the device to OFFLINE. I’ve just had a look at this and can extend this (hopefully easily!) to wait for a few seconds and if there’s no report, set the state. I think this gives a pretty solid grounding for providing this feedback based directly on the device response.
It would certainly be interesting to know if this is true or not. I honestly can’t see why it would be any different now, but who knows… My guess is it’s one of those things - you don’t see the error when you don’t think there’s anything wrong as you’re just not looking for it
I will Thanks. I just need to get clear of some of these other issues I’m working on relating to larger networks, and then we can take a look at this one again…
Thanks. I just need to get clear of some of these other issues I’m working on relating to larger networks, and then we can take a look at this one again…