dresden-elektronik / deconz-rest-plugin

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

Battery is always reporting 0% in _TZ3000_wkai4ga5 (TS0044 4-gang) #7048

Closed josemi73 closed 11 months ago

josemi73 commented 1 year ago

Describe the bug

Hi, the device in the title is not reporting battery status, how could I debug it?

image

Steps to reproduce the behavior

Battery status reports 0% always.

Expected behavior

it should show the real status of the battery. Buttons are working properly.

Screenshots

image

image

Environment

deCONZ Logs

18:22:47:265 DB found sensor C_I_4BTOLDOS 74 18:22:47:266 DB skip loading sensor C_I_4BTOLDOS 74, handled by DDF Tuya remote 4 gangs 18:23:35:451 Websocket 192.168.1.222:34182 send message: {"attr":{"id":"74","lastannounced":null,"lastseen":"2023-06-12T16:23Z","manufacturername":"_TZ3000_wkai4ga5","modelid":"TS0044","name":"C_I_4BTOLDOS","swversion":"1.0.2","type":"ZHASwitch","uniqueid":"70:ac:08:ff:fe:65:f4:c5-01-0006"},"e":"changed","id":"74","r":"sensors","t":"event","uniqueid":"70:ac:08:ff:fe:65:f4:c5-01-0006"} (ret = 2124871840) 18:23:35:452 APS-DATA.request id: 23, addrmode: 0x03, addr: 0x70ac08fffe65f4c5, profile: 0x0000, cluster: 0x0033, ep: 0x00 -> 0x00 queue: 1 len: 2 tx.options 0x04 18:23:49:317 DB sql exec REPLACE INTO sensors (sid, name, type, modelid, manufacturername, uniqueid, swversion, state, config, fingerprint, deletedState, mode, lastseen, lastannounced) VALUES ('74', 'C_I_4BTOLDOS', 'ZHASwitch', 'TS0044', '_TZ3000_wkai4ga5', '70:ac:08:ff:fe:65:f4:c5-01-0006', '1.0.2', '{"buttonevent":1002,"lastupdated":"2023-06-12T16:23:48.976"}', '{"battery":0,"on":true,"reachable":true}', '', 'normal', '1', '2023-06-12T16:23Z', '2023-06-12T16:23:40Z') 18:23:56:949 [INFO] - Button 1004 - TS0044, unicast to: 0x0000, endpoint: 0x01, cluster: ONOFF (0x0006), action: B1 double, payload: 01, zclSeq: 96 18:23:56:950 Websocket 192.168.1.222:34182 send message: {"e":"changed","id":"74","r":"sensors","state":{"buttonevent":1004,"lastupdated":"2023-06-12T16:23:56.949"},"t":"event","uniqueid":"70:ac:08:ff:fe:65:f4:c5-01-0006"} (ret = 2124870992)

Additional context

BabaIsYou commented 1 year ago

As I can see it seems that bindings for battery reports had been removed during a previous DDF modification. Are you able to modify DDF file directly onto your system to give a try to reintroduce the battery report with someting like this ?

    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0001",
      "report": [
        {
          "at": "0x0021",
          "dt": "0x20",
          "min": 14400,
          "max": 86400,
          "change": "0x00000002"
        }
      ]
    },

If not, but have access to DeConz GUI, then can be added using DDF editor.

josemi73 commented 1 year ago

As I can see it seems that bindings for battery reports had been removed during a previous DDF modification. Are you able to modify DDF file directly onto your system to give a try to reintroduce the battery report with someting like this ?

    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0001",
      "report": [
        {
          "at": "0x0021",
          "dt": "0x20",
          "min": 14400,
          "max": 86400,
          "change": "0x00000002"
        }
      ]
    },

If not, but have access to DeConz GUI, then can be added using DDF editor.

Hi @BabaIsYou Thank you for your answer. I have just modified inserting your lines into _TZ3000_TS0044_4gang_remote.json, right? It is the one that debug.txt deconz file shows up:

18:22:49:185 DEV found DDF for 0x70AC08FFFE65F4C5, path: /usr/share/deCONZ/devices/tuya/_TZ3000_TS0044_4gang_remote.json

Or should it be another file? I have rebooted deconz gateway but battery is not reporting yet. Perhaps I must wait several minutes/hours... No, because it seems that has been updated some seconds ago:

image

image

BabaIsYou commented 1 year ago

With the reports interval it could take until 4 hours before a first report. In Deconz GUI, if you force a read onto the cluster 0x0001, does it make a n update ?

josemi73 commented 1 year ago

With the reports interval it could take until 4 hours before a first report. In Deconz GUI, if you force a read onto the cluster 0x0001, does it make a n update ?

Hi again Must I do here? I press read button, but battery percentage keeps showing '0':

image

image

Info of json is different from deconz GUI vs json in filesystem:

image

If I do a hot reload or Open the same .json from filesystem, I do not see the changes in the DDF Editor (preview tab)

BabaIsYou commented 1 year ago
  1. It could stay to 0 if device is sleeping. Perhaps you have to awake the device during read.
  2. You’re comparing two different things. The bindings are in the « bindings » tab not the « items » one ;-)
josemi73 commented 1 year ago

image

@BabaIsYou And Is it normal that in DDF Editor changes in the json in filesystem are not shown? (Preview tab)

I have filled these fields, though I have seen in the zigbee2mqtt webpage that for TS0044 battery attribute is not readable:

image

and now:

image

I will wait 24h...

josemi73 commented 1 year ago

Updated!

image

I configured the Read in battery item, and I inserted the lines in .json @BabaIsYou wrote above.

Indeed it would be nice making persistence the change in the next release :-)

BabaIsYou commented 1 year ago

Hi. To make it persistent we’ll have to open a pull request with the updated DDF.

do you want to do it ?

Mimiix commented 1 year ago

Please keep open until pr is merged.

josemi73 commented 1 year ago

Hi. To make it persistent we’ll have to open a pull request with the updated DDF.

do you want to do it ?

I do not know github, it could be dangerous. I added your lines and I enabled the Read in the item battery, I suppose your lines did the trick, because in theory battery read does not work.

Smanar commented 1 year ago

I have filled these fields, though I have seen in the zigbee2mqtt webpage that for TS0044 battery attribute is not readable:

Yep, take care, the binding was not removed by error, with it devices have battery drain https://github.com/dresden-elektronik/deconz-rest-plugin/pull/6744#issuecomment-1427044174

From that I remember there is new version that need tuya unlock sequence, report battery naturally without bind/report and have battery drain if bind/report enabled. And like usual no way to reconise them.

Perhaps the device can work without bind/report but with the missing "read" ?

BabaIsYou commented 1 year ago

I guess that the removed report was too "stressfull" for a battery report (every 60s !?) and then could have drained the battery just for that.

josemi73 commented 1 year ago

I guess that the removed report was too "stressfull" for a battery report (every 60s !?) and then could have drained the battery just for that.

These lines you told me mean that the device reports every 14000->86400 seconds?

image

I will keep the change several days, and I will tell you. I have an automation in Home Assistant to warn if the battery is lower than 10%, and it is warning if it is 0%. If I see that the battery drains, Could it be changed to reports 100% always?

I have asked to a member in a Home Assistant Telegram group with the same device, but he is using zigbee2mqtt, and after several weeks, it is reporting 100% battery, with a message that informs that the info could be refreshed every 24 hours:

image

BabaIsYou commented 1 year ago

If I see that the battery drains, Could it be changed to reports 100% always?

Yes it can but this seems a kind of nonsense ... isn't it ? Just remove bindings and refresh.interval and put a default value of 100 or "static" value of 100 ;-)

These lines you told me mean that the device reports every 14000->86400 seconds?

Yes, between 4h and a whole day, or if value changes for .a value of 2

Could try also with a refresh.interval of 86400 also into "config/battery". Leak of read is usually not a trouble because without "read" function then "parse" function is used.

BabaIsYou commented 1 year ago

Yep, take care, the binding was not removed by error, with it devices have battery drain #6744 (comment)

Perhaps that making separated DDF files would have been, and is still, the right way to address this ?

BabaIsYou commented 1 year ago

These lines you told me mean that the device reports every 14000->86400 seconds?

Yes, between 4h and a whole day, or if value changes for .a value of 2

BTW have to reduce max to 65535 (maximum value for U8 num type)

josemi73 commented 1 year ago

Ok, I will reduce both min 64500, max 65500 then.

Smanar commented 1 year ago

I guess that the removed report was too "stressfull" for a battery report (every 60s !?) and then could have drained the battery just for that.

IDK they have made lot of tests on Z2M, before making this change https://github.com/Koenkk/zigbee2mqtt/issues/8072#issuecomment-1268580026

BabaIsYou commented 1 year ago

Ok. I deleted the PR and we will wait further results from @josemi73 regarding battery lifetime.

josemi73 commented 1 year ago

Ok. I deleted the PR and we will wait further results from @josemi73 regarding battery lifetime.

It is too soon to come to a conclusion.

image

Same battery percentage than yesterday, but last report 10 hours ago. Tomorrow I will look again.

My json file:

(...)
        {
          "name": "config/battery",
          "awake": true,
          "refresh.interval": 65500,
          "read": {
            "at": "0x0021",
            "cl": "0x0001",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0021",
            "cl": "0x0001",
            "ep": 1,
            "eval": "Item.val = Attr.val / 2;",
            "fn": "zcl"
          },
          "default": 0
        },
(...)        
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0001",
      "report": [
        {
          "at": "0x0021",
          "dt": "0x20",
          "min": 64500,
          "max": 65500,
          "change": "0x00000002"
        }
      ]
    },
  (...)
Smanar commented 1 year ago

Just by chance @sinus61 if you are still here, can you try the DDF too (with somes modification I think to be used by your devices), as you have some hardwares with the "battery leak feature".

josemi73 commented 1 year ago

Ok. I deleted the PR and we will wait further results from @josemi73 regarding battery lifetime.

I think that in the next few days battery will be reaching 100% after the modified DDF 🤣😊 (79 -> 91% today)

image

Could I insert this code modification into my smartphone to increase the battery instead plug it in everyday? 🤣🤣🤣

josemi73 commented 1 year ago

79% -> 91% -> 90% -> 100% -> 91% (...) -> 90%

I would approve the change.

It reached 100%!!! Wonderful!!! It recharges itself.

Currently 90%...

From 14 to 24 June:

image

Last month:

image

github-actions[bot] commented 12 months 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 11 months 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.

ekuekb commented 6 months ago

Hi, My name is Ekue, I am working on Home Assistance project and I had the same issue

Smanar commented 6 months ago

Hello, what is your device ? (the manufacture name)