i have setup openhab2 on a RPI3 with the hyperion.ng binding which connects to another RPI4 running hyperio.ng and kodi.
I have setup my thing / items as describe in the bindings documentation.
Controll via BasicUI is possible, I can turn on/off the LEDs.
Config is as follows:
Thing:
Thing hyperion:serverNG:myServer [ host=“192.168.0.xxx”, port=19444, priority=50, poll_frequency=15, origin=“openHAB”]
Thing astro:sun:home [ geolocation=" xx.yy,xx.yy,0", interval=60 ] {
Channels:
Type start : rise#start [ offset=-1, latest=“08:00” ]
Type end : rise#end [ offset=1, latest=“09:00”]
Type start : set#start [ offset=-1, latest=“14:00” ]
Type end : set#end [ offset=1, latest=“14:00” ]
}
Thanks for your reply, @wars: Thanks, lable=“LED Device [%]” did the job for my second iusse (2).
As 1 and 3 are still present i checked the log for more details.
2 Things which seem curious to me
[WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.openhab.binding.hyperion.internal.handler.HyperionNgHandler.updateHyperion(HyperionNgHandler.java:260) ~[?:?]
at org.openhab.binding.hyperion.internal.handler.HyperionNgHandler.handleServerInfoResponse(HyperionNgHandler.java:178) ~[?:?]
at org.openhab.binding.hyperion.internal.handler.HyperionNgHandler$1.run(HyperionNgHandler.java:103) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_152]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:1.8.0_152]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_152]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:1.8.0_152]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_152]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_152]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_152]
I am not clear what this means or how I can solve it. Thanks for any support
[WARN ] [g.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 192.168.0.xxx
[WARN ] [g.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 192.168.0.xxx
…
[INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at http://192.168.0:yyy:8080
[INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at https://192.168.0.yyy:8443
As said, I am running my setup on a RPI with both WLAN and ETH, first IP (xxx) is ETH and second is WLAN. May this cause any issues for OpenHAB?
And one more question, why are those lines written twice, is this normal?
Hi, yes both IPs run in the same network / IP space.
How shall this help? It isn’t my goal to have two networks on the PI, its just that both interfaces are active on the PI to easily switch if needed, but if this causes problems I am willing to turn wlan off.
I don’t know. What you are trying to do - two different portals to the “same” IP network - is called dual-homing.
I’ve no idea if your OS supports that, and if it does, if openHAB supports it.
I would guess not - unless you manage this kind of thing carefully with routing at both ends, you can get a query out one port eliciting a response via another. I’ll defer to real network expertise on that.
The thread I pointed at is someone carefully arranging his two network ports to avoid dual-homing.
Hi, there is no real reason or plan, its just that both interfaces are configured and active, but in the same network! So as far as I understand this is not dual-homing. But does it still causes problems for openHAB?
As the double IPs are both in the same network it should not cause a problem with the Hyperion binding where the hyperion.ng server is also running in the same network. Esp. because the error seems to be thrown once a scheduled rule is executed “Scheduled runnable ended with an exception”.
What else can I do to debug this?
Does anyone else who is using the hyperion.ng binding sees the same error log?
What about my other issue that state variables are not updated after i restart openhab, any idea on this? Is it a openhab or an hyperion-binding issue?
thanks for your reply. I am currently setting up openhab again after 2 years.
It was running via GUI controll, but the rules where never running properly and initialisation of variables also did never work.Yesterday I did update Openhab via apt-get and it was completly broken, therefore I did a complet reinstall and added my config files again to the installation. Looks like the rule is now executed, but the log still shows the same exeption.
Current setup (as per my understanding the latest and greatest)
openhab - Version: 2.5.4-1
binding-astro - 2.5.4
binding-exec - 2.5.4
binding-hyperion - 2.5.4
binding-kodi - 2.5.4
I am willing to debug more, but I do not know yet how to do this on openhab. If there is any documentation or and hint form your side how to debug, I am willing to do so.
Sorry, I meant what version of Hyperion.ng are you using? Based on the stacktrace I would guess at something having changed in the Hyperion.ng side in recent builds.
I’ve had a look through the response from Hyperion.ng 2.0.0-alpha.5…bad news I’m afraid. They have changed the JSON response and I’m not going to have to fix/test this any time soon.
Thanks for the reply even if there is no solution for now.
Does the change explain why I don’t get initial values in the items?
Or can you explain how it affects the binding? Are some features ok and others do not work?
BTW: Where could I find the source-code of the binding? Is it available on github?
Yes, the binding attempts to retrieve the status/initial values from Hyperion.ng but the response the binding is getting back is in a new format and is no longer recognised/supported by the binding.
You may find that issuing commands to Hyperion.ng may still work - I haven’t tried.
Anyhow the code is, of course, available in the openhab-addons repo.
I also faced NPE after migrating to hyperionNG alpha6:
==> /var/log/openhab2/openhab.log <==
2020-06-10 22:50:58.777 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.openhab.binding.hyperion.internal.handler.HyperionNgHandler.updateHyperion(HyperionNgHandler.java:260) ~[?:?]
at org.openhab.binding.hyperion.internal.handler.HyperionNgHandler.handleServerInfoResponse(HyperionNgHandler.java:178) ~[?:?]
at org.openhab.binding.hyperion.internal.handler.HyperionNgHandler$1.run(HyperionNgHandler.java:103) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_232]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:1.8.0_232]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_232]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_232]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]
It seems the API was changed so that Hyperion general state is handled by special componnent called “ALL”: