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.
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?
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.
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.
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) ?
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.
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…
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.
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
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.