LiXee ZLinky_TIC DDF File

[Smanar]

@JJF61

Is the only way to work now with this is through the DDF file? Should I sent it to you?

Yes, I think all is possible only using DDF, for the moment I don’t need it. So you are now at same point than @gd35, so sames questions than for him for the new field to add.

I m looking for “production consumption”, you are in “Standard” mode right ? Because this value seem only present on this mode (not the “historique”)

And BTW, you don’t need to restart deconz, can just make a “hot relaod” in the menu.

And a question, can you give me, from the deconz GUI (to know how work the device to compute the consumption) in the cluster 0x0702

• Your HP consumption value 0x0102
• Your HC consumption value 0x0100
• Your ??? consumption value on attribute 0x0000 (used by others users)

Edit:

<attribute id=0x0000 name=Current Summation Delivered type=u48 access=r required=m></attribute>
<attribute id=0x0001 name=Current Summation Received type=u48 access=r required=o></attribute>

The production is not on the attribute 0x0001 for “standard” mode ?

[JJF61]

Smanar,
I just looked in my Linky, and it says HISTORIQUE MODE TIC P. Apparently I have to contact EDF to get this changed to STANDARD. In the meantime, if this can help, I think this is the information you were asking me for ? (+ second post due to limitation on new users to only 1 image per post):

Just to confirm… I have to get EDF to change from HISTORIQUE to STANDARD ?

[JJF61]

[Smanar]

Thx.

So first, the attribute 0x0000 is 0, so it mean you realy need to use 0x0100 and 0x01002 for consumption
Secondly I m reading the documentation here GitHub - fairecasoimeme/Zlinky_TIC: Téléinformation Linky autoalimenté ZigBee 3.0
And from it, it seem you can’t have the production on standard mode

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

But I can be wrong, you can ask to EDF if you can have the production on the actual mode, and change it if you need/want.

Waiting for production stuff, I can make a part to have HC and HP, but how you want the value be displayed in the API ?

For me the easier way is removing the state/consumption and use instead state/consumptionHP and state/consumptionHC
But the problem is you probly need to make some “stuff” on the third app side, because I don’t thing it will be able to manage natively consumptionHP and consumptionHC.
And another choose you need to make, to create the 2 news fields, there is a barbarian method using only text edition, or creating 2 mores json to have them in the GUI (I will give you the files), there is more thing to do, but the futures fields will be visible in the GUI so easier to use after.

Or can use state/consumption1 and state/consumption2, like that we can use 1 for HP, 2 for HC, or for another contract 1 for consumption and 2 for production. So the news fields will be usable for other purpose.

[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

?