Hello! I just came across this and I’m trying to figure it out without getting into vibe coding. Can anyone point me in the right direction? The hardware looks promising, but I don’t know where to start since I’ve never used ESPHome
3 Likes
An alternative approach could be to use Zigbee pressure sensors, which will probably be easier to integrate with HE.
Below are some random AliExpress sites offering similar sensors :
Found one on Amazon :
4 Likes
If you happen to have an instance of Home Assistant you are running along with Hubitat these are extremely easy to setup in HA. Their directions are spot on and takes just minutes. The sensor works extremely well and does come over to HE via HADB with no issue.
I can also personally vouch for the service and customer care of this small private company as I did have a bad pressure strip. They promptly replied to emails and helped troubleshoot. Then immediately sent me a replacement strip.
If you are not using an instance of HA as well with your HE I would also recommend sticking to some form of the Zigbee sensor as it would be much easier to integrate.
2 Likes
If you want to try something easier, I've made an application that uses motions sensors and vibration sensors to detect if you're in, or out of bed.
2 Likes
@kkossev
I bought one of the zigbee
but I cannot get any data from it.
I did try a generic zigbee contact and pressure sensor, and nothing....
SO
I tried your zigbee reporting configuration driver and here is the log:
dev:39102026-05-09 13:06:12.641
info
Pressure is not supported!
dev:39102026-05-09 13:06:10.643
info
Pressure is not supported!
dev:39102026-05-09 13:06:08.840
error
java.lang.NumberFormatException: null on line 346 (method parse)
dev:39102026-05-09 13:06:08.765
error
java.lang.NumberFormatException: null on line 346 (method parse)
dev:39102026-05-09 13:06:08.679
error
java.lang.NumberFormatException: null on line 346 (method parse)
dev:39102026-05-09 13:06:08.645
info
Pressure is not supported!
dev:39102026-05-09 13:05:55.838
info
The Bed received Power Source: 03
dev:39102026-05-09 13:05:55.674
error
groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.math.BigDecimal#. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [class java.lang.String] [class [C] on line 432 (method parse)
dev:39102026-05-09 13:05:55.285
warn
Unsupported Attributte 0021
dev:39102026-05-09 13:05:55.284
warn
processGlobalCommand 0001 (read attribute response) UNKNOWN clusterId: 0001 data:[21, 00, 86]
dev:39102026-05-09 13:05:54.419
error
java.lang.NumberFormatException: null on line 346 (method parse)
dev:39102026-05-09 13:05:54.403
error
java.lang.NumberFormatException: null on line 346 (method parse)
dev:39102026-05-09 13:05:54.286
warn
Unsupported Attributte 0020
dev:39102026-05-09 13:05:54.285
warn
processGlobalCommand 0001 (read attribute response) UNKNOWN clusterId: 0001 data:[20, 00, 86]
dev:39102026-05-09 13:05:53.945
info
The Bed received Model Identifier: TS0601
dev:39102026-05-09 13:05:53.861
info
The Bed received Manufacturer name: _TZE200_seq9cm6u
dev:39102026-05-09 13:05:40.474
info
parseAttributes: HW version: 01
dev:39102026-05-09 13:05:40.405
info
The Bed received Applicaiton version: 69
dev:39102026-05-09 13:05:40.403
info
The Bed received Model Identifier: TS0601
dev:39102026-05-09 13:05:40.277
info
The Bed received Applicaiton version: 69
dev:39102026-05-09 13:05:39.733
info
parseAttributes: ZLC version: 03
dev:39102026-05-09 13:05:38.307
info
parseAttributes: HW version: 01
dev:39102026-05-09 13:05:37.740
info
The Bed received Applicaiton version: 69
dev:39102026-05-09 13:05:36.146
info
The Bed received Manufacturer name: _TZE200_seq9cm6u
dev:39102026-05-09 13:05:36.015
info
parseAttributes: ZLC version: 03
dev:39102026-05-09 13:05:35.983
info
The Bed received Applicaiton version: 69
dev:39102026-05-09 13:05:35.901
info
parseAttributes: ZLC version: 03
dev:39102026-05-09 13:05:35.828
info
parseAttributes: ZLC version: 03
dev:39102026-05-09 13:05:35.824
info
The Bed received Applicaiton version: 69
dev:39102026-05-09 13:05:35.754
info
parseAttributes: ZLC version: 03
dev:39102026-05-09 13:05:35.535
debug
The Bed sendZigbeeCommands received : [he raw 0xF441 1 0x01 0x0000 {10 00 00 00 00}, delay 100, delay 2000, delay 100, he raw 0xF441 1 0x01 0x0000 {10 00 00 01 00}, delay 100, delay 2000, delay 100, he raw 0xF441 1 0x01 0x0000 {10 00 00 03 00}, delay 100, delay 2000, delay 100, he raw 0xF441 1 0x01 0x0000 {10 00 00 04 00}, delay 100, delay 2000, delay 100, he raw 0xF441 1 0x01 0x0000 {10 00 00 05 00}, delay 100, delay 2000, delay 100, he raw 0xF441 1 0x01 0x0000 {10 00 00 06 00}, delay 100, delay 2000, delay 100, he raw 0xF441 1 0x01 0x0000 {10 00 00 07 00}, delay 100, delay 2000, delay 100, he raw 0xF441 1 0x01 0x0001 {10 00 00 20 00}, delay 100, delay 2000, delay 100, he raw 0xF441 1 0x01 0x0001 {10 00 00 21 00}, delay 100, delay 2000, delay 100, he raw 0xF441 1 0x01 0x0402 {10 00 00 00 00}, delay 100, delay 2000, delay 100, he raw 0xF441 1 0x01 0x0403 {10 00 00 00 00}, delay 100, delay 2000, delay 100, he raw 0xF441 1 0x01 0x0405 {10 00 00 00 00}, delay 100, delay 2000]
dev:39102026-05-09 13:05:35.512
debug
The Bed sending delayed command refreshAll
dev:39102026-05-09 13:05:35.511
debug
The Bed reading command refreshAll
dev:39102026-05-09 13:05:29.889
info
The Bed queued command refreshAll
dev:39102026-05-09 13:05:18.578
info
Zigbee Reporting Configuration - no automatic configuration on re-pair...
dev:39102026-05-09 13:03:54.226
info
zdo command: cluster: 0013 (device announce)
It does pair to HE initially as "device" but I tried different drivers, and nogo!
Of course when changing drivers, I always clicked configure....
1 Like
Maybe it requires a Spanish driver?
3 Likes
....well I am planning to use it for my bed....
GET IT, GET IT???? bed/OLAY??? 
This device uses Tuya-specific Zigbee commands - please test and follow-up here :
1 Like
@kkossev Thank you for the info. Very nice sensor.
I ordered one (long, 70 sm) to check how this toy is working. I like the sensor strip itself but the way it reports status to HE is not reliable. In the free air everything is OK. But when I placed the sensor in a bed under the sheet reporting "closed" (i.e. bed occupied) status is fast and very consistent. However, when bed becomes unoccupied reporting "open" status is very unreliable. Sensor may switch to open after very long unpredicted delays or may stay in the "closed" state forever. But this depends on how sensor is placed and what is above it when bed is not occupied. The experience could be very different for different users and installations. In my case the sensor is placed under the sheet (not under the matrass!) and covered only with a blanket when bed is unoccupied. This happens to be enough for the very unreliable “open” (i.e. unoccupied) detection. However, without the blanket sensor responsiveness is near ideal.
So "as is" sensor may not be reliable as a "bed presence" sensor.
But the good news is: physically this sensor is a variable resistor. My plan is to use ESP32 ADC and create a DIY Bed Presence Sensor. Output from the sensor (resistivity) follows nicely the applied pressure. So, with the appropriate values for the Threshold and Hysteresis sensor should detect bed occupancy very precisely. I already have ESP32-Hubduino DIY Bed Controllers for my adjustable beds. So, adding ADC-based Bed Presence Sensor will not be a big deal. I like the sensor strip itself, so I ordered two more of these.
PS.
@kkossev your current driver presents this sensor to HE as a contact sensor. By any chance does it send an analog value out? If "yes" then adjustable threshold and hysteresis may fix the problem.
1 Like
The Tuya Zigbee Contact Sensor++ driver latest version '1.3.0', time stamp '2026/05/11 11:08 AM' exposes the analogue value (I have named it 'rawPressure').
Wel, sounds very good.
I am using exactly this driver but I don't see this Attribute:
Surprisingly I am seeing "illuminance"?
Is this a actually a "pressure" value?
Anyway, this is very good that the Device exposes an analog pressure value.
My suggestion is:
- please add a configurable threshold for the "closed" state;
- and add a configurable threshold for the "open" state;
This effectively will create “hysteresis".
With his extra function in a driver users will be able to fine tune sensor sensitivity according to the specific setup.
PS.
Also, I think this Sensor should have a dedicated driver (but this is just my opinion).
Update the driver, it is W.I.P. and I do not bump the driver version when the newly added code is not verified to be working OK.
I read somewhere that this device auto-calibrates when the batteries are inserted.
I don’t know if this driver uses this technique, but “illuminance“ can be used to spoof analog values, such as air pressure, bed pressure, etc.
This was exactly the case yesterday, but I think that it is better to use a non-standard custom attribute, rather than misuse a standard HE capability.... so I changed it to 'rawPressure'.
1 Like
Do I have to do this manually?
My preference is to use HPM.
Maybe. But is very questionable because for autocalibration you have to:
- Install sensor where it needs to be placed.
- simulate a condition for open/closed but device must know it is doing calibration.
This is not the case. So, I am very skeptical about this auto-calibration option (if it exist).
Anyway, I am planning to use only a Sensor Strip connected to the ESP32 ADC Input Pin.
This way I can fine tune a sensor for the very specific environment.
BTW, this sensors will eliminate my cloud dependency once and for ever. My current Bed Presence Sensor is a Withing Pads but they are cloud-based. So, Bye! Bye! very last cloud-based integration.
1 Like
Performing HPM 'Repair' will also update the driver to the latest version.
I don't have this device, so until it is tested and confirmed to be working OK with the new device, I can't push automatic updates via HPM.
OK, I performed an HPM Repair but this did not change a picture:
I am still seeing an “illuminance” attribute instead of “rawPressure”:
I agree about automatic updates via HPM option.
But really you should add user-configurable options for closed/open thresholds in addition to whatever defaults you have now (since sensor output is analog you driver must have a built-in thresholds but I am to...o lazy to check a driver code).
You might try setting your driver to "DEVICE", then in the commands tab, clicking on all of the "DELETE" buttons. Then set your driver back to @kkossev's driver.
2 Likes
Sure, already did this. But no change, everything is the same.
Frankly I don't care because my plan is to add just a Sensor Strip (which is nothing more than very sensitive variable resistor) to the existing Bed Controller(s) based on ESP32+Hubduino.
It will be handled by ESP32 ADC plus minor logic around. HE will see this sensor as a “contact”.
1 Like
