dresden-elektronik / deconz-rest-plugin

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

lumi.plug.maeu01 Sensor values not updated in REST API #7108

Closed traschke closed 1 year ago

traschke commented 1 year ago

Describe the bug

After rebuilding my network, I cannot get the power and consumption sensors of lumi.plug.maeu01 to work via the REST API. The values don't update at all and show 0 all the time, with the exception of voltage. I followed the steps in the wiki article (updating firmware), which wasn't necessary as it is already on this version. The value of e.g. power can be seen in the "Analog Input (Basic) Cluster", so I assume that the values somehow reach deconz, but are not populated to the REST API.

I assume the correct DDF for the plug is used (see screenshot).

I re-paired the plug around 50 times today, nothing seems to help.

The smartplug just worked fine in my old environment, which was running the rather old deconz version 2.18.01, but I remember I had issues there as well getting it to work.

Steps to reproduce the behavior

  1. Pair Device
  2. measurements are not updated in REST API

Expected behavior

Measurements are updated in time in REST API so they can be used by 3rd party application (OpenHAB in my case)

Screenshots

image image image image image

Environment

deCONZ Logs

I can provide logs if needed.

Additional context

REST API output

/lights

{
  "config": {
    "groups": [
      "3"
    ]
  },
  "etag": "06313ddd12c7fcc3370a3af44f84e296",
  "hascolor": false,
  "lastannounced": "2023-07-15T16:50:23Z",
  "lastseen": "2023-07-15T17:05Z",
  "manufacturername": "LUMI",
  "modelid": "lumi.plug.maeu01",
  "name": "Smart plug 36",
  "state": {
    "on": true,
    "reachable": true
  },
  "swversion": "0x00000029",
  "type": "Smart plug",
  "uniqueid": "54:ef:44:10:00:4d:c0:4a-01"
}

/sensors

{
  "config": {
    "on": true,
    "reachable": true,
    "temperature": null
  },
  "ep": 21,
  "etag": "8c9a85367f49b5d63625ca61b9a190c5",
  "lastannounced": "2023-07-15T16:50:23Z",
  "lastseen": "2023-07-15T16:55Z",
  "manufacturername": "LUMI",
  "modelid": "lumi.plug.maeu01",
  "name": "Power 71",
  "state": {
    "current": 0,
    "lastupdated": "2023-07-15T16:50:30.401",
    "power": 0,
    "voltage": 223
  },
  "type": "ZHAPower",
  "uniqueid": "54:ef:44:10:00:4d:c0:4a-15-000c"
}
{
  "config": {
    "on": true,
    "reachable": true,
    "temperature": null
  },
  "ep": 31,
  "etag": "f7d3f8761e49b4753372f9e3a1ea8e70",
  "lastannounced": "2023-07-15T16:50:23Z",
  "lastseen": "2023-07-15T17:00Z",
  "manufacturername": "LUMI",
  "modelid": "lumi.plug.maeu01",
  "name": "Consumption 72",
  "state": {
    "consumption": 0,
    "lastupdated": "none"
  },
  "type": "ZHAConsumption",
  "uniqueid": "54:ef:44:10:00:4d:c0:4a-1f-000c"
}
Smanar commented 1 year ago

The DDF seem good for state/power for exemple

        {
          "name": "state/power",
          "refresh.interval": 10,
          "read": {
            "at": "0x0055",
            "cl": "0x000C",
            "ep": 21,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0055",
            "cl": "0x000C",
            "ep": 21,
            "eval": "Item.val = Math.round(Attr.val);"
          }
        },

Can you try to make manualy a bind with the cluster 0x000C / endpoint 0x15 from the device to the coordinator ? (not present in the DDF) And same for the consumption ? cluster 0x000C / endpoint 0x1F

For the current, the DDF use the same code than for the voltage, perhaps a problem on the idx ? There is no usefull logs ? (can play with "ddf" "info" and "info_l2" and if there is realy nothing "zcl")

traschke commented 1 year ago

I created the bindings with no effect. I noticed that the values "sometimes" seem to change. I guess the interval of updating these values is quite high and I wasn't patient enough. As I was thinking about it I remembered how I fixed this problem last time: In cluster FCC0 I changed the value of 0x00F6 (Reporting interval) from 300 (seconds, equals 5 minutes) to 10 seconds. Now the REST API magically reports the correct values in time.

I don't know if this is the "correct" solution to this problem or if theres anything else to be done, but it seems to work for me for now. I used this setting on a second plug (same model) and it works there as well.

image

Smanar commented 1 year ago

I m checking to add a field to set this value on the API, but it seem you have older model, that don't use DDF yet.

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/xiaomi/xiaomi_sp-euc01_smart_plug.json

Your device don't have attr/swversion and

"comment": "DDF for device firmwares at least above 0.0.0_0022, paired with xBee I fw 0x26400500 / xBee II fw 0x266f0700 and above",
  "matchexpr": "(R.endpoints.indexOf(0x15) !== -1) && (R.endpoints.indexOf(0x1F) !== -1);",

You have check if you aren't concerned by the firmware update ?

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Xiaomi-smart-plugs-not-working-correctly

github-actions[bot] commented 1 year ago

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

github-actions[bot] commented 1 year ago

As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.