SleepIQ Binding issue polling Sleep Number API

Hello,

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.

Thanks,

Dan

Summary

This text will be hidden

Continuing the discussion from SleepIQ Binding issue polling Sleep Number API:

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.

Thanks,

Dan

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.

Brian,

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!

Dan

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.

Any updates on this?

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.

@syphr42 Did you ever get your workspace figured out to troubleshoot the binding?