Hi, I've a couple of chosry switched fused spurs, which are tuya devices. They've been reporting fine for years, but suddenly with the latest home assistant update they're reporting power, voltage and amps that are 7-15 times reality. They still report correctly in the tuya app. I think this started with 2026.2.0 but continues with 2026.2.1 example 233v in tuya (which is correct) 2308 in home assistant, maybe a factor of ten, maybe not... current is 12000mA in tuya and 196A in HA 🙁 I'm using the official tuya integration.
#TUYA fused spur returning bad data in 2026.2.0 and 2026.2.1
wooden oyster
wooden oyster
So, I'm not sure if anyone has seen this post, but I'll document what I know so far here. It appears that this device publishes updated values for current,voltage,power upon change. Home assistant has interpeted this as a delta value being provided to add to the existing record for the value, leading to the home assistant store of that value increasing like a total or total_increasing entity. A template which looks at the current vs previous value upon change and restores this value shows the data is correct, however when power/current return to zero (in this case I have thermostatically controlled heating elements attached to the spurs ) home assistant doesn't record an update. This is either because the value "0" is never sent (and tuya natively discovers power dropping to 0 another way that home assistant can't see) or home assistant interprets a "delta" of 0 as no change, and I don't get a timestamp to update power usage from.)
This is what i've generated so far to work around this issue: - trigger:
- platform: state
entity_id: sensor.jkfswifi_3_power
- platform: state
entity_id: switch.jkfswifi_3_socket_1
to: "off"
sensor:
- name: "JKFS Immersion Power Corrected"
unique_id: jkfs_immersion_power_corrected
device_class: power
unit_of_measurement: W
state_class: measurement
state: >
{% if states('switch.jkfswifi_3_socket_1') != 'on' %}
0
{% else %}
{% set new = trigger.to_state.state | float(0) %}
{% set old = trigger.from_state.state | float(0)
if trigger.from_state else new %}
{% set delta = new - old %}
{% if delta > 0 %}
{{ delta }}
{% else %}
{{ states('sensor.jkfs_immersion_power_corrected') | float(0) }}
{% endif %}
{% endif %}
This is what i've generated so far to work around this issue:
-
trigger:
- platform: state
entity_id: sensor.jkfswifi_3_power - platform: state
entity_id: switch.jkfswifi_3_socket_1
to: "off"
sensor:
- name: "JKFS Immersion Power Corrected"
unique_id: jkfs_immersion_power_corrected
device_class: power
unit_of_measurement: W
state_class: measurement
state: >
{% if states('switch.jkfswifi_3_socket_1') != 'on' %}
0
{% else %}
{% set new = trigger.to_state.state | float(0) %}
{% set old = trigger.from_state.state | float(0)
if trigger.from_state else new %}
{% set delta = new - old %}
{% if delta > 0 %}
{{ delta }}
{% else %}
{{ states('sensor.jkfs_immersion_power_corrected') | float(0) }}
{% endif %}
{% endif %}
- platform: state
discord seems unfriendly to yaml.... the bullets are in fact "-"
wooden oyster
Key finding (this is the root cause)
Your device’s instantaneous measurement DPS values are explicitly marked by Tuya as report_type: "sum", not "change" or "periodic".
From the diagnostics:
"cur_power": {
"type": "Integer",
"value": {"unit":"W","scale":1},
"report_type": "sum"
}
"cur_voltage": { ... "report_type": "sum" }
"cur_current": { ... "report_type": "sum" }
This is critically wrong for instantaneous sensors, and Home Assistant 2026.2.x now respects this metadata.
What this means in practice
Before 2026.2.0
Home Assistant:
Ignored Tuya report_type
Treated cur_power, cur_voltage, cur_current as plain measurements
Accepted repeated values, including 0
Updated timestamps even when the value did not “change meaningfully”
so this is an AI assessment of my conundrum, seems that I only have a "sum" device to work with, drops to zero in the source are essentially lost, I may have to switch to localtuya to override the device template?
wooden oyster
I've raised an issue: https://github.com/home-assistant/core/issues/162753
wooden oyster
I've successfully worked around this issue with localtuya, which takes a little bit of getting used to. but seems to work fine.
Local Tuya notes.....
My problematic devices are:
"model": "JKFSWiFi"
"productId": "hk29zes6edyyn34r"
Symptom "power" entity started increasing like a total_increasing sensor rather than instantaneous measure.
- I set up without the optional cloud integration for localtua. This appears to be because of some glitch between UK region and european region in the api...
Once you've got your tuya iot cloud project in a datacentre that recognises your tuya mobile account you can get details of your device from the IOT core api debug.
"Query Devices in Project" - gets you JSON output including:
"localKey" - which is the special sauce for getting localtuya to work.
"id" - this is the reverence which localtuya will be able to discover
If your home assistant is on the same lan/subnet as your tuya devices, (mine is) localtuya will be able to discover all the devices you have locally.
CRITICAL: DONT use the same "friendly" name as the presumably existing cloud tuya instance of the same device.
WARNING : LocalTuya doesn't seem to clean up when you delete a device and later recreate based of the same "id" - be warned, you may need to go into device registry surgery which isn't pleasant.
setup.
once you pick the device id on localtuya, add the localkey the only extra I did on the main page is set poll to 10 seconds (which is the recommended minimum, might not be necesary)
I found the local tuya setup a little tricky.
You are prompted to set up entities for your new device.
id 1) is a switch , ignore the extra elements.
add an extra device (uncheck the no more devices)
id 18 is a sensor, type current "A" scaling factor 0.001 (for my devices)
id 19 is a sensor, type power "W" scaling factor 0.1
id 20 is a sensor, type voltage "V" scaling factor 0.1
All of these sensors work correctly via localtuya but since 2026.2.0 not on cloudtuya.