1
Nov, 2024

I am testing the LIXEE TIC module to Zigbee (Zlinky_TIC)

Where to buy this equipment?

Here is the link to his page dedicated to the ZlinkyTIC. I referenced the sellers and prices.

I open the box and check the received model

There are obviously two versions, one with internal antenna and one with external antenna.
The second is probably provided for when disturbances are generated and may need to move the antenna away from the housing.

The module is very simple, 3 rigid connectors, no instructions for use, I think it is a pretty good sign, it must be very simple.

On the back, we see a diagram that shows or puts the module in the Linky.

I will connect the module

I look at how the terminal blocks of the Linky and the module are marked, it is impossible not to understand:

I put ZigbeetoMQTT in pairing mode and connect the case, just press the black button to release the connect and slide the pins underneath. 

The blue LED flashes, the pairing is underway, I go back to Zigbee2MQTT to see the result.

I check the status of the module using the LED

The LED can have three states, if it is not good at this stage, there is no need to go further.

  • The LED flashes quickly several times = ZlinkyTIC is in pairing-waiting mode. 

  • LED flashes several times slowly = ZlinkyTIC encounters errors when acquiring Linky data. 😥

  • The LED flashes once every 3 seconds = The ZlinkyTIC works properly. The device correctly decodes the Linky 😊

I'm trying a Zigbee2MQTT integration

The integration worked perfectly at first.

The module is detected in "ZLinky_TIC"

The detected version does not differentiate between V1 and V2, it does not matter

I will look at the values, everything is there, magical, in a few seconds.

I test the sensor in Home Assistant

I give it an understandable name: Linky in Zigbee2MQTT then I'll look it up in HA

And that's it, all the data is present in Home Assistant.

Meaning of each data

A small painting is much more telling. For the three-phase, the result will be different.

I disable all entities that are not useful to me

Here are the entities of the Linky device:

I am updating the module Zlinky_TIC

I launched it via Home Assistant, but it can be launched from Zigbee2MQTt, in both cases, we can see that the update is in progress in Zigbee2MQTT as well:

Be careful, the update is very long, you have to let … run

In the end, I am not sure why this update started, as version 14 was already installed before the update. It does not matter, everything went well and the update flag went back to off.

I look at the settings page in Zigbee2MQTT

I found this page, there are no parameters, I do not know if it is useful. When in doubt, I configure.
Note, Update, small error, do not set KWh to 0 but to 3 because those are K.

[Archive] I use a template for HC/HP

I give here the template that I had made a historical mode to retrieve the HC or HP info according to the schedules.
Indeed, before the installation of this new Zigbee module, I used a USB ICT module.

This module also provided me with an HC.. or an HP.. value in the sensor.linky _active _register _tier _delivered (PTEC) variable.

To do this, I use a template entity, in the template.yaml file, I add:

- sensor: - name: Single current _id tariff period: sensor.period _tarifaire _en _cours state: >- {% if is_state("sensor.linky _active _register _tier _delivered", "HP..") %} HP {% else %} HC {% endif %}

Change of mode Linky

There are two modes, History Mode and Standard Mode.

I had ICT equipment that was not compatible with Standard mode, so I never changed.

Apart from this new module, it also operates in Standard mode according to its documentation. The standard mode is much more complete.

I am therefore sending a message to EDF to change the mode:

 

  • Online application made via the form on 03 November
  • Reply on 04 November
  • Switches to 05 November

Nothing to say, hat EDF!!

Switches from History Mode to Standard Mode

I must admit I skated a little on this switch to Zigbee and Home Assistant.

I tried to change the mode, to re-pair the … module The information did not go back, I spent a while there.

Finally, I closed everything, let it go for one night and took it back the next day, everything worked!

So you don't have to be in a hurry, there have to be … refresh cycles in short, it works, here are the screens.

Standard Mode Data

ICT controldesignationunitDefault valueHowdata typesize max
ADSCSecondary address of the Counter–NULLString12 because
NGTFName of the supplier tariff schedule––String16 because
LTARFSupplier tariff wording in progress––String16 because
NTARFCurrent tariff index number––Uint82 car
VTICICT version––Uint162 car
DATECurrent date and time–EX: E211022162000String10 cars
EASTTotal active energy extractedWh0Uint489 because
EASF01Active energy extracted Supplier, index 01Wh0Uint489 because
EASF02Active energy extracted Supplier, index 02Wh0Uint489 because
EASF03Active energy extracted Supplier, index 03Wh0Uint489 because
EASF04Active energy extracted Supplier, index 04Wh0Uint489 because
EASF05Active energy extracted Supplier, index 05Wh0Uint489 because
EASF06Active energy extracted Supplier, index 06Wh0Uint489 because
EASF07Active energy extracted Supplier, index 07Wh0Uint489 because
EASF08Active energy extracted Supplier, index 08Wh0Uint489 because
EASF09Active energy extracted Supplier, index 09Wh0Uint489 because
EASF10Active energy extracted Supplier, index10Wh0Uint489 because
EASD01Active energy extracted Distributor, index 01Wh0Uint329 because
EASD02Active energy extracted Distributor, index 02Wh0Uint329 because
EASD03Active energy extracted Distributor, index 03Wh0Uint329 because
EASD04Active energy extracted Distributor, index 04Wh0Uint329 because
EAITTotal injected active energyWh0ProductionUint489 because
ERQ1Total Q1 reactive energyVArh0Productionint169 because
ERQ2Total Q2 reactive energyVArh0Productionint169 because
ERQ3Total Q3 reactive energyVArh0Productionint169 because
ERQ4Total Q4 reactive energyVArh0Productionint169 because
IRMS1Effective current, phase 1A0single/three-phaseUint163 cars
IRMS2Effective current, phase 2A0Three-phasedUint163 cars
IRMS3Effective current, phase 3A0Three-phasedUint163 cars
URMS1Effective Voltage, Phase 1V0single/three-phaseUint163 cars
URMS2Effective Voltage, Phase 2V0Three-phasedUint163 cars
URMS3Effective voltage, phase 3V0Three-phasedUint163 cars
PREFPower reference app. (PREF)kVA0Uint162 car
STGERegister of Statutes–0String8 because
PCOUPPower cut-off app. (PCOUP)kVA0Uint82 car
SINSTIPower app. Instant injectedVA0Productionint165 because
SMAXINMax. app power injected nVA0Productionint165 because
SMAXIN-1Max. injected app power n-1VA0Productionint165 because
CCASNPoint n of the drawn active load curveW0int165 because
CCASN-1Point n-1 of the drawn active load curveW0int165 because
CCAINPoint n of the injected active load curveW0Productionint165 because
CCAIN-1Point n-1 of the injected active load curveW0Productionint165 because
UMOY1Moy voltage. ph. 1V0Mono/three-phaseUint163 cars
UMOY2Moy voltage. ph. 2V0Three-phasedUint163 cars
UMOY3Moy voltage. ph. 3V0Three-phasedUint163 cars
SINSTSPower app. Snapshot extractedVA0(Mono/Triphase since v10)Uint165 because
SINSTS
SINSTS1Power app. Snapshot extracted ph.1VA0Three-phasedUint165 because
SINSTS2Power app. Instant extracted ph. 2VA0Three-phasedUint165 because
SINSTS3Power app. Instant extracted ph. 3VA0Three-phasedUint165 because
SMAXNPower app. max. drawn nVA0(Mono / Triphasé since v10)int165 because
SMAXN
SMAXN1Power app. max. drawn n ph.1VA0Three-phasedint165 because
SMAXN2Power app. max. drawn n ph. 2VA0Three-phasedint165 because
SMAXN3Power app. max. drawn n ph. 3VA0Three-phasedint165 because
SMAXN-1App. max. output power n-1VA0(Mono / Triphasé since v10)Uint165 because
SMAXN-1
SMAXN1-1App. max. output power n-1 ph.1VA0Three-phasedUint165 because
SMAXN2-1App. max. output power n-1 ph.2VA0Three-phasedUint165 because
SMAXN3-1App. max. output power n-1 ph.3VA0Three-phasedUint165 because
MSG1Short message–0String32 because
MSG2Ultra-short message–0String16 because
PRMPRM (Identifier)–0String14 because
DPM1Start Point Mobile 1–0Uint82 car
FPM1End Point Mobile 1–0Uint82 car
DPM2Start Point Mobile 2–0Uint82 car
FPM2End Point Mobile 2–0Uint82 car
DPM3Start Point Mobile 3–0Uint82 car
FPM3End Point Mobile 3–0Uint82 car
RELAISRELAIS–0Uint163 cars
NJOURFNumber of current day supplier calendar–0Uint82 car
NJOURF+1Number of the next supplier calendar day–0Uint82 car
PJOURF+1Profile of the next supplier calendar day–0String98 car
POINT 1Profile of the next peak day–0String98 car
–Linky protocol–0Uint81 car

Data Home Assistant on Standard Mode

And that's it, all the data is present in Home Assistant (the same can obviously be consulted on Zigbee2MQTT)

Attempt to understand changes in HC/HP states

So now it’s an adventure, I don’t really understand what’s going on.

My HC/HP time changes are for example on 14:06 and 17:06 and here is the history recorded today:

Pretty incomprehensible then.

I wait one night to see the physical switch (heater console) and the indicators returned, here is the result:

I therefore note that:

  • STGE and conso correspond and are on the right time 02:06:07 for both.
  • 02:14:07 for NTARF and RELAIS.

At this stage, I do not explain the reason for the discrepancy, I will question on the forums to see if anyone knows, but at this stage, I will therefore use STGE to define whether we are in HC or HP.

I add a template to have HC/HP

In my templates.yaml file, I add:

- name: Single current _id tariff period: sensor.period _tarifaire _en _cours state: >- {% if is_state("sensor.linky_status _register", "003AC401") %} HP {% else %} HC {% endif %}

Understanding the 5 Energy Lines

I find myself in HA with 5 lines with the same title.

They correspond to the lines:

  • EAST
  • EASTF01
  • EASTF02
  • EASD01
  • EASD02

I went to check the indexes on the meter display to find myself there.

I give up EASD01 and EASD02, I don’t understand High Season, Low Season.

EAST is therefore the total consumption, EASTF01 the Conso Heures Creuses, EASTF02 the Conso H Pleines.

That is immediately clearer:

I add conso information in Energy

and

Data that I finally keep

After a battery of tests, I confirm what I thought, the real-time information is worthless, the Linky is not made for it. No need to think of having the instant conso thanks to him.

I therefore use it to retrieve the HC/HP info and to power HA’s Energy module.

Here are the data I keep:

MSG1 and MSG2, I keep them because I'm curious about what might happen in these message fields. We will see in several months or years if something appears.

NTARF/RELAIS/STGE, I will wait several days to see which of the 3 I keep, I will disable the other two then.

I keep the Conso Totale at this stage, but if I do not need it, I will deactivate it.

Accuracy of module configuration in Zigbee2MQTT

In the whitelist, it seems important to specify the information you need, it seems to limit the resources to send unnecessary data. I specified “EAST,EAIT,EASF01,EASF02,STGE,NTARF,RELAIS,MSG1,MSG2”

Conclusion

Finally, the fairly simple and efficient integration of this module allows me to feed the Energy module of Home Assistant and to have the information of HC/HP on my Dashboard.

This RetEx is still to be completed in time, it will evolve, I have left a few outstanding points above.

The readings of the various forums or Retex of other users suggest to me that the realisation of this type of equipment is particularly complex to achieve. Obviously the power supply provided to the module by the Linky is very very low, so it must be extremely optimised. The choice of Zigbee is a good thing, it is a technology that consumes very little, I imagine that in Wifi or Bluetooth, it would not work.

Being able to choose a whitelist of the data you want to use has to lighten the frames and the energy requirement of the module, which is a great idea.

Congratulations for the realization of this module, a very good job!

As a bonus, here is the Energy screen on my Dashboard, if that gives any ideas.

 

Bibliography or references