I think I don’t understand your last comment. Do you mean having a specific log to find the cause for initialization trouble? This is already included by using jdt.annotations.
You have to change the log level do DEBUG or TRACE to see all information from the binding.
Do you still have the trouble also after a restart of openHAB?
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
202
Oh…
(I don’t know enough to really know how to answer)
All I saw was…
Adding the binding to add-ons folder made it appear in bundles:list but only as installed.
Adding upnp transport changed the binding to Active.
Instantly, my AVR-X4400H HEOS bridge appeared in the PaperUI inbox.
When I added my HEOS credentials, the Thing changed to initialising and stayed in that state for a long time.
So I assumed that I needed to address the annotation issue.
It was probably a coincidence that adding the annotation binding was done at the same time as the HEOS bridge changed to online, at which point the AVR-X4400H HEOS thing appeared in the Inbox.
Is it normal for both the Bridge and the HEOS Thing contain Favourite switches?
@MDAR
Ok it seems that this may be just a single issue with the connections. Please let me know if it takes that long all the time you start openHAB
Regarding the channels, yes at the moment this is normal. I added the channels at the players and groups and let them also at the bridge for the moment to keep the compatibility to existing configurations. But if the community decides that it is better to have them on the player and groups directly instead having them at the bridge, I will remove them from the bridge with one of the next releases.
@majherek
Thanks for testing and your feedback. Regarding the channel name I will check it and correct it. Thanks for the hint.
I have also installed the 2.5 version it works great on my 2.4 stable.
However the readme says the channel is corrected to Shuffle, I still have Shuffel.
Also on the previous version the state of groups was not very consistent. Sometimes it said the group is online, however not… Can we test this somehow to make it more stable?
What are these new channels are in the ‘Players’? If I switch on one of the TuneIn Radio channels, it will start that on that Player? What does the ‘…Group’ does in the Bridge? It automatically builds that group?
Also are you considering making a pull request to have this binding in the official release or publishing it to Eclipse IoT Market?
@rkrisi
Thank you for using the binding.
The channel will be corrected with the next release. I already updated the channel but haven’t released a new .jar file.
Regarding the group online state I completely reworked the way how a group is considered as online or offline. So please test it on your binding and let me know how it works. From my side it worked way better with the new release.
The new channels are your favorites. If you switch it on they will start playing the favorite on that player or group. The group switch on the group build that group. Or also ungroup the player of that group.
I already placed a pull request for that binding. Here is the link:
This version is much more stable than before! Also the group online/offline things is improved! Thanks for your work!
Placing the dynamic channels on individual players and groups is also really good I think. I still haven’t moved to that solution yet, but it seems much more easier and understandable where to play and what. In my opinion, you can remove the channels from the bridge.
Ps.: However I’m still having problem with detecting if a group is offline or not.Sometimes it stays online even is the group is offline (ungroupped).
Sadly I have found a new problem… I can’t get my devices online in openHab (I think an update caused this). I only get an exception when I refresh the bundle:
2019-04-18 01:18:26.512 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.ClassCastException: org.openhab.binding.heos.handler.HeosBridgeHandler cannot be cast to org.openhab.binding.heos.handler.HeosBridgeHandler
at org.openhab.binding.heos.handler.HeosThingBaseHandler.initChannelHandlerFactory(HeosThingBaseHandler.java:127) ~[?:?]
at org.openhab.binding.heos.handler.HeosPlayerHandler.lambda$0(HeosPlayerHandler.java:56) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Thanks for the information.
It seems that Denon has changed the player IDs with the last update which was delivered to my HEOS this night.
All my players got a new player ID and has been discovered as new players within openHAB. My old players are still online but are not working anymore. But if you restart openHAB they will go offline.
So can you please try to remove the old players and groups within openHAB and add them again if they discovered correctly? Also please check if the player you use as Bridge is online and working correctly and that the bridge is set correctly within the players.
Please let me know if this solves your problem. I was not able to reproduce the fault message at my system. I will maybe add an additional check at the point of the binding to throw an error message if the Class can not be cast.
Are you using the latest release of the binding? Just in case…
Yes this was happened to me also last night. Since then I also figured out that the IDs changed. Replacing with new discovered Things it is working again. Replacing the ID in the old devices doesnt helped, dont know why…
I think this happened to me again There were no updates I think these days, but it seems that the player IDs changed again…
I’m using the latest version of the binding. I don’t know why this happens. Maybe Denon added a logic which changes regularly the player ID? Or it is just a coincidence that this happened to me twice in the last week (and never before)?
Some other bindings have some logic to “track” down already added Things. Would it be possible to add something similar to this binding? Like it always searches for new devices and if a device (Thing) is added and also found on the network (same IP, MAC, etc…) but the player ID is not the same, it should update that Thing, rather than adding a new entry to the Inbox?
@rkrisi
I can confirm the same happened to me. The players got new IDs again.
But Denon again released a new firmware at the 24.4.2019 which should fix the following issue:
24/04/2019 (U20.1)
HEOS firmware (1.505.140)
Resolves an issue that some Control Systems stopped controlling HEOS devices.
according to the Denon support the issue with the changing IDs is fixed with the latest firmware update (1.505.140).
So hopefully this was the last time the players got a new ID…
@Wire82
Hi!
I just discovered that after some time, the binding stops updating the values. It still can receive commands, but channel states are not updated, a bundle refresh is required to work again… can you have a look at this?
in the lastest 2.5 snapshot (working great!) there’s a cover item from type raw image. In the older versions there was an image_url of type string but that one is no longer there. Would it be possible to keep both in, so readding the image_url as well of type string. Reason for it is that I expose this binding to my neeo remote and that remote does not support raw images, only image url’s.
I don’t think this is a big thing but would be really greatful if you could add it in again or explain me how I can add it again.
Hi,
I am currently moving from windows to a synology docker openhab setup and within this process I am getting all the new and shiny stuff :). Now I am a bit confused where I can get the latest release of the Heos binding. If I understand correctly the Heos binding should now be official available in bindings to be installed via paperui but I can’t find it (openhab 2.4.0 official release). Is the one on github 1.4.1 from June 2018 the one I should use instead?
NoTechi
It is merged after 2.5M3 so it should be available in M4 coming soon. New bindings won’t show up on older versions of openHAB.
I will try to find the built jar from jenkins.