@aaronpk, I’m very interested in if you were able to get this to work with multiple strain gauges and how. I purchased a few of these strain gauges and they just arrived today so I’m playing around with them. I’d like to be able to measure either side of a king bed but I’m worried that I might not have enough resolution in the slats to detect one person’s side of the bed vs. the other. My wife definitely doesn’t want me using load cells (because then I can see weight). 
Thanks,
-Greg
It’s been working reasonably well actually! For the most part it can tell the difference between both sides of the bed. It only gets that wrong if one of us is sprawled out. But I have it set up to report “number of people in bed” into HA, which I use to affect other automations, for example:
That said, I’ve had a few problems with it over the last 6 months or so. Mainly the problem seems to be that the values tend to drift over time and I have to recalibrate the threshold for what “in bed” is. I wish I could figure out some way to trigger on the sharp change in value rather than looking for a simple cutoff, but I can’t figure out how to do that while also making it respond in under 0.5 seconds, which is my tolerance for whether it feels like it’s working correctly. So far, I’ve had to recalibrate it about 2-3 times in the last 6 months, so not too bad. And once it’s working, it works 99% of the time.
You can try the change rate attribute of the statistics sensor.
Will that respond within a half second though?
It will update as soon as your bed sensor updates. You will see negative spikes when the level changes from high to low rapidly and positive spikes when the level changes from low to high readings. Slow drift changes will be unnoticeable.
For quick responses you have to keep everything in esphome.io. I think you’ll have to use the delta filter in esphome.io. I’ve employed it in my laundry setup for detecting vibration of my washer and dryer and it works pretty darn well.
Before I used it, the sensors were just recording their value every minute and it was sensor data overload. I put charts on my HA page but they took a long time to load. I changed it to only update quickly (30s) when delta triggers otherwise update every 20 minutes, just to get a read. Leave the low resolution for stuff I don’t care about but use high resolution as soon as, and while, something is happening.
force_update: 1200s
vibration_update: 30s
delta_val: "1.25"
...
filters:
- throttle: ${vibration_update}
- or:
- heartbeat: ${force_update}
- delta: ${delta_val}
I’m not sure how you’re building your binary sensor to describe the on vs. off if someone is in bed but if you’re doing that in home assistant you should migrate it to esphome.io as well (template binary sensor). The more I learn about esphome.io the more I’m amazed.
Nope. I’ve used the statistics sensor in HA and looked at the change rate attribute quite successfully. Response time was very close to the 10sec I use for filtering in ESPhome.
Okay, technically you can use HA to do “quick” transitions but it isn’t a good idea if you can handle it from within ESPHome.io and it seems like Aaron can. If you do it with HA you’re spending a lot more resources and CPU cycles to do something you can do with much less processing/overhead. In my mind, it’s an efficiency waste. I prefer to do as much on an ESP8266 as possible before sending the results back to HA.
I agree but can ESPhome do change rate?
I didn’t actually find an advantage of using change rate as my sensor does not drift too much with temperature/humidity dead tree effects. So I dropped using it simply because it was an extra sensor I did not need.
I do have a slider I can use to set the in/out of bed threshold. I’ve been thinking of adding a bit of hysteresis (or two sliders, one for in bed level, one for out) to prevent the very occasional out of bed false trigger when moving during the night.
Now that ESPhome can import sensors from home assistant it would make sense to do this level comparison in ESPhome and only report change of state (in / out of bed) rather than reporting the level very frequently.
So I have esphome set up to do a first pass at filtering this data:
- platform: adc
pin: A0
name: "Bed Right"
update_interval: 100ms
attenuation: 11db
filters:
- sliding_window_moving_average:
send_first_at: 30
window_size: 30
send_every: 30
- or:
- delta: 0.3
- throttle: 120s
That effectively sends data to HA every 3 seconds or immediately if there is a change larger than 0.3. I then have HA configured to look for a simple above/below a value to determine in/out of bed.
If I were to use only the delta filter, I can’t rely on the fact that just because the value has gone up X means I’m actually out of bed. The values from the sensors drift over time, often where the drift is more than X. So I need some sort of threshold, or looking for a large change in a short period of time.
The problem with doing this 100% inside of esphome is that it essentially gives me no visibility in debugging it. If it fails to trigger, I won’t have any way to look at logs to find out why. The way it currently works I can at least go look at the last 24 hours of readings in HA and look at the values.
This might be the best option going forward. Right now I have to edit the HA config and restart it to change it.
Do you mean you’d still configure the threshold with your sliders in HA, but then the ESPhome device would read that value and only report data outside that range? That sounds potentially interesting. Got a link to the ESPhome docs on that feature? I can’t seem to find it.
Sort of. Instead of reporting values outside the range it would set/reset a template binary sensor in esphome. The state of this sensor (in/out of bed) is all that is reported to home assistant. I’m not sure if this:
Also I will still need to send the level of the strain gauge for display in home assistant so that I can see what to set the input_number to. However this can be at a much lower rate than the response time required.
It works. ESPHome:
binary_sensor:
- platform: template
name: "Master Bed Occupied"
lambda: |-
if (id(master_bed_sensor).state < id(trigger_level).state) {
return true;
} else {
return false;
}
sensor:
- platform: adc
pin: A0
name: "Master Bed Sensor"
id: "master_bed_sensor"
icon: mdi:hotel
update_interval: 1s
filters:
- multiply: 3.25
- sliding_window_moving_average:
window_size: 10
send_every: 1
- or:
- throttle: 180s
- delta: 0.05
- platform: homeassistant
name: "Trigger Level"
id: "trigger_level"
entity_id: input_number.master_bed_trigger_level
Home assistant, input_number:
master_bed_trigger_level:
name: Master Bed Trigger Level
min: 0
max: 2.5
step: 0.05
unit_of_measurement: V
icon: mdi:arrow-collapse-down
For you poor souls with a lot of noise in your sensor. Bad news:
Most probably its isn’t a issue with your power supply or connections.
I installed 2 sensors with the help of an ads1115 on to my standard ikea bed.
One sensor is working very well.
the other one not so much
Only issue I have now that I always take over her side of the bed as soon as she is getting up. 
that gets me such readings on the working sensor - somehow hard to interpreter.
@tom_l, I’m very interested in creating the same kind of thing you have with a velostat. I had previously purchased a set of strain gauge sensors but it turns out my bed doesn’t use slats. The entire subframe is steel so I have to take this another direction. I don’t suppose you could furnish details on what you used to build and how you built the velostat sensor?
Thanks,
-Greg
Duct tape, copper foil tape and velostat: Bed occupancy DIY sensor
There’s a better option here though: Bed occupancy sensor, using parts you have
LOL, awesome idea! I thought that was cloth or something. Fantastic!!
I am totally trying this right now. OMG.
What do you think the cause of the noise is then?
Crappy strain gauge amplifier?
I definitely expect it to be the case. New ones are on the way - First i gonna replace the amplifier and see whats going on. When this isn’t helping then it must be the gluing technique or the bend sensor itself. They should arrive soon, so i keep you posted.
Just FYI — Be sure to keep the sensor detection logic in the firmware at the sensor. The sensor should only ever show a binary state.
A lot of information can be determined by the raw data which is highly personal.
I did a project several years back on monitoring devices for an assisted living company. Along with a lot of other monitoring, they needed to know bed dwell time, and frequency/duration of night wanderings.
We had to tune the software at the sensor to force the sensor to be binary in|out (pots adj sensitivity for user weight.)
Let’s just say we learned a lot of things we didn’t really need to know.
What if that extra data is exactly what we want?
I want my bed to know if I’m in it and what I am doing as well. To trigger automations and what not.
It can also track my weight change.
