Understood. I realise you are developing, and it’s not my decision at all, but new Item types (and probably new state type) at this stage of the OH2 game are unlikely. Certainly something to think about for OH3.
I’ve made my suggestion to “get it working” for OH2 - separate binary channels for the switch proper and for the manual indication, plus for convenience a third channel to indicate a rejected command. There are other ways of course, the clonkiest is just to map to a 4-way number.
For OH3 some kind of read-only property for whatever an Item3 looks like seems attractive at first look - for a simple example, a temperature sensor.
On the other hand - assuming the Item-channel-binding model survives - this is really a property of the channel, not the Item. The Item may be linked (or using profile) to other channels that are still r/w.
I have no brilliant idea - it’s tricky, not just about read-only channel/Item, but also managing what happens if you do try a command (which is not unreasonable if the damn thing changes)
I had to do the exact same thing for cameras that have two controls for the InfraLED lights in them. I choose to handle it this way…
If you switch AUTO to on it sets the state of the manual controls to UNDEF.
If you move the manual controls, they set the state of the AUTO switch to OFF.
This way it makes using the controls in rules more predictable and you only need to send the command for what you desire and you don’t need to check is a control is locked out before trying to move it.
I personally would have preferred a three way switch but some brands of cameras need different controls and having the two separate switches was more flexible and re-useable between different brands of cameras.
Depends on what you mean as ‘a bug’ - I believe it’s a design bug and not a programming bug. The dynamic state provider has no listener or notification API that will allow the system to know about a change. The design is more akin to a map without a listener - you can make changes to the map all you want but those changes are only propagated when something retrieves them. The dynamicstateprovider is the same way - you can make changes all you want but those changes don’t become ‘visible’ until something pulls it (like reloading the paperui).
This is a tricky one in OH. Usually, the “auto” mode isn’t implemented by the device but by OH using Rules. Only a minority of commercial home automation devices support an “auto” mode, and when they do support an “auto” mode that does not stop the user from overriding the auto mode and turning the light on or off manually. It may be very common in building automation but it is not very common in home automation. I suppose in home automation we don’t have to worry about random people changing things you don’t want changed. In home automation, usually the manual actions by the humans will override any auto mode.
I don’t really have anything to suggest beyond the ideas that rossko57 presented. I agree, for OH 2 a new Item type is probably not going to be an option. I also agree that this is something to propose for OH 3.
Unfortunately, I think to get the desired behavior and interaction between the two Switches will largely be an exercise left to the user following rossko57’s example.
I came across the same problem. I have to reload Paper UI to show the new values. Is there a “workaround” to solve this? Maybe send another refresh command or so?
