Sleep Number: When the Mattress Joins the Automation System
Turning presence, comfort settings, and bedtime routines into useful automation
Sleep Number: When the Bed Knows You’re Home
Not in the HomeSeer store quite yet. It’s been running here every day, and the plan is to send it to the store as a beta.
Somewhere along the way, beds acquired cloud accounts.
Mine happens to know quite a bit about what is going on.
Who is assigned to each side.
Whether someone is actually in that side of the bed.
What firmness each side is set to.
What position the adjustable base is in.
Whether the foot warmer is running.
Which sounds faintly ridiculous right up until you realize something important:
A bed is actually a remarkably good occupancy sensor.
It does not decide you have disappeared because you have been lying perfectly still for twenty minutes.
It does not need motion to prove you are still there.
And, at least in my house, it does not enthusiastically report every visit from the cat as though someone has retired for the evening.
If the bed says someone is in it, that is a very useful thing for HomeSeer to know.
The slightly awkward part is that Sleep Number does not publish the API behind all of this.
So this one began with reverse engineering.
Mapping first, coding second
Before writing the plugin itself, I spent a session probing the live account in a deliberately read-only way and documenting what the service actually returned.
Not what a feature list suggested it might return.
Not what somebody remembered from a forum post.
Not what another integration assumed.
What the live service actually did.
That record became the working contract for the plugin.
Anything I directly observed is documented as observed.
Anything inferred is marked as inference.
Anything not tested is labeled accordingly.
That may sound overly cautious.
It pays for itself the first time something changes.
Without that baseline, when the integration breaks six months later the question becomes:
“Did Sleep Number change the API, or did I misunderstand it in the first place?”
With a capture of known-good behavior, that question has an answer.
I have become increasingly fond of answering questions with evidence rather than confidence.
The most expensive hour
One of the early discoveries was especially entertaining.
During testing, a 403 response did not mean my password was wrong.
The credentials were correct.
The service simply did not like the request as presented.
In the behavior I captured, the User-Agent mattered.
Use one the service did not recognize and the login failed with a response that looked very much like an authentication problem.
Use the expected client identity and the same credentials worked.
Those two situations were not distinguishable from the HTTP status code alone.
That is an excellent way to spend an hour retyping a password that was correct the entire time.
At some point you stop questioning the password and begin questioning your ability to type.
Eventually the network trace wins the argument.
That experience also reinforced why I wanted the API mapping written down before the plugin grew around it.
A 403 is a fact.
“The password is wrong” is an interpretation.
Those are not the same thing.
Two authentication paths, one actually needed
The service also exposed evidence of more than one authentication style.
There is a newer token-oriented flow.
There is also an older request-key style still represented in the service.
Only the token flow was required for this plugin.
So that is the one I implemented and tested.
The older path is noted in the research material, but it is labeled exactly for what it is:
Untested here.
Not:
Probably still works.
Not:
Should work based on older examples.
Untested.
Because “probably” has a bad habit of turning into “fact” after it has survived in a source comment for a year.
What the bed officially calls a Favorite
The adjustable base has its own built-in presets.
At first, those seemed like the obvious foundation for bedtime automation.
Save the position you like.
Recall it later.
Done.
And to be fair, that is exactly what the feature is designed to do.
Sleep Number’s own documentation describes a FlexFit Favorite as a saved base position.
Head position.
Foot position.
Per side where the base supports independent adjustment.
That works perfectly well for what it promises.
The trouble is that what I think of as:
“How I sleep”
is not just a base position.
It is several settings together.
Bedtime is more than an angle
For me, a bedtime state means something closer to:
Put the base here.
Set my side to this firmness.
Set the foot warmer the way I want it.
Those are three separate things.
The built-in FlexFit Favorite restores the position.
The Sleep Number firmness setting has its own separate Favorite.
Foot warming is controlled separately again.
Which means the manufacturer’s features are individually sensible, but there is no single built-in command that necessarily means:
Restore the complete state I personally call Bedtime.
That distinction becomes very obvious at approximately eleven o’clock at night.
You recall your favorite base position.
The bed moves exactly where it should.
And then you discover the firmness is still set to whatever somebody was experimenting with earlier.
Or the foot warmer is not where you expected it.
Nothing is broken.
Every individual feature behaved correctly.
They simply do not represent the same concept I wanted HomeSeer to represent.
So the plugin has its own favorites
The plugin therefore keeps its own named favorites, independently for each side.
A favorite can hold the settings that belong together from the automation point of view:
Base position.
Firmness.
Foot warming.
That means a HomeSeer favorite called:
Bedtime
can actually mean:
Put this side of the bed into the complete state I sleep in.
And another favorite can represent morning.
Or reading.
Or whatever combination makes sense.
This is a small feature.
It is also exactly the kind of small feature that becomes obvious only after living with the individual manufacturer controls for a while.
The hardware exposes settings.
The automation system gets to turn those settings into intent.
What the API surfaces
From the live service I tested, the plugin can obtain useful per-side information including:
Bed presence.
Assigned sleeper identity.
Sleep Number firmness setting.
And, depending on the installed base and options:
Foundation position.
Foot warming state and control.
The important qualification is that these are capabilities exposed by the account and equipment I actually tested.
Sleep Number has produced several generations of beds, bases, control systems, and optional features.
So the plugin does not pretend every account necessarily contains every capability.
It works from what the service reports for the actual bed.
That seems much safer than assuming:
“It says Sleep Number on the mattress, therefore it must support everything mine does.”
The presence sensor hiding in the mattress
The part I find most useful is still the simplest:
Is someone in bed?
The SleepIQ service has long exposed per-side isInBed information, along with the sleeper assigned to that side.
That turns the bed into something HomeSeer can use almost like a two-zone occupancy sensor.
Except it has one very useful advantage over motion.
A motion sensor observes movement.
The bed observes presence.
Those are related but different things.
Someone lying still for an hour is exactly what a bed is supposed to consider occupied.
And because each side is separate, the automation can know more than:
“There is motion in the bedroom.”
It can know:
“The left side is occupied.”
“The right side is occupied.”
“Both people are in bed.”
That creates much more useful automation conditions.
The interesting automation is everything around the bed
Once HomeSeer knows someone has actually gone to bed, a lot of other things become possible.
If both sides become occupied late at night:
Lock the house.
Turn off unnecessary lights.
Adjust the thermostat.
Quiet certain notifications.
Change exterior lighting.
Set nighttime modes.
Reduce whatever noise-producing automations make sense.
If one side gets up during the night:
Bring up a very low hallway light.
Do not light the house like an airport runway.
If both sides become empty in the morning:
Restore daytime behavior.
The bed itself is not really the interesting automation target.
It is the sensor that tells everything else:
The household has changed state.
That is much more useful than merely being able to adjust the mattress from HomeSeer.
Why the reverse-engineering notes matter
This is still an undocumented cloud API.
Sleep Number can change it.
They already have changed authentication behavior over time.
Community integrations have had to adapt repeatedly as endpoints, login behavior, and session handling evolved.
That is exactly why I wanted a clean line between:
What the company officially documents about the bed
and:
What I observed the private service doing.
The first is product behavior.
The second is implementation evidence.
Both are useful.
Only one comes with a promise from the manufacturer.
So when a future update breaks something, I do not want to be left with:
“I thought it worked like this.”
I want:
“On this date, this request returned this response. What changed?”
That is a much better starting point.
What I like about this one
The funny thing about this plugin is that the bed controls themselves are almost secondary.
Yes, HomeSeer can see firmness.
Yes, it can move the base.
Yes, it can control foot warming.
And yes, the plugin’s favorites let all of those settings travel together in a way the separate built-in favorites do not.
But the feature I value most is simply:
The bed knows someone is there.
Not because they moved.
Not because a motion detector saw something.
Because the bed itself knows it is occupied.
That turns out to be one of the most reliable signals in the house for answering a very human question:
Has someone gone to bed?
And once HomeSeer knows that, the useful automation is rarely the mattress.
It is everything else in the house knowing what time of the evening it has become.