The "summary" template...dang, learn something new about hubitat today. Thanks and incredible work. Will be donating via GitHub.
I'm happy it's working well for you. Thanks for the donation!
Occasionally seeing 
Guessing this is them throttling API calls.
That's just the authentication cookie expiring and is expected behavior. Throttling would likely show up as retrying a failed request (and it'll be error vs. info).
1 Like
Sorry for the slow response, but it was worth it because I discovered something surprising.
First, though, let me try to clear something up just to make sure we're talking about the same issue. I was not experiencing any problem in creating the favorite, only in selecting the favorite for the base position, once the preset was saved. When I hit the "On" switch from the device details page of the Bed device for either side, both sides respond. Which seems crazy, even for a split-top (shared feet, separate heads).
Yesterday, to troubleshoot the problem, I ran the same test with the Sleep Number app (not your code, just the native iOS app), and exactly the same behavior ensued . So this morning I called SleepIQ customer service. What they told me was astonishing.
For people with a split-top, the app can save presets for head position for each side of the bed separately, but if you then select that preset from either side, both sides move. They claim it's a design feature, not a flaw. I'm really struggling to wrap my head around how that could be a good idea, but okay I guess. No matter how stupid I think it is, they don't acknowledge it as a problem and don't appear to have any motivation to fix it any time soon.
The workaround is to use manual base controls to change elevation and achieve the same result. If only I had an home automation platform to save and apply these settings easily so I still had the convenience of preset positions. 
Oh wait a minute. I do. 
Thankfully your app plus Hubitat allow me and others to overcome the nincompoops at Sleep Number. I could even have multiple presets (reading, sleeping, ____ing, etc) pretty easily.
That's a long way of saying I don't think the problem is @rvrolyk's, but there is a decent workaround. Cheers!
1 Like
Thanks for looking into that and posting the info here. I've updated the documentation for the app to reflect that presets may impact both sides on flextop beds (seems that's the name they're using now). I agree it seems like a quirky feature so maybe they'll change it at some point; until then at least there are ways around it 
1 Like
Appreciate your partnership in problem solving this. Could never have done it without your help!
I am getting an error on one side of my bed, but not the other. This was working a few days ago but now throws this errors. For some reason it is not getting any sessions back for me with the API call. I seem to have valid sessions on sleepiq.sleepnumber.com.
Has anyone else seen this?
I tried turning sleep collection on and off to no avail. I have not removed and recreated this bed side yet.
I am going to monitor for a few days to see if it recovers as well.
dev:30452020-09-24 07:58:58.678 pm errorjava.lang.NullPointerException: Cannot get property 'startDate' on null object on line 385 (getSleepData)
dev:30452020-09-24 07:58:58.643 pm debugsleep data [sleeperId:-9223372034804985062, message:, tip:, fallAsleepPeriod:0, sleepData:[], smartAlarmStatus:[], dualTempData:[], bedExitAvg:0, bedExitMax:0, inBedAvg:0, inBedMax:0, inBedTotal:0, outOfBedAvg:0, outOfBedMax:0, outOfBedTotal:0, respirationRateAvg:0, respirationRateMax:0, respirationRateMin:0, heartRateAvg:0, heartRateMin:0, heartRateMax:0, restfulAvg:0, restfulMax:0, restfulTotal:0, restlessAvg:0, restlessMax:0, restlessTotal:0, sleepIQAvg:0, sleepIQMax:0, hrvAvg:null, hrvMax:null, hrvMin:null, sleepSessionTotal:0, sleepSessionCount:0]
dev:30452020-09-24 07:58:58.110 pm debugsending to parent getSleepData, null
The line that error is on should only be hit when sleep data is enabled.... I'm not sure why you'd be seeing it on the same device if you leave it disabled (I can't tell if you're indicating you toggled it or left it off).
I can see the error though - that debug output shows a map of data that I expect to see a startDate key in but it's not there. The expected output looks more like:
2020-09-24 05:43:32.488 pm debugsleep data [sleeperId:-9223372019930268959, message:, tip:A cooler body temperature promotes sleep. Avoid activities that raise body temperature near bedtime: exercise, meals, caffeine., fallAsleepPeriod:3020, sleepData:[[tip:A consistent sleep schedule reinforces your body’s sleep-wake cycle and helps promote better sleep at night., message:You had a GOOD nights sleep, date:2020-09-24, sessions:[[startDate:2020-09-23T21:50:02, totalSnoreTime:0, longest:true, date:2020-09-24, bedExits:[[bedExitDuration:147, bedExitTime:2020-09-24T03:11:25]], sleepIQCalculating:false, originalStartDate:2020-09-23T21:50:02, sliceList:[], restful:29299, originalEndDate:2020-09-24T07:34:56, sleeperGoalDuration:450, fallAsleepPeriod:3020, hrvActionCode:null, sleepNumber:45, totalSleepSessionTime:35094, avgHeartRate:70, restless:2628, fallAsleepDate:2020-09-23T22:40:22, isHidden:false, avgRespirationRate:14, isFinalized:true, hrv:79, sleepQuotient:75, endDate:2020-09-24T07:34:56, outOfBed:147, snoreSensitivity:null, inBed:34947, snoreData:[levelChanges:[], snoreActions:[], snoreSense:[]]]], goalEntry:null, tags:[]]], smartAlarmStatus:[], dualTempData:[], bedExitAvg:1, bedExitMax:1, inBedAvg:34947, inBedMax:34947, inBedTotal:34947, outOfBedAvg:147, outOfBedMax:147, outOfBedTotal:147, respirationRateAvg:14, respirationRateMax:14, respirationRateMin:14, heartRateAvg:70, heartRateMin:70, heartRateMax:70, restfulAvg:29299, restfulMax:29299, restfulTotal:29299, restlessAvg:2628, restlessMax:2628, restlessTotal:2628, sleepIQAvg:75, sleepIQMax:75, hrvAvg:79, hrvMax:79, hrvMin:79, sleepSessionTotal:35094, sleepSessionCount:1]
I think I can guard against this by simply checking sleepSessionCount (yours is 0, mine is 1) or guarding access to the session list but it means the tiles will be missing some data (I'll probably N/A as a placeholder in that case).
Not sure I'll have time to fix that tonight but I should be able to get something patched in over the next week at the most.
Thanks - certainly no rush on coding around it. What I can't figure out is why this device is not getting any session data. It was just a few days ago as I still have that old data in the State for the device:
Thats why I was messing with turning "Enable Sleep Data" off and on. My best hunch is this is some problem with the SleepNumber API. Sinc ethe other side of th ebed is still working its a bit odd for the APi to break like that.
I did also try re-authenticating with the App. That worked fine but did not fix this problem.
I'll update if it recovers after a good nights sleep tonight!
@rvrolyk, I finished configuring the simple automations to workaround the aforementioned weirdness with Sleep Number. Works great, with one exception. Not sure if you're familiar with Hubconnect, but I'm using it to create shadow dimmer devices on a different hub from the hub where SNC resides. When I adjust a dimmer on the SNC hub, all is good--the change in Level is reflected as expected on the other hub. But when I adjust the dimmer on the other hub, I get an error from the SNC app, and the SNC device never reflects the Level event. I've pasted the log below. Any ideas? TIA....
dev:17562020-09-24 11:48:37.245 pm errorgroovy.lang.MissingMethodException: No signature of method: user_driver_rvrolyk_Sleep_Number_Bed_949.setLevel() is applicable for argument types: (java.lang.Integer, java.lang.Integer) values: [50, 1] Possible solutions: setLevel(java.lang.Object) (setLevel)
That is odd and I can't say that I've seen the same problem but I also don't use the sleep data that often. The debug log shows the response the API returned so you should be able to see data from each side and compare. I don't know why it would suddenly break but hopefully it'll be different tomorrow morning.
That looks like a bug... sorry. I misread the capability requirement for SwitchLevel and it looks like it requires an optional duration in the method signature. I'll try to fix that as soon as I can.
I should have just waited a few days...it came back to working this morning. So I think there is some scenario where there are zero sessions returned and you probably just need to protect against that in the code @rvrolyk
Thanks for the update. I just released v2.1 which should fix both this and @mluck's problem due to the second signature for setLevel.
If either problems persist, please let me know.
2 Likes
Confirmed the Hubconnect issue is fixed -- thanks!
Russ - I want to thank you for this integration! When I got my bed a couple years ago, the installers had recommended setting the bed to 100 every morning and then resetting it to my sleep number before bedtime. I did that for a while and then overtime forgot about it - adjusting it every 2-3 weeks. Overtime, my sleep has gotten worse. Since installing your integration, I have an automation that deflates/refills/sets the bed every single day. And my sleeping is much better (and reflected by an increase in the Sleep-iq score).
So I really appreciate your making this available!
@aaiyar Mind sharing your rule for doing this? This is what I came up with but the wife is taking a nap so I haven't had a chance to test it.
Don’t mind at all, but I’m doing it through NR.
More interested in the logic than what app you use. I was planning on using a modified version of the one I posted. That was just a quick iteration so I can test when she gets up.
Aha - logic is similar to yours, with these differences:
- Current sleep number is saved to a variable
- Bed is deflated to 0 in steps of 10 (30 sec between steps)
- After 2 minutes, the bed is inflated to 100 in steps of 10 (30s between steps)
- After 5 mins, the bed is deflated to the saved variable value
All this happens 1 hour before bedtime
1 Like
