Open ghost opened 7 years ago
Yes the transitioning state exists since ever and is only used by Sonos when going from pause/stop to playing state. When this state is used by Sonos, the binding is setting the channel to UNDEF but there is always another final state sent by Sonos that will lead to the channel being set to a non UNDEF state. All this looks good to me.
"All this looks good to me."
@lolodomo You mean the current behavior looks good to you and thus the issue should be closed?
Yes but that is only my opinion.
Do you see any value in having the Undefined intermediate state? If not, I would agree with @nanosonde that it should not be set/send, but rather be swallowed.
Transitioning state is considered as Undefined by ESH. If you prefer ignoring this state, the binding code has to be changed.
If you prefer ignoring this state, the binding code has to be changed.
That's how I understood this issue report - as a request to change the binding accordingly.
So if nobody sees any value in that event, I would vote for changing the binding.
Hi! Ok, maybe the problem is only linked to the case where both bindings (sonos and MQTT-eventbus) should work together.
The original problem that was reported in this issue is that only the aforementioned UNDEF state can be seen with MQTT on the event bus. The final states (PLAYING/STOPPED) are never transmitted over MQTT.
I was assuming that this is somehow linked to this transitional state which gets published only instead of one of the final state.
There is certainly another reason. Check your event logs and you will see that the PLAYING state is sent.
You can also check in any UI that the player state is defined.
Yes, the player state is defined in the UI and the event log also shows the correct final state. But, I have no explanation why the MQTT eventbus binding behaves this way when used with the Sonos binding.
I have setup the OH dev env to debug the problem. I have setup some breakpoints in the MQTT eventbus binding an the Sonos binding. So far I can only observe this:
It looks like a bug in the MQTT event bus. Maybe the player state is not considered by MQTT ?
I finally encountered a case where channel updates are missing leading to the channel being set only to TRANSITIONING : issue #4447 Unfortunately I am not able to reproduce it on my dev environment.
Are you running OH on a slow machine like a RPI 2 ?
I am facing the same issue. When using the Sonos App to control a speaker the state of "control" does often not change from Pause to Play but rather Pause to Undef to Play. This is causing an issue with my openhab rules configuration.
I am running openhab on a RPI3.
Line 87961: 2019-09-16 19:28:40.174 [vent.ItemStateChangedEvent] - SonosConnectWohnzimmer2_Fernbedienung changed from PAUSE to UNDEF
Line 87969: 2019-09-16 19:28:41.714 [vent.ItemStateChangedEvent] - SonosConnectWohnzimmer2_Fernbedienung changed from UNDEF to PLAY
Line 87978: 2019-09-16 19:29:14.542 [vent.ItemStateChangedEvent] - SonosConnectWohnzimmer2_Fernbedienung changed from PLAY to PAUSE
Line 87992: 2019-09-16 19:30:22.064 [vent.ItemStateChangedEvent] - SonosConnectWohnzimmer2_Fernbedienung changed from PAUSE to UNDEF
Line 87998: 2019-09-16 19:30:23.529 [vent.ItemStateChangedEvent] - SonosConnectWohnzimmer2_Fernbedienung changed from UNDEF to PLAY
Line 88042: 2019-09-16 19:31:28.001 [vent.ItemStateChangedEvent] - SonosConnectWohnzimmer2_Fernbedienung changed from PLAY to PAUSE
I was sent over from this issue concerning the Sonos binding.
The Sonos binding is causing an "Undefined" event on the MQTT eventbus topic when playing or pausing a Sonos speaker.
After some investigation I found out that this is possibly related to the state transition "TRANSITIONING" which is also sent by the player besides the states "PLAYING" and "PAUSING".
Please read my comment in the other issue.
Maybe the issue #3062 is related to this.