Thanks for you work on this @martinvw. I’ve been trying out the new version. Here are my observations so far. Note that some of this behavior might be preexisting.
The main issue I’m currently having is that it never creates all of the channels on the bridge for the speakers. It will create some of them, but never all of them for some reason.
I disconnected a speaker for several minutes. It seemed to reconnect just fine after it started back up. OH was able to communicate with it again.
Speakers show as being online no matter how long they have been powered off. I was expecting them to eventually show as offline.
OpenHAB can send commands to powered off speakers and there is no indication that it failed.
For what it’s worth in the past the main thing I’ve been fighting (before this version too) is the speaker channels in the bridge. Even in your previous version, the binding only creates the channels when it is initialized. If for some reason a speaker isn’t listed in the HEOS app at that time, but later is connected again and discoverable, it will never get a channel in the bridge unless I restart the binding. It would be great if this speaker discovery/channel creation part could happen when speakers are discovered/connected.
If there are other scenarios I can test or if there’s anything you want me to look for in log files let me know.
Thanks for the observations, the fact they are not marked OFFLINE is wrong and I will have to look at it. The same holds for the speakers-channels on the bridge they should be there and I agree with you that they should be updated when new speakers are found while running.
Edit: @tree3887 I just realized that the device which lives next to my development machine was configured as a bridge so that is the ONLINE/OFFLINE scenario I tested while developing my first steps in updating the binding. Can you check whether that does work as expected. If you would like it would be helpful if you could also ONLINE/OFFLINE of groups.
I will look into handling other players coming online/offline.
All speaker channels were created on the bridge, even for offline speakers. I assume then that when an offline speaker is online again that it will work, but I haven’t tested that directly yet.
A speaker went offline after being powered off for 3 min, and subsequently came back online immediately after powering back on. This looked great.
A group I tested turned online and offline appropriately and looked good.
Disconnecting the bridge immediately set all related things to “bridge offline” status. All things had appropriate status after reconnecting the bridge. This happened pretty quickly.
The only issue I’ve found so far is that when sending a command to an offline speaker (e.g. control, volume) it changes the status of the speaker to be online, even though the speaker is still powered off. See the log snippet below.
2020-05-20 15:54:22.625 [ome.event.ItemCommandEvent] - Item 'MBHEOS_Control' received command PLAY
2020-05-20 15:54:22.628 [nt.ItemStatePredictedEvent] - MBHEOS_Control predicted to become PAUSE
2020-05-20 15:54:22.633 [hingStatusInfoChangedEvent] - 'heos:player:main:MasterBedroom' changed from OFFLINE to ONLINE
Great! Thanks for your quick and complete test, debug logging of the last scenario could be useful although it does not sound to hard to reproduce here. So if you have time some additional debug logging would be great.
Sure thing! I appreciate your work on getting these bugs ironed out. I find this binding immensely useful.
Below are the logs from the time surrounding me sending a command to the powered off speaker. Nothing is shown in debug for it.
One other oddity around this I’m seeing is that once this happens and the device is incorrectly ONLINE, that state persists even after I restart the binding (and even restarting OH).
2020-05-21 01:29:27.113 [DEBUG] [binding.heos.internal.api.HeosSystem] - Time since latest event: 25 s
2020-05-21 01:29:27.114 [DEBUG] [binding.heos.internal.api.HeosSystem] - Sending HEOS Heart Beat
2020-05-21 01:29:33.243 [DEBUG] [nternal.handler.HeosThingBaseHandler] - HEOS player/group is not found, rescheduling
2020-05-21 01:29:33.867 [DEBUG] [nternal.handler.HeosThingBaseHandler] - HEOS player/group is not found, rescheduling
2020-05-21 01:30:03.245 [DEBUG] [nternal.handler.HeosThingBaseHandler] - HEOS player/group is not found, rescheduling
2020-05-21 01:30:03.869 [DEBUG] [nternal.handler.HeosThingBaseHandler] - HEOS player/group is not found, rescheduling
2020-05-21 01:30:04.352 [ome.event.ItemCommandEvent] - Item 'GRHEOS_Control' received command PLAY
2020-05-21 01:30:04.356 [nt.ItemStatePredictedEvent] - GRHEOS_Control predicted to become PAUSE
2020-05-21 01:30:04.364 [hingStatusInfoChangedEvent] - 'heos:player:main:GuestRoom' changed from OFFLINE to ONLINE
2020-05-21 01:30:27.119 [DEBUG] [binding.heos.internal.api.HeosSystem] - Time since latest event: 85 s
Favorites can be started with their names only or with that unique identifier as well?
It seems for me that the unique identifier is not working, it won’t play anything with these new versions…I just figured it out now.
Also I have other problems with passing the correct name with NGRE to the item, so I can’t test that now if it works with the name of the favorite.
Yes this is what I had before. I sniffed these IDs from the log. However it stopped working but I don’t know why. Looked at the state, but the ID was the same when I started the favorite manually, so it did not changed. That’s why my only guess was that it only accepts favorite names here. But might be some other problem, maybe names also don’t work from rule.
@rkrisi any updates about this? Would be good to know for sure before merging it
FYI I made some small changes to the discovery mechanism, mostly about the internal bookkeeping en removing discovered devices when they are not accepted and do disappear again.
I have been using the previous version and works as it should I had other problems with my rules, not really the binding.
I also can’t say anything about the bugs reported by other users like the ThingStatus not representing the state correctly, for me it always seemed correct (though I never disconnect or turn off these devices completely, I just assumed this from the Group statuses which was correct everytime).
You mean the specific case where the players go online when sending a command to them? No I did not look into that. However the normal online / offline handling should work.
The persistent state could be caused by not initializing the status on start up. I’ll add a reminder to look into that later this week.
Maybe you can again run it in debug mode maybe its more explicit this time. What I do see is that sometimes the basic UI does not pick up changes but a refresh always fixes it.
Okay, looked at the log and code again I have some things for you to test (we could take it private somewhere)
Did you ever try whether setting the favorites channel to eg. ‘s98575’ using a rule leads to successfully starting the favorite?
Does the queue work? Did you link it to a channel?
Could you check the rest api, when I fetch the details using the /items/{itemname} I see the options what do you see there?
Do you have any errors (using developer tools) in your browser? I ask because I thought that maybe something is wrong with the details and it might need to be escaped or something like that?
Yes, that works when I enter one of the identifiers in PaperUI.
I do not use the queue because I have no “offline” music.
The options field is empty {"link":"http://10.0.0.248:8080/rest/items/HEOSBar_Favorites","state":"inputs","stateDescription":{"pattern":"%s","readOnly":false,"options":[]},"editable":true,"type":"String","name":"HEOSBar_Favorites","label":"Favorites","tags":[],"groupNames":["Group_HabPanel_Dashboard"]}
PaperUI throws one angular error and basicUI has no errors.
Now I have to use the HEOS app to select a station 
