LiXee ZLinky_TIC DDF File

Ha, yes, it’s probable third app can’t manage natively state/consumption_2 and state/production, it’s something new for deconz, you will be the first one with them.

You can check direclty in the API to see if the problem is from the api or the third app. Values are fine in the API ? with values ?

We can use the @gd35 trick to generate fake endpoint and fake sensor with classic name, but not sure its the better solution for the future. For me it s better to have HP and HC in the same sensor.

This will not be part of a real release?

If by API you mean the part of the screen on the left where you can see the values for each cluster, then yes, those values are correct. In the end, what I’m look for is values for the total HC consumed, total HP consumed, and the production count. These three items are in the “Simple Meetering” cluster (see image). It is items 0x0001, 0x0100 and 0x0102 that IU would like to have. For the moment, only 0x0100 is getting into HomeSeer, and the name is “Consumption 3 kWh” as in the image on my last post. What should I do to get the two missing values?

Hi @Smanar,

Back from holidays. I just saw that the new version of deconz is available. I did the upgrade. I was delighted to see that the rounding issue is now solved. I have now the correct values in OpenHAB. The last thing I should do is to change the DDF by removing the trick I did. I thus added a second consumption state (consumption_2). I saw the two states using Phoscon:

But the problem is on the OpenHAB side as you stated above with third app. I removed the thing and recreate a new one to see if there is a second channel created for the second state. Unfortunately not. So I have to investigate further… I reported this issue here:

I checked with Home Assistant if I can get the values of the two states. Again, I have only one. I am afraid that the bindings to Home Assistant or OpenHAB have to be modified to report the two values within the same sensor…

I have still some issues with the device: the reporting stopped sometimes for a couple of hours. But I also found that my container stopped so it means that the reporting issue is probably due to a crash of the container. Since the container restart automatically, I did not pay attention to that before. I will thus carefully monitor this issue in the following days.

It’s already in the code, at least thoses one, but can change later, others devs want to use more Add some news field for future DDF (Consumption/power device) by Smanar · Pull Request #5890 · dresden-elektronik/deconz-rest-plugin · GitHub
But don’t worry, it’s realy new (only @gd35 and @JJF61 use them for the moment), not official, and no stable version with it yet, but you can prepare the HA plugin.

If by API you mean the part of the screen on the left where you can see the values for each cluster,

Nope, this a deconz, so you have raw values, it’s the “reality” ^^, the API is the “matrix”, you need to check the JSON returned by it like https://forum.phoscon.de/uploads/default/original/2X/a/a64a0d15886b5943cb0fb25c5410a451e564ed9e.png

For the moment, only 0x0100 is getting into HomeSeer

But the problem is on the OpenHAB side as you stated above with third app. I removed the thing and recreate a new one to see if there is a second channel created for the second state. Unfortunately not. So

I checked with Home Assistant if I can get the values of the two states. Again, I have only one. I am afraid that the bindings to Home Assistant or OpenHAB have to be modified to report the two values within the same sensor

Same problem, thoses values are new, third app don’t use them yet. It’s perhaps possible to use “special cooking” to have them like for NodeRed, but the support will be not native yet.

You can ask third app to support them, but not sure values are good yet. For the moment need to check the working mode direclty in the API Json.

I ran into problems with the last update of deconz, since the upgrade I do not have anymore the values send to OpenHAB:

When using deconz, I can force to report the state (by hitting the read box of the attribute editor) and thus get the current value. If not, the value is not updated.

Am I the only one to have this problem with the new deconz update (v2.15.2-beta) ?

IDK, I don’t see something special on this version Release Temano · dresden-elektronik/deconz-rest-plugin · GitHub

Your previous one was the 2.15.1 ?

Can you check if the binding/reporting is still present on your DDF (lot of versions, and the setting can be done by other thing than the DDF on your previous working mode), because it’s realy the thing that cause this kind of issue.

Yes, I think that the previous version was 2.15.1

The binding/reporting seems ok:

  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0702",
      "report": [
        {
          "at": "0x0000",
          "dt": "0x23",
          "min": 60,
          "max": 300,
          "change": "0x00000001"
        }
      ]
    },
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0B04",
      "report": [
        {
          "at": "0x0505",
          "dt": "0x21",
          "min": 60,
          "max": 300,
          "change": "0x00000001"
        },
        {
          "at": "0x0508",
          "dt": "0x21",
          "min": 60,
          "max": 300,
          "change": "0x00000001"
        },
        {
          "at": "0x050F",
          "dt": "0x21",
          "min": 60,
          "max": 300,
          "change": "0x00000001"
        }
      ]
    },
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0xFF66",
      "report": [
        {
          "at": "0x0005",
          "dt": "0x21",
          "min": 60,
          "max": 300,
          "change": "0x00000001"
        }
      ]
    }

Ha yes I remember, we have changed the “min” value, its possible you check the periodicity when the device was working ? If you have a report every 60s or less ? (perhaps was the previous setting that have worked)

There is too an issue about broken sensors on last version, but I think it s more from the DDF core than a binding issue.

Edit:
Ok, I make a rollback on that I have said, I have found chnaged stuff on last version …

No luck on my side. I reinstall deconz but with the 2.15.1 release and now the ZLinky is not anymore connected to the zigbee network. The led is off. I disconnected the device from the Linky, did a reset but nothing happened.
So I will not be able to do additional experiments…

And I don’t find what mean the LED always off on the documentation.
What happen if try to re-include it ?

Eventually, it came back to life but I left it disconnected several minutes before inserting it again in the Linky slot. The led was always off. I successfully reincluded it into the network.

Latest news: yesterday I installed deconz 2.15.3. Since that, the reporting is done on a regular basis. I did not observe an interruption of several hours like in the past. I cross my fingers that this will continue.

For information there is still some issue with sensors after the 2.15.3, something about database (but have effect immediatly, not after somes hours)
So will be corrected in the next one.

Well, I still suffer from a lost connection although I found the situation much better with the latest stable version of deconz:

Deconz shows that there is no more link to connect to other zigbee devices:

The ZLinky blue led is on while having this issue.

The name is grayed, mean the device have left the zigbee network. If I m right you will have timeout error on logs.
If you try to read a random attribute, it make the device reachable or you have the red dot on the node title ?

La LED de l’appareil reste fixe : Le ZLinky_TIC fonctionne correctement. L’appareil décode correctement le Linky
Attention, le voyant lumineux n’a aucun lien avec le mode appairage ou la communication zigbee

If I tried to read an attribute, it does not make the device reachable. The reading does not terminate

Ok, so it s realy like a zigbee disconnection.

There is some shortcut to use in deconz (“L” to make the device leave and rejoin, “F5” that refresh the node) but for me you will have a timeout error.

You have lot of distance between the device and the first router ? what is this router ?
I don’t think it s a setting issue, else there would be more people with this issue ?

The device is very close to an ikea dimmable light (around 4m) and at 10m of the Deconz dongle. I will probably remove the two consumption devices (ZHAConsumption) and just let one device (ZHAPower) in the DDF. Then I will see if I have still the problem.

Just by curiosity you can enable LQI on deconz for some minuts to have values on connexion lines.