Teleinfo: your Linky meter in Gladys with the LiXee TIC module

Hello everyone! I present to you Teleinfo, an external integration that reads the tele-information (TIC) from your Linky or electronic meter with the LiXee TIC DIN rail module (USB, around €30). Source code: github.com/prohand/gladys-teleinfo.

The important point: USB

A Gladys external integration cannot read a USB serial key. This is the first thing to know before buying the module.

  • External integrations each run in their own Docker container, isolated by Gladys (read-only file system, no hardware access).
  • An integration manifest can request hardware access, but only among 4 classes: coral-usb, coral-pcie, gpu, and video. There is no class for a serial port (/dev/ttyUSB0, /dev/ttyACM0…).
  • These classes are only granted to sub-containers, and never in the form of a free /dev path.

Consequence: plugging the LiXee module into the Gladys server is not enough. The integration will not see it, even if it is properly detected by Linux.

The ZLinky (the Zigbee version of the LiXee) does not have this problem: it goes through Zigbee2MQTT. But the cheaper DIN rail USB version needs a network relay.

The solution: ser2net

ser2net shares the module’s serial port over the network (raw TCP), and the integration connects to it:

Meter (I1/I2) -> LiXee module (USB) -> ser2net (TCP 2000) -> Teleinfo integration -> Gladys

ser2net runs on the machine where the module is plugged in: the Gladys server itself, or a Raspberry Pi near the electrical panel (practical, the USB cable is limited to about 5 m).

sudo apt install ser2net
ls -l /dev/serial/by-id/

Then /etc/ser2net.yaml:

connection: &teleinfo
  accepter: tcp,2000
  enable: on
  options:
    kickolduser: true
  connector: serialdev,/dev/serial/by-id/usb-XXXX-if00-port0,1200e71,local
  • 1200e71 for historical mode (electronic meters, and most Linky by default).
  • 9600e71 for a Linky in standard mode.
  • Then sudo systemctl restart ser2net && sudo systemctl enable ser2net.

Warning: ser2net has no password. Keep this port on your local network, never open on the Internet.

What is sent to Gladys

The mode (historical or standard) is detected automatically. A device is created per meter, with only the values that your meter sends (single or three-phase, Base, HC/HP, Tempo, EJP).

  • Historical mode: index (Base, HC/HP, EJP, Tempo) in kWh, apparent power (PAPP), instantaneous and maximum intensity, subscribed intensity, tariff period, overload (ADPS).
  • Standard mode: total and per index drawn energy, injected energy, instantaneous and maximum apparent power, effective current and voltage, average voltage, load curve, current tariff.

The categories and units are the same as those used by Gladys for the ZLinky in Zigbee: a meter looks the same in both cases.

The values are sent every 60 seconds by default (adjustable from 15 seconds to 1 hour), only when they change, to avoid filling the history.

Scenes and dashboard (Gladys 5.1+)

The integration adds its own cards in the scene editor (category Integrations) and a widget for the dashboard.

  • Trigger « Tariff period change »: runs the scene when switching HC ↔ HP. Possible filter on the new period (off-peak, peak, base). Example: water heater during off-peak hours.
  • Trigger « Subscribed power overload »: warns before tripping. One trigger per overload, even if the power oscillates around the limit.
  • Action « Read the meter »: returns power, period, total index, and overload, for a condition or a message.
  • Widget « Electric meter »: live power, index, 24-hour curve, tariff period, overload, and reception status.

These functions require Gladys 5.1 or newer.

Installation

  1. Plug the LiXee module into the I1 and I2 terminals of the meter (no polarity, current cut off at the panel).
  2. Install and configure ser2net as above.
  3. In Gladys, install the Teleinfo integration, then enter the IP address of the ser2net machine and the port (2000).
  4. Click Test the connection: the meter number and current power are displayed. Then add the meter from the Discovery tab.

The connection status in the Configuration screen clearly indicates the problem: unreachable gateway, or connected but no valid frame (wrong speed or wiring). The detailed guide is in the documentation.

What I’m looking for

  • Testers with a real meter: the integration is tested with simulated frames, but not yet on a real Linky. @mutmut, you offered to test with your LiXee TIC DIN rail module here: with pleasure! If your teleinfo2mqtt already reads the port, you will need to stop it during the test (only one program at a time on the serial port). Feedback on three-phase and standard mode is also welcome.
  • An opinion on serial access: @pierre-gilles, a serial hardware class (for /dev/ttyUSB* / /dev/ttyACM*), granted by the user like coral-usb or video, would avoid ser2net. It would also be useful for other USB key integrations, such as the RFPlayer which is also requested in the thread. Is this feasible on the Gladys side?

Thanks for your feedback!

Thanks @prohand!
I see that it’s not so simple as soon as you have to plug something in via USB for now, I was expecting plug&play like I have with teleinfo2mqtt :frowning:

Do you install it on the host or in the Gladys docker or in the external integration docker?

Does this mean that when I switch from historical to standard, I need to modify the yaml and restart the service?

How is it detected automatically? By the code above?
Isn’t it possible to read the frames, analyze the content, and deduce whether it’s historical or standard?
The variables inside are quite distinct for one and the other, I thought it was simpler than that :frowning:

Very good because teleinfo2mqtt returns all information at each polling (10s currently because too much data otherwise), even if some do not change (Tempo red day for example).
On the other hand, for PAPP (instantaneous power in historical, I don’t know the equivalent in standard), is it possible to set it lower (e.g., 1s)?
I use it to see if there is any overrun (and manage load shedding) and in 15s you can have the Linky « disconnect » if too much power is drawn at time T (e.g., car charging + hot water + heating).

Last point, I have virtual MQTT devices to manage my Tempo indexes, how should I go about migrating (historical, conso30, cout30, etc.) to this integration?

Thanks @mutmut for these great questions! I’ll address them one by one.

1. Where to install ser2net?

  • Directly on the machine (the host) where the LiXee module is connected via USB, with sudo apt install ser2net.
  • Neither in the Gladys Docker nor in the integration one: neither of them sees the USB port.
  • For info, teleinfo2mqtt is « plug & play » because you give it the port with --device in its own docker run. An external integration can’t do that: it’s Gladys that creates its container, and without access to the serial port.

2. Switching from historical to standard: modify the yaml?

  • Yes: you replace 1200e71 with 9600e71, then sudo systemctl restart ser2net.
  • This normally only happens once in the meter’s life, when you request the switch to standard mode.
  • If you forget, the integration tells you in its status: « Connected, but no valid TIC frame: check the ser2net speed (1200 or 9600 baud). »

3. How is the mode detected?

  • Exactly as you describe: the integration reads the frames. In historical mode, the fields are separated by a space, in standard mode by a tab. The field names (PAPP, SINSTS…) also change.
  • But the speed is one level lower. At the wrong speed, only unreadable bytes are received, so no frames to analyze. And it’s ser2net that opens the serial port, with the speed from its config file, not the integration.
  • A path to explore: ser2net manages the RFC 2217 protocol, which allows the client to change the speed remotely. The integration could then try 1200 then 9600 on its own.

4. PAPP more often than every 15 s?

  • The published values in Gladys do not go below 15 s. Gladys limits an integration to 300 values per minute, and each value becomes a line of history. A three-phase meter in standard mode would quickly exceed this limit.
  • But for load shedding, you don’t need the history. The « Subscribed Power Exceeded » trigger analyzes each frame, so every 1 to 2 s, regardless of the publishing interval:
    • in historical mode, it is based on ADPS, which the meter sends as soon as the subscribed intensity is exceeded;
    • in standard mode (the equivalent of PAPP is SINSTS), it compares SINSTS to the subscribed power (PREF).
  • It triggers once per exceedance. The exceedance is considered finished after 60 s without a new signal.
  • The « Read Meter » action also returns the last received frame (1 to 2 s old), and not the last published value. You can use it in a scene condition.

5. Migrating your MQTT devices (Tempo index, history, conso30, cout30)

  • conso30 / cout30: nothing to recreate. Gladys calculates them alone from the indexes sent by the integration, as for the ZLinky. The Tempo prices are set in Gladys’s energy contract.
  • History: the integration cannot import old values, it only publishes current values.
  • Gladys has a « Migrate » function that moves the history, scenes, and dashboards from one device to another. Today, the button only exists on deprecated integrations (Netatmo, Tuya, Hue…), not on MQTT. @pierre-gilles, could we open it to MQTT devices?
  • Be careful with units: the integration publishes the indexes in kWh. If your MQTT indexes are in Wh, a migration would move the values without converting them.
  • In the meantime: keep your old MQTT devices for their history, and let both run in parallel