@kewashi - Thanks for the pull request, things look good and I've updated the live version.
I was just curious what got changed and I think I spotted a mistake.
I added a comment on the commit at the line in question (see below).
Here is the resulting code where the case is missing
You are right - the case was over written by mistake. I don’t have outlets so I didn’t catch this. Easy fix. I’m away from my computer now but will submit another update later
I didn't catch that either - I blame my horribly jet lagged brain... I just fixed it and pushed the update. thanks for spotting it @jtp10181
Just a quick follow up to show how I'm using this. This is a screen shot of my Sleep Number bed on my HousePanel dashboard. This uses the main device, not the child ones.
Just yesterday (after this working for at least 18 months), I started getting a storm of errors in the logs for this app. I was in the child device and noticed most of the values (like head position) were reading null. At the bottom of the device, the parent app name read "Sleep Number Controller API error"
Following to the app, it seemed to be working (had valid values under diagnostics), but the logs were filled with attempts over and over with errors (I'll private message you because I'm not sure what headers I should share with everyone), but they begin with:
Retrying failed request {uri=https://prod-api.sleepiq.sleepnumber.com, path=/rest/bed/{bed number}/{specific bed properties}, requestContentType=application/json, contentType=application/json, headers
and end with
java.net.SocketTimeoutException: Read timed out
I tried to pause the app, but it has continued despite doing that.
I also get warn messages of
method finishGetAsyncFamilyStatus of app Sleep Number Controller (Paused) ran for 121,936ms
I'm also getting these (two for each side of the bed)
I'll send the full error privately.
Thanks!
Any time you get errors like that I would reboot the hub. Any other driver or app might be getting stuck and causing everything else to slow down.
I did that last night, but it didn't change. Seems to keep repeating when the refresh rate of the app fires.
I noticed an option to use a switch to disable refreshes. So I made a virtual switch and I'm hoping at least that stops the errors for now while I can then troubleshoot without them reoccurring.
I tried making a new app with same credentials and it logs right in. It doesn't seem to be my login. When I go to create bed it loads the sub page fast until I choose the option for child devices. Then it gets hung up and errors in the logs trying to query the API for what features there are. In the original app, it seems to be pulling these from CACHE.
Maybe some diagnostic trials I should try?
This looks like SleepNumber is just having issues and will hopefully clear up. I'd say reboot and then see if the errors clear up in a day or so. If the log messages are a bother you could make the logging less verbose or disable the app for a day (turning off the refresh period would suffice).
That's basically where I'm at now, so I'll check again after a day or so. What's odd is I can run a routine on my GH to raise the bed to a custom head position and it runs. Seems it's only affecting the pull of info from their API. Perhaps it's found that because of the cache you have in your app?
I'm guessing it's just acting up; they've had issues in the past as well. Looking at my logs, I see some errors from this morning but nothing recent (but I do back off the polling during the day so maybe I don't see as many due to that).
I don't know how they architect it but it's totally possible the servers that handle the data fetches are different than the ones that handle operating it and it wouldn't surprise me if they pay more attention to controlling settings vs. getting status.
I have it off for now with the virtual switch I mentioned. Normally I run it every 30 minutes daytime and every 2 at night (mode based control). Is that too frequent?
That’s about what I poll at and mine hasn’t shown an error since about 8am. I can’t say if they direct things regionally or not (which may cause different errors per location) but hopefully you’ll see things work again soon.