Add support for French télé-information (TIC)

[raintonr]

Some (most?/all?) billing electricity meters in France have a serial output port for 'télé-information' (TIC) with several key data points such as actual meter reading, instantaneous current, instantaneous apparent power, etc. I think it would be handy to add support for this protocol.

Data is sent from the meter one way (transmit only - no response required) using a serial protocol. The physical hardware signal is modulated A/C voltage so cannot just be connected to a regular serial port. However, there are many examples of simple circuits that can adapt the the signal to something suitable for a TTL RS232 port. There are also numerous TIC to USB interfaces on the market that are presented in most operating systems as a serial port from which the data stream can be read.

Full specification of TIC from Enerdis (the French grid operator, in French):

https://www.enedis.fr/media/2027/download - 'historic' mode
https://www.enedis.fr/media/2035/download - 'standard' & 'historic' mode

Some friendlier information from a DIY project (many more pages like this can be found with a quick search):

https://faire-ca-soi-meme.fr/domotique/2016/09/12/module-teleinformation-tic/

[raintonr]

I intend to get hold of the required hardware so can have a crack at implementing this.

[Apollon77]

Beside the "issue" that it is not delivering OBIS format datapoints ( so we are again at "adapter currentlxy rlies on OBIS) I can not speak any french ... would be interesting to see how good auto translate tools are.

Aaand BTW ... is not something like https://github.com/tms0/teleinfo-publisher an easier option to integrate? ;-)

[raintonr]

... is not something like https://github.com/tms0/teleinfo-publisher an easier option to integrate? ;-)

Same protocol, but... (from that page)... "The application consists of a Docker image that embeds a Node-RED flow . The flow listens to the data on the serial port, verifies the information and publishes it to an MQTT topic." Yerch! 🤢

OBIS? Why does that matter? Listen to a stream, parse it (I assume the 'issue' because a custom parser will be necessary but parsers are easy to implement), set the relevant states, job done.

[raintonr]

OBIS? Why does that matter?

So I took a quick look at the code 😉

Yeah, but still... there are 2 options:

1. Forget about this feature request and just write a completely separate 'Teleinformation' adapter.
2. Massage the smartmeter adapter so it can cater not only for OBIS format, but other formats too (like TIC).

I don't like 1, mainly because it's already becoming difficult/confusing to find an adapter to do what you want given the number available.

So IMHO I think 2 would be nicer. It's not like this would need mountains of code and it would surely be nicer for the community to find interfaces for all smart meters (the 'odd' French TIC variety included, and who knows what in the future?) catered for in a single 'smartmeter' adapter.

@Apollon77 - what do you think? Shall I proceed and have a go at making a PR?

[Apollon77]

I struggle with the "add other sources like OBIS" a longer time because it would require somehow to have a mapping level from "the relevant protocol" to OBIS - because else it is internally two adapters (kind of) because dfata structures are differe t and so also state ID structures and such ... but the mapping is not thaaat easy and UI work and not natural.

Also right now all logic is in my smartmeter-obis library ... so ideally we add new protocols there or start with other libraries - or start othe rprotocol directly in adapter ...

How would you do it? @raintonr

[raintonr]

How would you do it? @raintonr

I think the adapter should have a more generic interface to data collectors. One data collector would be current OBIS code, and I would create a second for TIC. Then, depending on the configuration chosen, the OBIS or TIC collector would be used - you could import (require) them on demand.

Change storeObisData into something that just creates channel name or state/value pairs. There would be a similar function that does the same for TIC data. Then both would just pass that to an update function that does the actual work of set object, etc.

Maybe I should just make fork and show you - easier then trying to explain? 😉

[Apollon77]

Ok, then provide a PR please .. but I understand what you mean and yes good idea.

But please disable Sentry while developing ;-) I get all your dev-crashes reported ...

[raintonr]

But please disable Sentry while developing ;-) I get all your dev-crashes reported ...

What you talking about? Surely it all worked first time? 😉 🤡