Units in SML to HA

[pawelka]

How to pass units from script to home assistant using tasmota integration?

I wrote SML script and I see all sensors in HA, but units where no configured. How unit are passed to HA during discovery "SO19 0" -> Home assistant integration.

[sfromis]

Assuming that you by "Unit" means which unit of measurement each number is in, that is generally implied in the /SENSOR payloads published. Tasmota only includes explicit unit when there are options allowing the user to select unit of preference, like temperature in C vs F.

For energy monitoring, the implied units are same as used on the front page of Tasmota, V/Hz/A/W/VA/VAr/%/KWh. These are not passed.

[pawelka]

Yes, unit of measurement. I have proper units on front page, but not in HA. "These are not passed." - it's by purpose or it's missing feature or technical limitation with HA tasmota integration?

[sfromis]

Tasmota has been focused on minimal resource usage (running on a tiny MCU, saving bytes is of value), with units not being "needed" when there was no alternative to the one used. And the units used by energy monitoring are pretty self-evident, those are already used "everywhere".

I'm not using HA, and do not know anything about the Tasmota integration there, but my assumption is that regular energy monitoring already integrates reasonably with HA. Thus, the integration is most likely supplying the units, alternatively relying on some sort of shared assumption with HA. With KWh being such a self-evident unit to use, units may not have to be carried around there either.

[emdekext]

I seem to have a similar problem: values of the Tasmota RG-15 (rain)sensor integration are passed on to HA using the HA Tasmota integration (not MQTT), and all sensors are shown without mm units, but the Total value is shown as kWh units.
I checked the MQTT messages and as sfromis states: units are not published in the payload. The "shared assumption" theory sounds logical, but somehow HA assumes no unit for the values "RG-15 active", "RG-15 flowrate" and "RG-15 event"; these units should be "mm" according to the tasmota devices webpage, accept voor flowrate this should be "mm/h". But HA or the integration does assume the "kWh" unit for the total rainfall value, this should of course be "mm".
I turned on the MQTT integration/discovery for HA and it shows the same behaviour.

Is there a way to force units from Tasmota?

[emdekext]

well that was easy to fix on the Home Assistant side, just follow these instructions: https://community.home-assistant.io/t/unit-of-measurement/208905/2

[tyeth]

well that was easy to fix on the Home Assistant side, just follow these instructions: https://community.home-assistant.io/t/unit-of-measurement/208905/2

Link is broken, but the text is correct and works if copy and pasted.
https://community.home-assistant.io/t/unit-of-measurement/208905/2

[fitim7]

I need this too ...

[MacSass]

Hello,
I´m working on a desktop app to allow monitoring / using Tasmota devices in a dashboard.
All is working fine by using the HTTP interface and evaluating the HTTP JSON status responses.

The issue I´m running into is that I can get the sensor values, but as I don´t know from the JSON what type of measurement it is, I cannot show the "units of measurement" on my dashboard.
Tasmota currently only provides those units of measurement where the user can choose between more than one.

Unfortunately e.g. some energy sensors sometimes report a mix of e.g. "W" and "kWh" for current values vs. totals. Other sensors like light meters might have different units of measurement too.

Would the effort to implement Tasmota returning the sensor values with units of measurement a complicated thing? My feel it should not impose too much on complexity / memory usage as Tasmota already "knows" the units of measurement (they are shown in the web-ui).

Would it be reasonable to ask to provide those units of measurement in JSON returned on http status 8 request?

Thanks for your inputs ...

[barbudor]

Status 8 do provide units that have alternatives : Temperature in °C or °F, pressure in bar ot mmHg, speed in kph or mph
But not for Energy units because there are no alternatives.

It's not that it is complicated, it is done for the units that have alternatives, but because Tasmota has to run on ESP8266 devices where flash size is constrainted, we are avoiding adding any code that do not really provide value.
Especially for Energy, there would be 6 different units which are fixed.

So I suggest that you assume those units.

[MacSass]

@barbudor: Thanks for the fast response. The issue is not mainly with energy sensors but the broad range of sensors that users can connect to their devices and they want to be seen in my dashboard app.

E.g. I might get something back like this:
StatusSNS":{"Time":"2023-01-29T20:09:51","Strom":{"Total_in":1849.108,"Total_inT1":1208.386,"Total_inT2":640.722,"Power_cur":419,"Total_out":0.139}}

How should I know what units those are in? (In fact three of them are in kWh, one in W ). Users might have light sensors connected and want me to show Lux - but how should I even know that it is a light sensor? I would have to parse the sensor type and have a lookup table to see that values and units of measurements it would report - virtually impossible with those large amount of sensors supported by Tasmota (luckily).

Currently I would only see the option to parse the web UI html which would be slow, put a lot of burden on the ESP and might be very reliable. Having those units of measurement would be of great help for everyone doing Tasmota dashboards.
I checked two Android and one iOS app - they all don´t show any units of measurement - I guess for the same reason.

[barbudor]

Which driver provide you that ?
JSON key are not supposed to be translated. This has to be fixed

Back to your original question, each measurment is well indentified by a JSON key and, apart for the 3 units already listed that have alternatives, Tasmota is using a single unit for each type measurment.
Current is always in Ampere
Iluminance is always in Lux
Unfortunately this is not documented and that would be a valuable information to add in the docs

[MacSass]

Thanks - that is very helpful information for my general understanding.
So it should be possible to implement a lookup-table in my app that matches each JSON key to a "unit of measurement" (with the two exceptions of temperature and pressure, for those they are provide in JSON directly).

Cumbersome but doable ... as you mention that this is not currently documented - would it be possible for me to find those references in the code? I tried to take a quick look at the different sensor drivers but could not figure it out from there.

In regard to above status 8 sample: It was send to me by a customer stating it was an "IR smart meter interface". I´ll try to get more information about what type exactly and report back.

[sfromis]

Here, you can see most of the units in use, including the ones reported in the JSON:
https://github.com/arendst/Tasmota/blob/development/tasmota/language/en_GB.h#L923-L973

And here, you can see many (note different wording) of the HTML formats used for units:
https://github.com/arendst/Tasmota/blob/development/tasmota/include/i18n.h#L893-L929

The various constants used for what gets on screen also have #define in the same files. Not all drivers are using such constants, making a "total list" hard to generate.

Including units in all drivers generating both JSON and HTML would be no small task, but a good lookup table for later unit-assignments is not trivial either....

[barbudor]

@sfromis I think you are pointing twice to the same place in code

The text for each JSON measurment key is there https://github.com/arendst/Tasmota/blob/development/tasmota/include/i18n.h
but it is mixed with other no-to-be-translated keywords

I'm afraid that you would have to go through the list of D_JSON_xxx in my link above to find everything that looks like a measurment.
Then find that macro in the code to check which unit is used.

Sorry that it not so ready-to-use

[sfromis]

Twice, yes, here's the HTML block (also edited above)
https://github.com/arendst/Tasmota/blob/development/tasmota/include/i18n.h#L893-L929

Keyword string constants are indeed not separate blocks.

And to reiterate, those links are not all units or sensors, some drivers have them directly in the code.

[MacSass]

Thanks for your helpful responses - although it seems hard to implement that by just parsing the JSON returned to Status 8.
When I look at the HTML block I´m not sure I understand how the units are derived ... e.g. there are two lines referring to current:

const char HTTP_SNS_F_CURRENT_MA[] PROGMEM = "{s}%s " D_CURRENT "{m}%*_f " D_UNIT_MILLIAMPERE "{e}"; const char HTTP_SNS_CURRENT[] PROGMEM = "{s}" D_CURRENT "{m}%s " D_UNIT_AMPERE "{e}";

How would I know that a sensor returns mA and not A? How do I get from the JSON keys like in here:

{"StatusSNS":{"Time":"2023-01-30T23:24:58","ENERGY": {"TotalStartTime":"2021-08-27T14:23:03","Total":9.837,"Yesterday":0.029,"Today":0.028,"Power": 1,"ApparentPower": 3,"ReactivePower": 3,"Factor":0.35,"Voltage":224,"Current":0.014}}}

to the reference "unit of measurement". E.g. I can´t find the "Yesterday" key in the tables you cross referenced.

Is this an example of where the driver has it in his code directly?

My only current workable idea is:

• I try to hard cod the most commonly used JSON keys to a certain unit of measurement and don´t try to support all types of sensors.
  I think as this is non trivial, this is the reason why the smartphone apps don´t show any units of measurement at all. :-).

Tasmota seems to do it in a smart way showing those in the HTML gui and I have no idea how complex / memory consuming it would be to add those in a "clean" way to the Status 8 JSON, but I think it would be the most reliable and future proof way, if having those in external apps is of interest for Tasmota.

[sfromis]

To get exact answers, you can "just" check the source code of every driver, and follow the path of which #define symbols are used there. Energy drivers are a bit special, as they are using a common energy framework for much of the processing, as lots of drivers have the same exact outputs.

What I posted was merely a partial selection of some common ones, as an illustrative starting point. Tasmota does not at all do it in a "smart" way, as most drivers are doing the formatting in the code, often (not always) using the constants I pointed at.

Sorry, there is no "clean" strategy to get broad coverage. The closest would be a bit of non-trivial source code analysis to construct tables, but that is pretty fragile as things are refactored or amended from time to time. Not really recommended.

[sfromis]

https://github.com/emontnemery/hatasmota has many constants included, for the HA Tasmota integration, which has parallels with what you're talking about.

Haven't studied it much, but these files looks relevant.....
https://github.com/emontnemery/hatasmota/blob/master/hatasmota/const.py
https://github.com/emontnemery/hatasmota/blob/master/hatasmota/sensor.py

[MacSass]

Thanks @sfromis and @barbudor - those informations were very helpful.
Although for me it would obviously easier if Tasmota would provide those units within the status 8 JSON I understand that would not so easy to implement as well.
I will look into having a lookup-table for the most commonly used sensor key names and use those units then. For the more exotic sensors they would have to go without units then ...

Thanks again for your support - in case there is any hope to get units from JSON in the future - that would be even better (I think for many external applications).

[tyeth]

I found the units problem before fascinating, surely solved many times over. I then today lost an hour looking at the json OGC(Open Geospatial Consortium) info which is the meat an potatoes of the issue, i.e. Sensing, and then eventually had a quick pour over the wiki page which leads to the task forces examples document. The long and short of it is that you get unitsOfMeasurement in this document, it goes on about properties and then tasks, and it's verbose in the initial descriptions / schema, but the submitting tasks json is very terse / short. Maybe it'll help someone.
https://en.wikipedia.org/wiki/SensorThings_API

[phiresky]

I found the other answers confusing since you have to choose your own name of the sensors in the Smart Meter Interface script, so I'm not sure what is meant by "it is implicit".

For the Home Assistant Tasmota integration, the map of MQTT key to unit of measurement is here:

https://github.com/emontnemery/hatasmota/blob/master/hatasmota/sensor.py#L153 (SENSOR_UNIT_MAP)

The corresponding constants are defined here:
https://github.com/emontnemery/hatasmota/blob/master/hatasmota/const.py

So in your Smart Meter Interface if you e.g. name your sensor "Power" it will get the correct icon and unit "W", if you name it "Energy" it will have unit "kWh".

with script:

1,77070100010800ff@1000,Gesamtimport,kWh,Energy,4
1,77070100100700ff@1,Leistung-aktuell,W,Power,2

tasmota will publish

{..., "Energy": 11.1111, "Power": 11.1111}

which in home assistant will show up as kWh and W correctly (not because of the unit_of_measurement field in the script but because of the magic name "Energy" and "Power"

[zwoabier]

@phiresky do you know where the actual mapping happens? Because I'm facing an issue with tasmota and ha discovery. I try to configure a electricity meter based on a sml scipt where I have 3 energy consumption readings (total, tariff_1 and tarif_2).

My problem is now that the json prefix I configure needs to be unique to get a sensor created in ha but if I add _1 or _2 to the well known mappings from here

My sml script in tasmota is like that

>D
>B
->sensor53 r
>M 2
+1,3,s,16,9600,Home,1
+2,5,s,16,9600,Total,4

1,77070100010800FF@1000,Consumption Total,kWh,Total,3
1,77070100010801FF@1000,Consumption Tariff 1,kWh,TotalTariff_1,3
1,77070100010802FF@1000,Consumption Tariff 2,kWh,TotalTariff_2,3
1,77070100020800FF@1000,Yield Total,kWh,Energy,3
1,77070100100700ff@1,Aktuelle Power,W,Power,0
1,77070100600100ff@#,Server-ID,,ID,0

2,=h====================================

2,77070100010800FF@1000,Consumption Total,kWh,Total,3
2,77070100020800FF@1000,Yield Total,kWh,Energy,3
2,77070100100700ff@1,Power,W,Power,0
2,77070100600100ff@#,Server-ID,,ID,0

This results in a discovery message like this

{
  "sn": {
    "Time": "2025-03-05T12:05:06",
    "Haus": {
      "Total": 129.105,
      "TotalTariff_1": 48.443,
      "TotalTariff_2": 80.662,
      "Energy": 102.203,
      "Power": -3835,
      "ID": "0a01454..."
    },
    "Gesamt": {
      "Total": 243.339,
      "Energy": 40.54,
      "Power": -3747,
      "ID": "0a01454..."
    }
  },
  "ver": 1
}

If I remove the _1 and _2 from the TotalTariff I end up with only one sensor because the aren't unique

{
  "sn": {
    "Time": "2025-03-05T11:52:14",
    "Haus": {
      "Total": 129.104,
      "TotalTariff": 80.662,
      "Energy": 101.976,
      "Power": -892,
      "ID": "0a01454..."
    },
    "Gesamt": {
      "Total": 243.337,
      "Energy": 40.331,
      "Power": -807,
      "ID": "0a01454..."
    }
  },
  "ver": 1
}

[sfromis]

The actual mapping happens where phiresky linked. If you want to use the unit mappings for additional values, you cannot modify the field name, not even by adding a suffix.

AFAICT, what could work would be a JSON array syntax like "TotalTariff":[48.443,80.662], or have multiple sensors like Haus_1 and Haus_2, each having a simple TotalTariff value.

The specific mapping from TotalTariff to KWh is this line:
https://github.com/emontnemery/hatasmota/blob/e17c2773f383eb81290bfc7207b5e639fc39f749/hatasmota/sensor.py#L178

[zwoabier]

Yeah by mapping I was thinking of parsing the json string like TotalTariff_1 and mapping to the type TotalTaiff.
Especially for energy meters it is common to have a two tariff meter (at least in Germany) what would require a TotalTariff_1 and TotalTariff_2 if we speak of energy meters and the sml addon for tasmota and HA.