Deconz-rest-plugin: [New device request] Osram Smart+ mini switch

[NicolasBoulanger]

Hello,
i bought 2 zigbee osram mini switch, i made a pull request to make it working on zigbee2mqtt, but now i use conbee :)
i have 1 blue and 1 white
i like these remotes for my roller shutter
https://www.amazon.fr/dp/B074PYT9R4/ref=twister_B07MVNX6V6?_encoding=UTF8&psc=1
the device is detected in deconz but can only switch on and off all lights
here screenshot of the 2 remote (maybe different)
if you need more informations tell me :)
thanks !

Blue:

White:

[Smanar]

Hello.
What is the mystery with this device ^^ ?

There is so much issue about it
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2082
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/374
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/294
ect ...

Some people say it's working, some other not.

And I don't see the problem, I m missing something ?

This device is detected in deconz ? I don't see it in supported device on the code, you have it as light or sensor ? Can you show me the device JSON pls ?

You want to use it for your roller shutter ? But how it work ATM, I m seeing only 3 button on the device and according to the cluster it can make on/off+ level control + color control, seriously ???

Edit:

Button 1 short press: All ON
Button 1 long press: Brightness UP
Button 2 short press: 2700K / Brightness 100%
Button 2 long press: Change color (forward)
Button 3 short press: All OFF
Button 3 short press: Brightness DOWN

[NicolasBoulanger]

its not really working, i cannot see remote in switch category on deconz software
it is detect but cannot assign light or whatever
remote can switch on all light with up button
turn on life with down button
i cannot configure button in deconz

i use it with:
short up press : open my living room cover
short circle pres: stop living room cover
short down press: close living room cover

long press up: open desktop window cover
long press circle: stop desktop window cover
long press down: close desktop window cover

my second remote, i use it for garden light

which json logs you need ? which command?
this logs ?

15:52:24:069 APS-DATA.indication srcAddr: 0x532a, srcEp: 0x02 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 215, rssi: -6715:52:24:069 APS-DATA.indication srcAddr: 0x532a, srcEp: 0x02 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 215, rssi: -67

15:54:00:255 APS-DATA.indication srcAddr: 0x50b9, srcEp: 0x02 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 215, rssi: -67

thanks !

[Smanar]

Ok so you are using it with zigbee broadcast (or group) command ?

Are you using an home assistant application with deconz ? HASS openhab or other ? (and have an API key ?)
If yes can you see the remote in it ?

[NicolasBoulanger]

i'm using unicast: default configuration in deconz docker version

im using home assistant only to display my entities, but
my automations are in node-red vm
my configuration :
proxmox server :
deconz vm
node-red vm
hassio vm

all in bridged network, managed by my unifi router
i use deconz api in node-red with node-red-contrib-deconz palette
i cannot see remote in hassio

[NicolasBoulanger]

if can help
this is my commit on zigbee2mqtt repo
https://github.com/NicolasBoulanger/zigbee-herdsman-converters/commit/bd4463b2a370b47e6654006d8363a3f63e513886?fbclid=IwAR3F1yndD9fTJZn1ShBC_P3vqy6BHgwLUYNk9_R7z9F7jQV2ot6su9akhv4

[Smanar]

Ok so I think this device is not in deconz at all.

It will be something I will ask again soon, so to see your device in deconz API, you can use this kind of url
http://IP:PORT/api/API_KEY/sensors
For ip and port, it's the same you are using than for phoscon
For API_KEY I think you can find it somewhere on the deconz plugin in HASS

Now I can try make a ZHAswitch for this device, so you will have a value for all fonctions (IDK how much yet).

But if you want to make "direct connexion" between your shutter and the remote, not sure if it will work. You can make try using phoscon.
IDK if your shutter support "direct connexion", wich one cluster they need, and why you can use it with bulb and not the shutter (perhaps the shutter use windowcovering cluster ?)

But if you want a buttonevent value like for ikea remote to use it with nodered, I think it will be possible.

But it's strange no one have already do it ^^, I think there is a trap I haven't see yet.

[NicolasBoulanger]

ok i'll check with the api
my shutter is in wifi (shelly2.5 module) so, event, yes and button configuration in web interface, it will be the solution
thanks !

[NicolasBoulanger]

i think this is the action for remote switch?

[bphermansson]

Ok so I think this device is not in deconz at all.

It will be something I will ask again soon, so to see your device in deconz API, you can use this kind of url
http://IP:PORT/api/API_KEY/sensors
For ip and port, it's the same you are using than for phoscon
For API_KEY I think you can find it somewhere on the deconz plugin in HASS

You can get the API key by locking up the gateway and run a Rest client, or Curl:
curl --header "Content-Type: application/json" --request POST --data "{ \"devicetype\": \"\"}" http://192.168.1.15/api
The API gets back as username, "{"username":"D7nnnnnn"}}]".
This is explained at https://dresden-elektronik.github.io/deconz-rest-doc/getting_started/.

[NicolasBoulanger]

Ok so I think this device is not in deconz at all.
It will be something I will ask again soon, so to see your device in deconz API, you can use this kind of url
http://IP:PORT/api/API_KEY/sensors
For ip and port, it's the same you are using than for phoscon
For API_KEY I think you can find it somewhere on the deconz plugin in HASS

You can get the API key by locking up the gateway and run a Rest client, or Curl:
curl --header "Content-Type: application/json" --request POST --data "{ "devicetype": ""}" http://192.168.1.15/api
The API gets back as username, "{"username":"D7nnnnnn"}}]".
This is explained at https://dresden-elektronik.github.io/deconz-rest-doc/getting_started/.

yes i have my key :)

[Smanar]

Ok so I have started https://github.com/Smanar/deconz-rest-plugin/commit/55ecd9a1dc7b72e48f41e2f922d47aafcb5d6371

But I have some problems for the table sensor.

Have you an Unix machine 32 bit to compile the code and make tries ?

The procedure is explained here > https://github.com/dresden-elektronik/deconz-rest-plugin at "Install deCONZ development package (optional, Linux only)"

You just need to change the step 1 by
git clone https://github.com/Smanar/deconz-rest-plugin.git

The new code will include the device, you will probably have some issue with braodcast command (some bulbs in your network will react to the remote). You will have a new sensor, a ZHAswitch with "bouttonevent" field.
I think the device will be invisible in phoscon, but you can see it in the API or HA.

If you enable the deconz log (like in your second post) you will see something like

14:54:41:654 no button handler for: XXXXXX sensor ep: 0x01 cl: 0x0006 cmd: 0x42 pl[0]: 0x00

Everytime you press a button (for the missing one, but I think only 2 will work)
I just need the button (short/long/release) you have pressed and the message

[bphermansson]

I've tried this and it's working. I installed Smanars patch and started a search for new switches in Phoscon. I see the switch in Deconz and in the logs:

13:11:05:886 0x00124B0014B71F47 onOff 0 --> 1
13:11:05:887 no button map for: PSMP5_00.00.03.16TC ep: 0x01 cl: 0x0006 cmd: 0x0A pl[0]: 000
13:11:05:887 ZCL attribute report 0x00124B0014B71F47 for cluster: 0x0006, ep: 0x01, frame control: 0x18, mfcode: 0x0000

[Smanar]

But to make it working I need all button value, I have some problem to guesss them (3 mode / 4 cluster/ 3 endpoint .....), and it's easier with debug.
Just press a button and give me the log with "no button map" for missing one
You have Short press / long press / release for all 3 buttons (I think, not sure)

[NicolasBoulanger]

@bphermansson can you did it ? you have this device too ?
thanks

[Smanar]

I can make explanation if you need @NicolasBoulanger ?
You have some problem with your OS ?

[bphermansson]

I have the Osram remote that is black in rubber. It has three button, large and small arrow and a circle. The output I get from Deconz is noisy and I only see one of the buttons, the small arrow. It gives this on a short press:
18:08:35:642 no button map for: PSMP5_00.00.03.16TC ep: 0x01 cl: 0x0702 cmd: 0x0A pl[0]: 000
Can't see no difference on a long press. Can some values from Zigbee2Mqtt help?

[Smanar]

I think I have values from zigbee2mqtt @NicolasBoulanger give a link for that https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2763#issuecomment-627491001

But it's realy faster using debug ^^. I will try better tommorow

But I don't understand why you have only the small arrow and not the big, I can understand for the "O" but the arrow ...
Perhaps It is already working, this debug message is only for not working button.
And there is something strange too

cl: 0x0702

Cluster metring ?

I will try to make better using this mapping

[Smanar]

And I m stupid.

Better to check working values before the no working one ^^.

Pls can you check in the json (or somewhere else) the "buttonevent" value, if the value is "none" I m totaly wrong, if you have something like X00Y I have at least 1 good value in my table.
This field is the last pressed button.

[Smanar]

So I have used this message
13:11:05:887 no button map for: PSMP5_00.00.03.16TC ep: 0x01 cl: 0x0006 cmd: 0x0A pl[0]: 000

So now I m using 1 endpoint by button, but always cluster 0006 and command 0x0A.
I m almost sure I miss the cluster 0008 but IDK wich one command to use with it

[NicolasBoulanger]

is good for you with these logs ?

11:55:47:312 no button map for: SML001 ep: 0x02 cl: 0x0406 cmd: 0x0A pl[0]: 000
11:55:49:309 no button map for: SML001 ep: 0x02 cl: 0x0400 cmd: 0x0A pl[0]: 000
11:55:55:431 no button map for: SML001 ep: 0x02 cl: 0x0402 cmd: 0x0A pl[0]: 000
11:02:34:469 no button map for: RWL021 ep: 0x02 cl: 0x0001 cmd: 0x0A pl[0]: 021

[Smanar]

Bas luck, RWL021 is a philips dimmer and SML001 is a HUE motion sensor ^^.

And now I m looking better, I have based my table on

13:11:05:887 no button map for: PSMP5_00.00.03.16TC ep: 0x01 cl: 0x0006 cmd: 0x0A pl[0]: 000
13:11:05:887 ZCL attribute report 0x00124B0014B71F47 for cluster: 0x0006, ep: 0x01, frame control: 0x18, mfcode: 0x0000

But It's not the good device too 0x00124B0014B71F47 is not in the good MAC range adress.

The log I need will contain "no button handler for: Lightify Switch mini" (not sure for typo).

[Smanar]

No-one can compile the code and give me some logs ?
I don't even know if only one works ...

[bphermansson]

Maybe later tonight I can give it a try.

[bphermansson]

Some new findings. Now I see my switch as 0x75B7 in Deconz. It's a Osram Lightify Switch Mini. Pushing the circle gives:

07:57:23:092 APS-DATA.indication srcAddr: 0x75b7, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 167, rssi: -70
07:57:24:083 APS-DATA.indication srcAddr: 0x75b7, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0300, lqi: 167, rssi: -70

(and my Hue lamp switches on)

Pushing the large arrow:

08:01:20:906 APS-DATA.indication srcAddr: 0x75b7, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 151, rssi: -72
08:01:21:002 APS-DATA.indication srcAddr: 0x192c, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 255, rssi: -34
08:01:21:003 no button map for: PSMP5_00.00.03.16TC ep: 0x01 cl: 0x0006 cmd: 0x0A pl[0]: 000

The small arrow:
08:03:33:218 APS-DATA.indication srcAddr: 0x75b7, srcEp: 0x02 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 159, rssi: -71
08:03:33:300 APS-DATA.indication srcAddr: 0x192c, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 255, rssi: -35
08:03:33:302 no button map for: PSMP5_00.00.03.16TC ep: 0x01 cl: 0x0006 cmd: 0x0A pl[0]: 000
08:03:33:302 ZCL attribute report 0x00124B0014B71F47 for cluster: 0x0006, ep: 0x01, frame control: 0x18, mfcode: 0x0000

[NicolasBoulanger]

Some new findings. Now I see my switch as 0x75B7 in Deconz. It's a Osram Lightify Switch Mini. Pushing the circle gives:

07:57:23:092 APS-DATA.indication srcAddr: 0x75b7, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 167, rssi: -70
07:57:24:083 APS-DATA.indication srcAddr: 0x75b7, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0300, lqi: 167, rssi: -70

(and my Hue lamp switches on)

Pushing the large arrow:

08:01:20:906 APS-DATA.indication srcAddr: 0x75b7, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 151, rssi: -72
08:01:21:002 APS-DATA.indication srcAddr: 0x192c, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 255, rssi: -34
08:01:21:003 no button map for: PSMP5_00.00.03.16TC ep: 0x01 cl: 0x0006 cmd: 0x0A pl[0]: 000

The small arrow:
08:03:33:218 APS-DATA.indication srcAddr: 0x75b7, srcEp: 0x02 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 159, rssi: -71
08:03:33:300 APS-DATA.indication srcAddr: 0x192c, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 255, rssi: -35
08:03:33:302 no button map for: PSMP5_00.00.03.16TC ep: 0x01 cl: 0x0006 cmd: 0x0A pl[0]: 000
08:03:33:302 ZCL attribute report 0x00124B0014B71F47 for cluster: 0x0006, ep: 0x01, frame control: 0x18, mfcode: 0x0000

Did you try long press on both buttons?
Thanks !

[Smanar]

Hello, what is the MAC adress of your osram remote ?

Because perhaps the line

cluster: 0x0006, lqi: 255, rssi: -35
08:03:33:302 no button map for: PSMP5_00.00.03.16TC ep: 0x01 cl: 0x0006 cmd: 0x0A pl[0]: 000

is for the device 0x00124B0014B71F47 PSMP5

And this one is already on the table https://github.com/Smanar/deconz-rest-plugin/blob/master/sensor.cpp#L146

Can you share the complete log ?

[NicolasBoulanger]

i found this image for phoscon app ?

[Smanar]

But phoscon is closed source.
We can't make something on our side.

[bphermansson]

I made some log files now. First I press the buttons one by one, long press and short press. The second log is just one short push on one button.

https://pastebin.com/Pb8j85z3

https://pastebin.com/VmFCnvEU

[Smanar]

Nice thx.
So there is a problem on my code, button event are not working at all. Need to check more closely the log.

[Smanar]

Ok, sorry for manipulation, but I have a problem in the code.

I have make a new version with some debug line. But theses lines will be displayed only if you use --dbg-info=2 in your command. https://github.com/Smanar/deconz-rest-plugin/commit/4142a4c0fdd509787830bb4f6c758efa6ff46ecc

Idk if you have a slider on your application or something to raise the log level ?

If you can send me the same log when you press some button ?

[olicooper]

No idea if it'll help but I started attempting to add support for the Smart+ mini switch too (I gave up as I didn't have the time). Anyway, here is my commit which might prove useful? https://github.com/olicooper/deconz-rest-plugin/commit/70e42e9da35a6774dd79970a4a55e987a3e7d238

Also, there are more supported functions than the one listed here:

Button 1 short press: All ON
Button 1 long press: Brightness UP
Button 2 short press: 2700K / Brightness 100%
Button 2 long press: Change color (forward)
Button 3 short press: All OFF
Button 3 short press: Brightness DOWN

I think you can also double press buttons too. I believe double (short) pressing Button 2 will switch the light to ~3000K / Brightness 100%

[Smanar]

Yep, thx, I will take some lines to use in mine.

ATM I have some result on the 4 buttons mini switches, so I don't see why the 3 button will not work.

Edit:
Haven't checked double press yet ...

[bphermansson]

I use the command line as described in the Deconz doc for adding new devices. I ran the below command and pushed all buttons, long press and short. From what I can see in the product documentation you can use the remote for six functions, three buttons, long or short push.
The command:

deCONZ --dbg-info=2 --dbg-aps=1 --dbg-zcl=1 --dbg-zdp=1 --http-port=80 > osram.txt

Log file:
osram.txt

[Smanar]

Ok so now I understand why I can never see the good debug logging.
There is something that missed, your device is not in the API, so it doesnt handled button event.

Can you try to re-include the remote using Phoscon pls ? I think atm it's working because of broadcast message.

[bphermansson]

Ok, I pretty sure I'm getting correct values now.

Circle long - 21:28:14:228 APS-DATA.indication srcAddr: 0x89ef, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0300, lqi: 103, rssi: -78
Circle short - 21:29:34:605 APS-DATA.indication srcAddr: 0x89ef, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 119, rssi: -76
Little arrow short: 21:31:07:949 APS-DATA.indication srcAddr: 0x89ef, srcEp: 0x02 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 87, rssi: -80

The cluster-value indicates which button is pressed?

[olicooper]

@Smanar I am trying to get the switch mini to work so I have created my own repo from your code (see my deconz repo) and run the compiled code, but now the clusters are not showing in the deconz GUI for the device and I don't have any useful logs showing the device commands etc.
This is an example log when pressing a button:

08:51:03:276 APS-DATA.indication srcAddr: 0xfda1, srcEp: 0x02 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 151, rssi: -72
08:51:03:276 APS-DATA.indication from child 0xFDA1
08:51:03:277 verify 0x000d6f00XXXXXXXX is child node after 839916 s
08:51:03:299 MyDebug 1
08:51:03:453 Node 0x000d6f00XXXXXXXX is known by 1 neighbors, last seen 0 s

I am not familiar with what is happening in the code, so my additions may have caused an issue. Do you know what might be wrong?
How can I help to get the button mapping configured?

[Smanar]

@bphermansson yes, but I need more than the cluster, I need to the command and the parameter too, It's for that I m using the "no button map" output debug, all informations are here.

08:03:33:302 no button map for: XXXX ep: 0x01 cl: 0x0006 cmd: 0x0A pl[0]: 000

@olicooper on the file sensor.cpp line 1315, you have disabled all the sensor value table.
And the easier way is looking for "no button map", like I have said before, you will have all value in one debug line.

I have advanced more for the 4 button, I think I have all value for the table, and I have started to mix the created device, if you want to test the code, I think it will be the same for the 3 button device.

[olicooper]

Thanks for taking a look! I've started understanding it a bit more and I was hoping that by disabling sensor.cpp line 1315 I would see 'no button map' in the logs. I will re-enable it.

For some reason inside da_web_plugin.cpp this line isn't returning the sensor node sensorNode = getSensorNodeForAddress(ind.srcAddress()); (see this). It isn't getting to the "MyDebug 0.2" log. I've tried resetting the device.

[Smanar]

Yep but this is not trigger in your situation (for the moment).
For the moment when this part of code is trigger you have a sensorNode, so all the part that start at line 728 is not used.

I have started to put code in it for future ^^
On second step (It's that I have do for the 4 button) I will mix all endpoint, so it's possible the API don"t find a sensorNode, so it will search on the other endpoint to find it. But this part is not used yet for the 3 buttons.

[olicooper]

@bphermansson Do you also have a "Climax Power Switch" connected? I've looked at your logs and I think the "no button map" logs are related to this device rather than the Lightify Switch Mini. During my own testing I am finding that I can't find any "no button map" logs for my switch - but I get it for other devices.
The MAC address 0x00124B0014B71F47 is for a Texas Instruments device. I think you should find logs with a mac address that starts with 0x000D6F which is the switch mini (the chip is made by Ember Corporation).

[olicooper]

@Smanar I don't think it has found a sensorNode by line 728 though from what I see in my log files:

16:24:58:814 APS-DATA.indication srcAddr: 0xc6f2, srcEp: 0x02 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 191, rssi: -67
16:24:58:814 APS-DATA.indication from child 0xC6F2
16:24:58:814 verify 0x000d6f00XXXXXXXX is child node after 839916 s
16:24:58:843 MyDebug 0.1
16:24:58:843 MyDebug 1

[Smanar]

Can you show me the device created by the API for this device (the JSON) after the inclusion, you will have at least 3 devices.

[olicooper]

Its working! This is the latest mapping: https://github.com/olicooper/deconz-rest-plugin/commit/5aeb0a89276d2771f2ca398d76df6e7279acb6c5

Unfortunately the down long release mapping isnt working. the logs say it is not bound even though it is correct in the button map. Any thoughts?

19:36:52:722 APS-DATA.indication srcAddr: 0x92c2, srcEp: 0x02 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 119, rssi: -76
19:36:52:723 APS-DATA.indication from child 0x92C2
19:36:52:724 MyDebug 1
19:36:52:724 MyDebug 2
19:36:52:724 MyDebug 3
19:36:52:724 MyDebug 4
19:36:52:724 MyDebug 6
19:36:52:724 Force binding of attribute reporting for sensor Lightify Switch Mini
19:36:52:724 no button handler for: Lightify Switch Mini ep: 0x02 cl: 0x0008 cmd: 0x03 pl[0]: 0x00

Also, the button is still sending a broadcast message to all the lights but I don't know how to suppress this?
Can we configure the button to work with a single light directly?

[Smanar]

Yes, I have exactly same problem on the 4 buttons one > https://github.com/dresden-elektronik/deconz-rest-plugin/issues/374#issuecomment-633254527

I think we need to use more debug line in the fonction checkSensorButtonEvent(), and for me the problem can be from

            else if (ind.clusterId() == LEVEL_CLUSTER_ID &&
                       (zclFrame.commandId() == 0x03 ||  // stop
                        zclFrame.commandId() == 0x07) )  // stop (with on/off)
            {
                ok = false;
                if (buttonMap->zclParam0 == sensor->previousDirection) // direction of previous move/step
                {
                    sensor->previousDirection = 0xFF;
                    ok = true;
                }
            }

We have cluster 0008, command = 3 so this part can set ok to false again. And I have same bug on same cluster same command.

Yep, to disable broadcast message, if I m right we can do that with biding the remote to the coordinator (or another group), we can check with Xiaomi opple method.

And for the last question, IDK if it's a a good idea, ATM my objective is making a device in the api that can send all buttons used, to use the remote with an application. For the moment I haven't enabled the group feature

[olicooper]

For the broadcast issue, a developer from zigbee2mqtt said they had fixed it: https://github.com/Koenkk/zigbee-herdsman-converters/commit/7756df8ccb314c9c52c89b0640107573f1aa9bdc and this is interesting too: https://github.com/Koenkk/zigbee2mqtt/issues/962#issuecomment-478301484

Edit: I have gone in to deconz and bound cluster 0x0006(OnOff) and 0x0008(LevelControl) to an individual light for each endpoint (all three buttons), then bound 0x0001(Power) and 0x0001(Poll) to the coordinator and the switch is not broadcasting anymore!
Edit2: After setting up the bindings as mentioned above, there are no logs for the button presses anymore. I had to remove the device in deconz and add it back in again for the logs to start appearing again.

I added payload debugging. When I first press the down button (hold action) I noticed there is payload data 0126. There is no payload for the release action. Can we use this? I assume the first byte is the value of pl[0] but what is the second byte 26?

22:15:24:114 APS-DATA.indication srcAddr: 0x92c2, srcEp: 0x02 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 103, rssi: -78
22:15:24:115 APS-DATA.indication from child 0x92C2
22:15:24:115 verify 0x000d6f00XXXXXXXX is child node after 839916 s
22:15:24:116 MyDebug 1
22:15:24:116 MyDebug 2
22:15:24:116 MyDebug ZCL attribute report 0x000D6F00XXXXXXXX for cluster: 0x0008, ep: 0x02, frame control: 0x11, mfcode: 0x0000
22:15:24:116    MyDebug payload: 0126
22:15:24:116 MyDebug 3
22:15:24:116 MyDebug 4
22:15:24:117 MyDebug 6
22:15:24:117 button 3001 Down long
22:15:24:117 Force binding of attribute reporting for sensor Lightify Switch Mini

[olicooper]

@Smanar I have got the down long release working. There were two ways we could fix it - see my latest commit - but I have gone for changing the buttonMap param to 0x01 which seems cleaner?

[bphermansson]

@bphermansson Do you also have a "Climax Power Switch" connected? I've looked at your logs and I think the "no button map" logs are related to this device rather than the Lightify Switch Mini. During my own testing I am finding that I can't find any "no button map" logs for my switch - but I get it for other devices.
The MAC address 0x00124B0014B71F47 is for a Texas Instruments device. I think you should find logs with a mac address that starts with 0x000D6F which is the switch mini (the chip is made by Ember Corporation).

That's true, I have a Housegard branded Climax switch.

I will try again and see if I can get more info from the Osram switch.

[olicooper]

@bphermansson if you install my patch the button mappings should be working now and it'll be good to see if it works for you too. This is the repo: https://github.com/olicooper/deconz-rest-plugin

[bphermansson]

@olicooper I see your debug rows, should I see anything more?

11:30:09:359 APS-DATA.indication srcAddr: 0x53ce, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 183, rssi: -68
11:30:09:359 APS-DATA.indication from child 0x53CE
11:30:09:360 verify 0x000d6f000e1b8d80 is child node after 785732 s
11:30:09:368 MyDebug 0.1
11:30:09:368 MyDebug 1
11:30:09:382 verify neighbor status: APP_SUCCESS (0x00) 
11:30:09:409 Node 0x00124B00167E5F97 is known by 1 neighbors, last seen 0 s
11:30:09:648 Mgmt_Lqi_req zdpSeq: 201 to 0x086BD7FFFE064F13 start index 3
11:30:09:648 APS-DATA.request id: 8, addrmode: 0x03, addr: 0x086bd7fffe064f13, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x00
11:30:09:696 APS-DATA.confirm id: 8, status: 0x00 SUCCESS
11:30:09:696 APS-DATA.confirm request id: 8 -> confirmed, timeout 29914440
11:30:09:776 APS-DATA.indication srcAddr: 0xf0d8, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 151, rssi: -72
11:30:09:776 APS-DATA.indication request id: 8 -> finished
11:30:09:776 APS-DATA.request id: 8 erase from queue
11:30:09:776 ZDP status = 0x00 -> SUCCESS
11:30:09:776 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 8, node: 0xF0D8
11:30:09:776 ZDP Mgmt_Lqi_rsp zdpSeq: 201 from 0x086BD7FFFE064F13 total: 5, startIndex: 3, listCount: 2
11:30:09:776     * neighbor: 0x000D6FFFFEDABE85 (0xBFAE), LQI: 35, relation: 0x02 rxOnWHenIdle: 1
11:30:09:776     * neighbor: 0x000D6FFFFEAAC57B (0x5DE6), LQI: 95, relation: 0x01 rxOnWHenIdle: 0
11:30:09:889 Node 0x000D6FFFFEDABE85 is known by 5 neighbors, last seen 34 s
11:30:09:980 poll node 00:21:2e:ff:ff:04:0c:91-01
11:30:09:980 Poll light node Unknown 5
11:30:10:327 MAC Poll 0x02 0x53CE
11:30:10:346 APS-DATA.indication srcAddr: 0x53ce, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0300, lqi: 159, rssi: -71
11:30:10:347 APS-DATA.indication from child 0x53CE
11:30:10:356 MyDebug 0.1
11:30:10:356 MyDebug 1
11:30:10:369 Node 0x000D6F000E1B8D80 is known by 1 neighbors, last seen 0 s
11:30:10:477 Daylight now: goldenHour1, status: 160, daylight: 1, dark: 0
11:30:10:848 Node 0x00178801026FF283 is known by 4 neighbors, last seen 6 s
11:30:10:885 poll node 00:12:4b:00:14:b7:1f:47-01-0702
11:30:10:885 Poll ZHAConsumption sensor node Consumption 2
11:30:11:146 Poll APS request to 0x00124B0014B71F47 cluster: 0x0702 dropped, values are fresh enough

[olicooper]

I've attached an example of me pressing the down button.
The line after MyDebug 6 will look like this: button <button-number> <button-command> .
If you press each button you should see the correct button being described.

02:56:30:052 APS-DATA.indication srcAddr: 0x7565, srcEp: 0x02 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 175, rssi: -69
02:56:30:053 MyDebug 1
02:56:30:053 MyDebug 2
02:56:30:053 MyDebug ZCL attribute report 0x000D6F00XXXXXXXX for cluster: 0x0008, ep: 0x02, frame control: 0x11, mfcode: 0x0000
02:56:30:053    MyDebug payload: 0126
02:56:30:054 MyDebug 3
02:56:30:054 MyDebug 4
02:56:30:054 MyDebug 5.3 mode: 1 ep: 0x02 cluster: 0x0008 cmd: 0x01
02:56:30:054 MyDebug 6
02:56:30:058 button 3001 Down long
02:56:30:059 Force binding of attribute reporting for sensor Lightify Switch Mini (2)

[bphermansson]

Hmm I don't see that...

$ git checkout bc2fc1071ed4265712bcc19032c3a1792f7c5bc6
Note: checking out 'bc2fc1071ed4265712bcc19032c3a1792f7c5bc6'.
...
HEAD is now at bc2fc10 Osram switch mini - Alternative long press down release handling
$  qmake && make -j2
make -f Makefile.Release
make[1]: Entering directory '/home/pi/Downloads/olicooper/deconz-rest-plugin'
make[1]: Nothing to be done for 'first'.
make[1]: Leaving directory '/home/pi/Downloads/olicooper/deconz-rest-plugin'
$  sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins
$ deCONZ --dbg-info=2 --dbg-aps=1 --dbg-zcl=1 --dbg-zdp=1 --http-port=80 

12:47:40:625 Node 0x00124B0014B71F47 is known by 1 neighbors, last seen 0 s
12:47:41:104 Node 0x000D6FFFFEAAC57B is known by 1 neighbors, last seen 17 s
12:47:41:189 APS-DATA.indication srcAddr: 0x53ce, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 255, rssi: -55
12:47:41:189 APS-DATA.indication from child 0x53CE
12:47:41:189 verify 0x000d6f000e1b8d80 is child node after 785732 s
12:47:41:190 MyDebug 0.1
12:47:41:190 MyDebug 1
12:47:41:206 verify neighbor status: APP_SUCCESS (0x00) 
12:47:41:325 APS-DATA.indication srcAddr: 0x2e61, srcEp: 0x02 dstAddrMode: 2, profile: 0x0104, cluster: 0x0500, lqi: 255, rssi: -46
12:47:41:326 IAS Zone Status Change, status: 0x0031, zoneId: 100, delay: 0
12:47:41:326 MyDebug 0.1
12:47:41:326 MyDebug 1
12:47:41:472 poll node 00:21:2e:ff:ff:04:0c:91-01
12:47:41:472 Poll light node Unknown 5
12:47:41:584 Node 0x000D6FFFFEF1370B is known by 5 neighbors, last seen 10 s
12:47:42:065 Node 0x000B57FFFE99F616 is known by 1 neighbors, last seen 32 s
12:47:42:158 MAC Poll 0x02 0x53CE
12:47:42:174 APS-DATA.indication srcAddr: 0x53ce, srcEp: 0x03 dstAddrMode: 2, profile: 0x0104, cluster: 0x0300, lqi: 255, rssi: -55
12:47:42:174 APS-DATA.indication from child 0x53CE
12:47:42:175 MyDebug 0.1
12:47:42:175 MyDebug 1
12:47:42:336 poll node 00:12:4b:00:14:b7:1f:47-01-0702
12:47:42:336 Poll ZHAConsumption sensor node Consumption 2
12:47:42:545 Node 0x000B57FFFE27551E is known by 0 neighbors, last seen 0 s
12:47:42:577 Poll APS request to 0x00124B0014B71F47 cluster: 0x0702 dropped, values are fresh enough

[olicooper]

It might be because there are bindings the have already been configured in deCONZ. After I manually bound some clusters of the switch to different devices I was unable to see any of the debug messages anymore.
Maybe try re-adding your device? I was able to use Phoscon web UI.

This is the steps I used to re-add the device:

1. Press and hold the middle and down buttons for ~10 seconds until the light stops flashing
2. Click add new sensor in Phoscon
3. Press and hold the middle and up button for ~3seconds until the light stops flashing
4. Wait for Phoscon to say the sensor is added

[Smanar]

So much thing to read, sorry if I forget something.

So natively the remote make as bind

• Power Configuration to the gateway
• Poll Control to the gateway
• On/Off to the bulb
• Level Control to the bulb

And to disable braodcast they make

• Power Configuration to a group for endpoint 1
• On/Off to the gateway for endpoint 1 and 2
• Level Control to the gateway for endpoint 1 and 2
• Color control to the gateway for endpoint 3

ATM I m making only the 3 lasts but for all endpoint, so for me it's enought to stop brodcast command ... You still have braodcast problem ?

But I m checking the code for the relase problem, you have made a rollback of your code to change only the parameter, it's enought to make the device working ?

Edit: I have gone in to deconz and bound cluster 0x0006(OnOff) and 0x0008(LevelControl) to an individual light for each endpoint (all three buttons), then bound 0x0001(Power) and 0x0001(Poll) to the coordinator and the switch is not broadcasting anymore!
Edit2: After setting up the bindings as mentioned above, there are no logs for the button presses anymore. I had to remove the device in deconz and add it back in again for the logs to start appearing again.

And If you make all binding to the gateway ?

[bphermansson]

Oh, I have trouble with the vocabulary... I tried to add it as a switch in Phoscon.
But now, great success! It shows up in the logs and I can even see it in Home Assisstant :)

Event 1 fired 6:44 PM:
{
    "event_type": "deconz_event",
    "data": {
        "id": "lightify_switch_mini_8",
        "unique_id": "00:0d:6f:00:0e:1b:8d:80",
        "event": 3002
    },
    "origin": "LOCAL",
    "time_fired": "2020-05-26T16:44:41.667421+00:00",
    "context": {
        "id": "9cfc44280cd945b3a30176aad6062c0a",
        "parent_id": null,
        "user_id": null
    }
}
Event 0 fired 6:44 PM:
{
    "event_type": "deconz_event",
    "data": {
        "id": "lightify_switch_mini_7",
        "unique_id": "00:0d:6f:00:0e:1b:8d:80",
        "event": 2002
    },
    "origin": "LOCAL",
    "time_fired": "2020-05-26T16:44:10.616804+00:00",
    "context": {
        "id": "4c54cd080d92402ca54a200fd433193e",
        "parent_id": null,
        "user_id": null
    }
}

[bphermansson]

Now I just wonder why the Osram switches on and off my Climax device.

[Smanar]

08:03:33:218 APS-DATA.indication srcAddr: 0x75b7, srcEp: 0x02 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 159, rssi: -71
08:03:33:300 APS-DATA.indication srcAddr: 0x192c, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 255, rssi: -35
08:03:33:302 no button map for: PSMP5_00.00.03.16TC ep: 0x01 cl: 0x0006 cmd: 0x0A pl[0]: 000
08:03:33:302 ZCL attribute report 0x00124B0014B71F47 for cluster: 0x0006, ep: 0x01, frame control: 0x18, mfcode: 0x0000

He is sensible to Cluster 0006 so it s because broadcast command, and I don't think a group one.
Do you know how to bind / unbind device using deconz ?

And why only this one ?

[olicooper]

So natively the remote make as bind

• Power Configuration to the gateway
• Poll Control to the gateway
• On/Off to the bulb
• Level Control to the bulb

This is what the official Osram mobile app does when the switch buttons are configured by the user. I found out this information from here.

But I m checking the code for the relase problem, you have made a rollback of your code to change only the parameter, it's enought to make the device working ?

Yes, just by changing the down button release param binding to 0x01 instead of 0x00 it has fixed the issue. This might be the same for the 4 button switch. Add this debug output to your code and look at the part that says sPrevD: to see if it output 0x01. I really think it should be 0x00 but it isn't and that is why the binding doesn't work.

When I bound the clusters (OnOff,LevelControl, etc.) in deCONZ it stopped the switch broadcasting to all lights (I could control a single light directly) but it also stopped the debug logs appearing so something wasn't right. I had to delete and re-add the switch to get the debug messages to appear again.

And If you make all binding to the gateway ?

I will try this. Which clusters do you want me to bind to the coordinator - OnOff,Level Control and Color Control ?

[Smanar]

So yes Gz, using 0x01 is realy better that the "hack" I had in my mind ^^.

The code use all theses 3.
And the code need them, if you look at the device it havent usefull input cluster (the blue one), all usefull cluster on/off, level, color are outputcluster (in grey), so we need to bind the conbee and the remote, so it send the command to the conbee and the conbee can manage them.

If you disable all binds, and make them to a bulb, the conbee can't detect them.

But wich one we need in more or less to disable all other broadcast command, it's another story.
I can be wrong on my code, and bind only some endpoint.

[alloro72]

sorry, I'm not good developer, I've got 3 of these switch, how to add it in deconz on Hassio? how can I help you debugging the switch values? should I have to replace some plugin files modified by you? I really appreciate your work, Thank you

[Smanar]

Hello, thx for proposition but with hass.io, it 's not possible to do something, at least if your are not Engineer. This OS is not made for modifications.

[olicooper]

I noticed in the logs there was 1 unbound command for the middle button so I have been testing what other button combinations there are...
To work out what the buttons do I reset one of my _Osram RGBW_ lights and my _Osram Switch Mini_ remote to factory defaults and paired them manually with the Zigbee Light Link function.

It is really interesting:

1. [UP BUTTON] Double press == some sort of 'identify' function which makes the light turn white/light-green color for ~1 second
2. [CENTER BUTTON] Double press == turns the light off
3. [CENTER BUTTON] Short Press + Wait 200ms + Long press == change color temperature from ~2400k > ~4000k until you release the button.
4. [DOWN BUTTON] Double press == does nothing (fyi a single press would turn the light off normally)

Also, in regards to the broadcast issue, I have managed to get it to work. I think my bindings were slightly wrong before.

But wich one we need in more or less to disable all other broadcast command, it's another story.
I can be wrong on my code, and bind only some endpoint.

This works for me:

• On/Off to the gateway for endpoint 1 and 2
• Level Control to the gateway for endpoint 1 and 2
• Color control to the gateway for endpoint 3

Edit: I have re-captured the commands from the logs after my experiments. I am a bit confused about what is happening because there are multiple commands for a single button press sometimes. I have also noticed that the mapping for the middle button has changed, I wonder if updating the bindings causes the button to behave differently?

Here is a pastebin for you: https://pastebin.com/e03KBuCw

[bphermansson]

I don't now if it's a bug, but the battery in my switch has discharged over night. It was discharged yesterday morning and I replaced it. The device worked fine yesterday, but now it's empty again.
I'm running https://github.com/olicooper/deconz-rest-plugin/commit/bc2fc1071ed4265712bcc19032c3a1792f7c5bc6

[olicooper]

Very interesting, I have one of these buttons and I haven't experienced this. I have disabled battery reporting for you to test. Do you have more than 1 of these buttons and does it have the same problem? I will re-add my own button with the old code to see if it happens to mine too.
I have also updated the button numbering because it was wrong :)

[Smanar]

So If using the code I make

On/Off to the gateway for endpoint 1 and 2
Level Control to the gateway for endpoint 1 and 2
Color control to the gateway for endpoint 3

It will disable broadcast command ?

And yes binding can filter command, for exemple If I bind only color control cluster to endpoint 3, you will never receive level control command from this endpoint.

It just a choice, we don't need all command to use this remote. The 3 bindings on top, are thoses one used in sensor table.

For battery, take a look in "poll control cluster", I think inside you can set the pooling perid for batterie for exemple.
If you pool too fast it will decrease the batterie life faster.

And there is too an option to disable it.

By defaut the code let the setting as it.

[bphermansson]

I just have one of these devices. Can I see the battery usage somehow? I connected the device to a power supply for now to avoid replacing batteries every day.

[olicooper]

In deCONZ, under the "power configuration" cluster, you can see the battery remaining attribute. Under "poll control" cluster some of the attributes are configurable (rw) so you may be able to solve your battery consumption issues by changing the poll interval to be a bigger number or by resetting your device to factory defaults (I'm not sure how to do this). It is also possible your buttons are sticking on or the device is water damaged?

[olicooper]

@Smanar is there a way to delete the 'deleted' sensors in the API? I want to start fresh by resetting the switch and removing all information from deCONZ etc so I know that I am working from a clean slate.

[Smanar]

@bphermansson , and if after @olicooper tips, you still have problem, you can launch deconz in debug mode, to see if the problem don't come from deconz.
If you touch nothing and have a request to or from the device every minut, it's not normal.

To delete a sensor in the API you can use
curl -X DELETE http://IP:PORT/api/KEY/sensors/ID

BTW, I m looking the code to make only the needed bind, and there is nothing for that yet, we realy need to check if it's something vital.

I have see you already have make change to mix sensor, have you already test it ?

And have you test

• the bind we need to don't make (but I don't think it's a problem)
• the bind we miss to avoid braodcast.

[bphermansson]

Thanks for the tips! The device seems ok and I don't think it's been near water. Strange. The Check-in intervall is set to 14400, the Long Poll is 20 and Short Poll is 2. Is that normal values?

[olicooper]

Those values are wrong, did you press "read" in deCONZ and then press a button on the remote before reading the values? Mine are as follows:

• Check-in interval = 0
• Short poll = 4
• Long poll = 48000
• Fast poll timeout = 720

[Smanar]

@olicooper have you tried if the code to mix the 3 device in one is working ?

[olicooper]

Sorry I've been busy so I haven't been able to but I will try to do this tomorrow. I don't understand what you mean by 'mix' ?

[Smanar]

On the first version you have 1 entries in the API by end point (so 3).
With the code you are using ATM, you have only 1 entries.

[olicooper]

I have reset deconz to factory defaults, and added the remote back in to test with my latest code: https://github.com/olicooper/deconz-rest-plugin/commit/f6ed67b4500fef7157c03fa9721e9d77c1882b59

Binding 1 output cluster to the gateway (endpoint 1) for each endpoint on the remote (all 3 buttons) stops _all_ broadcast messages when pressing the buttons. I then looked at the logs and I couldn't see all of the button events because I didn't have all the required bindings, so I added them in until I could see all the button events again.

Bind all of these to endpoint 1 of the gateway:

• ep: 1, cluster: 0x0006
• ep: 1, cluster: 0x0008
• ep: 2, cluster: 0x0006
• ep: 2, cluster: 0x0008
• ep: 3, cluster: 0x0008
• ep: 3, cluster: 0x0300

@Smanar Is this what you need?
There is 1 missing function I would like to add for this button but I don't know how, can you advise me? ...
Center button: Short press, then long press

• Changes the light bulb colour mode (cluster:0x0008, attribute: 0x0008) to "Color temperature".
• Cycles the temperature (cluster:0x0008, attribute: 0x0007) from ct: 485 (orange) > ct: 370 (white) until the button is released.

You can see my pastebin from my other comment which has the command logs (line 166): https://pastebin.com/e03KBuCw

I'd also like to get the battery reporting to work.

Thanks @Smanar 👍 !

[Smanar]

You can use your own code, I base mine on yours ^^.

For the missing command I have made like for the 4 buttons, I have enabled the param, before this modification the code use only ep, cluster and cmd for cluster 0300. https://github.com/Smanar/deconz-rest-plugin/commit/b02ae14f6d6fe2fe2a5d244619a9a3906c202e20
So I think you will have now some unworking command for the middle button, but you will be able to use more command.

I can't use your log because

21:50:29:636 MyDebug 5.3 mode: 1 ep: 0x03 cluster: 0x0300 cmd: 0x0A sPrevD: 0xFF

The debug line don't display param.
But now you will have more " no button handler for", so it will be easier to finish table.

So you confirm me that the code don't make bind itself, you need to make bind manually to avoid broadcast command ?
In the code logic (I think) the binding is done in the fonction checkSensorBindingsForClientClusters()
So if all is right, you will see in log "create binding for client cluster" with the cluster 0008 0006 0300 and the endpoint 1 / 2 / 3.
Perhaps you will have "skip check bindings for client clusters". If yes, I know the problem, my fault.
It can explian too why the batterie reporting is not working, all binds are not working.

BTW have you take a look in the API for how much device the code create ATM ?

[olicooper]

I have got battery reporting to work now: https://github.com/olicooper/deconz-rest-plugin/commit/c24519a3dac4f2a76d3fbe905a58c7848f264901

BTW have you take a look in the API for how much device the code create ATM ?

There are 3 sensors created (one for each button) in /sensor API endpoint. The battery percent
is showing up for each device too 🎉 I read your comment https://github.com/dresden-elektronik/deconz-rest-plugin/issues/374#issuecomment-636339677 and I guess that means device 'mixing' isn't working if we see 3 instead of 1?

Update:
I have updated my code with your changes and re-tested (https://github.com/olicooper/deconz-rest-plugin/commit/275d615dd040f38a36bb2470b0e34cc784f328b0). I don't see any logs with "create binding for client cluster" or "skip check bindings for client clusters". When deleting and re-adding the button I need to manually add the bindings to stop it broadcasting.

So I think you will have now some unworking command for the middle button, but you will be able to use more command.

All the buttons seem to be working the same as before so I don't think anything has changed.

Although the battery level was reported before the update, now that I have deleted the button the battery reporting has stopped again even after binding the power cluster (0x001) to the gateway.
I have also got these logs appearing which might be related to battery reporting: https://pastebin.com/4asYnrNW

[Smanar]

yes, so the mixing is not working.
The binding is not working too

Before this modification the code can't make a difference beetween

{ Sensor::ModeScenes, 0x03, 0x0300, 0x0A, 0x72, S_BUTTON_3 + S_BUTTON_ACTION_SHORT_RELEASED, "0" },

and

{ Sensor::ModeScenes, 0x03, 0x0300, 0x0A, 0x00, S_BUTTON_3 + S_BUTTON_ACTION_SHORT_RELEASED, "0" },

For exemple, it's for that you have sometime same value return for different actions, now the code can check too the param value.

On my side I have made some change https://github.com/Smanar/deconz-rest-plugin/commit/d85aabe36960f616abcf65f8bba33fdb0a140404

• Enabled binding for POWER_CONFIGURATION_CLUSTER_ID, we are readind value, but not enble it ^^
• add more debug line to check why other bind are not working, I think it's because group creation.

For the device mix, can you give me a JSON entry from a device, I have take the hypothese the entry is created in the cluster COMMISSIONING_CLUSTER_ID because on the other device, entry have *-1000 in the UniqueID, but you can have oher one now.
The code I m using for that is in de_web_plugin.cpp line 4073

[olicooper]

For the device mix, can you give me a JSON entry from a device

{
    "7": {
        "config": {
            "group": null,
            "on": true,
            "reachable": true
        },
        "ep": 3,
        "etag": "bf6c0e7f54438e380cb97310c68cb379",
        "lastseen": "2020-05-31T08:29:50.955",
        "manufacturername": "OSRAM",
        "mode": 1,
        "modelid": "Lightify Switch Mini",
        "name": "Lightify Switch Mini",
        "state": {
            "buttonevent": 3002,
            "lastupdated": "2020-05-31T08:18:27.739"
        },
        "swversion": "e.1.11.0M",
        "type": "ZHASwitch",
        "uniqueid": "00:0d:6f:00:xx:xx:xx:xx-03-0006"
    }
}

For exemple, it's for that you have sometime same value return for different actions

The logs show the correct event when I press each of the buttons, so I think the mappings are fine and it knows which buttons I have pressed.

I will combine your code with mine, re-test and give you the logs soon. 👍

[olicooper]

Okay, I merged and rebuilt your code, then deleted and un-paired the button from deconz, then re-added the button via 'add new sensor' on Phoscon. These are the logs: https://pastebin.com/hh2cahnE

I don't see any "MyDebug 15" etc.
Hopefully it helps!

[Smanar]

Ok so the device was created in cluster 0006.
So I have disable all entry creation in POWER_CONFIGURATION_CLUSTER_ID and move my code. I think you will understand what I m trying to do
If I m right the entry will be created only during out cluster parsing but only for endpoint 0x01.

To add the "double press middle button" I need the new "no button handler for" because the param filed is not diaplayer in your previous logs.

So on your log the code making

10:43:53:056 0x000D6F00XXXXXXXX (Lightify Switch Mini) create binding for attribute reporting of cluster 0x0001 on endpoint 0x01

So it's ok for battery I think.

And for other

skip check bindings for client clusters (no group)

It's because I haven't enabled group. My first objective was don' tuse group, but there is nothing in the code to make direct easy binding without group.
So on the new code, you will have a group during the device creation, and all binding will use this group.
For the moment I have mimic the busch-jaeger code https://github.com/Smanar/deconz-rest-plugin/commit/5d22b7e663896c6c58e963d81b24d22532fedbd0

[olicooper]

I have tried your changes. When adding the sensor from scratch deconz seems to identify all endpoints of the button without pressing the buttons. The OnOff (0x0006) and Level Control (0x0008) clusters of endpoint 1 (UP button) don't broadcast anymore when the button is pressed and I can still see the button press in the logs but the other two endpoints/buttons are still broadcasting.

I am now seeing additional logs like:

13:52:50:960 MAC poll fastEnddeviceProbe() 0x000D6F00XXXXXXXX
13:52:50:960 0x000D6F00XXXXXXXX (Lightify Switch Mini) create binding for attribute reporting of cluster 0x0001 on endpoint 0x01
13:52:50:961 discard double entry in binding queue (size: 3) for for 0x000D6F00XXXXXXXX, cluster 0x0001
13:52:50:961 MyDebug 11
13:52:50:961 MyDebug 12
13:52:50:961 MyDebug Bind 0 mid:x�u
13:52:50:961 MyDebug 13
13:52:50:962 MyDebug 14
13:52:50:962 MyDebug 15
13:52:50:962 0x000D6F00XXXXXXXX [Lightify Switch Mini] create binding for client cluster 0x0006 on endpoint 0x01
13:52:50:962 discard double entry in binding queue (size: 3) for for 0x000D6F00XXXXXXXX, cluster 0x0006
13:52:50:964 0x000D6F00XXXXXXXX [Lightify Switch Mini] create binding for client cluster 0x0008 on endpoint 0x01
13:52:50:964 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0008
13:52:50:964 0x000D6F00XXXXXXXX [Lightify Switch Mini] create binding for client cluster 0x0300 on endpoint 0x01
13:52:50:965 discard double entry in binding queue (size: 4) for for 0x000D6F00XXXXXXXX, cluster 0x0300

Battery reporting is still not working as the value is still null in the API.

[Smanar]

You haven't more lines after this log ?
The code first parse endpoint, then clusters, so if i m right you will have the same line for the 2 others endpoint just after. Or an error message ?

For batterie it's possible you need some time to have the first report.

[olicooper]

so if i m right you will have the same line for the 2 others

There are 6 entries with the following exact lines:

13:52:50:962 0x000D6F00XXXXXXXX [Lightify Switch Mini] create binding for client cluster 0x0006 on endpoint 0x01
13:52:50:964 0x000D6F00XXXXXXXX [Lightify Switch Mini] create binding for client cluster 0x0008 on endpoint 0x01
13:52:50:964 0x000D6F00XXXXXXXX [Lightify Switch Mini] create binding for client cluster 0x0300 on endpoint 0x01

Bindings are only happening on endpoint 1 from what I can tell. It seems there is only 1 group assigned to endpoint 1 so the for loop only has a single iteration https://github.com/olicooper/deconz-rest-plugin/blob/20478458678eb6fc619cd2000ef81cf6ef3d567a/bindings.cpp#L2663
I feel like it should be adding the cluster bindings for all endpoints.

I added MyDebug 20 to the code and I get logs like:

15:22:33:371 MyDebug 20 addSensorNode cluster: 0x0005 ep: 0x01
15:22:33:371 MyDebug 20 addSensorNode cluster: 0x0006 ep: 0x01
15:22:33:371 MyDebug 20 addSensorNode cluster: 0x0008 ep: 0x01
15:22:33:376 SensorNode 4: Switch 4 added
15:22:33:378 MyDebug 20 addSensorNode cluster: 0x0005 ep: 0x02
15:22:33:378 MyDebug 20 addSensorNode cluster: 0x0006 ep: 0x02
15:22:33:378 MyDebug 20 addSensorNode cluster: 0x0008 ep: 0x02
15:22:33:383 SensorNode 8: Switch 8 added
15:22:33:384 MyDebug 20 addSensorNode cluster: 0x0005 ep: 0x03
15:22:33:385 MyDebug 20 addSensorNode cluster: 0x0006 ep: 0x03
15:22:33:385 MyDebug 20 addSensorNode cluster: 0x0008 ep: 0x03
15:22:33:389 SensorNode 9: Switch 9 added

Sorry this is taking so long 😢 I'll be very happy when this is finished!

[Smanar]

Same, lol realy unlucky with this device.

But the magic is here https://github.com/olicooper/deconz-rest-plugin/blob/master/bindings.cpp#L2521

In this part in add the 3 cluster and the 3 endpoints, so I don't understand why it loop only on the first one ...
Can try to put some debug on variable srcEndpoints ?
If the code is good you will have

13:52:50:961 MyDebug 13
13:52:50:962 MyDebug 14
13:52:50:962 MyDebug 15
3 bindings
13:52:50:962 MyDebug 14
13:52:50:962 MyDebug 15
3 bindings
13:52:50:962 MyDebug 14
13:52:50:962 MyDebug 15
3 bindings

The part you have modified is not for binding (not directly) but for sensor creation.

Edit:
Ha, perhaps gids.size() .

[Smanar]

Ok so I have a hack to try https://github.com/Smanar/deconz-rest-plugin/commit/10bc4388dc03e6e5a3e7fe7c45da5ab7e7e1eae3

But it s realy something ugly.

If we still have problem with that, I think I will make a fonction tu make bind without group.

[olicooper]

Your hack works! All buttons are automatically bound... But there are a LOT of repeated logs when adding the sensor to deconz so I think something is wrong. The sensor took ~1min to add and the line MyDebug 14 gid: 1 was repeated in the logs 396 times. Its based on this code https://github.com/olicooper/deconz-rest-plugin/commit/4f4281f76643fc0143c02aac2da8da0c432ef13b

Here is a sample: https://pastebin.com/B8x0xB7A I added some additional logging to help you.

[Smanar]

And it's always the same line log ?

Because I don't see why it take 1 mn.
The code make 9 binding command in queue list (we can decrease this number) on the first part, than after it just say they are still in queue and so it wait for sensor ready before sending them (and not sending it again)

Have you still the complete log ?

We can have a problem, if the device take 1mn to be ready, its possible the code try to send the command more than 1 time

21:52:46:390 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0006

It's this one the important one, you need to have only 2 / 3 maximum time this line (by cluster and and endpoint)

21:52:46:392 discard double entry in binding queue (size: 9) for for 0x000D6F00XXXXXXXX, cluster 0x0006

This one is just for information

Battery device are slow, and we are trying to send 9 bind command, it ' s not a problem because the code use queue list but

• Need to check if it's not commands that slow down the inclusion.
• Need to check if the code doesn't try to make too much request.

I think it's possible too disable some "return check", I will take a look later.

BTW, this line is strange

21:52:46:392 device announce 0x000D6F00XXXXXXXX (0x947A) mac capabilities 0x80

How many time have you it ? With the same Network ID (0x947A) ?

[olicooper]

Yeah I have the logs but it would take too long to sanitise them and they are 8000+ lines long.

It's this one the important one, you need to have only 2 / 3 maximum time this line (by cluster and and endpoint)

These are all of them (10 in total).. At 21:52:46:390 the queue binding task logs are shown, then there is 100+ MyDebug 14 gid, then there is one more queue binding task at 21:52:56:426 for endpoint 1:

21:52:46:390 MyDebug 14 gid: 1
21:52:46:390 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0006
21:52:46:390 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0008
21:52:46:390 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0300
21:52:46:390 MyDebug 14 gid: 1
21:52:46:390 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0006
21:52:46:390 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0008
21:52:46:390 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0300
21:52:46:390 MyDebug 14 gid: 1
21:52:46:390 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0006
21:52:46:391 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0008
21:52:46:391 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0300

/// Lots of logs that read e.g.:
///
/// 21:52:46:402 MyDebug 14 gid: 1
/// 21:52:46:402 discard double entry in binding queue (size: 9) for for 0x000D6F00XXXXXXXX, cluster 0x0006
///

21:52:56:416 APS-DATA.indication from child 0x947A
21:52:56:420 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 5, node: 0x947A
21:52:56:420 DB pushZdpDescriptorDb()
21:52:56:421 FP indication 0x0000 / 0x8004 (0x000D6F00XXXXXXXX / 0x947A)
21:52:56:421                       ...     (0x000D6F00XXXXXXXX / 0x947A)
21:52:56:421 ZDP indication search sensors 0x000D6F00XXXXXXXX (0x947A) cluster 0x8004
21:52:56:421 ZDP indication search sensors 0x000D6F00XXXXXXXX (0x947A) clear timeout on cluster 0x8004
21:52:56:426 0x000D6F00XXXXXXXX (Lightify Switch Mini) create binding for attribute reporting of cluster 0x0001 on endpoint 0x01
21:52:56:426 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0001

How many time have you it ? With the same Network ID (0x947A) ?

Just 2 entries:

21:52:46:392    nwk address changed 0x0000 -> 0x947A [2]
21:52:46:392 device announce 0x000D6F00XXXXXXXX (0x947A) mac capabilities 0x80
21:52:46:392 set fast probe address to 0x000D6F00XXXXXXXX (0x947A)
21:52:46:392 FP indication 0x0000 / 0x0013 (0x000D6F00XXXXXXXX / 0x947A)
21:52:46:392                       ...     (0x000D6F00XXXXXXXX / 0x947A)
21:52:46:392 device announce 0x000D6F00XXXXXXXX (0x947A) mac capabilities 0x80
21:52:46:398 discard sensor config push for config/reachable (already pushed)

I have 3 entries nwk address changed 0x0000 -> 0x947A that happen just after the device binding starts (queue binding task).

Why are there so many discard double entry logs then? It seems wrong to have so many, is this because the sensor is not online? I have been keeping the remote close to the gateway so it isn't a signal problem and the battery is still good despite all this testing haha 🤣 .

[Smanar]

lol, yes batterie was one of my worry.

I have just finished my breakfast ATM, I will take a look on the code but

discard double entry in binding queue (size: 9) for for 0x000D6F00XXXXXXXX, cluster 0x0006

Is not a problem

21:52:46:390 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0006

is a problem. But If I have correctly understand, you have a serie of 9 request at 21:52:46 and just another at 21:52:56 ?

So it's not a problem for the device, 9 request make 2 time spaced by 10s, can't freeze a device for 1mn.

I will take a look to decrease spamming.

The sensor took ~1min

It mean when you have used phoscon to include it, it have take 1 mn to have the "read" message ?

[olicooper]

But If I have correctly understand, you have a serie of 9 request at 21:52:46 and just another at 21:52:56

Yes that's correct.

It mean when you have used phoscon to include it, it have take 1 mn to have the "read" message

I think I will try to add the sensor again to test. I remember that the message indication light for the button was flashing green for a while on deCONZ before everything was configured. Maybe it was a one off and it won't happen again?

[Smanar]

Ha ?
I don't think the light on the button can depend on deconz.
It's hardware, I don't think the device wait for complete inclusion, I think it's something time based.

And I have checcked the code, the fonction checkSensorBindingsForClientClusters() is realy used on so much part in the code. The usage is perhaps normal, you can make a try with another switch from another brand.
But As I have said, I don't thnik this fonction is something heavy for conbee/code. I will ask to discord to be sure.

[olicooper]

I didn't explain it well.. The node entry on deCONZ has a node status light on the left-hand side. This was flashing green for longer than I usually see.

you can make a try with another switch from another brand

Yeah good idea. I have one Xiaomi button.

I am working today so I won't be as quick to test as usual :)

[Smanar]

Xiaomi don't use bind ^^.

I m asking to other dev ATM.

Edit:
Ha ok on the node, I thought it was on the device, green mean pooling.

[olicooper]

Ah okay, might not be able to then. I have 3 Osram lights, 2 Osram buttons, 1 Xiaomi button, and 1 Xiaomi PIR sensor.

[Smanar]

I can, If I haven't answer I will make test on my side.

But If it s ok We still need to check battery return, and double clic on central boutton.

And this device create a group now, so you can too use direct connexion features.

[Smanar]

So I have make test with the ikea remote, and I can have 3 loops for complete binding. But realy far away your 100 cycles.

I m checking your logs, and I miss lot of thing, I haven't "create binding for client cluster" around debug 14, and all "bind success".

On ikea remote there is 10s beetween 2 checks., but not on your (only 1 ms)

21:52:46:390 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0006
21:52:46:391 discard double entry in binding queue (size: 9) for for 0x000D6F00XXXXXXXX, cluster 0x0006

I think somewhere in the code this fonction is spammed, but I can't find where.
If you have complete logs, check if you can find the previous fonction that call this one. Or in last try, put a "My debug X" just before all call to fonction checkSensorBindingsForClientClusters()

Edit:
Find it

21:52:46:390 DeviceAnnce of SensorNode: 0x000D6F00XXXXXXXX

But it's like your device spaming join request ....

Try to put some debug line in void DeRestPluginPrivate::handleDeviceAnnceIndication(const deCONZ::ApsDataIndication &ind)

Perhaps you have somrthing wrong in the loop
for (; si != send; ++si)

This part of code can explaion the bug.

• You have one rejoin by your device
• it call the fonction handleDeviceAnnceIndication
• bug in this loop
• spam of debug "DeviceAnnce of SensorNode:" and fonction checkSensorBindingsForClientClusters

[olicooper]

I haven't "create binding for client cluster"

These are all the "create binding for ..." logs (there are none for 'client cluster'):

21:48:32:349 create binding for attribute reporting of cluster 0x0006
21:48:32:349 create binding for attribute reporting of cluster 0x0008
21:48:32:349 create binding for attribute reporting of cluster 0x0300
21:52:56:426 0x000D6F00XXXXXXXX (Lightify Switch Mini) create binding for attribute reporting of cluster 0x0001 on endpoint 0x01
21:53:02:436 0x000D6F00XXXXXXXX (Lightify Switch Mini) create binding for attribute reporting of cluster 0x0001 on endpoint 0x01
21:53:08:477 0x000D6F00XXXXXXXX (Lightify Switch Mini) create binding for attribute reporting of cluster 0x0001 on endpoint 0x01
21:53:14:523 0x000D6F00XXXXXXXX (Lightify Switch Mini) create binding for attribute reporting of cluster 0x0001 on endpoint 0x01
21:53:20:543 0x000D6F00XXXXXXXX (Lightify Switch Mini) create binding for attribute reporting of cluster 0x0001 on endpoint 0x01
21:53:26:557 0x000D6F00XXXXXXXX (Lightify Switch Mini) create binding for attribute reporting of cluster 0x0001 on endpoint 0x01

There is 1 "bind success" log (it was in the middle of the binding 'spam' logs):

21:52:58:425 Bind response success for 0x000d6f00XXXXXXXX ep: 0x01 cluster: 0x0001

I will be able to run another test now. Can I delete the zll.db and deCONZ will create a new one? That would be the easiest way to reset back to factory defaults if I can.

[Smanar]

No, I think your install is fine but the log I searching is "create binding for client cluster" on line 2669

• create binding for attribute reporting of cluster : need to check to utility of this one
• create binding for attribute reporting of cluster 0x0001 on endpoint 0x01 is for the battery every 6s

But why we need 6 tries to make the bind ?
This fonction is too in the suspect loop (on previous issue)

I realy think there is a problem in the fonction handleDeviceAnnceIndication(), it can explain all our bugs.

[Smanar]

@olicooper

I can explain why, but I m almost sure the part

std::vector::iterator si = sensors.begin();
std::vector::iterator send = sensors.end();
for (; si != send; ++si)

Make more than 1 loop, it s for that whe can have just 1ms beetwen
21:52:46:390 DeviceAnnce of SensorNode: 0x000D6F00XXXXXXXX [1]

and
21:52:46:391 DeviceAnnce of SensorNode: 0x000D6F00XXXXXXXX [1]

And It explain the spam too.

To be sure you can for exemple use

       DBG_Printf(DBG_INFO, "DeviceAnnce of SensorNode: 0x%016llX [1]\n", si->address().ext());
       DBG_Printf(DBG_INFO, "Mydebug 22: 0x%02X\n", si->fingerPrint().endpoint);

Around line 13315, I think you will have more than 1 Sensornode, and perhaps with other endpoint.

And a

DBG_Printf(DBG_INFO, "Mydebug 23: %d\n", sensors.size());

[olicooper]

I have run it again. The first time the sensor wouldn't add for some reason, so I restarted deconz and it worked the second time.

I stopped everything communicating besides 1 light and the button so the logs were cleaner.
Here is a more complete log which I hope helps you more: https://pastebin.com/dSavRvte
I added more debug lines in in various places but I don't see a lot of them in the logs. It is based on this commit: https://github.com/olicooper/deconz-rest-plugin/commit/ac331a86d3f2c6a741c3fddf5d802cc18f4e06e3

I watched deconz as it was adding the sensor and I saw the "node status light" [[blink blue a few times, then green a few times]] x~3-5 times.

Edit: I didn't see your previous message until now. I can add that debug line in and see what happens.

[olicooper]

I've added MyDebug 22 output to my code below DeviceAnnce of SensorNode (see https://github.com/olicooper/deconz-rest-plugin/commit/edd7ca24925c5e30ad3483faceb6ac3ba751fb10). These are the logs that were output:

20:50:00:394 APS-DATA.indication from child 0x4328
20:50:00:395 MyDebug apsdeDataIndication profileId:0x0000, cid:0x0013
20:50:00:395 MyDebug DeviceAnnce nodesSize: 2, nwk: 0x4328
20:50:00:395 MyDebug DeviceAnnce 1
20:50:00:395 DeviceAnnce of SensorNode: 0x000D6F00XXXXXXXX [1]
20:50:00:395 Mydebug 22: 0x01
20:50:00:395 MyDebug 11
20:50:00:395 DeviceAnnce of SensorNode: 0x000D6F00XXXXXXXX [1]
20:50:00:395 Mydebug 22: 0x02
20:50:00:395 MyDebug 11
20:50:00:395 DeviceAnnce of SensorNode: 0x000D6F00XXXXXXXX [1]
20:50:00:395 Mydebug 22: 0x03
20:50:00:395 MyDebug 11
20:50:00:395 MyDebug DeviceAnnce 2 foundCount:3
20:50:00:395 MyDebug DeviceAnnce 3 sSenSt:0, apsCtrl:1
20:50:00:399 discard sensor config push for config/reachable (already pushed)
20:50:00:402 discard sensor config push for config/reachable (already pushed)
20:50:00:405 discard sensor config push for config/reachable (already pushed)

[Smanar]

Nice ^^ It s a good news. Thx, I did not know this working mode, realy good to know.

Ok so now we know why you have spam, and we can light the code, give me 1 hour.

[Smanar]

So On the last code https://github.com/Smanar/deconz-rest-plugin/commit/2cf236599cd14e5ba764b07e430e24d916989bf9

• Binding on cluster POWER_CONFIGURATION_CLUSTER_ID Only for cluster 0x01.
• Decrease bind spamming.
• make the group management easier.

So you will have 2 bind less for battery and 24 less for cluster 006 008 300.

Idk if the device mix have worked, but now you will have battery report only on one of them if you still have 3 entries.

[olicooper]

Thanks for your updates! I've tested them and we're almost there...

For some reason the buttons aren't all binding correctly. It seems bindings are randomly missed.
I paired my first button but the "down short" (endpoint 2, cluster: 006) didn't bind, so I manually bound it in deCONZ and it worked after that.
I then tested it again with my other button and this time the "center short"/"center long" buttons (endpoint 3, cluster: 300) didn't work. Interestingly, there is no broadcast message for the center buttons even though none of the bindings worked for the center button.

Update: I paired the second button with deconz again and all endpoints worked. I'm not sure if it is okay of not. Maybe it is just taking a really long time to be fully configured?

Battery reporting is fine I think, I got the battery update on one of the buttons so I will wait for the other one to update too.

Idk if the device mix have worked

I still see 3 entries in the REST API.

but now you will have battery report only on one of them if you still have 3 entries.

Yes, there is only one "battery": ... entry on endpoint 1 for each button.

I have also fixed an incorrect binding in sensor.cpp. It used to work but over the last few days it is different. The new binding works for both buttons.

Here's the entries:

{    
    "5": {
        "config": {
            "battery": null,
            "group": "7",
            "on": true,
            "reachable": true
        },
        "ep": 1,
        "etag": "37f8a1ab352fe06f52d0563231bcdc77",
        "lastseen": "2020-06-03T09:50:35.809",
        "manufacturername": "OSRAM",
        "mode": 1,
        "modelid": "Lightify Switch Mini",
        "name": "Lightify Switch Mini (2)",
        "state": {
            "buttonevent": 1002,
            "lastupdated": "2020-06-03T09:50:29.296"
        },
        "swversion": "e.1.11.0M",
        "type": "ZHASwitch",
        "uniqueid": "00:0d:6f:00:XX:XX:XX:XX-01-0006"
    },
    "6": {
        "config": {
            "group": "6",
            "on": true,
            "reachable": true
        },
        "ep": 2,
        "etag": "7e64fba0a516783aea79d7b9c8fe0eb8",
        "lastseen": "2020-06-03T09:50:35.809",
        "manufacturername": "OSRAM",
        "mode": 1,
        "modelid": "Lightify Switch Mini",
        "name": "Lightify Switch Mini (2)",
        "state": {
            "buttonevent": 2002,
            "lastupdated": "2020-06-03T09:50:26.463"
        },
        "swversion": "e.1.11.0M",
        "type": "ZHASwitch",
        "uniqueid": "00:0d:6f:00:XX:XX:XX:XX-02-0006"
    },
    "7": {
        "config": {
            "group": "7",
            "on": true,
            "reachable": true
        },
        "ep": 3,
        "etag": "eac97d698d6ecd01744bfcb1a2673072",
        "lastseen": "2020-06-03T09:50:35.810",
        "manufacturername": "OSRAM",
        "mode": 1,
        "modelid": "Lightify Switch Mini",
        "name": "Lightify Switch Mini (2)",
        "state": {
            "buttonevent": 3002,
            "lastupdated": "2020-06-03T09:50:32.256"
        },
        "swversion": "e.1.11.0M",
        "type": "ZHASwitch",
        "uniqueid": "00:0d:6f:00:XX:XX:XX:XX-03-0006"
    }
}

[Smanar]

Pff, it' s boring. So new version too https://github.com/Smanar/deconz-rest-plugin/commit/1afdf7ed0607b2b03fa151a9b3d5cd04f2bb5f9d

So working

• the bind.
• the broadcast disabling.

Not working:

• the device mixing (I hope it will be fine now)
• the double press, middle button. (ned logging)

And yes it can take some time, and more if the device go to sleep.

[olicooper]

Tested again.. https://pastebin.com/XVwDMvRG

Still 3 sensor entries in the API, assigned to 2 groups

I don't think the battery reporting is working though as I have left it for a long time, and also tried pressing buttons occasionally but the status never updated. When I make a request to read the power 0x0001 cluster, the battery status updates on the API. You can see it happening at the bottom of the logs (after I press the up button).

• the double press, middle button. (ned logging)

The logs for the double press are in one of my previous logs (log1 - line 389, log2 - line 166). This is all the output I got when I pressed the button. So I think these are the commands:

| endpoint | cluster | command | payload | NOTES |
|:---|---|---|---|---:|
|0x03|0x0008|0x04|0xFE|center press short start|
|0x03|0x0300|0x03|0xFE|center press short end|
|0x03|0x0300|0x0A|0x72|center press long start|
|0x03|0x0300|0x01|0x00|center press long end|

I have found out more information on what happens with the light when the button is pressed..

• Changes the colour 'mode' of the light to Color temperature
• Cycles from ct: 485 (min) to ct:370 (max)

[Smanar]

Yep but you have make this log before the modification on cluster 300

10:44:54:315 MyDebug 5.3 mode: 1 ep: 0x03 cluster: 0x0008 cmd: 0x04 sPrevD: 0xFF

So there is no param value in log, and no "no button handler" (because all command validate endpoint + cluster, the difference was the param) Except this one for release after the short press+long press, but it the same than "0 long release"

10:44:56:095 no button handler for: Lightify Switch Mini ep: 0x03 cl: 0x0300 cmd: 0x01 pl[0]: 0x00

for device mixing, a more agressive fonction > https://github.com/Smanar/deconz-rest-plugin/commit/7734ef859db3e0baaee201c635018f63dc0a24b8

BTW this log is so usefull, there is still attribute spamming because of FastProbe, realy need to check the code tommorow.

[olicooper]

This code is still quite confusing to me because I don't know enough about ZigBee otherwise I'd be trying to help you with the code more! So, thanks for all your work, its really appreciated! :+1: :+1:

for device mixing, a more agressive fonction

Only the first endpoint is visible in deconz and the sensor won't fully initialise so I don't think that code is going to work. It took me ~5 pairing attempts to get the device to show up in deconz too.

So there is no param value in log

Do I need to add any more debug logs or manual cluster bindings to get the values we need? Here is a log of the button press using the latest working code (https://github.com/olicooper/deconz-rest-plugin/commit/c9ced96d9ec32ed3dae8a4ef3430f7c1c45fc20a): https://pastebin.com/ixEWHbMX

[Smanar]

For double press, I m realy not sure, you have

22:11:55:679 button 3001 0 long press
22:11:55:989 button 3002 0 short press
22:11:56:664 no button handler for: Lightify Switch Mini ep: 0x03 cl: 0x0300 cmd: 0x01 pl[0]: 0x01
22:11:56:716 button 3003 0 long release

You have the action during the double press, or after releasing the long press (after the double press) ? On Osram /Hue gateway ,

Le fingerprint is not the same too

{"d":2064,"ep":1,"in":[0,1],"out":[5,5,6,6,8,8],"p":260}
{"d":2064,"ep":2,"in":[0],"out":[5,6,8],"p":260}
{"d":2064,"ep":3,"in":[0],"out":[5,6,8],"p":260}

and there is 2 endpoint on a group and 1 in a second group .....

So daily try > https://github.com/Smanar/deconz-rest-plugin/commit/626c96300a4a2e861a86fb9493ca3d8d624cf12c

• A new group try, you will have 3 group if you have 3 devices.
• A new switch mix to test, with some debug line, less agressive.

Edit :
I have found why the figerprint are not the same, you haven't the cluster 0001 on other clusters.

[olicooper]

Latest tested: https://pastebin.com/vsxMNDxD

• Group mixing is working, only 1 /sensor created (see below) 👍
  
  
  
  • Group is null, maybe this is good? I used to get light groups appearing in Phoscon so hopefully not anymore?
  
  
• Paired first time
• All current button mappings work (see logs) and update on the API
• battery reporting needs work though, can we poll ep: 0x01, cl: 0x001, attr: 0x0020 when the device first appears on the network?

{
    "config": {
        "battery": null,
        "group": null,
        "on": true,
        "reachable": true
    },
    "ep": 1,
    "etag": "5a3002d8ac2f24e9cf6a09583ec10d89",
    "lastseen": "2020-06-05T09:50:44.800",
    "manufacturername": "OSRAM",
    "mode": 1,
    "modelid": "Lightify Switch Mini",
    "name": "Lightify Switch Mini (2)",
    "state": {
        "buttonevent": 2002,
        "lastupdated": "2020-06-05T09:50:44.186"
    },
    "swversion": "e.1.11.0M",
    "type": "ZHASwitch",
    "uniqueid": "00:0d:6f:00:XX:XX:XX:XX-01-0006"
}

You have the action during the double press, or after releasing the long press

Its hard to tell because the logs are written in batches (I'm using tail -f). I think it works like this:

1. I short press then long press -> 3 commands sent
2. Then I long press release after a period of time -> 4th + 5th command sent

I think the first command sent is what we need to detect ep: 0x03, cl: 0x0008, cmd: 0x04, pl: 0xFE. If we can detect this first command, then we know the next 3 commands are related to the double press, so we can ignore the normal bindings and wait for the 5th command ep: 0x03, cl: 0x0300, cmd: 0x01, pl: 0x00

Great work! 💯

[Smanar]

Ha ?
I don't understand why this code works better than previous ...

For the baterry, it will not work after some time ?

For the double command I m checking this file https://pastebin.com/e03KBuCw
I think we can't use all the first clic phase, because the remote can't guess if you will press it a second time, so I m sure it will be same event.

And you already have that for for simple clic

22:11:35:259 MyDebug 5.3 mode: 1 ep: 0x03 cluster: 0x0008 cmd: 0x04 sPrevD: 0xFF

So I don't see a specific command to the double press.

For the group. You are right, no group was created at all, so a big part part was ignored, so the code haven't make bind at all ? You don't have make them yourself ? no broadcast problem ?

I realy don't understand how this code can work ...

[olicooper]

For the baterry, it will not work after some time ?

If I don't press read on deconz for cluster 0x001, the battery information is never updated. I have tried leaving it doing nothing, and I have tried pressing buttons for a while but nothing updates it automatically.

because the remote can't guess if you will press it a second time

The remote doesn't send any command until I have already pressed the button for the second time.
This log (https://pastebin.com/e03KBuCw) has all the different commands that I originally found so its quite confusing. Fyi, the button has 2 types of double click:

1. short press + long press <-- this is the one I am trying to make work
2. short press + short press

The more recent log is clearer: https://pastebin.com/ixEWHbMX and there are 5 commands that are output instead of 4 in the new log. I will double check that these are still correct though.

You are correct, the center short press and the center double press start with the same command but our button mappings don't listen to the first command for center short press.

The center short press is identified using the second command ep: 0x03 cluster: 0x0300 cmd: 0x0A pl[0]: 0x72 so if I understand it correctly, we should be able to catch ep: 0x03 cl: 0x0008 cmd: 0x04 pl[0]: 0xFE, then ignore the commands between and wait for ep: 0x03 cl: 0x0300 cmd: 0x01 pl[0]: 0x01 (see line 53 on https://pastebin.com/ixEWHbMX).

You don't have make them yourself ? no broadcast problem ?

No broadcast problem from what I can tell. We have bound the endpoints to the coordinator which stops the broadcast from happening, so I think I that is why it is still working fine.

[Smanar]

I will check for battery, perhaps the binding is ok, but not the reporting.
Or it can just don't support reporting and use pooling (there is a pooling cluster), but from my memory on some log we can see the battery report with "non handler button" log.

The remote doesn't send any command until I have already pressed the button for the second time

Ha ? so you have only 1 command with double press, you haven't the same than the simple press + another ?

The double short press isn't working too ?

22:11:56:664 no button handler for: Lightify Switch Mini ep: 0x03 cl: 0x0300 cmd: 0x01 pl[0]: 0x01

Yep, I think too this one is to try, but idk wich one command it will be, will be a suprise.

For "ep: 0x03 cl: 0x0008" I m less sure, you have it only one time, and just after 600ms, you have the
long press, and you have it too for short press, I think you have this command every time you touch the buton.

For broadcast problem, we will see later, easy to correct, we have make it one time, we can re do it ^^, We don't have broadcast, just beacuse the group is locked.

[Smanar]

For battery you are sure it's attribute 0x0021 ?

Reporting not ok

09:23:33:364 configure reporting rq seq 8 for 0x000D6F00XXXXXXXX, attribute 0x0001/0x0021
09:23:38:375 ZCL configure reporting rsp seq: 8 0x000D6F00XXXXXXXX for ep: 0x01 cluster: 0x0001 attr: 0x0021 status: 0x86

0x86 mean Error

[olicooper]

I will check for battery, perhaps the binding is ok, but not the reporting.

Yes, think that too. I have also tried manually binding cluster 0x001 to be sure, but still no battery report.

you haven't the same than the simple press + another ?

You have to press the button quickly otherwise it sends two simple commands.
I always see a different output with the short press + long press
For example:

• short press + wait <200ms + long press == 5 commands seen on the log https://pastebin.com/ixEWHbMX
• shortpress + wait >1second + long press == two separate commands

The double short press isn't working too ?

Yeah, that is another command that doesn't work, but all it did was turn the light off the same as down short press. I didn't want to give us too much work to do so I ignored it 😄

For battery you are sure it's attribute 0x0021

No the battery reporting is on 0x0020 "battery voltage", is the code wrong? I thought I'd already configured it to work on 0x0020? see this deconz picture

[Smanar]

For battery I think it's my bad. I think I have removed it myself. https://github.com/Smanar/deconz-rest-plugin/commit/30311e22814862144f868b929c5d254f49de2539

I m using standard value

            rq.minInterval = 3600;
            rq.maxInterval = 3600;

If I m right you will have in log "status: 0x00"

Or better
https://github.com/Smanar/deconz-rest-plugin/commit/884facc3ba298e821b0e797b5ea56b9c5af6b0fe
With the mystery command

[olicooper]

If I am correct, it looks like this 'mystery' command will be triggered just before the 0 long release (https://pastebin.com/e03KBuCw line 112) command and also when I double press too (https://pastebin.com/ixEWHbMX line 66). It will be interesting to see.

What was the code doing that you removed in de_web_plugin https://github.com/Smanar/deconz-rest-plugin/commit/30311e22814862144f868b929c5d254f49de2539 ?

Update:
Sorry, my testing was bad this morning and I didn't realise that the broadcasting issue came back whoops! But I think I fixed it again: https://github.com/olicooper/deconz-rest-plugin/commit/3c608bb1c0aa4af01e8f1823695d927fbe656269 .. There are 3 entries in the API again though, and they are assigned to a single group.

The mystery command doesn't seem to be appearing in the logs. I assume it is because of the cool off/timeout period between commands maybe - I'm still testing it though

Update 2:
"Suprise" appeared when I double pressed (along with long press and long release etc.) 👍

20:07:41:374 no button handler for: Lightify Switch Mini ep: 0x03 cl: 0x0008 cmd: 0x04 pl[0]: 0xFE
...
20:07:42:145 button 3001 0 long press
...
20:07:42:363 button 3002 0 short press
...
20:07:43:125 APS-DATA.indication from child 0xC496
20:07:43:125 MyDebug apsdeDataIndication profileId:0x0104, cid:0x0300
20:07:43:125 MyDebug 1
20:07:43:125 MyDebug 2
20:07:43:126 MyDebug ZCL attribute report 0x000D6F00XXXXXXXX for cluster: 0x0300, ep: 0x03, frame control: 0x11, mfcode: 0x0000
20:07:43:126    MyDebug payload: 0119
20:07:43:126 MyDebug 3
20:07:43:126 MyDebug 5.1
20:07:43:126 MyDebug 5.2
20:07:43:126 MyDebug 5.3 mode: 1 ep: 0x03 cluster: 0x0300 cmd: 0x01 sPrevD: 0xFF
20:07:43:126 button 3004 0 Suprise
20:07:43:126 Force binding of attribute reporting for sensor Lightify Switch Mini (2)
20:07:43:126 MyDebug 11
20:07:43:129 Websocket 192.168.1.99:33256 send message: {"e":"changed","id":"8","r":"sensors","state":{"buttonevent":3004,"lastupdated":"2020-06-05T20:07:43.125"},"t":"event","uniqueid":"00:0d:6f:00:XX:XX:XX:XX-03-0006"} (ret = -1092744)
20:07:43:130 discard sensor state push for 8: state/lastupdated (already pushed)
...
20:07:46:338 button 3003 0 long release

Update 3:
I have come to realise that un-pairing the button (holding center+down button for 10 seconds) then sending 'delete' request in the API doesn't properly work, so our testing isn't predictable and we are getting strange results. I have 1 remote doing one thing, and the other doing something else with the same code. I have created a 'default' database that will hopefully mean we are starting from a known point each time, but I think I also have to restart the RaspberryPi because the RaspBee seems to hold on to the connections even when deconz is closed. It's all a bit of a mess and deconz isn't very easy to code or test at all!

I didn't realise before, but the button is broadcasting again and I think it was being masked before so I didn't spot it. I have been re-introducing some of the old code to see what could stop it broadcasting again but I haven't had any luck yet.

[Smanar]

The code I removed was for group, I have removed it because it not working at all, and it create more than 1 group, was a try.

For the battery, the important part are the lines I have added, but I m almost sure have already see them at a moment.

For the mystery command, we can't be sure for line 122 in first log, because you haven't param in the log

22:14:24:528 MyDebug 5.3 mode: 1 ep: 0x03 cluster: 0x0300 cmd: 0x01 sPrevD: 0xFF

As hack it's possible too using the sPrevD.

And yes, I know, deleting a device can not work a 100%, you probably need to delete some group by hand for exemple

On the first "update" comment, you mean with this modification, you will have 3 device created but a working group (and only one) ?

The code for binding (and disable broadcast) use group, so we need to have a group for it work.
So I have made some modification to re-enable group.
On your log you have before the modification

09:23:30:345 skip check bindings for client clusters (no group)

So you haven't bind at all.

I have re-enable the previous code, this one have already worked. I have put some comment in the code to explain it for you can debug it, if it don't work.

I haven't modified the code, so you still have only 1 device created, but with a group this time https://github.com/Smanar/deconz-rest-plugin/commit/83f182adce0c848f1f4685df1950bcbab62a6a26

And the good news, is as we have only 1 device created, will be hard for code making 3 group ^^

[olicooper]

Getting more consistent results now so hopefully more reliable testing.
I see 1 sensor in the API which has all button events, so I think the grouping/mixing issue is fixed.

Broadcast is not happening for endpoint 1 👍, but endpoint 2 and 3 are both broadcasting. Manually binding to cluster 0x0006 (onoff) for ep 2 and 3 stops them broadcasting. I feel like we had a fix a while back, but I can't seem to find it 😢

[Smanar]

This one is easy.
Just look in your log for "create binding for client cluster 0x%04X on endpoint 0x%02X"
If you see only the endpoint 0x01, and only this one.

line 2527
Replace
srcEndpoints.push_back(sensor->fingerPrint().endpoint);

by

srcEndpoints.push_back(0x01);
srcEndpoints.push_back(0x02);
srcEndpoints.push_back(0x03);

The previous code use 3 device, one by endpoint, but the new one only 1.

[olicooper]

I think I have got it working but I had to add that hack in again (https://github.com/Smanar/deconz-rest-plugin/commit/2cf236599cd14e5ba764b07e430e24d916989bf9#diff-70a87389db32b8f306683c8362093bfcL2519) so there is probably something wrong with groups...
https://github.com/olicooper/deconz-rest-plugin/commit/dbf424b2305be8ddbafc1937fdcfbd8c379a2673

At first it appeared it wasn't working, but after rebooting the rpi and trying again it worked okay. Can't believe I have to reboot the whole thing to make it work 😞

[Smanar]

I think this part is not usefull.

   QString gid0 = gids[0];
   gids.append(gid0);
   gids.append(gid0);

If you look at groups in API, I m almost sure you will found only 1.

What haven't worked on your first try ?

Have you take a look on logs ? for me we have almost finished, I don't see what can be missing, perhaps a ramdom bug that need sometime a reboot.

[Smanar]

So yes, you are right, we need this part. Because the code parse in same time endpoint and group, so we need to have the same number.

for (int j = 0; j < (int)srcEndpoints.size() && j < gids.size(); j++)
{
QString gid = gids[j];

But it's not working without reboot, nothing in logs ? still spanning bind command bug ?

[olicooper]

I removed the hack again (https://github.com/olicooper/deconz-rest-plugin/commit/3d3958371f72e306113b173cba2ba0c830196ced) and retested (after rebooting). Here is the log: https://pastebin.com/3zq7F0pL

Removing the hack made the problem come back. The problem is that endpoint 2 and 3 start broadcasting again. You can see that gids.size() is only 1 when we need 3...

18:10:38:522 MyDebug 13 srcEndpointSize: 3, gidSize: 1

Update:
I've retested with the previous code (https://github.com/olicooper/deconz-rest-plugin/commit/dbf424b2305be8ddbafc1937fdcfbd8c379a2673) and it works properly.

• No broadcasting
• 1 sensor in the API, assigned to 1 group
• All button events appear in the API

I don't understand why the code needs to loop the endpoints and groups at the same time!? I think the hack might have to remain in the code for it to work properly, or the for loop needs refactoring.
https://github.com/dresden-elektronik/deconz-rest-plugin/blob/02a02d1369895cda4bbe3cfdf0c95af959be8cea/bindings.cpp#L2623

[Smanar]

Yep ^^, lot of code need refactoring, but I think it will be for next API version.

• The fonction works only with group
• The fonction work with 1 group by endpoint, because on classic device , there is 1 endpoint by button (1 gang switch or 2 gang switch)

For us group are useless (for the moment) and we want to use all command in the same device.

And it will be worse for the 4 button, because this one have more than 4 endpoint.

For the moment you can just put a comment about why you are using this hack, it's not a problem because it will be used by only this device.

But if all is working you can make the PR to the official github, but don't forget to clean the code first ^^.

[olicooper]

So what should we do with the hack? Is there a better implementation?

Also, the battery reporting is still not working even though we've added the code to support it. I will look at what might be wrong with it but do you have any suggestions?

[Smanar]

I think it's better use the hack with explanation than making a full fonction just for that (the code is full of hacks )

For battery reporting, take a look on log for exemple searching for "0x0001"
You can check
1 - the bind
2 - the reporting
3 - an error during the reporting
4 - a "no button handler" for cluster 0x0001
5 - take a look on polling cluster if all the previous check are good.

09:23:33:364 configure reporting rq seq 8 for 0x000D6F00XXXXXXXX, attribute 0x0001/0x0021
09:23:38:375 ZCL configure reporting rsp seq: 8 0x000D6F00XXXXXXXX for ep: 0x01 cluster: 0x0001 attr: 0x0021 status: 0x86

0x86 mean error.

[olicooper]

~Yeah the button also has alarm mask attribute which makes sense why there is no button handler for 0x0021~

[Smanar]

Ok so there is another problem ^^, it's attribute 0x0020 not 0x0021.

Edit:
Do you see something in code about binding or reporting on attribute 0x0021 ? Because I m looking the code and all is with 0x0020.

[olicooper]

Sorry, I didn't mean to say 0x0021 (I don't think it has battery percentage attribute?)...
I took a picture of the power cluster output 0x0001 so you can see what I see on deCONZ.

The button reports battery level on cluster 0x0001 ep 0x0020 but it also has an alarm mask on ep 0x0035 and cluster 0x0000 ep 0x0013 too.

As you have said before, I think reporting on 0x0020 is working because:

17:10:16:365 MyDebug apsdeDataIndication profileId:0x0104, cid:0x0001
17:10:16:365 ZCL configure reporting rsp seq: 46 0x000D6F00XXXXXXXX for ep: 0x01 cluster: 0x0001 attr: 0x0020 status: 0x00

I've also seen these:

17:11:45:234 MyDebug DeviceAnnce 3 sSenSt:1, apsCtrl:1
17:11:45:234 FP indication 0x0000 / 0x0013 (0x000D6F00XXXXXXXX / 0x9028)
17:11:45:234 ... (0x000D6F00XXXXXXXX / 0x9028)

Update:
In my previous tests I could get the battery stats to appear if I manually read the data on the power cluster. I decided to enabled forced reading of the battery stats as a test and it seems to work! Do you think this fix is correct - I'm not sure about read frequency? https://github.com/olicooper/deconz-rest-plugin/commit/0bec4e049c0bdd2d00aeddf29a11d313298a316c

I wonder if the read problems are because we don't push the sensor fingerprint in bindings.cpp? srcEndpoints.push_back(sensor->fingerPrint().endpoint)... see this part in de_web_plugin.cpp

These are the logs:

11:19:26:228 MyDebug 40 SensorNode 2 / Switch 2 <-- new debug added
11:19:26:228 SensorNode 2: Switch 2 added
11:19:26:228 0x000D6F00XXXXXXXX (Lightify Switch Mini) create binding for attribute reporting of cluster 0x0001 on endpoint 0x01
11:19:26:228 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0001
11:19:26:229 Update Sensor 0x000D6F00XXXXXXXX Basic Cluster
11:19:26:229 MyDebug apsdeDataIndication profileId:0x0104, cid:0x0000

One last thing.. The middle button event seems to take longer to appear/update on the API than the other two buttons. Do you know why that might be? I disabled the 'suprise' button mapping to test but it didn't make it any quicker.

[olicooper]

We might be close to having these devices supported in the API (not Phoscon yet) 🤞 ..
Related: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/294 | https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1893 | https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2082

[Smanar]

No you are right, and I have checked on other project it s 0x20 for sure.

We don't make

srcEndpoints.push_back(sensor->fingerPrint().endpoint

But we make

 srcEndpoints.push_back(0x01);
  srcEndpoints.push_back(0x02);
  srcEndpoints.push_back(0x03);

so at final it's same.

For me the problem can come from
1 - A bad setting when configuring reporting

            rq.attributeId = 0x0020;   // battery voltage
            rq.minInterval = 3600;
            rq.maxInterval = 3600;
            rq.reportableChange8bit = 0;

you can try other values, on z2m they are using 300, 3600, 0. (reportableChange8bit = 0xFF for disabled)

2 - Or just the device don' use reporting but the pooling cluster, I have exactly same problem for legrand switch, it's the code you are using ^^

But this code work for legrand because this device make a device announce every time you press the button, not sure osram do same. With this code it's possible the value will be updated only 1 time.
And the reporting is working on z2M, so I realy don't see why It don't work.

For the middle button, have you take a look on log in same time, to see wich one action is delayed ? Its perhaps normal and coming from the hardware ?

[olicooper]

Right, I messed around with the reporting attributes and can't explain why changing intervals sorted it, but I configured rq.minInterval = 900 and 15 minutes later I got a status update as expected.

12:22:15:637 Node data 0x000D6F00XXXXXXXX profileId: 0x0104, clusterId: 0x0001
12:22:15:637 0x000D6F00XXXXXXXX: update ZCL value 0x01/0x0001/0x0020 after 0 s
12:22:15:637 MyDebug apsdeDataIndication profileId:0x0104, cid:0x0001
12:22:15:637 MyDebug 1
12:22:15:637 MyDebug 2
12:22:15:637 MyDebug ZCL attribute report 0x000D6F00XXXXXXXX for cluster: 0x0001, ep: 0x01, frame control: 0x18, mfcode: 0x0000
12:22:15:637    MyDebug payload: 2000201c
12:22:15:637 MyDebug 3
12:22:15:637 MyDebug 5.3 mode: 1 ep: 0x01 cluster: 0x0001 cmd: 0x0A sPrevD: 0xFF
12:22:15:637 Force binding of attribute reporting for sensor Lightify Switch Mini
12:22:15:637 MyDebug 11
12:22:15:637 MyDebug 12
12:22:15:637 MyDebug 13 srcEndpointSize: 3, gidSize: 3
12:22:15:637 MyDebug 14 gid: 1

Maybe making the min interval shorter means we get a report before the device goes in to deep sleep? I'm not convinced it is fixed so I'm going to test again to ensure it wasn't accidental etc.

What do you think is in this payload? MyDebug payload: 2000201c It must be some battery related statistics right?

Update:
From the related links below people have had batteries draining quickly from the min interval set at 300 so I'm going to increase it again and see if it still works okay, then call it a day probably cus this has dragged on for a long while now! 🤣

Related links:

• https://github.com/Koenkk/zigbee2mqtt/issues/532
• https://community.smartthings.com/t/release-osram-lightify-switch-mini/115412/20

[Smanar]

Ha, you have cleaned the code ?
I don't find your "MyDebug payload: 2000201c" ? But I have checked the code and no, I think the part you have find this code is realy just for attribute reporting command, there is no values inside.

[olicooper]

I've started a pull request...
https://github.com/dresden-elektronik/deconz-rest-plugin/pull/2917

I had to create a new fork because the master branch was a mess and GitHub still don't allow multiple forks... my old forked-repo is still there as a mirror though.

I'm currently testing that pull request so should be done soon. I can create another PR if there are bugs found but I don't think there are. Let me know if there is anything wrong etc. and I'll fix it 👍

Ideally I would have the double press working too but its probably not going to be easy so I think its better if this is added later too.

[Smanar]

Yep, it s better ^^, because so much tries.

I think it will be ok for the 3 buttons remote.
But not sure for the 4 buttons, this device have 6 endpoints.

And I think it can be usefull to bind only the usefull cluster for exemple only the 0008 and 0006 or only the 0300. Because without that it can make 3 * 6 = 18 binds.

But you are right, even not perfect, the PR will be usefull, at least for some returns.

[olicooper]

I had a look at the binds for the 4 button and one of them is on the comissioning cluster 0x1000 which we disabled so I think it's 5 binds total, but I can't see how there are more than 4 endpoints when there is only 4 buttons? I was looking at this: https://pastebin.com/xdG3Mw0Z

And I think it can be usefull to bind only the usefull cluster

Yes, I think it would be better. zigbee2mqtt has this: https://github.com/Koenkk/zigbee-herdsman-converters/commit/7756df8ccb314c9c52c89b0640107573f1aa9bdc#diff-6c9a6acf22f90d1c6e524d9f3c5c1745R1347-R1353 Not sure how you do this though.

Also, the battery updates are working 👍

[Smanar]

IDK, perhaps they are not usefull, and I don't find the device on other project.
Better to wait for a beta tester with return, than spend time for nothing. Your code is enought for that, just need to wait for some logs.

And you are right, hard to that with the actual code, If I have time tommorow, I will try to make something without too much ugly hacks.

Happy for battery, because I haven't more idea for it :)

[olicooper]

I'm considering making the battery updates every 43200 seconds (12 hours) because the battery is only a CR2450 so 1 update every hour is going to drain the battery still. How can we make a manual request to fetch the battery voltage when the deice first pairs with the gateway? Would I be okay adding this back in? https://github.com/olicooper/deconz-rest-plugin-old/commit/1e05921289432c63b589c83203fdad085082a235#diff-c941fc017347f7109bf6036ba9505576L5666-L5677

[Smanar]

I m agree with you, make it every hour is useless.
But the notification can be used as "device life check", so it can have some reaction on deconz, just make test and choose the prefered one.

If you make code change on the branch you have make the PR, the modification will be used too on this github.

But I realy don't think it's something usefull, there is no devices that use that, because you just need some time to have the value, the device make lot of requests during inclusion, better to remove the useless one.

[Smanar]

BTW, I have started something.

Not sure it will be usefull, so it's just a prototype https://github.com/Smanar/deconz-rest-plugin/commit/8986adfec2cd03a863bc39bfacefa4dd5691548c

Not compiled/ Not tested, so don't spend too much time on it.

But with this code, you can choose the endpoint, the group and the cluster like in Z2M, and it s compatible with old code.

The return will be "false" so I think you will have an error message but the binding will work.
To cheat, you can use "ret = true;" juste after the fonction list.

[olicooper]

I have tested your prototype code and its working. There were a few compile issues and I updated it a bit too so check out my latest commit for the changes. https://github.com/olicooper/deconz-rest-plugin-old/commit/c5253434e774119ccf46800eb4be1a569bdbcea3

The first cluster binding task starts at 19:08:51:349 and the last one is at 19:09:29:396 which is around 30 seconds to completion.

This is the first binding task:

19:08:51:346 0x000D6F00XXXXXXXX (Lightify Switch Mini) create binding for attribute reporting of cluster 0x0001 on endpoint 0x01
19:08:51:346 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0001
...
19:08:51:349 0x000D6F00XXXXXXXX [Lightify Switch Mini] create binding (S) for client cluster 0x0006 on endpoint 0x01
19:08:51:349 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0006
19:08:51:349 0x000D6F00XXXXXXXX [Lightify Switch Mini] create binding (S) for client cluster 0x0008 on endpoint 0x01
19:08:51:349 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0008
19:08:51:349 0x000D6F00XXXXXXXX [Lightify Switch Mini] create binding (S) for client cluster 0x0006 on endpoint 0x02
19:08:51:349 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0006
19:08:51:349 0x000D6F00XXXXXXXX [Lightify Switch Mini] create binding (S) for client cluster 0x0008 on endpoint 0x02
19:08:51:349 queue binding task for 0x000D6F00XXXXXXXX, cluster 0x0008
19:08:51:349 0x000D6F00XXXXXXXX [Lightify Switch Mini] create binding (S) for client cluster 0x0300 on endpoint 0x03
19:08:51:349 queue binding task for 0x000D6F00XXXXXXXX , cluster 0x0300

Still no broadcasting with this new code and all bindings are still present so this solution will work 👍

checkSensorBindingsForClientClusters is called from a lot of places which makes it harder to modify. I don't think these changes should be part of the PR but it is a good thing to add in!

[Smanar]

I have already do an update since, but the last is not tested ^^.
With the next one if you don't set group, the binding will be done on the coordinator.
https://github.com/Smanar/deconz-rest-plugin/blob/osram/bindings.cpp

But on bad branch, will correct tommorow

And In my mind, I prefer remove the "return ret" on line 2576 (and all the code before. Like this the code can be compatible for old and new binding mode.

If you are using the new one srcEndpoints.size() will be = 0, so so all the "if loop" will be skipped and the code will continue normally at line 2768.
So futures modifications on code will be used too.

But like you idk if theses changes can be used in your PR, for me it's usefull for some other device, we realy miss a simple bind fonction.
It's not usefull for the 3 buttons, but perhaps for the 4 buttons, with it you can reduce the bind requests.

And I have set only the last bind able to change the ret value, it will work like before the modification, and I m not sure it will be usefull to check all command, it s just a binding list, if 1 succed, all other will do same.

[olicooper]

So futures modifications on code will be used too.

Yes that's a good point, I will use your code for the next version. The reason I copied the code was to be 100% sure it wasn't going to execute anything else for the test. I knew it probably wouldn't though 😊

But like you idk if theses changes can be used in your PR, for me it's usefull for some other device, we realy miss a simple bind fonction.

I think we need to ask the main developers about it maybe? I would probably submit another PR with this added function, then update the code later on to use this so that it is all kept clean and separate. Maybe this won't work for the development of that other device you are working on though? It would be nice to speak directly with the main devs though, maybe they will add it straight in without a PR?

Happy to test it soon. Good work!

[Smanar]

Don't worry for that, my modification don't impact the rest of the deconz code.
For me it will depend on osram 4 button device, this code is not realy usefull for the 3 buttons, but if you need it for the 4 button, you can take it.

In the worst sistuation it's your device that will not work, no impact for others devices.

And the code just take 10/20 lines.

And PR take somes days to be validated, so hard to wait beetween 2 of them, it's for that you can see some PR used for 5/6devices or more.

[olicooper]

Hi Smanar, I noticed one small issue when I bound a light to the button in the old UI, the center (0) button sets the color back to default but it doesn't make the light go to 100% like it should. I've added some new code to bind one of the missing button handlers and it works again but could you double check that this implementation is okay? https://github.com/olicooper/deconz-rest-plugin-old/commit/7d2c24b736b65eea0995ba502b6324bad7e24c4e
Thanks 👍

[Smanar]

Lol, don't worry, I trust you, you know the code for this device as good than me, and you have the device to make test and not me.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[NicolasBoulanger]

Thanks for your hard work ! 🎉

[7wells]

Hello,

I have switched from the not-anymore-supported Osram Lightify gateway to Phoscon on Raspberry Pi 2 with RaspBee II from Dresden-Elektronik. As I was able to pair the grey and blue Osram SMART+ Switch Mini (AC0251 600NJ | x 1718 and AC0251 700NJ | x 1718), I thought I could put them to use as well. They appear (besides a normal-sized Osram SMART+ Switch) in Phoscon under switches. However, when I try to connect them in a group, they are not offered, i.e. do not appear in that selection screen at all; only the normal-sized switch is there. So it seems that Phoscon adds them as switches but cannot use them in groups to apply them to certain lights/plugs etc. for whatever reason.

Now do these mini switches work for you in Phoscon? How can you apply them to existing groups?

I have no experience yet with deconz and logs etc., so I do not yet know how I can provide some logs, but I am willing to learn. :)

Thanks for your kind help and hints!

[Smanar]

Hi, I don't think phoscon support thoses switches, for me the better is using third application.

[7wells]

What is so different with the mini switch in comparison to the normal-sized switch?

If logs or sniffed traffic of the mini switch helps, I could try to provide such, but would need a little help how to accomplish this. I think that I have everything that is needed, except the knowledge how to start. ;)

[Smanar]

The problem is the API have nothing to see with phoscon.
Phoscon use the api like third app, Try to ask here https://github.com/dresden-elektronik/phoscon-app-beta

If your device is the 3 button device, this one use native zigbee command, so you can use group feature in the "old web app", it will be direct connexion, without using deconz/phoscon/API.

But I don't remember what will be the 3 used command with this remote (and you will be not able to change them)

[7wells]

Thank you so much, I will look there. It is indeed the 3 buttons switch (available in different rubber colours). And I just now realise that my comments might be off-topic here, sorry.