I am working on mnigrating from OH2 to OH3 (having long ago made the ecosytyem change from 1 to 2.
Unsurprisingly, this is proving a little painful, since much like last time, the whole way in which everything works has changed and it’s like re-learning everything from scratch.
Irrespective, as I am sure you are aware, not all bindings got potred - and I am stuck trying to manage LightwaveRF using OH3.
As a very ugly workaround, I am proxying my lightwaveRf light switches with the alexa binding - meaning I can send instructions to the Alexa binding to manage / change the state of my LightwaveRf devices (using the Alexa LightwaveRF integration)
My question is this - when using the Symantic Model GUI to trigger state updates, why are state changes from ON to OFF not firing an event to trigger a statew update?
i.e. If I hit the toggle in the symantic model GUI to change my light state to ON, it fires the event to the Alexa bnding → which in turn triggers a state change and eventually does switch my light on. The Alexa binding alwas reports my lightwaveRf lights as ‘unkown state’ sinve they do not have any feedback loop - but when I selct the toggle again to switch a light off, I would like ot to fire the off event.
If I do this in a rule, or elsewhere, it works fine. The only time nothing happens when I use the toggle in the symantic model GUI.
As you’ve correctly identified, there is a UI limitation where the switch UI widget will not work properly with Items with NULL or UNDEF states. Such are assumed to be ‘off’ so no OFF command can be sent.
You might confirm that is your issue by examining your Item state - there are are other possible causes for the same symptom.
That’s your real problem, which it would be desirable to fix. I don’t know anything about LightwaveRF.
However, openHAB includes a feature ‘autoupdate’ which essentially guesses the likely outcome of commands and updates Item state accordingly.
In your case, the ‘broken’ Alexa feedback is probably suppressing this action.
See “binding veto” here -
You may be able to circumvent this by forcing autoupdate mode.
But that won’t help if Alexa is positively setting UNDEF state. Check in your events.log what is going on with your Item, by way of commands, predictions, and state changes.
In my case, my lightwaverf switches are unable to feed back their status, so the Alexa response is driven purely by the data it receives from the lightwaverf integration. Alexa never knows the state of this device.
It’s crummy but it feels like I am going to have to create some sort of a proxy object that triggers state updates based on OH state, not on reported state from the binding.
That’s horrible
Thnks for the response though - it clarifies what I suspected was the issue.
Thanks rossko, I got this.
I did check my state and it does revert to unknown - since this is what Alexa gets back from the lightwaverf skill.
The state updates to what we would expect “ON” then reverts to unknown. For now, I am looking at creating my own widget for managing these stateless items - appreciate your help though.
I’ll test autoupdate shortly - bouncing my system at the moment.
Thanks
If I wasn’t so dumb I would have got it working sooner
Autoupdate seems to have done the trick - though I had to set autoupdate to true to get it working properly.
