search

fmartinou / teleinfo2mqtt

Publish teleinfo to mqtt topics
https://fmartinou.github.io/teleinfo2mqtt
MIT License
64 stars 17 forks source link

Fix inconsistent hass configuration when processing incomplete frames #62

Closed madmatah closed 9 months ago

madmatah commented 10 months ago

Hello!

I use teleinfo2mqtt in Standard mode. I noticed a strange behavior with the teleinformation data transmitted to Home Assistant: some values were completely absent (e.g. SINSTS), while other data were correctly transmitted and regularly updated. Restarting the teleinfo2mqtt service fixed the problem, but the behavior was rather random and I encountered the same problem with other values.

After a few debugging sessions in teleinfo2mqtt, I realized that there was a lot of interference on my serial link, despite the shielded cable used (the Linky meter is outside my house, more than 30m away).

As a result, a lot of values are corrupted. Looking at the frames emitted by the StandardTicMode service, I found that they contained between 25 and 40 labels and that I almost never had a "complete frame".

This is not a big deal, as the data is transmitted very regularly. But it is a problem for Hass discovery. The configuration published on the discoveryTopic is based on the content of the first frame published by the TicMode service. This means that the published configuration is incomplete if the first frame contains corrupted data.

Proposal

To solve this issue, I propose not to rely on the labels contained in the first frame to publish the configuration. As the exhaustive list of labels is known for each TicMode, I propose to use this list to publish the configuration.

I'm aware that some of the values in the published configuration will not be transmitted by the counter, depending on each individual's situation (e.g. production data). But I don't think it's a problem.

WDYT? I hope I haven't missed an important detail about how Hass discovery works, I'm new to mqtt ^^

(and by the way, thanks for this very useful project!)

fmartinou commented 9 months ago

Hi @madmatah ,

Thank you very much for your contribution 👍 For the moment, I merge it to a dev branch to see test it in action.

I want to see what it looks like by myself. For example, I have a "base" contract in "history" mode, so I suppose that with your changes, I'll get all "heure creuse/ Heure pleine" sensors, all "tempo" sensors and so on.

madmatah commented 9 months ago

Yes, that's right. That's the downside of this solution. Looking forward to your feedback on these tests :)

If the tests aren't conclusive, I've thought of another approach, which would be to publish the configuration of each label independently. And this publication would be triggered when a label is received for the first time.

fmartinou commented 9 months ago

The number of sensors for my personal situation increased from 7 to 35 ^^. All these extra sensors are created on HA with an "unknown" value.

That's not a very big deal in my opinion.

The current implementation is very simple but safe so I'm rather in favour to keep it as this for the moment.