Thanks! I'll try that later tonight or tomorrow.
I just released v4.1.1 that adds support for core climate (if you have a bed that supports it). I also realized I owed an update to the readme after the last big change so that's now done too.
Note that briefly v4.1.0 was released (maybe for 3 minutes) but had a bug which caused it to refer to a non-existent (in most cases) beta library - apologies if that tripped anyone up.
2 Likes
I think there’s a bug with trying to set the core climate to off. This is what I’m getting in the logs.
How did you trigger that? All invocations made from the driver pass string and number which matches the method signature.
Is it possible the driver setting for the timer (core climate duration) is null (empty)? That should result in a different error but it’s my only guess.
I tried it from the device and also from a custom action in a rule. Both produced the same result for core climate, but worked for foot warmer.
I’m not surprised the rule didn’t work given the method signature (it requires string and number). Foot warming has an overload that allows the timer to be omitted.
When you tried from the device, did you leave the duration empty? If so I think I know how to fix this (but am surprised the Hubitat allows an empty field).
Yes, I left the duration empty when I tried from the device.
Ok, I think the fix is to set line 410 to read:
void setCoreClimateState(String temp, Number timer = 30) {
I’ll try to get an update out with that before the weekend is over.
1 Like
I just submitted this change as 4.1.2.
2 Likes
Just tried to install the app on a C7 hub that’s fully updated and got an error.
Error Occurred During Installation
An error occurred while installing the package: Failed to install app https://raw.githubusercontent.com/rvrolyk/SleepNumberController/master/SleepNumberController_App.groovy. Please notify the package developer..
I suspect it is trying to install the app before the library bundle, the bundle might need to be moved up in the manifest file so it goes first I am not totally sure.
Try manually installing the library from the raw code: https://raw.githubusercontent.com/rvrolyk/SleepNumberController/master/SleepNumber_Library.groovy
Or the Bundle https://github.com/rvrolyk/SleepNumberController/raw/master/SleepNumber_Library.zip
Then install the rest via HPM.
I think when HPM reinstalls the bundle it will just replace the existing library so it should not cause a duplicate in the code, may want to go back and check after though.
HPM is, as far as I know, supposed to install the bundle first and then the rest of the code (I think driver then app). I've seen a few issues like this but no logs have ever been shared so I can't say what's going on for sure.
@jason.o.brown - if you are still having issues, can you enable debug logging in HPM and try again and PM me those logs?
Otherwise what @jtp10181 suggested to install the raw code is a good work around.
Yes you are correct, I had a spare hub fairly wiped clean and just did a new install, worked perfectly fine. I wonder if the library bundle is silently failing in these cases and then the app fails because the library is not there.
yeah, it's strange. Jason shared the debug logs (which are pretty sparse) and it doesn't seem to show any log for the bundle. It seems to download the controller (app), driver (bed) and then jumps straight to installing the controller. e.g., I never see a line that says it's installing the library.
I read the code, I was wrong, it's bundle, app, driver (which makes more sense I think) but I can't see any reason it would be skipping the bundle for some hubs. As far as I can see, it reads the manifest JSON and then would just try to download the various parts prior to install and it logs when doing so but since we don't see logs for the bundle it seems like it just doesn't think there is one. Why this would work for some but not others is a mystery to me.
Thanks for this integration. I have a new sleep number bed and this is working well for me. The one odd thing is the bed name came back as a long random string of numbers. The child devices look and work normally despite this oddity.
I’m excited to use the presence to enhance my night time lighting rules.
1 Like
Glad this is working for you! The numbers are actually the identifier for the bed sides as per sleep number (whereas the other devices are virtual). So while it looks strange, it’s definitely intended 
Good to know. I thought there was some sort of weird translation issue going on like data flowing into an integer variable when it was expecting a string variable... spent too many years coding in FORTRAN I suppose.
I’ve been using this integration successfully and enjoying it a lot. But I see a few things that would be good to tweak. First, is there a way for the child devices to update immediately instead of waiting for the parent device to respond?
Also, for the light dimmer, I would see where in the code you use levels 1, 2, and 3 only and I think it would be better to set to Low for any dimmer 30% or below and High at 70% or above and Medium in between.
[EDIT - removed the Forever fixed idea, found that it is already there with a setting]
I can tweak my local version, but let me know if you like these ideas enough to issue an update. The edits seem easy so you could easily do it judging from how professional your code looks.
By the way, my bed is a Climate 360 so I can verify that this support works.
Here's the tweak I used:
// tweaked to support all levels; same original 3 plus the full slider range - Low is <= 30, High >= 70, 30 < MED < 70
if ( level == 3 || level >= 70 ) {
val = sHIGH
} else if ( level == 2 || level > 30) {
val = sMED
} else {
val = sLOW
}
type or paste code here
Would you consider adding the capability sleepSensor to the device driver? That way one can select just these devices in other apps based on this capability.
[EDIT] I went ahead and made a version that does this. I submitted a pull request for your consideration. It seems to work fine but I haven't fully battle tested it yet. If others want to try it now before merge, you can find it in the "kewashi" branch of my fork here:
Sorry for the slow response, I’m out of the country with very limited service (and no computer). I’ll be back in a few days and will take a look at your changes. All of them sound reasonable to me but I want to make sure changing the mapping doesn’t impact other users and use cases.
1 Like
