I have been troubleshooting a SleepIQ issue for a few weeks with no resolution. What I have observed is that the SleepIQ binding will work correctly for 30 minutes after the bundle is restarted in the Kraft console. After 30 minutes of reporting from the SleepIQ API it becomes inconsistent. For example, one successful update over an hour which is causing automation issues with inconsistent bed presence.
See below log file:
2019-11-08 09:53:29.871 [WARN ] [org.glassfish.jersey.internal.Errors] - The following warnings have been detected: WARNING: Cannot create new registration for component type class org.syphr.sleepiq.api.impl.SleepIQImpl$1: Existing previous registration found for the type.
2019-11-08 09:53:30.037 [DEBUG] [internal.handler.SleepIQCloudHandler] - Unexpected error while communicating with SleepIQ cloud
java.lang.NullPointerException: null
at org.openhab.binding.sleepiq.internal.handler.SleepIQCloudHandler.refreshBedStatus(SleepIQCloudHandler.java:159) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]
2019-11-08 09:53:30.175 [WARN ] [org.glassfish.jersey.internal.Errors] - The following warnings have been detected: WARNING: Cannot create new registration for component type class org.syphr.sleepiq.api.impl.SleepIQImpl$1: Existing previous registration found for the type.
2019-11-08 09:53:30.335 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred during notification about bridge status change on thing 'sleepiq:dualBed:1:master': null
java.lang.NullPointerException: null
at org.openhab.binding.sleepiq.internal.handler.SleepIQCloudHandler.getBed(SleepIQCloudHandler.java:242) ~[?:?]
at org.openhab.binding.sleepiq.internal.handler.SleepIQDualBedHandler.updateProperties(SleepIQDualBedHandler.java:100) ~[?:?]
at org.openhab.binding.sleepiq.internal.handler.SleepIQDualBedHandler.bridgeStatusChanged(SleepIQDualBedHandler.java:92) ~[?:?]
at org.eclipse.smarthome.core.thing.internal.ThingManagerImpl$4.run(ThingManagerImpl.java:901) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240]
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:1142) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
I have tried to back off the refresh rate on the sleep number API that was previously working at a 60 second refresh interval without any change. This binding was working fine for > 6 months prior to this and started about two weeks ago. I am not sure if something changed in the SleepIQ API with a recent software update.
Just an update to this in case anybody else is having the issue. I have created a rule to restart the binding once the error is seen (about every 30 minutes). It has restored the use of presence with the SleepIQ binding to restore automation. Hopefully the binding will be fixed in a future release.
I’m having the same issue. How did you create a rule to respond to an error so that I can do the same? @syphr42 are you having challenges with the binding recently as well? I’m on 2.5.0M5 myself, but I think the binding hasn’t changed appreciably in quite some time.
I am running 2.4.0. The issue starting I think after sleepIQ changed something in the API interface. I could not debug it enough to see why it started after 30 minutes after authentication… I turned on all the logging and was not enough to go on.
For the rule:
rule "Restart SleepIQ Binding when Offline"
when
Thing "sleepiq:cloud:1" received update OFFLINE
then
logInfo("Automation", "Rule=SleepIQ Binding offline... restarting Cloud Service!")
executeCommandLine("bash /usr/share/openhab2/runtime/bin/client bundle:restart org.openhab.binding.sleepiq")
end
You can then see the execution in the openhab.log:
2019-12-01 19:46:17.191 [WARN ] [org.glassfish.jersey.internal.Errors] - The following warnings have been detected: WARNING: Cannot create new registration for component type class org.syphr.sleepiq.api.impl.SleepIQImpl$1: Existing previous registration found for the type.
2019-12-01 19:46:17.458 [INFO ] [ipse.smarthome.model.script.Automation] - Rule=SleepIQ Binding offline... restarting Cloud Service!
2019-12-01 19:46:17.466 [INFO ] [lipse.smarthome.io.net.exec.ExecUtil] - executed commandLine 'bash /usr/share/openhab2/runtime/bin/client bundle:restart org.openhab.binding.sleepiq'
Hope that helps… At least it works till the binding is addressed!
I haven’t noticed any problems lately with the SleepIQ binding, but I just checked my logs and it appears to be flapping. It will get updates correctly and then an error occurs and the bridge goes offline. A few minutes later it corrects itself and starts getting updates again (at least for me running OH 2.4.0).
The API for SleepIQ (at least when I wrote the binding) was unpublished so I’m actually a little amazed it went this long without any issues.
This week is a bit hectic, but I will try to look at the binding this weekend and see what’s going on.
Quick update: I’ve run a set of tests with the SleepIQ API library (separately from the OH binding) and it appears to be working correctly. From that, my assumption is that there is a bug in the binding, though I don’t know why it didn’t appear until recently (perhaps something subtle changed in the API that is only apparent over time).
I do see a couple of possible suspects in the code for NPEs that I can make more robust, but I’ve spent the afternoon trying to get a working development environment without luck so far. Once I have a working environment, I’ll run some tests and hopefully be able to create a PR.
That fits the symptoms that restarting the binding allows it to work for 30 minutes before creating another error and repeats the cycle (the binding basic function is ok). Possibly the API does something different after 30 minutes like re-authenticate?
The binding has been working fine here with the rule to restart on the error. It has been running like this for a few weeks and the automation is working consistently.
I upgraded to release 2.5 yesterday and the above rule stopped working. In 2.5 to tighten security you can no longer execute bash commands to restart bundles without authentication. To establish a trusted key between applications follow this thread: Security of Karaf console. Once the key was created the rule started to work again.
@syphr42 did you ever find out why the binding is going offline after 30 minutes?
No, not yet. I still don’t have a working development environment. After creating the new workspace in Eclipse, OH refuses to start. I’m probably missing a bundle somewhere or there is some setting in Eclipse that I’m missing. I will have to figure out how to get a working setup before I can debug the issue further.
No updates but the rule to restart the binding every 30 minutes is at least a workaround for the time being. I have been using it for a few months and the automation has restored.
There is no solution to fixing the binding yet… but if you restart the binding with a rule when it goes offline it will restart every 30 minutes but works well.
@Dan_H Thanks for the response. I have installed the keys and can ssh -p 8101 openhab@localhost and it doesn’t ask for a password. So I assume I have that set up correctly but it’s not restarting the modular. I just don’t know how to troubleshoot this further. Any help would be greatly appreciated.
Looks like the restart is working but SleepIQ is going OFFLINE about once a minute.
I remember having a similar issue executing the restart with the executeCommandLine via the rule after the security update even with the keys.
Here is what I did… I used the executeCommandLine command to run a shell script to restart it that way… and it worked.
Here is the rule:
rule "Restart SleepIQ Binding when Offline"
when
Thing "sleepiq:cloud:1" received update OFFLINE
then
logInfo("rule", "Rule=SleepIQ Binding offline... restarting Cloud Service!")
var results_script=executeCommandLine('sh /home/openhab/sleepiq.sh', 6000)
logInfo("results", results_script)
end
Thanks Man that did the job. I did have the key setup incorrectly. Openhabian is the main user on my setup and everything is owned by the openhab user. So basically ssh -p 8101 openhab@localhost then following the key instructions. Thanks again
@syphr42 Any luck in getting your dev environment working? I have the auto-restart thing setup, but it’s really polluting the logs. I’m honestly surprised you’re not seeing this yourself. Can we help you get your environment working maybe?
