After almost 30 years of having a queen bed (and 10 years of owning our current queen mattress from Casper), we finally upgraded to a king-sized bed with a new Tempur-Pedic TEMPUR-ProAdapt mattress and an adjustable power base. The TEMPUR-Ergo Smart Base might not be the typical kind of tech gadget I write about here, but it has USB-A and USB-C ports, WiFi, and is controllable via an app, so it qualifies! 🙂

The TEMPUR-Ergo Smart Base uses the SleepTracker AI STS-60 system which consists of specialized sleep tracking sensors (one for each side of the bed) along with the regular motors to raise the head, feet, and lumbar areas plus vibrating massage motors. Connecting the smart base to your wireless network allows you to use the SleepTracker app to track, monitor, and review your sleep habits (which are pretty accurate and detailed compared to what I get from my Apple Watch), along with remote control functions that mimic the physical remote control.

There’s also an Alexa skill but it’s very basic and not user-friendly. You can use voice commands to execute preset positions (TV mode, Zero-G, flat, favorites, etc.) but other control (like just raising my head or feet, or turning on massage mode) seems to fail (“I don’t know how to do that.”). The skill also specifically mentions you can use voice to control the under-bed lighting but I could not get that to work either. After a few days of this frustrating experience with the Alexa skill, I deleted it and started looking for other/better ways to control the bed and integrate it into my existing home automation setup with HomeSeer.

I didn’t get far with my research on the HS forums. Apparently older versions of the Tempur-Pedic smart bases used WiFi controllers and could be controlled with SSH/telnet commands, but the newer ones based on SleepTracker AI don’t work that way. So I hit a wall on the HomeSeer side but I did find current work being done for these smart beds in HomeAssistant.

I’ve played around with HA in the past but always bounced off of it. When I first encountered it in 2017 I was solidly in the ADT Pulse camp and when I re-designed my home automation system in 2021 I ended up selecting HomeSeer. HA is definitely more flexible (and thus, more complicated) but for whatever reason I just could never get myself to jump in completely. But now it looked like using HomeAssistant was going to be the best way to build some automations around my new smart bed so I started tinkering again.

Since my last encounter with HA I’m also now deep into running Docker containers on my Synology NAS so it seemed like using the container version of HA was the quick way to get started. But, the Docker version doesn’t support add-ons (which are separate from integrations) and of course my setup was going to require two add-ons: Mosquitto (an MQTT messaging broker) and smartbed-mqtt. It turns out that HomeAssistant add-ons are just more Docker containers so after going down a few more internet rabbit holes (like this article) I figured out how to run all three containers separately on my NAS and get them to talk to each other as if this was a normal HA OS install. My Docker compose file ended up looking like this:

version: '3.8'

services:

  smartbed:
    image: smartbed-mqtt
    container_name: smartbed
    restart: unless-stopped
    volumes:
      - /volume1/docker/smartbed/data:/data
    depends_on:
      - homeassistant
      - mosquitto

  mosquitto:
    image: eclipse-mosquitto
    container_name: mosquitto
    volumes:
      - /volume1/docker/mosquitto:/mosquitto
      - /volume1/docker/mosquitto/data:/mosquitto/data
      - /volume1/docker/mosquitto/log:/mosquitto/log
    ports:
      - 1883:1883
      - 9001:9001
    restart: unless-stopped

  homeassistant:
    image: homeassistant/home-assistant
    container_name: homeassistant
    environment:
      - PUID=1029
      - PGID=100
      - TZ=America/New_York
    volumes:
      - /volume1/docker/homeassistant/config:/config
    ports:
      - 8123:8123
    restart: always
    depends_on:
      - mosquitto

Which created and started the three separate Docker containers:

Logged into HomeAssistant then, I was then able to add the MQTT integration and set it up to use mosquitto running in its separate container. Getting the smartbed-mqtt add-on to run in its own container outside of HA took a little more work, but luckily in the Discord community someone had already come up with the instructions. This was my first real experience with actually building a Docker container and this also allowed me to make some minor changes to the run.sh script, primarily putting in a sleep delay (so the service wouldn’t start until HomeAssistant was completely up and running) also the required changes to the options.json file to set the MQTT host (again, the Mosquitto container) and my SleepTracker AI credentials.

After all of that, my smart bed device and its entities appeared in the HomeAsssistant UI!

Now I had basically replicated the remote control features of the SleepTracker AI mobile app in HomeAssistant but my primary control system is HomeSeer, so how to get HomeSeer and HomeAssistant talking to get HA entities into HS devices and features which could then be exposed to Alexa or controlled via HS events? Enter the AK HomeAssistant plug-in for HS4. I’ve used Alex’s HS4 plug-ins before (specifically AK WebIO for controlling my Digital Loggers Web Power Switch) and while the $40 for another plug-in just to control my smart bed seemed excessive, after working with the trial version for a few days it was obvious this solution was worth it to me.

After installing the plug-in, I set up the configuration with the IP address of the HomeAssistant container and a long-lived access token. The plug-in then connected to HA and let me choose the entities I wanted to pull into HS4, which created a device and those selected features:

I also created a new dashboard in HSBuddy to mimic the SleepTracker AI remote app (so I don’t need to use the HomeAssistant mobile app). At this point I could create events in HS4 but what I really wanted was better voice control with Alexa, so I exposed some of the features for voice control (which you can see by the microphone icons in the screenshot above), let Alexa discover them, and then built routines around them. Now when I say “Alexa, good night!” to our bedroom Echo, Alexa will arm the alarm, turn off the TV and the bedroom lights, then set the bed to our favorite position for sleeping and start a 30-minute massage. The only weird thing here is that the “press/push” devices (like the preset buttons or massage settings) in Alexa appear as on/off devices and for some reason always show as “on”. So in my routine, I had to send a command to turn off, and then on again in order for the action to actually execute. I had to get creative and throw in some “waits” (5 seconds is the lowest amount of “wait” time Alexa allows in a routine) for example, to make sure the bed was done moving into position before sending the massage commands, otherwise they’d get lost. And for the massage pattern, we like option #2, which on the physical remote requires pressing the button twice so in my Alexa routine I had to send “off/on, wait, off/on” to do that. I have a corresponding “good morning” routine that sets the bed back to the flat position and I can also now use Alexa properly to control the under-bed lighting.

The smartbed-mqtt add-on doesn’t expose all the features of the SleepTracker AI module, like presence detection (if someone is in bed) or the temperature or air quality or snoring sensors. It’d be cool to be able to create events to, say, turn on the under-bed lighting at night when someone gets out of bed, or turn down the thermostat if SleepTracker AI thinks the room is too warm for sleeping. But even considering all the network hops occuring in my setup (Alexa > HS4 > HomeAssistant > MQTT > SleepTracker AI > bed) there’s no noticeable lag and I have better control than with the default SleepTracker AI app and skill. Pretty cool!