Tasmota Integration does not set device_class of my smartmeter reader correctly

[Subito]

The problem

The Tasmota Integration Auto-Detects my Smartmeter-Reader, but fails to set some attributes correctly. device_class, state_class and unit_of measurement don't get set. That means that I can't add the SmartMeter Reader to the Energy Dashboard.

Is there any more information that could help? I'm using a pre-manufactured bitShake-SMR. Here are some informations:

Tasmota Version 13.0.0(tasmota32)
Erstellungs-Datum & -Uhrzeit    2023.08.09 13:17:09
Core-/SDK-Version   2_0_10/4.4.5.230614

What version of Home Assistant Core has the issue?

core-2023.11.2

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Tasmota

Link to integration documentation on our website

https://www.home-assistant.io/integrations/tasmota

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @emontnemery, mind taking a look at this issue as it has been labeled with an integration (tasmota) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `tasmota` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign tasmota` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

tasmota documentation tasmota source _{^{(message by IssueLinks)}}

[jens-fluegel]

I am facing the exact same issue. I have smartmeter providing consumption and feed-in counter but only consumption entity is correctly created by the tasmota integration. Because the entity is created and updated automatically I unable to correct that manually.

This is the sensor data being send to the mqtt broker:

The Tasmota integration creates all three entities but the feed-in ("Supply") is missing the the device_class, state_class and measurement.

Where is documented what the correct mqtt value are so that the Tasmota integration identifies the values correctly?

This is the corresponding bitShake smartreader script to get the sensor data into mqtt: `>D

B ->sensor53 r M 1 +1,5,s,16,9600,Energy 1,77070100010800ff@1000,Consumption(1.8.0),kWh,Total,16 1,77070100020800ff@1000,Feed-in(2.8.0),kWh,Supply,16 1,77070100100700ff@1,Current Power,W,Power,16

`

Would great to get a solution soon.

[Speedymatze]

Habe das gleiche Problem, gibt es dafür keine Lösung?

[step21]

Soweit ich weiß ist die Lösung das man es in der config.yaml konfiguriert. Macht vielleicht auch Sinn weil man ja nicht unbedingt alle möglichen Sensoren in der Energieübersicht will.

[Speedymatze]

Alles klar, also wird der Fehler nicht sinnvoll behoben, schade.

[step21]

Wenn müsste das Tasmota machen glaub ich, weil vom Gerät nicht notwendigerweise mitgegeben wird was es ist.

[emontnemery]

@step21 @Speedymatze Please don't use German on the issue tracker.

[emontnemery]

The root problem is that the sensor definition in Tasmota firmware leaves too much freedom, and Home Assistant needs to guess what kind of sensor is connected. Please share the output of command status 8 on the console.

[Subito]

Here is my status 8 output:

08:51:57.771 CMD: status 8 
08:51:57.779 MQT: stat/tasmota_B7FAC0/STATUS8 = {"StatusSNS":{"Time":"2024-03-06T08:51:57","SM":{"1_8_0":7555000.000,"1_8_1":0.000,"1_8_2":0.000,"2_8_0":0.00000000,"16_7_0":0.00,"36_7_0":0.00,"56_7_0":0.00,"76_7_0":0.00,"96_1_0":"XXXXXXXXX"}}}

I'm currently working around this issue by creating a sensor that maps to the desired state but has the correct attributes set:

- sensor:
    - name: Electricity Meter Total
      unique_id: electricity_meter_total
      attributes:
        device_class: energy
        unit_of_measurement: Wh
        state_class: total_increasing
      state: "{{ states.sensor.bitshake_smartmeterreader_sm_1_8_0.state }}"

[emontnemery]

Thanks @Subito 👍

"1_8_0", "1_8_1" etc. are OBIS data points. I think the way forward is to teach the Tasmota Home Assistant integration about these.

@jens-fluegel Your issue is different, what Tasmota sensor have you configured?

[jens-fluegel]

Here is my status 8 output:

13:19:43.278 MQT: stat/fluegel_smartmeter_1/STATUS8 = {"StatusSNS":{"Time":"2024-03-10T13:19:43","Energy":{"1_8_0_Consumtion":6076,"2_8_0_Feed-in":8709,"Power":5}}}

I am using the following Tasmota sensor: Tasmota Version: 13.0.0(tasmota32) Core-/SDK-Version: 2_0_10/4.4.5.230614

The OBIS data point could be one approach or some key works in the data record name let the Tasmota Home Assistant set the right attributes. If I do change "1_8_0_Consumption" to just "Consumption" it works but it does not work for the second data record. Even if I change it to "2_8_0_Consumption" or just also "Consumption" the second sensor does not have the right attributes.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[Subito]

This issue is still relevant

[MarcusLerch]

I’m facing the same issue, is there any update or a workaround?

[step21]

I’m facing the same issue, is there any update or a workaround?

If I remember correctly the solution was to reset the tasmota device (and remove all remnants) and then for usage over time create an extra custom entity.

[Subito]

@MarcusLerch I worked around it by wrapping it in another sensor which has the correct state_class set and gets its state from the original sensor:

- sensor:
    - name: Electricity Meter Total
      unique_id: electricity_meter_total
      attributes:
        device_class: energy
        unit_of_measurement: Wh
        state_class: total_increasing
      state: "{{ states.sensor.bitshake_smartmeterreader_sm_1_8_0.state }}"

[MarcusLerch]

Thanks @Subito and @step21. Defining the sensor in a template in configuration.yaml didn't work out for me, but pointed me in the right direction. I used a helper to define essentially the same thing and even used the same state definition. After that it showed up in the energy dashboard and it now works like a charm.

[ristomatti]

While I did not find the answer to the issue I'm experiencing from this thread, I suggest a simpler solution to this issue. I have a bunch of devices running an ancient version of Espurna which I cannot be bothered to update. That old Espurna firmware has MQTT based HA integration built in but it uses some no longer supported attributes for all the energy sensors. To fix the problem, I didn't create a template sensor or a helper but instead I've added a customize.yaml config file that corrects the attributes.

Here's an example config which I'd believe could be used as a workaround to this issue with Tasmota as well:

sensor.electrolux_ac_current:
  friendly_name: AC Current
  device_class: current
  icon: mdi:current-ac
sensor.electrolux_ac_voltage:
  friendly_name: AC Voltage
  device_class: voltage
  entity_category: diagnostic
  icon: mdi:sine-wave
sensor.electrolux_ac_power:
  friendly_name: AC Power
  device_class: power
  state_class: measurement
  icon: mdi:flash
sensor.electrolux_ac_reactive:
  friendly_name: AC Reactive Power
  device_class: power
  entity_category: diagnostic
  icon: mdi:flash  
sensor.electrolux_ac_apparent:
  friendly_name: AC Apparent Power
  device_class: power
  entity_category: diagnostic
  icon: mdi:flash
sensor.electrolux_ac_factor:
  friendly_name: AC Power Factor
  device_class: power_factor
  entity_category: diagnostic
  icon: mdi:alpha-f-circle-outline
sensor.electrolux_ac_energy:
  friendly_name: AC Energy
  device_class: energy
  state_class: total_increasing
  icon: mdi:lightning-bolt