search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.89k stars 496 forks source link

LiXee ZLinky_TIC #5459

Closed chpego closed 2 years ago

chpego commented 2 years ago

Device

Screenshots

Simple Metering

image

Electrical Measurement

image

Smanar commented 2 years ago

So this issue happen on device added using DDF (with invalid sensor resources ?), but during the deconz launching/restart with DDF disabled.

And I have learned something, the uniqueid is not static ? During the working mode deconz can change/update a uniqueid ?

Less important, but about the Lixee cluster, I have made a try with a Legrand cluster, I have same result than you, but even the attribute fonction and the cluster name don't appear, it s seem the procedure is working.

  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0xFC40",
      "report": [
        {
          "at": "0x0000",
          "dt": "0x30",
          "min": 0,
          "max": 0
        }
      ]

You have added the state/alarm state too ?

AdrienBigot commented 2 years ago

@Smanar yes the problem appears on devices added throught DDF editor and not available at reboot because DDF are disabled by default. I've just reproduced the problem with a new device added to test the state/alarm. I've added a device AirQuality since the LiXee Specific cluster is not available in the "available devices" column (the right column in the DDF editor) and I modified it by adding the new state/alarm and the correct binding / reporting. Little problem, when I try to modify the subdevice type from ZHAAirQuality to LiXeeCluster, this value is not saved and back to ZHAAirQuality after reload. But, nevermind, I can still test with that name. lixee

At the beginning it worked fine : 

{
    "schema": "resourceitem1.schema.json",
    "id": "state/alarm",
    "datatype": "Bool",
    "access": "R",
    "public": true,
    "description": "True when an alarm is detected.",
    "parse": {"fn": "ias:zonestatus", "mask": "alarm1,alarm2"}
}

At reboot, with DDF disabled my device has a bad endpoint : 

 "7": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": "8f063cd77aa3789448084cacdecc590a",
    "lastannounced": null,
    "lastseen": "2021-11-24T17:23Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "AirQuality 7",
    "state": {
      "airquality": null,
      "airqualityppb": null,
      "lastupdated": "none"
    },
    "swversion": "4000",
    "type": "ZHAAirQuality",
    "uniqueid": "00:15:8d:00:05:be:9b:92-ff-ff66"
  }

And the worse is here. When I loaded my DDF file a new AirQuality device has been created with good values but the old AirQuality device remained with values belonging to others clusters. I'm going to be crazy.

{
  "1": {
    "config": {
      "configured": true,
      "on": true,
      "sunriseoffset": 30,
      "sunsetoffset": -30
    },
    "etag": "4582f4991e9a137e77bc66f5199cafaa",
    "manufacturername": "Philips",
    "modelid": "PHDL00",
    "name": "Daylight",
    "state": {
      "dark": true,
      "daylight": false,
      "lastupdated": "2021-11-24T18:01:20.602",
      "status": 230,
      "sunrise": "2021-11-24T06:51:28",
      "sunset": "2021-11-24T16:14:42"
    },
    "swversion": "1.0",
    "type": "Daylight",
    "uniqueid": "00:21:2e:ff:ff:06:9b:04-01"
  },
  "2": {
    "config": {
      "battery": 100,
      "offset": 0,
      "on": true,
      "reachable": true
    },
    "ep": 1,
    "etag": "8a1ad480e436edb6e0a022257e2a7359",
    "lastannounced": "2021-11-03T17:53:52Z",
    "lastseen": "2021-11-24T17:58Z",
    "manufacturername": "LUMI",
    "modelid": "lumi.weather",
    "name": "Multi Sensor",
    "state": {
      "lastupdated": "2021-11-24T17:58:26.051",
      "temperature": 1732
    },
    "swversion": "20191205",
    "type": "ZHATemperature",
    "uniqueid": "00:15:8d:00:01:9d:18:b7-01-0402"
  },
  "3": {
    "config": {
      "battery": 100,
      "offset": 0,
      "on": true,
      "reachable": true
    },
    "ep": 1,
    "etag": "d25990142062450ead597dab307404ad",
    "lastannounced": "2021-11-03T17:53:52Z",
    "lastseen": "2021-11-24T17:58Z",
    "manufacturername": "LUMI",
    "modelid": "lumi.weather",
    "name": "Humidity 3",
    "state": {
      "humidity": 5808,
      "lastupdated": "2021-11-24T17:58:26.085"
    },
    "swversion": "20191205",
    "type": "ZHAHumidity",
    "uniqueid": "00:15:8d:00:01:9d:18:b7-01-0405"
  },
  "4": {
    "config": {
      "battery": 100,
      "offset": 0,
      "on": true,
      "reachable": true
    },
    "ep": 1,
    "etag": "f3af3465854183de1a4344ebdae1acf4",
    "lastannounced": "2021-11-03T17:53:52Z",
    "lastseen": "2021-11-24T17:58Z",
    "manufacturername": "LUMI",
    "modelid": "lumi.weather",
    "name": "Pressure 4",
    "state": {
      "lastupdated": "2021-11-24T17:58:26.104",
      "pressure": 1001
    },
    "swversion": "20191205",
    "type": "ZHAPressure",
    "uniqueid": "00:15:8d:00:01:9d:18:b7-01-0403"
  },
  "5": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": null,
    "lastannounced": null,
    "lastseen": "2021-11-24T18:13Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "Consumption 5",
    "state": {
      "consumption": 1.03294E+7,
      "lastupdated": "none"
    },
    "swversion": "4000",
    "type": "ZHAConsumption",
    "uniqueid": "00:15:8d:00:05:be:9b:92-01-0702"
  },
  "6": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": null,
    "lastannounced": null,
    "lastseen": "2021-11-24T18:13Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "Power 6",
    "state": {
      "current": 3,
      "lastupdated": "none",
      "power": 640,
      "voltage": null
    },
    "swversion": "4000",
    "type": "ZHAPower",
    "uniqueid": "00:15:8d:00:05:be:9b:92-01-0b04"
  },
  "7": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": "75fa180982ab55c7c3b97e3fe8095e98",
    "lastannounced": null,
    "lastseen": "2021-11-24T17:23Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "AirQuality 7",
    "state": {
      "airquality": null,
      "airqualityppb": 640,
      "lastupdated": "none"
    },
    "swversion": "4000",
    "type": "ZHAAirQuality",
    "uniqueid": "4000"
  },
  "8": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": "5447e52291f200f39320392a55fb1767",
    "lastannounced": null,
    "lastseen": "2021-11-24T18:13Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "AirQuality 8",
    "state": {
      "alarm": false,
      "lastupdated": "none"
    },
    "swversion": "4000",
    "type": "ZHAAirQuality",
    "uniqueid": "00:15:8d:00:05:be:9b:92-01-ff66"
  }
}
Smanar commented 2 years ago

@manup but it s normal the DDF core (even I m not sure it's his fault, but never see this kind of issue before) is able to create new entry (outside a inclusion procedure) or edit an uniqueid ?

The "hot reload" command can create a new entry outside the inclusion procedure ?

So what are the "static values" only the manufacture and model id ? So it mean we can have a new ID at every test ?

AdrienBigot commented 2 years ago

Hi,

@manup if some informations are missing, I can help and do more testing. And if needed, I can arrange you a ssh access to my testing deCONZ instance linked to LiXee device. Thank you.

Adrien

Smanar commented 2 years ago

Hello, the last beta is out, if you have some time to check if you still have this kind of issues ?

AdrienBigot commented 2 years ago

Hi,

It's not very clear for me what diferent DDF mode (bronze, silver gold ....) means exactly but I've tested with latest v2.13.3-beta.

WHen I start deconz and request I've first : 

curl -s -X GET -H "Content-Type: application/json" http://xxxxxxxxxxxxxxxxxxxxxx.fr/api/XXXXXXXXXXXXX/sensors/ | jq .
{
  "1": {
    "config": {
      "configured": true,
      "on": true,
      "sunriseoffset": 30,
      "sunsetoffset": -30
    },
    "etag": "f4923cbea8aa922e857ac86dda24f419",
    "manufacturername": "Philips",
    "modelid": "PHDL00",
    "name": "Daylight",
    "state": {
      "dark": true,
      "daylight": false,
      "lastupdated": "2021-12-10T21:21:40.297",
      "status": 230,
      "sunrise": "2021-12-10T07:08:31",
      "sunset": "2021-12-10T16:09:45"
    },
    "swversion": "1.0",
    "type": "Daylight",
    "uniqueid": "00:21:2e:ff:ff:06:9b:04-01"
  },
  "2": {
    "config": {
      "battery": 100,
      "offset": 0,
      "on": true,
      "reachable": true
    },
    "ep": 1,
    "etag": "853c074b3ecf65b4144bfed9fb8da51b",
    "lastannounced": "2021-12-06T22:55:19Z",
    "lastseen": "2021-12-10T21:24Z",
    "manufacturername": "LUMI",
    "modelid": "lumi.weather",
    "name": "Multi Sensor",
    "state": {
      "lastupdated": "2021-12-10T21:24:36.939",
      "temperature": 1459
    },
    "swversion": "20191205",
    "type": "ZHATemperature",
    "uniqueid": "00:15:8d:00:01:9d:18:b7-01-0402"
  },
  "3": {
    "config": {
      "battery": 100,
      "offset": 0,
      "on": true,
      "reachable": true
    },
    "ep": 1,
    "etag": "56208e7082341f70427084c12786c6a5",
    "lastannounced": "2021-12-06T22:55:19Z",
    "lastseen": "2021-12-10T21:24Z",
    "manufacturername": "LUMI",
    "modelid": "lumi.weather",
    "name": "Humidity 3",
    "state": {
      "humidity": 4596,
      "lastupdated": "2021-12-10T21:24:36.997"
    },
    "swversion": "20191205",
    "type": "ZHAHumidity",
    "uniqueid": "00:15:8d:00:01:9d:18:b7-01-0405"
  },
  "4": {
    "config": {
      "battery": 100,
      "offset": 0,
      "on": true,
      "reachable": true
    },
    "ep": 1,
    "etag": "eea1b0bb43eb52b2abba598c60ecc67b",
    "lastannounced": "2021-12-06T22:55:19Z",
    "lastseen": "2021-12-10T21:24Z",
    "manufacturername": "LUMI",
    "modelid": "lumi.weather",
    "name": "Pressure 4",
    "state": {
      "lastupdated": "2021-12-10T21:24:37.039",
      "pressure": 1002
    },
    "swversion": "20191205",
    "type": "ZHAPressure",
    "uniqueid": "00:15:8d:00:01:9d:18:b7-01-0403"
  },
  "5": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": "3589b37f1be1acb3bcebddc34053c2b8",
    "lastannounced": null,
    "lastseen": "2021-12-10T20:52Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "Consumption 5",
    "state": {
      "consumption": null,
      "lastupdated": "none"
    },
    "swversion": "4000",
    "type": "ZHAConsumption",
    "uniqueid": "00:15:8d:00:05:be:9b:92-ff-0702"
  },
  "6": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": "8018ca0904efa575bb1023f61e5905d8",
    "lastannounced": null,
    "lastseen": "2021-12-10T20:52Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "Power 6",
    "state": {
      "current": null,
      "lastupdated": "none",
      "power": null,
      "voltage": null
    },
    "swversion": "4000",
    "type": "ZHAPower",
    "uniqueid": "00:15:8d:00:05:be:9b:92-ff-0b04"
  },
  "7": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": "27cfedb6ae6ad3a8832e2be2a3e871ca",
    "lastannounced": null,
    "lastseen": "2021-11-24T17:23Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "AirQuality 7",
    "state": {
      "airquality": null,
      "airqualityppb": null,
      "lastupdated": "none"
    },
    "swversion": "4000",
    "type": "ZHAAirQuality",
    "uniqueid": "00:15:8d:00:05:be:9b:92-ff-ff66"
  }
}

So, sensors 5 6 and 7 have a bad endpoint.

Then, I load the DDF File : 

curl -s -X GET -H "Content-Type: application/json" http://xxxxxxxxxxxxxxxxxxxxxx.fr/api/XXXXXXXXXXXXX/sensors/ | jq .
{
  "1": {
    "config": {
      "configured": true,
      "on": true,
      "sunriseoffset": 30,
      "sunsetoffset": -30
    },
    "etag": "f4923cbea8aa922e857ac86dda24f419",
    "manufacturername": "Philips",
    "modelid": "PHDL00",
    "name": "Daylight",
    "state": {
      "dark": true,
      "daylight": false,
      "lastupdated": "2021-12-10T21:21:40.297",
      "status": 230,
      "sunrise": "2021-12-10T07:08:31",
      "sunset": "2021-12-10T16:09:45"
    },
    "swversion": "1.0",
    "type": "Daylight",
    "uniqueid": "00:21:2e:ff:ff:06:9b:04-01"
  },
  "2": {
    "config": {
      "battery": 100,
      "offset": 0,
      "on": true,
      "reachable": true
    },
    "ep": 1,
    "etag": "853c074b3ecf65b4144bfed9fb8da51b",
    "lastannounced": "2021-12-06T22:55:19Z",
    "lastseen": "2021-12-10T21:24Z",
    "manufacturername": "LUMI",
    "modelid": "lumi.weather",
    "name": "Multi Sensor",
    "state": {
      "lastupdated": "2021-12-10T21:24:36.939",
      "temperature": 1459
    },
    "swversion": "20191205",
    "type": "ZHATemperature",
    "uniqueid": "00:15:8d:00:01:9d:18:b7-01-0402"
  },
  "3": {
    "config": {
      "battery": 100,
      "offset": 0,
      "on": true,
      "reachable": true
    },
    "ep": 1,
    "etag": "56208e7082341f70427084c12786c6a5",
    "lastannounced": "2021-12-06T22:55:19Z",
    "lastseen": "2021-12-10T21:24Z",
    "manufacturername": "LUMI",
    "modelid": "lumi.weather",
    "name": "Humidity 3",
    "state": {
      "humidity": 4596,
      "lastupdated": "2021-12-10T21:24:36.997"
    },
    "swversion": "20191205",
    "type": "ZHAHumidity",
    "uniqueid": "00:15:8d:00:01:9d:18:b7-01-0405"
  },
  "4": {
    "config": {
      "battery": 100,
      "offset": 0,
      "on": true,
      "reachable": true
    },
    "ep": 1,
    "etag": "eea1b0bb43eb52b2abba598c60ecc67b",
    "lastannounced": "2021-12-06T22:55:19Z",
    "lastseen": "2021-12-10T21:24Z",
    "manufacturername": "LUMI",
    "modelid": "lumi.weather",
    "name": "Pressure 4",
    "state": {
      "lastupdated": "2021-12-10T21:24:37.039",
      "pressure": 1002
    },
    "swversion": "20191205",
    "type": "ZHAPressure",
    "uniqueid": "00:15:8d:00:01:9d:18:b7-01-0403"
  },
  "5": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": null,
    "lastannounced": null,
    "lastseen": "2021-12-10T21:30Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "Consumption 5",
    "state": {
      "consumption": 1.06201E+7,
      "lastupdated": "2021-12-10T21:31:09.777"
    },
    "swversion": "4000",
    "type": "ZHAConsumption",
    "uniqueid": "00:15:8d:00:05:be:9b:92-01-0702"
  },
  "6": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": null,
    "lastannounced": null,
    "lastseen": "2021-12-10T21:30Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "Power 6",
    "state": {
      "current": 2,
      "lastupdated": "2021-12-10T21:31:09.683",
      "power": 760,
      "voltage": null
    },
    "swversion": "4000",
    "type": "ZHAPower",
    "uniqueid": "00:15:8d:00:05:be:9b:92-01-0b04"
  },
  "7": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": "1667c2360a546878482342c6251b94f1",
    "lastannounced": null,
    "lastseen": "2021-11-24T17:23Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "AirQuality 7",
    "state": {
      "airquality": "unhealthy",
      "airqualityppb": null,
      "lastupdated": "2021-12-10T21:31:02.263"
    },
    "swversion": "4000",
    "type": "ZHAAirQuality",
    "uniqueid": "00:15:8d:00:05:be:9b:92-ff-ff66"
  },
  "8": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": null,
    "lastannounced": null,
    "lastseen": "2021-12-10T21:55Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "AirQuality 8",
    "state": {
      "alarm": false,
      "lastupdated": "2021-12-10T21:59:16.232"
    },
    "swversion": "4000",
    "type": "ZHAAirQuality",
    "uniqueid": "00:15:8d:00:05:be:9b:92-01-ff66"
  }

}

Sensors 5 and 6 are now OK (according to the DDF config), BUT we got a zombie sensor 7 with bad endpoint in uniqueid and a new sensors 8 that is pretty OK.

I say pretty because I've modified the file /usr/share/deCONZ/devices/generic/constants.json and added a file /usr/share/deCONZ/devices/generic/subdevices/LiXee_sensor.json to have a good subdevice type : ZHALiXee

But this good subdevice type is visible only when I query the sensor directly : 

curl -s -X GET -H "Content-Type: application/json" http://xxxxxxxxxxxxxxxxxxxxx.fr/api/XXXXXXXXX/sensors/8 | jq .
{
  "config": {
    "on": true,
    "reachable": true
  },
  "etag": "9353eb328d25543633835736498b8636",
  "lastannounced": null,
  "lastseen": "2021-12-10T21:53Z",
  "manufacturername": "LiXee",
  "modelid": "ZLinky_TIC",
  "name": "LiXee 8",
  "state": {
    "alarm": false,
    "lastupdated": "2021-12-10T21:59:16.203"
  },
  "swversion": "4000",
  "type": "ZHALiXee",
  "uniqueid": "00:15:8d:00:05:be:9b:92-01"
}

So I think there is again problem inside the database.

Smanar commented 2 years ago

It's not very clear for me what diferent DDF mode (bronze, silver gold ....) means exactly but I've tested with latest v2.13.3-beta.

I haven't confirmation, but I think "gold" will enable the DDF even you are on "basic" mode.

And if you close and restart deconz, you will have again the "bad uniqueid" devices ?

And for information, I need to use "strict" mode on my side, "hybrid" don't work, the legacy code have still priority on the DDF one.

AdrienBigot commented 2 years ago

To be sure not to have side effect caused by bad values into database, I've purged from the sqlite database all LiXee references (mac address) from tables ressource_item , sub_devices an sensors tables.

At the first start of deCONZ my device is detected like in this : start

A curl of /sensors endpoint doesn't contains anything about the LiXee device.

Then, I load my DDF File, the device is seen as LiXee. Good point.

ddf_loaded

A curl contains all sensors with good uniqueid : 

"5": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": "072761e12e339ceee5eac44e23b49d28",
    "lastannounced": null,
    "lastseen": "2021-12-11T18:24Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "Power 5",
    "state": {
      "current": 4,
      "lastupdated": "2021-12-11T18:28:15.132",
      "power": 840,
      "voltage": null
    },
    "swversion": "4000",
    "type": "ZHAPower",
    "uniqueid": "00:15:8d:00:05:be:9b:92-01-0b04"
  },
  "6": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": "c64019fcf2c89bd800ecdac5eb4671ba",
    "lastannounced": null,
    "lastseen": "2021-12-11T18:24Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "Consumption 6",
    "state": {
      "consumption": 1.06366E+7,
      "lastupdated": "2021-12-11T18:28:30.106"
    },
    "swversion": "4000",
    "type": "ZHAConsumption",
    "uniqueid": "00:15:8d:00:05:be:9b:92-01-0702"
  },
  "7": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": "8db4bcf0863e8b0d9dd3df250d05c1c3",
    "lastannounced": null,
    "lastseen": "2021-12-11T18:24Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "LiXee 7",
    "state": {
      "alarm": false,
      "lastupdated": "2021-12-11T18:28:33.702"
    },
    "swversion": "4000",
    "type": "ZHALiXee",
    "uniqueid": "00:15:8d:00:05:be:9b:92-01-ff66"
  }

All is good for now.

If I stop and start deconz without loading DDF file API returns sensors with bad uniqueid. This bad uniqueID is only returns by API, I cannot find this bad uniqueID in the database.

 "5": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": "faa24682514dd962658c8778e719f4ae",
    "lastannounced": null,
    "lastseen": "2021-12-11T18:24Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "Power 5",
    "state": {
      "current": 4,
      "lastupdated": "2021-12-11T18:25:20.460",
      "power": 880,
      "voltage": 0
    },
    "swversion": "4000",
    "type": "ZHAPower",
    "uniqueid": "00:15:8d:00:05:be:9b:92-ff-0b04"
  },
  "6": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": "6a7225cef9401dc5e3e0a47fbf2b829f",
    "lastannounced": null,
    "lastseen": "2021-12-11T18:24Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "Consumption 6",
    "state": {
      "consumption": 1.06366E+7,
      "lastupdated": "2021-12-11T18:25:29.204"
    },
    "swversion": "4000",
    "type": "ZHAConsumption",
    "uniqueid": "00:15:8d:00:05:be:9b:92-ff-0702"
  },
  "7": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": "dcda74a8c65adb65319e8a6efce64242",
    "lastannounced": null,
    "lastseen": "2021-12-11T18:24Z",
    "manufacturername": "LiXee",
    "modelid": "ZLinky_TIC",
    "name": "LiXee 7",
    "state": {
      "lastupdated": "2021-12-11T18:25:28.331"
    },
    "swversion": "4000",
    "type": "ZHALiXee",
    "uniqueid": "00:15:8d:00:05:be:9b:92-ff-ff66"
  }

And if I load again DDF, all is back to normal state / uniqueid.

I don't see anymore my zombie sensors and I think it was a due to a bad record in my database caused by many many tests ...

So now, I'll try to power on many many electrical devices and test if the state/alarm change from false to true. I think we are closed to have a functional device. But I can't imagine to ask people to use DDF files like I did. So what would be the best solution ?

Smanar commented 2 years ago

So now, I'll try to power on many many electrical devices and test if the state/alarm change from false to true

BTW, for information, 1 week ago I was at a client with a linky, He need to use 45A on a 30A lnstallation before something cut the power and it was the circuit breaker not the linky.

But I can't imagine to ask people to use DDF files like I did. So what would be the best solution ?

I think the issue is perhaps not visible if DDF are enabled all the time, but for me there is still something bad somewhere.

AdrienBigot commented 2 years ago

Hi,

I've checked the alarm. In the Enedis documentation it says "L’intensité de référence est calculée de la façon suivante : IR = P Référence en VA/200 V." So My IR max is 6000/200 = 30A.

With a current of 32A (2amps above my 30A allowed) I successfully trigger a change from false to true on the alarm state.

curl -s -X GET -H "Content-Type: application/json" http://xxxxxxxxxxxxxxxxxxxxxxxxxxxx.fr/api/XXXXXXXXXXXX/sensors/ | jq '.["5","7"].state'
{
  "current": 32,
  "lastupdated": "2021-12-12T17:55:11.209",
  "power": 7180,
  "voltage": null
}
{
  "alarm": true,
  "lastupdated": "2021-12-12T17:55:11.453"
}

But now, my alarm is always set to true because the ADPS (Avertissement de dépassement de Puissance Souscrite) is set to 32 adps

I don't know how many time I have to wait for an update of the 0x0005 id by the Linky ... @fairecasoimeme maybe are you aware about that ? I didn't see this information neither in the Enedis documentation nor yours.

AdrienBigot commented 2 years ago

Checked just now (more than 24hours after the first test), the value of the attribute 0x0005 in the cluster 0xff66 is still the same as yesterday : 32A. Therefore, the subscribed power exceeded alarm is always set to true.

@fairecasoimeme : did you ever face this situation ?

Thank you in advance.

Adrien.

fairecasoimeme commented 2 years ago

Normally, the information is updated from Linky all of 7 second. To my knowledge, I never had this case. If it persist i can ask to Enedis.

chpego commented 2 years ago

Checked just now (more than 24hours after the first test), the value of the attribute 0x0005 in the cluster 0xff66 is still the same as yesterday : 32A. Therefore, the subscribed power exceeded alarm is always set to true.

from here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5459#issuecomment-975690456

image

it should be normal, no ?

AdrienBigot commented 2 years ago

@chpego yes it should be normal to have the alarm to "true" but only when attribute "avertissement de puissance souscrite" is set to a value > 0.

When I ran my test this attribute changed to 32A because I exceeded my 30A allowed. But as soon as I fall below 30A, this attribute should go back to 0. However, on my side, it remained more than 24 hours at 32A while I was only consuming a few amps. The problem seems not to be on deCONZ but on the Enedis side.

@fairecasoimeme This morning this value is back to zero. I've try a second test and I confirm the problem. I can confirm that the value of ADPS change every 7-10 secondes but only when this value is over my max allowed power.

I'll try to explain it clearly :

  1. I turn on many devices and ADPS value increase to 38A.
  2. I turn off one device, the value change to 34A in a few seconds.
  3. I turn off another device, the value change to 31A.
  4. And finally I turn off all unecessary devices, I'm stuck to the last 31A value since 10 minutes (and I think for many hours).

So I confirm that if I exceed the limit value, the changing values above this limit are regularly updated but once I fall below my max value, I remain stuck at the last value recorded above the limit.

Edit : 3 hours later, same problem. the value of ADPS is still 31 A.

Smanar commented 2 years ago

This morning this value is back to zero

But it return to 0 after a time ?

BTW @AdrienBigot about the DDF issue, I m not sure to understand that he have said, but if you can take a look ?

the uuid should be restored from DDF after restart, could it be that the file isn't loaded? This would be visible in the Editor title bar which should show the file path.

I think after you restart, if you go to see the DDF editor, you will found something. But as at restart DDF are disabled, idk if it can have an impact, but can be something usefull to check.

AdrienBigot commented 2 years ago

But it return to 0 after a time ?

When you ask me this question, I remember that I've unplugged and plug again my Zlinky_TIC (to try to solve a physical problem with my old Linky device that not fit very good with this module ...) and since this moment value was back to zero. So I try to reproduce it and that did the trick !! If I unpluged and plug my Zlinky, my ADPS 36A stucked value is back to 0 ! @fairecasoimeme could you try to reproduce this ? Is the zlinky_tic capable to store in memory this value ?

I m not sure to understand that he have said, but if you can take a look ?

OK I understand !! Since the last deCONZ version, DDF are enabled at boot for file with Gold status. So I change the DDF status to Gold and place my file in the directory where deCONZ expects to find the DDF files : ~/.local/share/dresden-elektronik/deCONZ/devices/ And it works !

But as you said in a previous post, there is something bad somewhere. (If I remove my file and start deCONZ, bad uniqueid appears again and mess up my database).

AdrienBigot commented 2 years ago

For information, Since deCONZ can uses DDF files at boot, I can use these informations in Home Assistant. It also needs some modifications in deCONZ file /usr/share/deCONZ/devices/generic/constants.json and add a file /usr/share/deCONZ/devices/generic/subdevices/LiXee_sensor.json to have a good subdevice type.

lixee_deconz_ha

@Smanar what is missing to integrate correctly this device in deconz ? I understand that because of different type of installation, different type of contract etc ... it'not easy . But can we move forward by adding missing config file to recognize correctly the LiXee subdevice type ? It also needs specific cluster config in general.xml.

Thanks !

Here my DDF file content : 

{
  "schema": "devcap1.schema.json",
  "manufacturername": "LiXee",
  "modelid": "ZLinky_TIC",
  "product": "ZLinky_TIC",
  "sleeper": false,
  "status": "Gold",
  "path": "/devices/zlinky_tic_with_alarm.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/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": "0x0000",
            "cl": "0x0702",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0000",
            "cl": "0x0702",
            "ep": 1,
            "eval": "Item.val = Attr.val"
          }
        },
        {
          "name": "state/lastupdated"
        }
      ]
    },
    {
      "type": "$TYPE_LIXEE_SENSOR",
      "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": "0x0B04",
      "report": [
        {
          "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": "0x0702",
      "report": [
        {
          "at": "0x0000",
          "dt": "0x23",
          "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 commented 2 years ago

@Smanar what is missing to integrate correctly this device in deconz ?

You know better the answer than me ^^.

I understand that because of different type of installation, different type of contract etc ... it'not easy.

Yep, but I think your config will be the more standard, for the moment I think the better way is using a different DDF file, according to the user setting. Will be realy hard to make only 1 DDF for all situations

But can we move forward by adding missing config file to recognize correctly the LiXee subdevice type ? It also needs specific cluster config in general.xml.

I will make the PR for the Lixee cluster now. (I m not sure, You have modified something on your side ?)

There is not yet an "official DDF store" (I will ask some information for that), but I think this issue is easy to find, to have a working DDF. There is this link https://forum.phoscon.de/c/ddf-library/21 but I don't see how thoses one will be transfered to deconz later.

And BTW some news about the method to reset the attribute 0x0005 ? But It can be normal, for exemple some presence sensor, send a notification at every detection but never reset the value.

AdrienBigot commented 2 years ago

I will make the PR for the Lixee cluster now. (I m not sure, You have modified something on your side ?)

Great ! Thank you ! I saw your PR #5592 but in the commit I didn't see new subdevice and constant.json file modification. Are you preparing another PR ?

And BTW some news about the method to reset the attribute 0x0005 ?

I've opened an issue here : https://github.com/fairecasoimeme/Zlinky_TIC/issues/34

Smanar commented 2 years ago

I saw your PR #5592 but in the commit I didn't see new subdevice and constant.json file modification

Ha yes, haven't thinked about that. You don't prefer a ZHAalarm ? because for exemple HA will be able to manage them natively ? I can propose a ZHALiXee, but this type will be usable only for this device, and deconz try to be not specific.

A ZHALiXee can be usefull for future parameter, for exemple "option tarifaire" will be strange in a ZHAalarm if one day it was usefull to use it dynamically. But it mean all third app need to manage this new type.

Ca use a new ZHAtype, but need to find "THE usefull type", there is no special type for manufacture.

Edit:

I think it can work without editing the json file if we use "type": "ZHALiXee", Instead of "type": "$TYPE_LIXEE_SENSOR",

AdrienBigot commented 2 years ago

I think it can work without editing the json file if we use "type": "ZHALiXee", Instead of "type": "$TYPE_LIXEE_SENSOR",

I've checked and it's OK.

You don't prefer a ZHAalarm ? because for exemple HA will be able to manage them natively ?

You are perfectly right ! I've forgot it but it's exactly what I've done to be able to use it in HomeAssitant. So, for the moment it's good to say we'll use ZHAAlarm surbdevice for this case. If it appears there is other needs, other people will open tickets :)

I'll try to add my DDF file in the forum. Maybe it will help ... : https://forum.phoscon.de/t/lixee-zlinky-tic-ddf-file/1164

@chpego : since few day , HA updated its deCONZ integration to 6.11.1 and Bump deCONZ to 2.13.4. So, you can try to use DDF file.

chpego commented 2 years ago

Yep @AdrienBigot , i've already updated HA and deconz. So i will try as soon as possible 👍

chpego commented 2 years ago

Great news, after upload your last DDF file, it's seems to be OK in HomeAssistant : image

pipiche38 commented 2 years ago

@Smanar just for your information, this is quiet plugin oriented, but I guess you can also find some usefull infos https://github.com/pipiche38/Domoticz-Zigate-Wiki/blob/master/en-eng/Technical/zlinky-integration.md

Smanar commented 2 years ago

It make so much widgets in domoticz ^^, not sure I will use all features.

libussa commented 2 years ago

So in reality was not as terrifying than the table size, sorry for my reaction @fairecasoimeme . I still hope that no one will use the "Mode standard" soon.

I actually have standard mode enabled, and am hesitant on buying this module...Would it work with deconz in the current state?

Smanar commented 2 years ago

Arfff. already ... No, nothing was done for the standard mode yet.

antoinelibert commented 2 years ago

Hello,

I have received the module and I'm currently using it with the DDL file uploaded previously in this issue. I'm in "Historique" mode and it's working great so far (deconz+HA). I have asked my energy provider to switch to "Standard" and I'm expecting to change some cluster and attribut ID in the DDL to make it work again, is that right? (This is just for the basic info we already have with the "historique" mode and some I would like to have such as "Tension efficace")

Smanar commented 2 years ago

It's a different working mode. First better to edit the xml file to support the mode "standard" and test values (the XML with lixee value is here https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5592)

Need to check wich one attribute can be usefull here https://github.com/fairecasoimeme/Zlinky_TIC#mode-standard

For me :

I m thinking the DDF can probably work for both mode, it's exactly the same one ....

antoinelibert commented 2 years ago

Thanks for the additional infos. I will report back when my Linky switches mode.

antoinelibert commented 2 years ago

So, my energy provider just switched me to Standard mode. Everything seems to work fine except the electricity consumption index value which jumped almost 25 kWh. It seems that the value is now based on "INDEX MID" value on the Linky screen and not the first screen anymore. Otherwise, I have now the voltage too :)

image

Smanar commented 2 years ago

So the bad one is ?

Need to use 0x0100 Instead ? Can add it to the xml to test.

antoinelibert commented 2 years ago

Hello,

I fixed it by just editing the DDF file to use 0x0100 instead of 0x0000. I didn't edit the general.xml file at all.

image

Now everything works as expected

image

Smanar commented 2 years ago

Have added them to the xml file https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5592

But I don't see how to make a DDF that can work for both mode. On the DDF you have editing the bind too ? (to know if the device need it)

antoinelibert commented 2 years ago

I have a limited understanding of DDF/Deconz/Zigbee but maybe the easiest for now will be to include the DDF file for "historique" mode by default as most of the people will have their Linky meter configured in that mode. Anyone wanting more should do a custom DDF file. Maybe a wiki page for specific device? Is there such a thing?

I did redo the binding but after removing all bindings and restarting Deconz, it still works (values still auto update in HA). Not sure I understand the purpose of bindings.

chrifabre commented 2 years ago

Hello, I acquired the Linxee Zlinky and I followed this post carefully.

Smanar commented 2 years ago

We can make 2 DDF for the moment, but have you edited this line in the DDF 

      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0702",
      "report": [
        {
          "at": "0x0000",
          "dt": "0x23",
          "min": 1,
          "max": 300,
          "change": "0x00000001"
        }
      ]
    },

To known if the bind is usefull or not. If not we can use the 2 returns to update the same field in the json. But if the bind is usefull, better to make 2 DDF than making 2 binds with one for nothing.

BTW, if you add the second mode here https://forum.phoscon.de/t/lixee-zlinky-tic-ddf-file/1164 ?

@chrifabre perhaps this link can help you ? https://forum.phoscon.de/t/ddf-editor-how-to-drag-bindings/1351/13 But you can just intall the DDF file.

but how to download it in deCONZ integrated in Home Assistant?

Good question, but here I can't help you

AdrienBigot commented 2 years ago

Hello,

but how to download it in deCONZ integrated in Home Assistant?

I use a separated deCONZ instance on a dedicated raspberry PI so my config is not the same than HA container. But If you are able to push files inside your HA deCONZ container I think it's faisable.

deCONZ read DDF files when it starts in the directory : ~/.local/share/dresden-elektronik/deCONZ/devices/ To be sure where deCONZ read files, in the DDF editor, try to Open a DDF file and note the directory where you are in the dialog box.

For me it's : Capture d’écran du 2022-01-21 18-48-55

But maybe @chpego can help, I remember he did it successfully.

chpego commented 2 years ago

@chrifabre If you've acces on the core system from SSH in HA, you can search in your files directory here (/mnt/data/supervisor/addons/data/core_deconz/), if you've the deconz addon ;) You can push xml files in this directory

antoinelibert commented 2 years ago

We can make 2 DDF for the moment, but have you edited this line in the DDF

      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0702",
      "report": [
        {
          "at": "0x0000",
          "dt": "0x23",
          "min": 1,
          "max": 300,
          "change": "0x00000001"
        }
      ]
    },

To known if the bind is usefull or not. If not we can use the 2 returns to update the same field in the json. But if the bind is usefull, better to make 2 DDF than making 2 binds with one for nothing.

With further testing, I almost sure that we need the binding. Index value was not updating after a cold reboot of the module. So I put them back.

BTW, if you add the second mode here https://forum.phoscon.de/t/lixee-zlinky-tic-ddf-file/1164 ?

I have added the DDF file for "standard" mode in the forum.

MrMoblys commented 2 years ago

Hello,

I managed to integrate LixeeTIC into HA by following this tutorial but the DDF is for Standard mode and a basic contract. I am in History mode and HP/HC contract. I managed to recover one of the sensors (HP) but I do not understand how the DDF works to add another sensor in connection with HC.

Could you help me please ?

Otherwise bravo for the development of the product and its integration.

chrifabre commented 2 years ago

Hello Thank you for your messages. I use Hassio + DECONZ integration. It is impossible for me to make the windows float in the DECONZ browser. On the other hand, with Putty, I can't find the json files (DDF), nor the directories displayed

Smanar commented 2 years ago

~/.local/share/dresden-elektronik/deCONZ/devices/

This folder don't exist on your config ?

Perhaps something like /opt/deCONZ/devices

chrifabre commented 2 years ago

Operating System: Home Wizard OS 7.2 Version core-2021.12.10 Add-on: deCONZ Current version: 6.11.1

I can't find "/opt/deCONZ/devices" I searched with "deCONZ", "dresden-elektronik", without success.

MrMoblys commented 2 years ago

Hello,

I managed to integrate LixeeTIC into HA by following this tutorial but the DDF is for Standard mode and a basic contract. I am in History mode and HP/HC contract. I managed to recover one of the sensors (HP) but I do not understand how the DDF works to add another sensor in connection with HC.

Could you help me please ?

Otherwise bravo for the development of the product and its integration.

I answer myself because I think I have found.

This is what I have in HA: 2022-01-23_15h46_06

Here is my DDF: zlinky_tic.txt

Smanar commented 2 years ago

If I m right you have both DDF here https://forum.phoscon.de/t/lixee-zlinky-tic-ddf-file/1164 for both modes.

Time for include DDF officially in deconz.

MrMoblys commented 2 years ago

Operating System: Home Wizard OS 7.2 Version core-2021.12.10 Add-on: deCONZ Current version: 6.11.1

I can't find "/opt/deCONZ/devices" I searched with "deCONZ", "dresden-elektronik", without success.

On the HA OS console, type "login" and find: /mnt/data/supervisor/addons/data/core_deconz/.local/share/dresden-elektronik/deCONZ/devices/

MrMoblys commented 2 years ago

If I m right you have both DDF here https://forum.phoscon.de/t/lixee-zlinky-tic-ddf-file/1164 for both modes.

Time for include DDF officially in deconz.

I was inspired by it ;)

antoinelibert commented 2 years ago

Hello,

I'm currently seeing an annoying issue is that deconz doesn't report that the device is unavailable if I unplug it. My HA entity values are stuck to the latest number instead of showing "unavailable". This is messing with the statistics graph and data. (I needed to sent back my module for a hardware issue https://github.com/fairecasoimeme/Zlinky_TIC/issues/42).

Can this be fixed in the DDF file?

Smanar commented 2 years ago

How many time you unplug it ? The delay to mark a device as unreachable is around 24h from my memory (I can check if needed) for sensor. But it's faster for router.

But during this time the device stop to send report, so your graph are not updated ?