LiXee ZLinky_TIC DDF File

[gd35]

Hi Smanar,

After several attempts, I succeeded to get the two values (HC and HP). The solution was to have two ZHAConsumption in the DDF, one for HP and the other one for HC. By doing this, these two values are now reported (I checked with the Phoscon API) as well as within OpenHAB. I have now two “Things”, one consumption item for each thing. I will let them to store the values the rest of the day to see if the automatic update is done. By the way, the two reported values are rounded:

Deconz Phoscon API / OpenHAB
16927450 → 16927500
11822691 → 11822700

Is there a parameter I can change to avoid the rounding ?

Thanks for your help

[Smanar]

@gd35

The solution was to have two ZHAConsumption in the DDF, one for HP and the other one for HC

Ha yes, good idea, like that the support is native on third app.

Do you need to use bind/report or poll for thoses attributes ?

Is there a parameter I can change to avoid the rounding ?

Yep, in the json it’s here

"eval": "Item.val = Attr.val"

In the editor it s “expression”, but by defaut the value is not rounded, have you check if the value in the json is rounded, it can be HA that make the convertion.
Else can you show the editor panel for this parameter ?

[gd35]

Hi Smanar

Concerning the second ZHAConsumption, I gave it a different id:

By doing this, it created a new sensor.

New values are reported automatically to OpenHAB. I have now my consumption histograms that appear like what I had with the Ecodevice.

Thanks again

[gd35]

Concerning the rounding, the values appear rounded when using the Phoscon API (2 zeros at the end):

For the two states, I have

"eval": "Item.val = Attr.val"

The rounding problem seems to come from something else. I will investigate further this problem and will let you know.

[Smanar]

Ha, using the 0x02 is a good idea, but it s a little tricky ^^, this value is the endpoint, so need to be 0x01.
Will see how will move the DDF core, IDK if we need to use endpoint, or if we can use all we want.

So in the API, you are seing 2 more 0 than using the GUI ? Strange, with “Item.val = Attr.val”, you need to have exaclty the same, or this line is disabled and use legacy code instead of DDF one.

Can you show the complete DDF (for me and others ) ?

[gd35]

Herewith is the DDF file I use

{
  "schema": "devcap1.schema.json",
  "manufacturername": "LiXee",
  "modelid": "ZLinky_TIC",
  "vendor": "LiXee",
  "product": "ZLinky_TIC",
  "sleeper": false,
  "status": "Bronze",
  "path": "/devices/zlinky_tic_with_alarm_HCHP.json",
  "subdevices": [
    {
      "type": "$TYPE_POWER_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0x0b04"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/consumption",
          "refresh.interval": 300,
          "read": {
            "at": "0x0100",
            "cl": "0x0702",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0100",
            "cl": "0x0702",
            "ep": 0,
            "eval": "Item.val = Attr.val"
          }
        },
        {
          "name": "state/current",
          "refresh.interval": 300,
          "read": {
            "at": "0x0508",
            "cl": "0x0b04",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0508",
            "cl": "0x0b04",
            "ep": 1,
            "eval": "if (Attr.val != 65535) { Item.val = Attr.val; }"
          }
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/power",
          "refresh.interval": 300,
          "read": {
            "at": "0x050f",
            "cl": "0x0b04",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x050f",
            "cl": "0x0b04",
            "ep": 1,
            "eval": "if (Attr.val != -32768) { Item.val = Attr.val; }"
          }
        },
        {
          "name": "state/voltage",
          "refresh.interval": 300
        }
      ]
    },
    {
      "type": "$TYPE_CONSUMPTION_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0x0702"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/consumption",
          "refresh.interval": 300,
          "read": {
            "at": "0x0102",
            "cl": "0x0702",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0102",
            "cl": "0x0702",
            "ep": 0,
            "eval": "Item.val = Attr.val"
          }
        },
        {
          "name": "state/lastupdated"
        }
      ]
    },
    {
      "type": "ZHAAlarm",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0xff66"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/alarm",
          "refresh.interval": 30,
          "read": {
            "at": "0x0005",
            "cl": "0xff66",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0005",
            "cl": "0xff66",
            "ep": 1,
            "eval": "Item.val = Attr.val > 0 ? true : false",
            "fn": "zcl"
          },
          "default": false
        },
        {
          "name": "state/lastupdated"
        }
      ]
    },
    {
      "type": "$TYPE_CONSUMPTION_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x02",
        "0x0702"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/consumption",
          "refresh.interval": 300,
          "read": {
            "at": "0x0100",
            "cl": "0x0702",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0100",
            "cl": "0x0702",
            "ep": 1,
            "eval": "Item.val = Attr.val"
          }
        },
        {
          "name": "state/lastupdated"
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0702",
      "report": [
        {
          "at": "0x0000",
          "dt": "0x23",
          "min": 1,
          "max": 300,
          "change": "0x00000001"
        }
      ]
    },
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0B04",
      "report": [
        {
          "at": "0x0505",
          "dt": "0x21",
          "min": 1,
          "max": 300,
          "change": "0x00000001"
        },
        {
          "at": "0x0508",
          "dt": "0x21",
          "min": 1,
          "max": 300,
          "change": "0x00000001"
        },
        {
          "at": "0x050F",
          "dt": "0x21",
          "min": 1,
          "max": 300,
          "change": "0x00000001"
        }
      ]
    },
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0xFF66",
      "report": [
        {
          "at": "0x0005",
          "dt": "0x21",
          "min": 1,
          "max": 300,
          "change": "0x00000001"
        }
      ]
    }
  ]
}

[Smanar]

Lol, you innovate, another thing you are doing, and I think you are the first.
At start deconz sensor are made by cluster, so it mean 1 cluster > 1 sensor. And you are using different cluster for the same sensor. I think you will trigger some discussion about DDF management ^^.

So If m right this DDF generate :

• a power sensor with 0x01, with consumption, power, current
• a consumption sensor with 0x01 with consumption
• a alarm sensor
• a consumption sensor with 0x02 with consumption

And you are using binding/report for cluster/attribute : 0x0702/0x0000 0x0B04/0x0505 0x0B04/0x0508 0x0B04/0x050F 0xFF66/0x0005

I think you can remove the consumption on the first one, it will use bad value (and the bind/report 0x0702/0x0000)

And as you are not making bind and report for the HP and HC value, I think the DDF core never use the “Parse” part but instead the “Read” part. (or the device make native report, but will be strange)
And this part don’t have an “expression” field so I m not sure how it work, will ask to others (or perhaps you can see something in log about the rounding ?)
But it mean too you are using polling, the gateway ask for the value with a constant timer, defined in “interval”, so don’t use a too low value, if I m right, you are using 300s ATM.

Edit:
So even the device use poll, it need to use the “parse” “expression” field, so the problem is elsewhere.
Perhaps looking logs with the field “DDF”. Or trying

Item.val = Attr.val / 100

To see if it change something.

[JJF61]

Hello Smanar and gd35,
I do not know if gd35’s rounding problem is solved, or if you already know this, but it seems that Linky records consumption in watts every few seconds, but displays it on Linky box in kWh. For example, in deCONZ, my HP consumption is showing as 27196872, but on the Linky box, it shows as “27197 kWh”.
I contacted EDF on Friday and they are switching me to STANDARD, but they said it could take two weeks
Smanar, if you want to modify my DDF to get HP consumption, HC consumption and apparent power to create devices while waiting for the STANDARD switch, please let me know and I can send you the DDF that I am using now. Or maybe it is easier and it will take up less of your time if we just wait for STANDARD to be active?

[w.vuyk]

JJF61,

No need to see it in Phoscon. The plugin is independent from Phoscon. It is on the same level as it is using the API connection. The plugin supports more then Phoscon up till now.
If you see devices getting create in the plugin, send me the json on the HS forum, so I can anticipate on it?

[Smanar]

The round issue is from deconz, he don’t see the same value in the GUI (the raw value) than on the API.
As in the DDF he use only

Item.val = Attr.val

We need to have the same value, and the value is * 100 somewhere. (for me from the legacy code)

@JJF61

Smanar, if you want to modify my DDF to get HP consumption, HC consumption and apparent power to create devices while waiting for the STANDARD switch, please let me know and I can send you the DDF that I am using now

@gd35 have already make a working DDF for HP and HC (except the round issue, and the polling question)
Will just need to add another sensor for you for production consumption. But I think we will not use his tips ^^ (create more sensor with different endpoint) and create a state/consumption_production for example.

Edit:
So you have ask for a Standard mode to have production, but you keep the HP HC mode ? I don’t find this mode on the documentation.

[JJF61]

Smanar, I may be confused, but from what I understand, the Linky is either single-phase or three phase, and the tarif is either BASE or HC/HP. STANDARD and HISTORIQUE are simply modes of how the data is displayed and archived (at ENEDIS). So switching from HISTORIQUE to STANDARD mode does not affect my contract… I still am on HC/HP. I think it is best to wait until this STANDARD mode is activated, because we can then see how the production (hopefully!) will appear in the clusters. No one seems to be talking about Apparent Power in the Electrical Measurement cluster… will that be in the DDF too?

[Smanar]

From that I m reading, possible mode are

0 - Mode historique monophasé
1 - Mode standard monophasé
2 - Mode historique triphasé
3 - Mode standard triphasé
5 - Mode standard monophasé producteur
7 - Mode standard triphasé producteur

On historique mode, I can see a HC/HP mode but I can’t see it on standard mode.
There is a big change according to the mode GitHub - fairecasoimeme/Zlinky_TIC: Téléinformation Linky autoalimenté ZigBee 3.0
Will see when you will have the new mode, I think HP and HC are here

EASF01	0x702	0x0100	RP		Uint48	9 car	Wh	Energie active soutirée Fournisseur, index 01	0
EASF02	0x702	0x0102	RP		Uint48	9 car	Wh	Energie active soutirée Fournisseur, index 02	0

No one seems to be talking about Apparent Power in the Electrical Measurement cluster… will that be in the DDF too?

Yep, it s state/power state/voltage state/current

[gd35]

Hi,

I did not tell you that my linky is set to “Historique” mode and I have a tri-phase contract. But I do not need to get values related to the three phases. So the “Historique” mode is fine to me (This mode was required when I installed the ecodevice)

With the Phoscon API, I see 5 sensors:

I do not know why I got two Power Sensors… Anyway, I use Power 28, Consumption 29 and Consumption 32.
Despite this, everything works fine with nice graphs displayed within OpenHAB. I removed the consumption state in Power 28. But this state still appears when using the Phoscon API.

I now that I did not really follow the rules but this was the only way to get the two values (HC, HP). It seems that if you have two consumption states in the same ZHAConsumption item, you cannot access them in Phoscon and thus in OpenHAB.

However, the two consumption states in the ZHAConsumption items have of course the same endpoint (0x01). The trick I used to get a unique id by using $address.ext-0x02-0x0702 does not mean that I used the endpoint 0x02. What is important is to be sure to have a unique id. Otherwise, it seems that the sensor is not created. As far as I understood how Phoscon manage the sensors !

Thanks again for your help

[Smanar]

@gd35

I do not know why I got two Power Sensors

Ha yep, right, I m reading again your DDF, with the “02” you are using only a TYPE_CONSUMPTION_SENSOR, not a TYPE_POWER_SENSOR …
And the ZHAAlarm is created only 1 time, why not the ZHAPower.

[gd35]

Hi JJF61 and Smanar

Rounded problems are not yet solved. It does not come from the LInky since the Ecodevice I used before displayed correctly the power consumption in watt. Moreover, the values are displayed correctly with deconz. I suspect that this is Phoscon that makes the rounding.

[Smanar]

But values are already bad in the API ? seeing LiXee ZLinky_TIC DDF File - #29 by gd35

You have value with “00” added, so if I m right it s the raw value, see in deconz (The GUI) and something * 100 this value, no ?
Try to use as expression “Item.val = Attr.val *2” for exemple, to see if the value is * 2, if yes, the DDF is working, if not, something is by-passing the DDF.

BTW, we have missed the last code merge, I need to make a PR fastly (for next week) to add field your need.
I have learned values need to be in code first, before they can be used in the DDF.
So tell me the field you can need in future (even you don’t need them ATM, because can need 1 month if we miss the next one)

• state/current_P1
• state/current_P2
• state/current_P3
• state/consumption_2

?

[gd35]

Hi Smanar,

The four states will be useful. For the first three states, I will use them to see if the three phases are well balanced in term of consumption.

Since the consumption issue is solved (except the rounding issue but I will try to multiply by 2 to see if the ddf is not bypassed), I am trying to check all the available clusters to see what I could extract that would be useful for me and others. First of all in the “Basic” cluster, I found a minor issue: the attribute id 0x0007 (Power source) displays “Mains (single phase)” although I have three phases.

Concerning the “Simple Metering” cluster, I have the following available attributes:

Not so much information I can get from them except the two values HCHC and HCHP

For the “Electrical Measurement”:

Again, except the “Apparent Power” attribute, nothing to get from this cluster

For the “Meter Identification” cluster:

The attribute “AvailablePower” could be added to the list of useful values.

[gd35]

And for the “LiXee specific cluster”:

not much useful information here.

So the question I have is can I get the values of some attributes in a cluster that are not shown with the deconz GUI ?
Such as these ones:

[gd35]

@Smanar

But values are already bad in the API ? seeing LiXee ZLinky_TIC DDF File - #29 by gd35

You have value with “00” added, so if I m right it s the raw value, see in deconz (The GUI) and something * 100 this value, no ?
Try to use as expression “Item.val = Attr.val *2” for exemple, to see if the value is * 2, if yes, the DDF is working, if not, something is by-passing the DDF.

I just did it. I did a “hot reload” (twice), and nothing changed in the phoscon API. Still the same value. Should I write the new ddf file before doing a “hot reload”. By the way, it seems that I have to change the name of the file to see the change. It seems that I cannot rewrite on the same ddf. Did you have the same behavior ?

[Smanar]

For the attribute 0x0007 in cluster 0x0000, It concern the device itself, not your installation. all the attributes can be used even the device is not connected to the installation.

For the Cluster “simple Metring”, I haven’t see usefull missing attributes, there is the “BBRx” one, but I realy don’t know what it is, and still haven’t see someone that need it.

For the Cluster “Electricial measurement” have added some values on XML. Something to test, it seem the power is only available for Triphase installations.
But not usefuall having intensity AND power, as both value moving same, and one can be calculated from the second one.
It’s personnal, but for me current is more “understandable” by users.

The attribute “AvailablePower” is static, and you have it on your contract, I don’t see what you can do with this value in third app ?

For the Lixee Cluster, have added some others attributes, but unknow for me, will be for tests.

Have added all new field, except for power (Are you sure relay need them ?)
And don’t set the HP/HC by defaut

Add some news field for future DDF (Consumption/power device)

@gd35

Should I write the new ddf file before doing a “hot reload”. By the way, it seems that I have to change the name of the file to see the change. It seems that I cannot rewrite on the same ddf. Did you have the same behavior ?

Ha, perhaps a tips.
The file is locked because of right issue ? wich one folder are you using ? the “user” one or the “system” one ? can try to unlock it
sudo chmod -R 777 file_folder_name

But if you can create a new file at same place, mean probably it s just deconz that use and lock the file (or another app)