Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug with MH-Z19B and Home Assistant #4992

Closed
muuuh opened this issue Jan 20, 2019 · 9 comments
Closed

Bug with MH-Z19B and Home Assistant #4992

muuuh opened this issue Jan 20, 2019 · 9 comments
Labels
bug Type - Confirmated Bug fixed Result - The work on the issue has ended workaround Result - The work on the issue has ended with an alternative solution

Comments

@muuuh
Copy link

muuuh commented Jan 20, 2019

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,

@muuuh muuuh changed the title Bug with MHZ19B and Home Assistant Bug with MH-Z19B and Home Assistant Jan 20, 2019
@arendst
Copy link
Owner

arendst commented Jan 21, 2019

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.

@arendst arendst added bug Type - Confirmated Bug help needed Action - Asking for help from the community labels Jan 21, 2019
@andrethomas
Copy link
Contributor

andrethomas commented Jan 21, 2019

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"}

@arendst
Copy link
Owner

arendst commented Jan 21, 2019

That's why I love this issue list.

Will make the change as suggested.

@andrethomas
Copy link
Contributor

That's why I love this issue list.

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

@arendst
Copy link
Owner

arendst commented Jan 21, 2019

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...

@andrethomas
Copy link
Contributor

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.

@arendst
Copy link
Owner

arendst commented Jan 21, 2019

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

arendst added a commit that referenced this issue Jan 21, 2019
6.4.1.10 20190121
 * Fix Hass discovery of MHZ19(B) sensors (#4992)
@arendst arendst added fixed Result - The work on the issue has ended workaround Result - The work on the issue has ended with an alternative solution and removed help needed Action - Asking for help from the community labels Jan 21, 2019
@andrethomas2
Copy link
Collaborator

Closing this issue as commit dcabb9c which was merged to development should solve this issue.

Support Information

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

@muuuh
Copy link
Author

muuuh commented Jan 22, 2019

Thank you! Works for me

gemu2015 pushed a commit to gemu2015/Sonoff-Tasmota that referenced this issue Jan 27, 2019
6.4.1.10 20190121
 * Fix Hass discovery of MHZ19(B) sensors (arendst#4992)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Type - Confirmated Bug fixed Result - The work on the issue has ended workaround Result - The work on the issue has ended with an alternative solution
Projects
None yet
Development

No branches or pull requests

4 participants