LiXee ZLinky_TIC DDF File

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.

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:

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 ?

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

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)

Ok, so I can forget this one.

Good. I do not mind. Current is fine to me.

My fault… the home automation system runs on my Synology. I used Docker to run deconz. I did the manual editing outside the docker container and thus this modified the ownership of the file. It was not deconz. So I changed the ownership and it works now.

  1. It is not 00 added. The value is just rounded: 1720694 → 17206700.

  2. Ah ah, I use the expression “Item.val = Attr.val *2” and got… twice the value with the phoscon API but still with the rounding.

The problem was the ownership of the files when I tried the first time. So there is no by-pass.

In the debug view, I got this line:

And this value is not rounded. It is the correct one. So would it be the Phoscon API that rounds the value ?

I found this in the forum

There is also a rounding issue. It is said “like rounding to nearest 100 when we reach 8 digits”. And the two values HC & HP have 8 digits…

Your analysis below of the problem makes sense.

I am forced to put here my answer to your questions as I cannot reply more than 3 times to this subject…

I will ask to swoop, because for me the value is /100, rounded then * 100 again …

Ok, others devs have give me a new thing to explore for the 'magic rounding".
I have just 2 questions

  • do you need a so precise value ? it s an error of 100 w/h, idk what is the unit used on your third app ?
  • are you able to check in the sql, if the value is already rounded ? The problem can be from the json stuff, so the value can be fine on deconz, but badly displayed when using websocket for exemple.

Got this device since a week. Running on a Pi4 with the last beta version, mode Historique with HPHC. Everything works perfectly but after a few hours (between 12h and 24h), values are not updated anymore. The solution I found is to connect the Deconz GUI and do a Device Reboot in the Edit menu. But the issue is coming back after the same period of time.

All my other sensors are working perfectly.

As a workaround is it possible to schedule a device reboot in the crontab?

Am I alone to have this issue?

So you are using this DDF LiXee ZLinky_TIC DDF File - #31 by gd35

Seriously, need to centralise all DDF for this device …

And no, there is no request in the API to reset a device. But the issue is strange, I will be happy to know if you are alone too. Have you tried to increase or decrease reporting value ?

When you have the issue, are you able to ask new value using the GUI ? (mean only the reporting is broken)

BTW, on the next deconz version we will have as new field

  • state/production
  • state/consumption_2 (for HP/HC)
  • state/current_p1
  • state/current_p2
  • state/current_p3

So we can add some more useful field.

Hi Smanar and ecoursel,

I have noticed an unexpected behaviour concerning the power consumption. Herewith is a graph showing the power consumption for the last 2 days. I observed two flat curves from 23:16 till 3:38 the first day and from 2:54 till 7:35h the next day. The probability to have these two flat curves to remain the same for several hours (even during the night) is low. So I suspect that the device does not communicate during these two periods. I have to further investigate this issue.

Hi Smanar,

  1. I can afford the rounding issue. No need to be precise. But I am sometimes a purist and want to know what was the problem behind the rounding issue. Just to satisfy my intellectual curiosity :wink:

  2. I execute this command: sqlite3 zll.db ‘select * from nodes;’ > log
    but I did not see any information concerning the ZLinky_TIC sensor in the log file

Thanks again

Or perhaps the value was 0 ? (I have already see this issue, I have a device that stop report consumption if I turn it “off”, but don’t send a 0 value)
Because if a reporting stop working, deconz detect it and use poll mode.
The device was marked as “unreachable” ? (If you log that too ?)
@eoursel have this kind of issue too, but for him the report never restart.
And BTW your curves are normal ? so much move from 0 to 6k in a short period …

Just to satisfy my intellectual curiosity

Same for me, so frustrating to don’t find where it s from.
There is a PR about this kind of issue Fix DDF handling of negative values and values above 2^52 by manup · Pull Request #5910 · dresden-elektronik/deconz-rest-plugin · GitHub but for me it s not the same problem.
The value is displayed fine in logs, so I don’t think it s from the JS stuff, but I think the guilty can be the code that “make” the json in the API.

Have just checked the database too, and you are right, nothing was stored inside.
And was hard to add more debug line in code.
BTW can you show all the logs you can have when the value is updated ? with flags DDF/info/Info_l2 ?

Hi Smanar,

The value was not zero. I checked the curve for the last night and I did not find a stable value for a long time…

It seems normal since I have a heating floor (3000W + 4150W) that is switched on during the night (HC) depending of the external temperature.

Is that what you are looking for ?

Thanks again,

I m speaking about this line

https://forum.phoscon.de/uploads/default/original/2X/0/0243f81b8fa77533607f5bb19b688c063187fe15.png

If you can have some more lines before and after to locate the code ?

Hello Smanar and gd35,

I have been waiting for the electricity company to change my Linky from Historic mode to Standard mode, in order to be able to get the Solar Panel Production (injection). They say this will be done by Friday of this week. In the meantime however, Windows 10 decided to update itself without warning, and after the update, there are now 5 devices in Homeseer :

“Consumption 3 kWh” corresponds to the total metering for HC (heures creuses), and “Power 2 Watts” is the current load in the house. I do not need the other 3 devices that are there, so only the HP (heures pleines) consumption and the production index are missing now.​

I will post again after the change from HISTORIC to STANDARD…

Thanks,

  • JJF61

I got the following entries in the log:

I got this from the “Debug view” when I checked the DDF box only. If I checked Info/Info_l2/ddf, I have too many entries displayed on the screen. Is there a way to send this info into a log file without stopping deconz ?

@JJF61 I have started a DDF for Standard + Production + HPHC, but you will need a recent deconz version (not published yet, will be the next one)

{
  "schema": "devcap1.schema.json",
  "manufacturername": "LiXee",
  "modelid": "ZLinky_TIC",
  "product": "ZLinky_TIC Standard mode with production",
  "sleeper": false,
  "status": "Gold",
  "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/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": "0x0100",
            "cl": "0x0702",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0100",
            "cl": "0x0702",
            "ep": 1,
            "eval": "Item.val = Attr.val"
          }
        },
        {
          "name": "state/consumption_2",
          "refresh.interval": 300,
          "read": {
            "at": "0x0102",
            "cl": "0x0702",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0100",
            "cl": "0x0702",
            "ep": 1,
            "eval": "Item.val = Attr.val"
          }
        },
        {
          "name": "state/production",
          "refresh.interval": 300,
          "read": {
            "at": "0x0001",
            "cl": "0x0702",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0100",
            "cl": "0x0702",
            "ep": 1,
            "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"
        }
      ]
    }
  ],
  "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"
        }
      ]
    }
  ]
}

I haven’t set the bind, because IDK wich one are usefull, it seem HP/HC work for @gd35 without bind, so …

In the json you will have 1 sensor for consumption and inside
state/consumption > cluster 0x0702, attribute 0x0100 HP
state/consumption_2 > cluster 0x0702, attribute 0x0102 HC
state/production > cluster 0x0702, attribute 0x0001 Production

But I m not sure for attributes.

@gd35 , no to send logs to a file, need to restart deconz. and yes if you have too much devices, logs are too much talkatives.
I will try this week end with a fake device and a fake entry to see if the api can handle big number.

Edit:
I can reproduce the “magic rounding”, just using DDF.

Hi,

Bad news today, my ZLinky_TIC is not anymore part of the zigbee network. It is disconnected so no more data are sent to my home automation system as show here:

It is the second time I had this issue as show here:

I read somewhere that some users might have the same problem… Is it a firmware issue ?

I just did a reboot using deconz and the problem is solved but I don’t know how many days this will work…