@de_employees this really is a shame.
Sorry @tompijls , we had so much devices to integrate at least that our integration programmers have barely kept up. Thatās why some of the equipment has been left behind.
I asked again, sry for that delay.
Hi everybody, sorry it has been a while. After many tests and discussions later the problem is a bit unique and turned out a rabbit hole, this switch is a Sunricher also rebranded by SLC, Namron and ROBB.
Details
With latest deCONZ version the switch and button events are working correctly in the REST-API, it also uses proper unique groups instead broadcasting to all lights which was a problem in the initial post.
The Phoscon App switch editor shows all buttons for configuration generically based on the data in button_maps.json, which is good so farā¦
However the generated rules for the rows 2-4 point to the wrong sensor. The switch could have been implemented as one sensor covering all buttons, but has instead four sensors one for each row, and here the generic approach breaks.
Although it would be simple to combine all sensors into one with a small code change, this would break existing setups which only use the REST-API but not Phoscon Appā¦
Fix
I have extended the button maps handling to provide a bit of extra information in PR Button maps support specify endpoint for buttons by manup Ā· Pull Request #5901 Ā· dresden-elektronik/deconz-rest-plugin Ā· GitHub and adapted the Phoscon App.
With the next version the button assignments for rows 2-4 need to be re-created in the Phoscon App Switch Editor but should work afterwards.
@manup Replied on the respective DDF PR as well. Youāre currently making wrong assumptions on the model Identifier to expose the button row correctly in Phoscon. Also, our beloved binding to group 0xFFF0 plays a role here.
Like said, I got the device and it works perfectly (if you know how to dance around the annoyances of binding tp the ALL group) 