I created a pull request to add support for the sunbeam heated mattress pad (home-assistant/core#84869). It looks like the mattress pad and blanket use the same configuration.
4 Likes
Thanks for putting this out there. This was my first adventure into Tuya devices so it helped a lot.
Iāll add that I found the issue with Pre-heat not functioning correctly was due to the first two automations interacting with each other. Whenever āBED_Set Side A input number to match manual heat level changeā runs, it triggers āBED_Set heat level for Side Aā to also run. When the Pre-heat in enabled it seems to set the heat level value to 10 on the device, which then updates Home Assistant through the second automation, and then the first automation runs and overrides the pre-heat setting.
I didnāt need to control the pre-heat time, so instead of adding the āBED_Preheat Side Aā automation, I added a condition to the second automation checking if the Pre-heat was off and this prevented home assistant from cancelling pre-heat and losing the ideal heat setting.
I found something quite interesting - note that I do not have a king/queen-size but a full-size pad. My ID numbering is almost the same as listed above using āside Aā.
I recently changed WIFI and had to reset my mattress pad and the previous local key doesnāt work anymore (trial expired). Turns out I can re-register with a different email and got it going again. Because I was redoing everything, I decided to put the extra IDs that I had no idea what they were for as sensors (ID 13, 102, and 103). Here are what I found out about the āsafelyā feature:
-
The interesting one is ID 103 which has a value āUser_Confirmationā. When I turn the mattress pad on remotely, the value changed to ā45_minutes_beforeā. The value of ID 103 does not change if I turn the mattress on using the physical keypad.
However, when I push the physical button for the āsafetyā confirmation, the value changes back to āUser_Confirmationā. I am not sure if I can use HA to force this value to āUser_Confirmationā using a select or something. But what I found out next is a perfect workaround to the āsafetyā feature (I prefer not to āforceā a value to the API and break the system because I have no idea what that ID is for). -
It turns out that if you do not use the āPowerā (ID 14 in my case) to turn on the mattress remotely, the ID 103 will never change to ā45_minutes_beforeā and no user confirmation is required. There are 2 ways to turn the mattress on without using the āpowerā switch:
a) The preheat switch will turn on the mattress without requiring the safety confirmation
b) Change the power level will also turn the mattress on without requiring the safety confirmation
I will be using the āpower levelā as a way to get around the safety āfeatureā, which makes perfect sense if you use the tuya app. The app developer made an assumption that you cannot use the preheat function nor set the power level in the tuya app until you turn on the power. But then again developing API is a very different story, and they should not assume the flows in their app will be followed when the API is exposed.
I have attached two screenshots from my device - the āinitialā state showing āUser_Confirmationā message, and the one that showing ā45_minutes_beforeā message after I turn the mattress on using the power switch. Hope this help.
edit: I have not yet tested my observation above thoroughly but definitely will in the next few days. I also attached a screenshot after over an hour of turning it on using the power level only.
3 Likes
I think I may be seeing something similar to what you described. Would you mind dropping your automations/YAML, please?
Sorry for the late reply. I just saw the message. I ended up using the āpreheatā to remotely turn on the heated pad, then change the heat level. This way, the pad will turn on even if the heat level stays the same as last known value (the last heat level set before powering off).
Here is the YAML code from the visual edtor. I gave up learning the templating because my integration uses sensor temperature to adjust the heat level of my sunbeam but the ānoneā / āunavailableā status causes much trouble. I use this to turn on my heated pad on a schedule (start and stop time variable set using the helper). It will adjust the heat level throughout the night depending on my bedroom temperature (I set the max at level 5 which is hot enough for me lol).
Note: I have a separate automation to turn the heated pad off at the time set in input_datetime.bed_heater_automtion_end. Both automations are not optimized in any way but they work and much easier for me to update without thinking the edge cases 
Hope this is what you are looking for.
Post Edit:
- if you want to use the preheat, you can do that after setting the level, then turn on the preheat one more time. I did not do that in my automation. The first preheat action is to make sure that the heated pad will turn on remotely without requiring user confirmation. It has been working for me in the past week or so.
- I have a full-size heated pad, not queen/king so I do not have side A and B. Just side A.
- I also created a āvirtualā fan in YAML to put all entities together as a single āheated fanā device that can be exported to Alexa so that it can be controlled by voice.
āvirtualā entities used:
- input_datetime.bed_heater_automation_start (when to turn on the heated pad)
- input_datetime.bed_heater_automation_end (when to turn off the heated pad)
- input_boolean.bed_heater_automation_enabled (enabling automation)
Tuyaās entities used:
- switch.bed_heater_power (the on/off switch)
- select.bed_heater_level (the heat level)
- switch.bed_heater_preheat (the preheat on/off switch)
alias: Bed Heater Auto On
description: ""
trigger:
- platform: state
entity_id:
- sensor.bedroom_sensor_temperature
- platform: time
at: input_datetime.bed_heater_automation_start
id: automation_start
condition:
- condition: and
conditions:
- condition: state
entity_id: input_boolean.bed_heater_automation_enabled
state: "on"
- condition: numeric_state
entity_id: sensor.bedroom_sensor_temperature
below: 66
- condition: or
conditions:
- condition: trigger
id: automation_start
- condition: time
after: input_datetime.bed_heater_automation_start
before: input_datetime.bed_heater_automation_end
action:
- if:
- condition: state
entity_id: switch.bed_heater_power
state: "off"
then:
- service: switch.turn_on
data: {}
target:
entity_id: switch.bed_heater_preheat
- if:
- condition: numeric_state
entity_id: sensor.bedroom_sensor_temperature
above: 63
then:
- service: select.select_option
data:
option: "3"
target:
entity_id: select.bed_heater_level
else:
- if:
- condition: numeric_state
entity_id: sensor.bedroom_sensor_temperature
above: 60
then:
- service: select.select_option
data:
option: "4"
target:
entity_id: select.bed_heater_level
else:
- service: select.select_option
data:
option: "5"
target:
entity_id: select.bed_heater_level
mode: single
1 Like
https://fccid.io/2ANDL-WBR3 Hereās the FCC information on the tuya chipset in this one.
If Iām reading correctly from other descriptions of the WBR3 online say itās got a RTL8720CF. I donāt know if this is pin-compatible with any standard ESP chips, but it does look like itās on the roadmap for libretuya.
Just a thought for anyone willing to wait to have a fully non-tuya integration.
1 Like
For the people who have integrated this, is it working with localtuya on HACS or the built-in (cloud) Tuya integration?
So, asking for a friend ā¦ what is / are a ā@Participantā. You might consider a bit more sharing and transparency, IMHO.
To your question. I have been using the TinyTuya python library to interact with Sunbeam as a external proxy via MQTT to Home Assistant and Google voice (via Nabu Casa) for 6 months or so. It works, however not ideal. I think I like abstracting the Tuya stuff outside Home Assistant as much as possible until total non-cloud control possible. I would like to replace the Tuya firmware in the Sunbeam to make it 100% local control, however have not explored if possible as yet.
Using the TinyTuya interface āworksā however requires a level of monitoring that is not realistic for ārealā home automation and āsignificant otherā acceptance IMHO.
Good hunting!
im using localtuya on HACS
Yep, local Tuya been flawless for 1 yr+
As some mentioned in this thread, this device is using the WBR3 Tuya module - I followed Blakadderās module replacement guide, and confirmed that I can run Tasmota on the device with an ESP8266 dropped in. The housing can be opened relatively easily by removing the four feet + the screws thereunder - the module is on the reverse side of the PCB.
Iāve sent in a template to the repository, but hereās what Iām using right now:
{
"NAME": "Sunbeam Heated Blanket",
"GPIO": [0, 2272, 0, 2304, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
"FLAG": 0,
"BASE": 54,
"CMND": "DeviceName Sunbeam Heated Blanket|TuyaEnumList 1,9|TuyaEnumList 2,9|TuyaEnumList 3,9|TuyaMCU 11,1|TuyaMCU 61,4|TuyaMCU 12,8|TuyaMCU 13,14|TuyaMCU 14,15|TuyaMCU 62,20|TuyaMCU 63,21|TuyaMCU 15,24|TuyaMCU 16,25|TuyaMCU 0,28|TuyaMCU 0,29|WebButton1 Master Power|FriendlyName1 Master Power|WebButton2 Master Preheat|FriendlyName2 Master Preheat|WebButton3 SideA Power|FriendlyName3 SideA Power|WebButton4 SideB Power|FriendlyName4 SideB Power|WebButton5 SideA Preheat|FriendlyName5 SideA Preheat|WebButton6 SideB Preheat|FriendlyName6 SideB Preheat|Rule1 ON TuyaReceived#DpType2Id28 DO Publish2 stat/%topic%/TIMER1 %value% ENDON ON TuyaReceived#DpType2Id29 DO Publish2 stat/%topic%/TIMER2 %value% ENDON|Rule1 1"
}
I plan on getting it working with HomeAssistant soon, probably using one of the templates shared above as a baseline. If anyone has any examples of configurations that work with Google Assistant, Iād be extra-interested.
e: Learning some things about the timer functionality:
- Tasmota has a bug in handling timers with values greater than 32767, see Tasmota#18048. A workaround is to use the following rule: Rule1 ON TuyaReceived#DpType2Id28 DO Publish2 stat/%topic%/TIMER1 %value% ENDON ON TuyaReceived#DpType2Id29 DO Publish2 stat/%topic%/TIMER2 %value% ENDON
, but theTuyaMCU` setting will need to be changed to unbind the timers. Iāve changed the template above accordingly. - The sleep timer DPs (28, 29) are not really read/write, and are actually write-only. This means that the enum is the only way to set these values. Tasmota does not have enough possible enum types, so we can get around this by calling
TuyaSend4directly from HA.
Still working on getting it attached properly to HA.
e2: Got it working well with HA, hereās my configuration. Instructions are below:
# DIY Tasmota Sunbeam Heated Blanket
# Instructions:
# 1. Replace "TASMOTA__TOPIC" with the topic setting in Tasmota.
# (usually "tasmota_" plus the last six characters in the MAC address).
# 2. Replace "MAC__ADDRESS" with the full MAC address of the Tasmota device.
# 3. Rename this file to "configuration.yaml"
# 4. Make sure the Tasmota integration is turned on, and the device is reporting as expected.
# 5. Drop this in the config/packages/ha-sunbeam-tasmota directory (create it if it doesn't exist.
-----
mqtt:
select:
- unique_id: ha-sunbeam-tasmota-autooff-a
object_id: sidea_autooff
name: Side A Auto-Off
icon: mdi:bed-clock
command_topic: cmnd/TASMOTA__TOPIC/TuyaSend4
# The "0:00" setting will keep the blanket on.
command_template: >
{% if value == "0:00" %}
26,20
{% else %}
26,{{ this.attributes.options.index(value) - 1}}
{% endif %}
options:
- "0:00"
- "0:30"
- "1:00"
- "1:30"
- "2:00"
- "2:30"
- "3:00"
- "3:30"
- "4:00"
- "4:30"
- "5:00"
- "5:30"
- "6:00"
- "6:30"
- "7:00"
- "7:30"
- "8:00"
- "8:30"
- "9:00"
- "9:30"
- "10:00"
state_topic: stat/TASMOTA__TOPIC/TIMER1
value_template: >
{% if value|int > 36000 %}
0:00
{% else %}
{{ this.attributes.options[((value|int)/(60 * 60 * 0.5))|round(0,"ceil")|int] }}
{% endif %}
device:
name: Sunbeam Heated Blanket
connections:
- [ "mac", "MAC__ADDRESS" ]
- unique_id: ha-sunbeam-tasmota-autooff-b
object_id: sideb_autooff
name: Side B Auto-Off
icon: mdi:bed-clock
command_topic: cmnd/TASMOTA__TOPIC/TuyaSend4
# The "0:00" setting will keep the blanket on.
command_template: >
{% if value == "0:00" %}
27,20
{% else %}
27,{{ this.attributes.options.index(value) - 1}}
{% endif %}
options:
- "0:00"
- "0:30"
- "1:00"
- "1:30"
- "2:00"
- "2:30"
- "3:00"
- "3:30"
- "4:00"
- "4:30"
- "5:00"
- "5:30"
- "6:00"
- "6:30"
- "7:00"
- "7:30"
- "8:00"
- "8:30"
- "9:00"
- "9:30"
- "10:00"
state_topic: stat/TASMOTA__TOPIC/TIMER2
value_template: >
{% if value|int > 36000 %}
0:00
{% else %}
{{ this.attributes.options[((value|int)/(60 * 60 * 0.5))|round(0,"ceil")|int] }}
{% endif %}
device:
name: Sunbeam Heated Blanket
connections:
- [ "mac", "MAC__ADDRESS" ]
- unique_id: ha-sunbeam-tasmota-temperature-master
object_id: master_temperature
name: Master Temperature
icon: mdi:thermometer-lines
command_topic: cmnd/TASMOTA__TOPIC/TuyaEnum1
command_template: >
{{ value|int - 1}}
options:
- "1"
- "2"
- "3"
- "4"
- "5"
- "6"
- "7"
- "8"
- "9"
- "10"
state_topic: stat/TASMOTA__TOPIC/RESULT
value_template: >
{{ value_json.TuyaEnum1|int + 1 }}
availability_topic: tele/TASMOTA__TOPIC/LWT
payload_available: "Online"
payload_not_available: "Offline"
device:
name: Sunbeam Heated Blanket
connections:
- [ "mac", "MAC__ADDRESS" ]
- unique_id: ha-sunbeam-tasmota-temperature-a
name: Side A Temperature
icon: mdi:thermometer-lines
command_topic: cmnd/TASMOTA__TOPIC/TuyaEnum2
command_template: >
{{ value|int - 1}}
options:
- "1"
- "2"
- "3"
- "4"
- "5"
- "6"
- "7"
- "8"
- "9"
- "10"
state_topic: stat/TASMOTA__TOPIC/RESULT
value_template: >
{{ value_json.TuyaEnum2|int + 1 }}
availability_topic: tele/TASMOTA__TOPIC/LWT
payload_available: "Online"
payload_not_available: "Offline"
device:
name: Sunbeam Heated Blanket
connections:
- [ "mac", "MAC__ADDRESS" ]
- unique_id: ha-sunbeam-tasmota-temperature-b
name: Side B Temperature
icon: mdi:thermometer-lines
command_topic: cmnd/TASMOTA__TOPIC/TuyaEnum3
command_template: >
{{ value|int - 1}}
options:
- "1"
- "2"
- "3"
- "4"
- "5"
- "6"
- "7"
- "8"
- "9"
- "10"
state_topic: stat/TASMOTA__TOPIC/RESULT
value_template: >
{{ value_json.TuyaEnum3|int + 1 }}
availability_topic: tele/TASMOTA__TOPIC/LWT
payload_available: "Online"
payload_not_available: "Offline"
device:
name: Sunbeam Heated Blanket
connections:
- [ "mac", "MAC__ADDRESS" ]
3 Likes
Iām using it with localtuya via HACS. Itās connectivity has been solid.
Hereās how Iāve got mine set up with just built-in cards. Nothing toggles the power for the auto-off reasons listed above, so the bottom 3 buttons are for off only, while the top 3 initiate preheat, with a drop down for the current setting. I wish there were a service call to iterate (forwards and backwards) across the values in a select, because thatād enable +/- buttons on each side of a tile with the current value, but this works with no extras.
type: vertical-stack
cards:
- show_name: true
show_icon: false
type: button
tap_action:
action: call-service
service: switch.turn_on
data: {}
target:
entity_id: switch.master_bedroom_heated_blanket_master_preheat
entity: switch.master_bedroom_heated_blanket_master_preheat
icon: mdi:bed-king-outline
name: Preheat Whole Bed
icon_height: 30px
show_state: false
hold_action:
action: none
- type: horizontal-stack
cards:
- type: vertical-stack
cards:
- show_name: true
show_icon: true
type: button
tap_action:
action: toggle
entity: switch.master_bedroom_heated_blanket_left_side_preheat
icon: ''
name: Preheat
- type: entities
entities:
- entity: select.master_bedroom_heated_blanket_left_side_heat_level
icon: ''
secondary_info: none
name: ' '
state_color: true
- show_name: false
show_icon: true
type: button
tap_action:
action: call-service
service: switch.turn_off
data: {}
target:
entity_id: switch.master_bedroom_heated_blanket_left_side_power
entity: switch.master_bedroom_heated_blanket_left_side_power
icon: mdi:radiator-off
name: 'Off'
show_state: false
hold_action:
action: none
- type: vertical-stack
cards:
- show_name: true
show_icon: true
type: button
tap_action:
action: toggle
entity: switch.master_bedroom_heated_blanket_right_side_preheat
icon: ''
name: Preheat
- type: entities
entities:
- entity: select.master_bedroom_heated_blanket_right_side_heat_level
icon: ''
secondary_info: none
name: ' '
state_color: true
- show_name: false
show_icon: true
type: button
tap_action:
action: call-service
service: switch.turn_off
data: {}
target:
entity_id: switch.master_bedroom_heated_blanket_right_side_power
entity: switch.master_bedroom_heated_blanket_right_side_power
icon: mdi:radiator-off
name: 'Off'
show_state: false
hold_action:
action: none
- show_name: true
show_icon: false
type: button
tap_action:
action: call-service
service: switch.turn_off
data: {}
target:
entity_id: switch.master_bedroom_heated_blanket_master_power
entity: switch.master_bedroom_heated_blanket_master_power
name: Turn Blanket Off
icon: mdi:power-off
hold_action:
action: none
Received my Sunbeam heated mattress pad today. However, when attempting to add the device to the Tuya app, I am receiving a āDevice Adding Timeoutā error. I have tried this on my mixed 2.4 & 5Ghz network, as well as a separate 2.4Ghz network. This is my 10th Tuya device so I am not really new to the process. Additionally, the device adds right away to the Sunbeam app. Any thoughts?
Hope you can figure it out! I donāt have any suggestions, but I didnāt have any issue with my mixed 2.4 & 5Ghz network. So maybe the issue is unrelated to your network.
Iām having the same issues adding my blanket that @t.snow3 is reporting. The blanket works fine with the Sunbeam app, but for the life of me I canāt get it talking to the Tuya app. it āactsā like everything is fine, and then fails at the very end.
I wonder if the blankets (mattress pads) got a new firmware that the generic app doesnāt likeā¦
I know Iām slow to respond, but here is what I have setup. The condition is the only thing I added.
alias: BED_Set Side A input number to match manual heat level change
description: ""
trigger:
- platform: device
device_id: #######
domain: select
entity_id: select.side_a_heat_level
type: current_option_changed
condition:
- condition: state
entity_id: switch.side_a_preheat
state: "off"
action:
- service: input_number.set_value
data:
value: "{{ (states.select.side_a_heat_level.state | int) }}"
target:
entity_id: input_number.side_a_heat_level
mode: single
This one should be the same as what was originally shared, but here it is anyway:
alias: BED_Set heat level for Side A
description: ""
trigger:
- platform: state
entity_id: input_number.side_a_heat_level
condition: []
action:
- service: select.select_option
data:
option: "{{ (states.input_number.side_A_heat_level.state | int) }}"
target:
entity_id: select.side_a_heat_level
mode: single
I was having similar issues but spent more time in the tuya dev portal and found out there were some agreements and such that I had to still fill out
ESPHome just added TinyLibre, which can flash Tyuaās custom chips. Has anyone checked out what it would take to convert these pads?
Just got my mattress and it added to tuya just fine and I can control it in there, however in HA under tuya it lists the mattress pad but with no entities, any thoughts on why? I did the download diagnostics and I see commands in the json for it.