Closed madmatah closed 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.
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.
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.
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!)