Tasmota: Bug with MH-Z19B and Home Assistant

Created on 20 Jan 2019  路  9Comments  路  Source: arendst/Tasmota

Hi,

there is a bug with MQTT, Home Assistant, Home Assistant MQTT Discovery and the MH-Z19B (link).

It can be seen at the log files:

18:58:45 MQT: homeassistant/sensor/aaa_MHZ19_CarbonDioxide/config = {"name":"mhz MHZ19 CarbonDioxide","stat_t":"~SENSOR","avty_t":"~LWT","pl_avail":"Online","pl_not_avail":"Offline","unit_of_meas":" ","val_tpl":"{{value_json['MHZ19'].CarbonDioxide}}","uniq_id":"aaa_MHZ19_CarbonDioxide","device":{"identifiers":["aaa"],"name":"mhz","model":"Generic","sw_version":"6.4.1.8(sonoff)","manufacturer":"Tasmota"}, "~":"mhz/tele/"} (retained)

18:58:53 MQT: mhz/tele/SENSOR = {"Time":"2019-01-20T18:58:53","MHZ19B":{"CarbonDioxide":1619,"Temperature":25.0},"TempUnit":"C"}

The name of the json parameter is MHZ19, but the device name is MHZ19B (ending with B!). This results to Home Assistant not finding the correct json element which was announced and to 0 values.

Best regards,

bug fixed workaround

All 9 comments

Nice find.

The MHZ19 sensor can either be a MHZ19 or a MHZ19B. At restart init time the sensor is being forced as MHZ19 as it cannot be detected at that time as either MHZ19 or MHZ19B.

Once some reading has been taking from the device the correct version can be detected and the name might change to MHZ19B.

The problem with Hass detection is that it runs before the correct MHZ19 hardware version could be detected and you get the issue you noticed here.

Delaying HASS discovery is not really a solution as one never knows when the correct MHZ19 is detected so if someone comes up with a solution the Hass community would be happy.

One solution could be to keep the sensor name at MHZ19 and add a type variable to the JSON containing the data if anyone feels the need to use it then it will not cause the sensor name to change

type not yet determined:

{"Time":"2019-01-20T18:58:53","MHZ19":{"CarbonDioxide":1619,"Temperature":25.0,"Type":""},"TempUnit":"C"}

Type identified as A (or not B)

{"Time":"2019-01-20T18:58:53","MHZ19":{"CarbonDioxide":1619,"Temperature":25.0,"Type":"A"},"TempUnit":"C"}

Type identified as B

{"Time":"2019-01-20T18:58:53","MHZ19":{"CarbonDioxide":1619,"Temperature":25.0,"Type":"B"},"TempUnit":"C"}

That's why I love this issue list.

Will make the change as suggested.

That's why I love this issue list.

I'm in a room that has < 410ppm :)

Problem is if I change the name to MHZ19 sec it will probably rain issues of people who had a MHZ19B configured in Node-Red, OpenHab,...

I think the easiest solution is to name all MHZ19 types just MHZ19B. MHZ19 is an "older" model and I hope not many people are using this...

Yeah was just thinking I'd have to change my node-red... and we know how good us users are at reading release notes so probably best to assume MHZ19B irrespective which type is detected - I don't think the type has much use for end-user use case as the user would know which type is deployed and there isn't anything different to do on the home automation side whether its an A or B type - its just the data that matters.

Right. So I make it best of both worlds. I'll add the type field too and keep the name fixed at MHZ19B

Closing this issue as commit https://github.com/arendst/Sonoff-Tasmota/commit/dcabb9c6dc1668209a6a770446253b79efbe1cc5 which was merged to development should solve this issue.

Support Information

See Wiki for more information.
See Chat for more user experience.

Thank you! Works for me

Was this page helpful?
0 / 5 - 0 ratings

Related issues

TylerDurden23 picture TylerDurden23  路  3Comments

he-so picture he-so  路  3Comments

abzman picture abzman  路  3Comments

esp32x picture esp32x  路  3Comments

ximonline picture ximonline  路  3Comments