You should be able to remove the other binding and then add this to your addons folder as a drop-in replacement. It only fixes the overwriting of group-membership.
It does not change functionality with regards to the master of a group. @airbone42 it would be great if you could check whether the answer of @Wire82 helps for your use-case.
@Wire82 would I break a use-case of you by making two groups distinct if they have a different master?
Two other suggestion from my side are :
1 to create a rule-action for groups, which would just call set_group with some member ids in a specific order.
2 to allow duplicate groups with the same hash to co-exist respecting the order of members, the only draw-back is they will then all be marked ONLINE.
Would one (especially the last one) work for both @Wire82 and @airbone42?
I cannot get the binding to work when I drop it in the addons folder. Are there any configuration settings I need to change or enable to get bindings in the addons folder to work?
@martinvw First of all thanks a lot for your continuous effort in building this. Actually it wouldn’t solve all my issues. The latest issue that I discovered is that I also couldn’t find a way to just remove one device from a group. If I switch of a group it’s totally ungrouped, but there are several cases when I just want to remove one device.
Right that could work, I was still thinking in the old way it was handled that the smaller group is already turned on due to the fact that it’s speakers are part of the bigger group. My fault
I was able to get the missing dependancies installed via the console, and I can confirm that the test-jar does fix the group-membership overwriting issue. Thank you for providing it. It does appear that groups are now mutually exclusive, even if they have the same GID. This is very helpful for my case. Thank you for the support.
As I perform more testing, I notice that although I define a group as (1,2,3), where 1 is the master, when I turn the group on in PaperUI, it does not always honor 1 as the master. Now I’m getting (3,2,1). This is counter to what @Wire82 described in his earlier post.
How does the OFFLINE detection work? I have multiple Denon HEOS devices at home and they are randomly marked ONLINE or OFFLINE - regardless of their actual state.
Specifically: I have a HEOS 7 setup as the HEOS Bridge. Through it, I have multiple players and groups available. One of them is a HEOS 3, which is currently listed as OFFLINE - although the Denon HEOS app on my smartphone lists it and I am even able to play music on it. Additionally, I am able to ping the device’s IP address. So from my point of view, this Thing as online and available as it gets.
Unfortunately it is still displayed as OFFLINE in OpenHAB. I have checked the IP address and serial number listed under the properties and they match my actual HEOS player. Besides the “have you tried turning it off and on again?”-approach, I haven’t tried much.
Oddly, my Inbox shows 3 new things, which have been discovered: My group of 2 HEOS 1 players and the corresponding players in that group - although I have already added them as a Thing. It does list the player which is shown as OFFLINE as ignored - if I add it, it is added with a lengthy ID (which is hexadecimal instead of decimal), and still shown as OFFLINE
Could you enable logging for org.openhab.binding.heos and give some information like which openHAB which binding version etc.
Do you have one HEOS bridge or multiple? Can you control the player from the OFFLINE thing and does that status give any complications? Can you compare (screenshot?) the details properties of the discovered but the previously ignored thing and the thing which appears OFFLINE?
Is there any way to send the play state stop to a heos device? I detected that when using tune-in to listen to some radio a “pause” is simply ignored (probably as it’s not possible to pause a stream, but only stop it). Unfortunately, the default openhab player has only play and pause, but no stop.
I tried it already by sending direct Heos CLI commands to the speaker, it works when I set the play state to stop instead of pause.
Yes that was the idea to use in the binding internally stop/pause depending on the heos-scenario, while obviously it also has to be a pause in openhab, as they don’t support more.
Anyone else seeing these warnings after upgrading to OH3?
2021-01-12 11:56:33.857 [WARN ] [fig.discovery.DiscoveryResultBuilder] - Representation property 'serialNumber' of discovery result for thing 'heos:player:dcbc810e-ea46-16cb-0080-0005cd51ce40:1827671404' is missing in properties map. It has to be fixed by the bindings developer.
at java.base/java.lang.Thread.getStackTrace(Thread.java:1607)
at org.openhab.core.config.discovery.DiscoveryResultBuilder$1.run(DiscoveryResultBuilder.java:181)
at org.openhab.core.config.discovery.DiscoveryResultBuilder$1.run(DiscoveryResultBuilder.java:1)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.openhab.core.config.discovery.DiscoveryResultBuilder.getStackTrace(DiscoveryResultBuilder.java:178)
at org.openhab.core.config.discovery.DiscoveryResultBuilder.build(DiscoveryResultBuilder.java:157)
at org.openhab.binding.heos.internal.discovery.HeosPlayerDiscovery.handleDiscoveredPlayers(HeosPlayerDiscovery.java:117)
at org.openhab.binding.heos.internal.discovery.HeosPlayerDiscovery.scanForPlayers(HeosPlayerDiscovery.java:98)
at org.openhab.binding.heos.internal.discovery.HeosPlayerDiscovery.startScan(HeosPlayerDiscovery.java:83)
at org.openhab.binding.heos.internal.discovery.HeosPlayerDiscovery.scanForNewPlayers(HeosPlayerDiscovery.java:223)
at org.openhab.binding.heos.internal.discovery.HeosPlayerDiscovery.playerChanged(HeosPlayerDiscovery.java:228)
at java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:807)
at org.openhab.binding.heos.internal.handler.HeosBridgeHandler.triggerPlayerDiscovery(HeosBridgeHandler.java:494)
at org.openhab.binding.heos.internal.handler.HeosBridgeHandler.delayedInitialize(HeosBridgeHandler.java:168)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
this happens every 2 hours for all my players and is glogging up my logfiles.
