I have two of these devices - ESW-0ZAA-EU and RSH-ZigBee-SC04 - and thanks to v2.22.0 the batteries are no longer drained in a few days - thanks for this improvement. Even with v2.22.1 I see that the battery status is shown as “0%”.
I have these scenes programmed to activate events created in Homeseer HS4. Over the last couple of weeks, both devices will not have any response when button 1 is pressed, long pressed or double pressed. The other three buttons control their programmed scenes without issue.
v2.22.1 has not changed this behaviour.
All events - even those for button 1 - run as expected when manually activated.
Is there anything I can do to get button 1 working again? I have tried re-pairing to no avail. Do I need to delete from deConz and start from scratch?
Hello, can you enable log in the GUI, deconz / help / Debug view, with flag “info_l2”
And press a not working button, you will see output about button map, can you share the error message and the button you have used ?
Thank you for getting back to me and I have run your request. The switch is called “4 S 2” and the non working button is labelled “Green”. I believe that the data you wish is as below:-
06:30:42:628 Websocket 192.168.1.24:58448 send message: {“attr”:{“id”:“48”,“lastannounced”:“2023-06-07T07:39:53Z”,“lastseen”:“2023-06-09T05:30Z”,“manufacturername”:"_TZ3000_wkai4ga5",“modelid”:“TS0044”,“name”:“4 S 2 Red”,“swversion”:null,“type”:“ZHASwitch”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-02-0006”},“e”:“changed”,“id”:“48”,“r”:“sensors”,“t”:“event”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-02-0006”} (ret = 342)
06:30:42:629 Websocket 192.168.1.24:58448 send message: {“attr”:{“id”:“49”,“lastannounced”:“2023-06-07T07:39:53Z”,“lastseen”:“2023-06-09T05:30Z”,“manufacturername”:"_TZ3000_wkai4ga5",“modelid”:“TS0044”,“name”:“4 S 2 Blue”,“swversion”:null,“type”:“ZHASwitch”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-04-0006”},“e”:“changed”,“id”:“49”,“r”:“sensors”,“t”:“event”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-04-0006”} (ret = 343)
06:30:42:630 Websocket 192.168.1.24:58448 send message: {“attr”:{“id”:“46”,“lastannounced”:“2023-06-07T07:39:53Z”,“lastseen”:“2023-06-09T05:30Z”,“manufacturername”:"_TZ3000_wkai4ga5",“modelid”:“TS0044”,“name”:“4 S 2 Yellow”,“swversion”:null,“type”:“ZHASwitch”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-03-0006”},“e”:“changed”,“id”:“46”,“r”:“sensors”,“t”:“event”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-03-0006”} (ret = 345)
06:30:42:631 Websocket 192.168.1.24:58448 send message: {“attr”:{“id”:“45”,“lastannounced”:null,“lastseen”:“2023-06-09T05:30Z”,“manufacturername”:"_TZ3000_wkai4ga5",“modelid”:“TS0044”,“name”:“4 S 2 Green”,“swversion”:“1.0.2”,“type”:“ZHASwitch”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-01-0006”},“e”:“changed”,“id”:“45”,“r”:“sensors”,“t”:“event”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-01-0006”} (ret = 329)
I hope this makes more sense to you than it does to me!! Let me know if there is anything else I can do to help.
You haven’t error message ?
I need a message like this one
[INFO] - No button map for: %s%s, endpoint: 0x%02X, cluster: %s, command: %s, payload: %s, zclSeq: %u\n
Thanks again for getting back to me. I had saved the log as a text file and have just done a search for [INFO] which returns the following:-
06:34:10:970 [INFO] - No button map for: lumi.motion.ac02, unicast to: 0x0000, endpoint: 0x01, cluster: XIAOMI (0xFCC0), command: ATTRIBUTE_REPORT (0x0A), payload: 1201230C000100, zclSeq: 105
This relates to window covering device that occasionally works - again despite repeated pairing. I had started a separate topic for this issue.
Any further advice would be appreciated.
I have run the debug view again and think this may be what you were looking for?
18:14:37:890 [INFO] - No button map for: TS0601, unicast to: 0x0000, endpoint: 0x01, cluster: BASIC (0x0000), command: 0x0A, payload: 01002047E2FF201FE4FF2000, zclSeq: 83
Bad luck ^^
This one is for the TS0601 and your device is a TS0044
But if you have no message it mean the device don’t make request.
You can have other message like
"[INFO] - Button %u - %s%s, endpoint: 0x%02X, cluster: %s, action: %s, payload: %s, zclSeq: %u\n",
This one is for working “mapping” or for not included “mapping”
[INFO] - No button handler for: %s%s, endpoint: 0x%02X, cluster: %s, command: %s, payload: %s, zclSeq: %u\n"
Else if you have other message, can be usefull too, I need something that happen only when you use the not working button.
Thanks again for reply and information. I will try again this evening and see if I can get any information from the log.
In the meantime, I have upgraded the ConBeeII firmware from 26580700 to 26780700 but that does not appear to have made any difference to this switch. I have now removed the battery from the device and will replace that this evening before trying the switch.
As you say, no request is being made as the description usually shows which button was last pressed and button one refuses to change anything. The other buttons all show the last press.
As I said, I have two of these devices and it seems strange that neither will now allow button one to work. Am just trying to get one of them to work before going back to the second one.
The firmware update can’t have impact.
The deconz version too, long time the code is untouched.
For the request, can be a deconz issue, but it’s strange for the same reason, the device need to send a “not managed” request, else all request are logged with this kind of message.
And all zigbee requests are visibles witrh flag “aps” and “aps_l2” but thoses one are harder to understand.
Thanks for reply and I did not expect FW update to make a lot of difference but thought it was worthwhile. I have pressed the non working button again and, searching for TS0044 I get the following. To explain, I have colour coded the four buttons with 1 = Green, 2 = Red, 3 = Yellow and 4 = Blue for ease of use.
18:08:55:364 Websocket 192.168.1.24:52636 send message: {“attr”:{“id”:“48”,“lastannounced”:“2023-06-10T17:07:14Z”,“lastseen”:“2023-06-10T17:08Z”,“manufacturername”:"_TZ3000_wkai4ga5",“modelid”:“TS0044”,“name”:“4 S 2 Red”,“swversion”:null,“type”:“ZHASwitch”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-02-0006”},“e”:“changed”,“id”:“48”,“r”:“sensors”,“t”:“event”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-02-0006”} (ret = 342)
18:08:55:365 Websocket 192.168.1.24:52636 send message: {“attr”:{“id”:“49”,“lastannounced”:“2023-06-10T17:07:14Z”,“lastseen”:“2023-06-10T17:08Z”,“manufacturername”:"_TZ3000_wkai4ga5",“modelid”:“TS0044”,“name”:“4 S 2 Blue”,“swversion”:null,“type”:“ZHASwitch”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-04-0006”},“e”:“changed”,“id”:“49”,“r”:“sensors”,“t”:“event”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-04-0006”} (ret = 343)
18:08:55:366 Websocket 192.168.1.24:52636 send message: {“attr”:{“id”:“46”,“lastannounced”:“2023-06-10T17:07:14Z”,“lastseen”:“2023-06-10T17:08Z”,“manufacturername”:"_TZ3000_wkai4ga5",“modelid”:“TS0044”,“name”:“4 S 2 Yellow”,“swversion”:null,“type”:“ZHASwitch”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-03-0006”},“e”:“changed”,“id”:“46”,“r”:“sensors”,“t”:“event”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-03-0006”} (ret = 345)
18:08:55:367 Websocket 192.168.1.24:52636 send message: {“attr”:{“id”:“45”,“lastannounced”:“2023-06-10T17:07:14Z”,“lastseen”:“2023-06-10T17:08Z”,“manufacturername”:"_TZ3000_wkai4ga5",“modelid”:“TS0044”,“name”:“4 S 2 Green”,“swversion”:“1.0.2”,“type”:“ZHASwitch”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-01-0006”},“e”:“changed”,“id”:“45”,“r”:“sensors”,“t”:“event”,“uniqueid”:“70:ac:08:ff:fe:3e:81:89-01-0006”} (ret = 347)
Don’t know if any of the above helps but events still work find when run from software (HS4) but not when pressing button one (green).
Can you enable “info” “info_l2” “aps” “aps_l2” “zcl” then press the button.
You will have so much logging so better to use a website like pastebin to share logs.
I have produced a log as requested and the data can be found in the text file on Index of /downloads which I trust you can access.
Ok so there is a problem
Yellow > "uniqueid":"70:ac:08:ff:fe:3e:81:89-03-0006"
Blue > "uniqueid":"70:ac:08:ff:fe:3e:81:89-04-0006"
Green > "uniqueid":"70:ac:08:ff:fe:3e:81:89-01-0006"
The DDF create only 1 entry, green for you deconz-rest-plugin/_TZ3000_TS0044_4gang_remote.json at master · dresden-elektronik/deconz-rest-plugin · GitHub
Have you tried to delete the device and re-include it ? You need to have only the “Green” one 01-0006
I think there is a conflict with the “before DDF” and the “After DDF”
Once again , many thanks for getting back to me. I note your comments re having one switch (no. 1 or green) as, when I first had a similar device, it only displayed a single switch with the12 scenes allocated to it.
However, this device shows four switches and I can not see anyway to use switch 1 (green) for all twelve scenes.
I have deleted the device from HS4 and removed the node from deCONZ as well as removing the battery from the device. I will then try adding it all back tomorrow.
May I ask what you mean by “before and after DDF”? That is outside my current knowledge!!
Many thanks again.
Wireless remote have only 1 entry, we use the state/buttonevent value to know wich one button is used and the action.
Recent deconz version use now DDF DDF cheat sheet · dresden-elektronik/deconz-rest-plugin Wiki · GitHub
Many thanks for reply and information on DDF - now beginning to make some sense although I still need to learn more! Have several questions having watched the deCONZ video linked…
Will “re” add the 4 scene switch later today and let you know how that goes.
Thanks again
Update as I have added the 4 scene switch again and this time it only shows one switch and the not the four as it did previously. Had added the various events . scenes to it and all appears to be working other than the battery is still showing as zero.
Thanks again for your help.
For the battery, can be related to Battery is always reporting 0% in _TZ3000_wkai4ga5 (TS0044 4-gang) · Issue #7048 · dresden-elektronik/deconz-rest-plugin · GitHub
But I haven’t answered on this topic yet.
Thanks for the information - up to a recent release of deCONZ, my 4 scene switch was using a new battery every couple of weeks! Having it report zero battery but working is preferable until such time as a permanent fix is found.