I have no idea how you work such magic. 
My favourite of those would be the map, the small part of my brain that is reserved for programming can see how that is structured.
Thank you once again for bringing your knowledge to the party.
@Anne11e I was too quick this is not allowed by the framework 
The code is there in the HEOS binding but the openHAB framework does not forward the ON/OFF.
It seems that if your knx things would be of the type system.rawrocker you could use a profile but most likely the knx binding has to changed for that . I must admit that my profile knowledge is minimal but looking at this it could even make sense to add another profile but I’m not sure about it maybe @cweitkamp could tell us more about the profiles.
The profile which could help us is system:rawrocker-to-play-pause and can be seen in action in the README of the EnOcean binding.
The alternative would be to have some rules to do this.
FYI, and for completeness, in OH3 - so disregard this for now if you’re not using it - state & command options, when not provided by the link/binding, you’re able to configure them (or override if they are) with metadata on the item.
So if you have an item for the radio station and say its valid options are 1, 2, or 3:
You can specify these options in the stateDescription metadata namespace, using:
- the UI
- text files (for static options)
- eventually, rules or other means (for dynamic options) - remember you can have an item defined using an .items file but have a metadata namespace for it in the JSONDB.
In the UI you would click on “State Description” under “Metadata” and provide the options in the text area:
The equivalent in an .items file would be:
String RadioStation "Radio Station" { stateDescription=" " [ options="1=BBC Radio 1,2=BBC Radio 2,3=Absolute Radio" ] }
The default widget for the item will now display the label of the corresponding option instead of the actual state. Moreover, if the item isn’t read only, the control becomes clickable and allows to select another option - sent as a command. Those are actually command options - but by default they are conveniently set to be the same as the state options. If they differ they’re configurable with the commandDescription namespace in the same manner.
3 Likes
thanks for your research. i tried the profile in my channel but this didn’t work, like you expected.
I have now created some rules for the ON/OFF
You can find everything about profiles here. If I understand you correctly you are looking for a way to convert / map OnOffType to PlayPauseType? AFAIR currently there is no way to do so other than a rule - even it is not that hard to archive. A profile sounds reasonable but before starting to code I would like to point to this feature request which could be a start or an approach to solve this issue.
Hello @PhilippRoessner and others,
I took a dive into profiles today and managed to create a profile that can be added to the playlist items and can be used to tune the action which is performed on sending a command. For @PhilippRoessner the action which would be most relevant is IGNORE.
We briefly discussed some modeling in an other topic.
My local changes give the following possible item definitions for playlists
String KantoorHEOS3_Playlists "Playlists normal, triggers PLAY_NOW" {channel="heos:player:-831584083:Playlists"}
String KantoorHEOS3_Playlists_t_1 "Playlists normal, triggers PLAY_NOW" {channel="heos:player:-831584083:Playlists" [profile="heos:play"]}
String KantoorHEOS3_Playlists_t_2 "Playlists triggers given action" {channel="heos:player:-831584083:Playlists" [profile="heos:play", action="PLAY_NOW"]}
String KantoorHEOS3_Playlists_t_3 "Playlists triggers given action" {channel="heos:player:-831584083:Playlists" [profile="heos:play", action="IGNORE"]}
String KantoorHEOS3_Playlists_t_4 "Playlists triggers given action" {channel="heos:player:-831584083:Playlists" [profile="heos:play", action="REPLACE_AND_PLAY"]}
String KantoorHEOS3_Playlists_t_5 "Playlists triggers given action" {channel="heos:player:-831584083:Playlists" [profile="heos:play", action="ADD_TO_END"]}
String KantoorHEOS3_Playlists_t_6 "Playlists triggers given action" {channel="heos:player:-831584083:Playlists" [profile="heos:play", action="PLAY_NEXT"]}
Is this something that makes sense for all of you? Or would it make more sense to have different channels for different actions? Any suggestions from you?
Thanks a lot!
Hi, I have a bunch of Heos devices in my house to use the multiroom functions.
I wanted to use openhab an some presence sensors to give the multiroom functionality some more intelligence. But I have several issues with the group functionality:
- Sometimes the bindings tells that multiple groups are activated which is not the case, it seems to mix up the groups if there are similar speakers playing. E.g. when I turn on the office/living room/kitchen group also the office/living room group is turned on. But also sometimes the groups don’t match at all, e.g. when the office and kitchen are currently playing also the group office/living room is sometimes turned on, which doesn’t make any sense.
- The bigger issue is, that it seems to mix up master and slaves. E.g. sometimes the office shall be the master and living room just the slave, and sometimes otherwise. Unfortunately, when I’ve created the office/living room group the living room/office group never shows up in the inbox when turned on.
I’ll now switch temporarily to a heos cli solution, until this is also working fine in openhab. Please let me know if I can assist you guys in anyway to get this solved or maybe even improve it, as the group/switch-logic gets quite complex when you have some more devices and constellations. 
In the binding there was a deliberate choice made that two groups which have the same members are treated as the same group, without making the distinction who is master and who is the slave. The fact that groups are turned on randomly is of course not intended behavior.
Does the fact that it treats those groups as the same already explain part of the behavior you see? What issue does that cause for you?
Yes it explains part of the bevahior. The issue that I have with that is, that I want to use openhab to turn groups off an on. E.g. when I’m listening in the office and move to the living room I switch on the office/living room group. That’s fine when the music is currently playing in the office. But if it’s the other way, I’m in the living room, listening to music there and move now to the office, turning on this exact group will set the office as the master and directly stop the playback in the living room, as obviously nothing is playing on the office. Therefore in this case the living room has to be the master.
@Wire82 do you recall why this approach was chose. What do you think is the most sensible to do? Should we rewrite the grouping such that two groups with the same members are the same depending on who is the master? Do you think that that could combine the best of two worlds?
Thanks a lot for your time and efforts!
@airbone42 & @martinvw
The reason for the current behavior is that the binding does not know, which player is currently playing music and taking this as a master for the group. Normally the group is build in the same arrangement like it was created the last time. So for example if it was player 1,2,3 (1 is the master then) it will be a group with the arrangement 1,2,3 for the next time the group is generated if you are using the grouping switch of the group. If you, for some reason, making a group with the listing 2,3,1 player 2 will be master and the binding is updating the arrangement. So if you are building the group the next time via OpenHAB it will be 2,3,1.
An idea is to use a rule within OpenHAB, to generate the group via the bridge. Then the rule could check which player of the group is currently playing and using this as a master. This works if our are using the player channels at the bridge. The first player you select, will be the master and will take over the currently played music for the group.
The other idea is, that this could be also added as a rule to the binding as included function.
I choose this behavior, because for me it was important, that a group is identified as the same group every time it is build, independent from the player sorting within the group. So a 1,2,3 group should be the same as 2,3,1 and 3,1,2 for example.
Does the answer helps a bit?
1 Like
I have been struggling with group functionality recently as well. For my example, let’s say I have players 1, 2, 3, 4. For this example, player 1 is always the master, and I want 3 distinct groups: (1,2), (1,2,3), (1,2,3,4). I create these groups in the UI. I can create the first group (1,2) and all is well. When I create the second group (1,2,3), all the group properties (“members”, “Members Hash value”, etc) in group 1 are over-written to match the properties of the group 2. When I create the third group (1,2,3,4), all the properties in group 1 and group 2 are overwritten with the properties of group 3. I am left with three groups that are essentially the same. When I turn one group on or off, the other two groups turn on or off at the same time. They are not distinct.
I understand that the GID for all these groups will be the same since they all have the same master player, but I’m looking for the ability to distinguish between the 3 configurations of the group so I can illuminate some local keypads to give a visual indication if that room’s player is part of the group or in local mode. If the “member” or “Members Hash value” was not overwritten, I might have a way to distinguish these configurations. Is this possible?
I will take a look at it this evening it should not be to hard to fix that part of the problem. It seems like the same issue which was also reported by @airbone42
@airbone42 / @CalPolyME I have a test-jar for you if you like:
https://download.martinvw.nl/org.openhab.binding.heos-2.5.9-SNAPSHOT.jar
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?
No
See also: https://www.openhab.org/docs/configuration/addons.html#through-manually-provided-add-ons
You could validate that you successfully removed the old binding using the karaf console, see the first part of https://www.openhab.org/docs/configuration/addons.html#through-configuration-files
@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.
Credits for who it deserves, @Wire82 did all of the work on the initial binding.
I mainly did technical refactorings and some small improvements
I would expect that you could do that by turning the smaller group on?
IE, group a,b,c is ON
then force grouping of the group a,b
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.
1 Like