I’m using it with Maker API. I’m confused about the UI and end points. I’m guessing that to change the pressure of the bed, I use setSleepNumber and look at level to monitor progress? Why is there a setLevel in the UI and what’s the point of it?
I’m not seeing the bed inflating or deflating most of the time. If I use the physical remote, the plugin gets the new level value. When I do see the API work, I see no progress, just new value after some seconds elapsed.
I’m doing the getSleepData call or I never get updated IQ info (time to sleep, hours in bed, etc.). So the plugin isn’t doing this automatically?
Also, I see no change in presence unless I get in/out of bed and trigger a poll (push poll “button” in the UI). Is this right?
What do ON and OFF do, in the UI?
What is privacy mode?
I have a bed with no head/foot/lights. It has responsive air state, but the button in the UI seems to do nothing, and the state isn’t shown on the edit device page.
Suggestion: provide an online status that is false when the cloud endpoint is down…
If you go back to the first post, there is a link that takes you to a more in depth description of how to set up and what features are available.
This is based on the refresh interval. From the linked readme: "You may select a refresh interval that varies based on time of data or a fixed one. If you are only using this for automation (not presence), I suggest a fixed one of 30 minutes or more since automation will trigger a refresh anyway. If you are using this for presence then I suggest a variable refresh in order to avoid sending a lot of extra traffic to the SleepIQ servers. For example, you may choose to use every 30 minutes during the day but when you're normally in bed, reduce to every minute or two. The app will only change back to the day schedule when day start time and both sides of the bed are away is true. "
Works the same as it does in the sleep IQ App
"Enable Privacy Mode: turns on privacy mode so no data is reported to Sleep Number. Disable Privacy Mode: turns off privacy mode so sleep info is tracked again."
It is the same as set level in the sleep IQ app and on your remote if you have one. In the Hubitat App, the bed pressure is a "dimmer" that you adjust using "set level"
If you look at the state variable section in the created device, you will see this:
Did you enable sleep data collection in the preferences of the device? Also, this may be affected by the refresh interval as well. It won't update until the bed presence shows as away.
Are you saying inflating or deflating from Hubitat doesn't result in the bed physically changing or just that you need to poll sometimes to get updated values? The former sounds like a possible bug (but would need more info to know) while the latter seems more likely related to your refresh settings and/or expectations and @tray_e copied the bit of help text for that (but let me know if that's not actually helpful).
You should've been able to create a single bed device (e.g., no head or foot, etc) and control the things applicable from that (such as responsive air). I do see I didn't add responsive air to the state so although you can change it, the value isn't actually reflected anywhere - this is a bug and I'll get that fixed as soon as I can (probably the same time I get to adding your other request for online status). If this doesn't seem to be working, can you PM me details of your device and app settings and logs (with debug logging enabled) with what you expect to work? I do know there's a bug with the new SN Climate360 beds since SN changed the entire API; I'll actually post a note about that in post #1...
this does show up in the app listing (the name of the app changes to reflect the state) but this isn't useful if you're trying to use the status in automations. It's a reasonable thing to add and I'll look at doing so after a refactor I've been working on is complete. I got a bit delayed due to a new baby so unfortunately I don't have an ETA but will definitely get this into a future release as soon as possible.
This is WAI; the API doesn't expose push updates and polling didn't seem worth the extra traffic (especially since they've blocked or threatened to block apps in the past).
It partially is for head/foot components but I missed adding it for the actual bed pressure. I'm happy to revise/improve documentation if there's something you find missing that would've been helpful. Feel free to either PM me here or file a bug on GitHub.
@mykesx -- I was actually wrong, this is shown correctly in the states provided you enabled responsive air in the device preferences. It's done this way because it's an extra HTTP call when enabled (to update the state) and therefore users who don't care won't get the extra HTTP call penalty.
I updated to 3.2.3 today using HPM. I now see these log entries in the logs . The ones about line 1273 was when I manually turned the bed flat using the side button on the bed, and line 449 comes up every time the app refreshed status every 30 minutes.
Perhaps that 1273 I had was my attempt to use an automation through Rule Machine to lower to flat before I had to use the button on the bed. I forgot that the rule didn't respond, which is why I resorted to the button.
I just pushed a new version that attempts to fix these. The foundation preset was a dumb bug and should be resolved. I think I identified the cast problem that popped up during refreshes as well. I tried to fix the underbed lighting but have no way to test.
@es_ferret - I don' t have underbed lighting on my bed so can you try that out and let me know how it goes? If it's still not working I may PM you for a bit of help.
I'll be glad to test the lighting out. Can you please explain what the new code was supposed to do? It looks like you were trying to switch from a brightness percentage to discrete settings like the SN mobile app?
This was just supposed to optimize the various type casts Groovy does to make it a bit more efficient during runtime. Unfortunately in doing so I missed a few spots where it was casting to the wrong thing (and thus trying to compare string to integer for example). I think I resolved all that in v3.2.5 but please let me know if something still fails to work.
I toyed around with the "Set Underbed Light State" command on the device page.
At first it seemed like the low, medium, high were out of sync (low was giving me brightest light, medium least bright, and high was medium).
Decided to look at the child app just for underbed light, and noted the whole design of that interface was different. Only On or Off seemed to work on that page and all the light was lowest brightness.
Went back to main app and tried again. This time the light level seemed to match the setting terminology, but the response wouldn't happen on the first press of the command's button. It only changed brightness when I hit the button a second time. Not sure why my switching to the child and back (or turning on and then off while on that page) might have jogged the settings into correct alignment with the setting terms. Neither am I sure why afterward it would only respond on the second press of the command button
I currently use the light on auto where it turns on when someone gets out of bed, so the observations I made don't really affect my usage, but it may be worthwhile to try to figure out that synchronization/ responsiveness for other users.
No warnings after updating to 3.2.5 and my rule machine automation for the presets is working again, but these errors were in the log (they seem to attribute to the parent app, but the timing/observations I made would coincide with when I went to the child app and could only get the on/off to work but not the level setting).
This should not have changed in the update I made... a while back when I moved things to a generic child (using the hubitat built-in driver) the various child device pages became more generalized and you can set the dimmable state but the level is specific (for underbed lighting) and can only be 1, 2 or 3. If you use the parent device (which is custom) the controls are a bit more obvious.
I suspect you entered something other than 1, 2 or 3 on the child page which correlates to the error you received (and provided). There's no way for me to modify the generic driver page (it's provided by Hubitat) so I can't really provide help there that it must be a specific value.
I can't seem to reproduce this (I realized I do have a single light but no outlets to control). If you turn on debug logging for the app, you should see a request being made after you hit the "Set underbed light state" button that looks something like this and then you should see the device log that it's been updated after a request to a foundation/outlet URL --
If you don't see the outbound request (the one I show at 10:27:27.334 PM) then there's some disconnect between the button and the request (which would be odd since it's pretty direct in the Hubitat driver interface but maybe it's lost somewhere); if that happens, debug logging in the driver page might help show something.
Hey @rvrolyk, everything minute of so, my logs are getting spammed with this error message (never seen it before and haven't touched anything in this automation (or this hub) for awhile. Any hint on what this means? Having no problems with the automation's functionality.
errorcom.hubitat.app.exception.LimitExceededException: App 964 generates excessive hub load on line 676 (method setConnectionState)
Reboot doesn't resolve. Also - I checked the app and device stats within Logging, and see nothing remarkable.
I've not seen that before but it looks like a message generated by the hub OS rather than the app itself. It seems like it's complaining the app is generating too much load (and I assume app 964 is the SleepNumber app). What's interesting is line 676 is just a closing block of one of the settings pages and the app doesn't actually have a method called setConnectionState (though the bed device does). Can you verify you're running the latest version and if not, try updating and see if the message disappears?
