Support for Innr Remote RC 110? #635
Comments
Not yet, but I'll be happy to give it a go, if some-one can lend me one. I do have an innr gateway and some innr lights (and the new innr SP 120 smart plugs!), so I would be able to sniff standalone mode as well as bridge mode.
Looking at the manual, it doesn't seem they are. See also the quick start. I doubt we'll be able to use the numbered buttons in the "Lights" setting, but probably, they would be usable in the "Scenes" setting. I expect that, effectively, this will be a 9-button switch (On, DImUp, DimDown, 1, 2, 3, 4, 5, 6) with each button only supporting Release (so |
|
Has anyone made progress on this one? It's a relatively cheap ZigBee remote with plenty buttons, so it'd be very desirable. (I'd be mostly interested in using the button events via Home Assistant.) It also seems to support continuous press, so maybe we can get button held and long release too? (I'm not incapable of programming low-level bits, but I've never worked with ZigBee on the protocol level. If somebody has pointers to docs I'd be grateful. Or if somebody felt like writing a patch + a few notes on how that all works, I'd be delighted to send someone a remote in exchange ;-) |
|
Not yet. Did not yet include it. But hope to find Some time for it soon. Do
you own the device and tried to include it?
Op wo 19 sep. 2018 om 23:49 schreef Lars Marowsky-Brée <
notifications@github.com>
… Has anyone made progress on this one? It's a relatively cheap ZigBee
remote with plenty buttons, so it'd be very desirable. (I'd be mostly
interested in using the button events via Home Assistant.) It also seems to
support continuous press, so maybe we can get button held and long release
too?
(I'm not incapable of programming low-level bits, but I've never worked
with ZigBee on the protocol level. If somebody has pointers to docs I'd be
grateful. Or if somebody felt like writing a patch + a few notes on how
that all works, I'd be delighted to send someone a remote in exchange ;-)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#635 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFpiKIxBqT0m9EPtbTwZBF_wvTWgpJATks5ucrvmgaJpZM4UhcN8>
.
|
Yes, I own one of them. It added itself fine to the ZigBee network and I can see it deCONZ's UI, but I would need a bit of help on getting started on how to add support to the code and export the events through the REST API. |
|
Don’t know about the coding part.
You can’t put it in a group like a HUE Dimmer for example?
… On 20 Sep 2018, at 10:34, Lars Marowsky-Brée ***@***.***> wrote:
Not yet. Did not yet include it. But hope to find Some time for it soon. Do you own the device and tried to include it?
Yes, I own one of them. It added itself fine to the ZigBee network and I can see it deCONZ's UI, but I would need a bit of help on getting started on how to add support to the code and export the events through the REST API.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFpiKALeSjHTA7ZPH-lMF4F4tFRDJTcRks5uc1MVgaJpZM4UhcN8>.
|
Since the remote doesn't show up in the web app, no. I can see it in the network graph only. Phoscon doesn't realize this is a remote switch so it doesn't expose the device. |
|
The innr remote is on sale at one of my local webshops, so I got me one, for the price of a Xiaomi! Paired it to my test network (hold the Program and - buttons for five seconds, until the light blinks five times): When the Scenes/Lights switch on the remote is in the Scenes position, the remote sends broadcast (!) commands from endpoint 0x01. When binding the OnOff cluster on endpoint 0x01 to a group, the switch sends groupcast commands instead. When pressing the On/Off button, the remote alternates between sending OnOff commands On and On with Recall Global Scene versus Off and Off with Effect (so two commands per press). The remote seems to remember the On/Off state! There's no commands on hold, nor on release. [Note Edited to use the command names instead of 0x41 and 0x42. Wireshark doesn't know these, but they're described in the ZCL spec.] When pressing/releasing the - or + button, the remote sends Level command Step, with Step Mode: Down (for -) or Up (for +), Step Size: 2, and Transition Time: 0xffff. When holding one of these buttons, the remote sends Move, with Step Mode: Down or Up, and Rate: 100. On release, the remote sends Stop. When pressing one of the numbered buttons 1 to 6, the remote sends Move to Level (with OnOff), where Level depends on the button: 2, 52, 102, 153, 194, or 254, for buttons 1 to 6 respectively. When the remote's switch is in the Lights position, it doesn't send any command on the number buttons. Instead, it remembers the button last pressed, and uses the (group) binding of the Level cluster of the corresponding endpoint as destination for the OnOff, -, and + buttons. So when binding 0x03 to group 0x1001, 0x04 to group 0x1002, after pressing 1, the OnOff, -, and + buttons send commands to group 0x1001 from endpoint 0x03; after pressing 2, the commands are sent to group 0x1002 from endpoint 0x04. The remote remembers the OnOff state separately for each endpoint. As far as I can tell so quickly, the Program and associated < and > buttons don't send any ZigBee commands (at least, when the switch has joined a network). Supporting the remote in the deCONZ REST API is going to be interesting. For the Scenes setting, it's indeed simply a 9-button switch. Typically this would be exposed as a single ZHASwitch resource (for endpoint 0x01) with buttonevents 1002 (On/Off); 2001, 2002, 2003 (-); 3001, 3002, 3003 (+); 4002 (1); 5002 (2); 6002 (3); 7002 (4); 8002 (5); and _9002 (6); We could change the order, so 1002, ..., 6002, would match the numbered buttons 1, ..., 6, but see below. For the Lights setting, it's probably easiest to expose an additional ZHASwitch resource per endpoint, with buttonevents 1002 (On/Off); 2001, 2002, 2003 (-); 3001, 3002, 3003 (+). This is why we don't want to change the order for the ZHASwitch resource on endpoint 0x01. In HomeKit, this would become a single accessory with 27 buttons! For the REST API, it would be enough to simply bind all 7 endpoints to the same group - the source endpoint can be used to determine the appropriate resource. For using the remote in dual mode (through the gateway and standalone, controlling the lights in a group directly), it would make sense to use a different group for each endpoint. @manup, I need your help here: where to get the group IDs? I suppose they need to be stored in |
|
Some more insights. The remotes sees the On/Off state for endpoint 0x01 as the combined state of the other endpoints. I.e. when setting endpoint 0x01 off, the remote assumes the groups for endpoints 0x03, ..., 0x08 are off as well. Same for setting 0x01 on. With the switch set to Lights, the remote forgets the number button pressed after some time - the next commands are sent from endpoint 0x01 and to the corresponding group. I've been thinking about exposing seven different ZHASwitch resources. While straightforward, it seems overkill. Alternatively, we could just continue to number the buttonevents using a single ZHASwitch resource. So 10002 (On/Off for 1); 11001, 11002, 11003 (- for 1); 12001, 12002, 12003 (+ for 1); 13002 (On/Off for 2); ...; 27001, 27002, 27003 (+ for 6). Not only fewer resources; it would also be easier on homebridge-hue and, I suppose, on plugins for other home automation platforms. I would like the buttonevents to have a continuous range in the 1000s, so |
|
OK, I got the REST API to create a single ZHASensor resource and to generate the buttonevent when pressing a button: I haven't yet figured out how to setup the bindings to the groups. Also |
|
Some more playing around. The remote returns a default response with status Software Failure (0xc1) when trying to get the groups or endpoints from the ZLL Commissioning cluster. However, each controller endpoint has a server Groups cluster, with the capacity of just one group. When adding a group to that endpoint, the corresponding commands will be sent to that group. No need to create a binding in that case. So it might be enough to create seven groups (or rather |
|
Even some more playing around. The trick with adding the group only seems to work for endpoint 0x01. For the other endpoints, a binding is required. The REST API plugin chokes on Here's the and here's the corresponding |
|
Reminds me of the Busch-Jaeger switches, these have up to 4 separated ZHASwitch resources where each can control a group. I have to admit the multiple ZHASwitch resources approach for a single physical switch is very cumbersome to handle in gui applications or any client in general, in the Phoscon App we've added a switches layer for that purpose just to combine the sensors of one device into a single switch resource or model, which it should be in first place. For the ubisys C4 whch also can control 4 groups the implementation is different, I think config.group contains a string list (?) — which should better be a json array. Not perfect either but easier to handle for the REST-API clients. |
Sounds familiar - I did the same in homebridge-hue.
Yeah, I saw So I implemented the same for the RC 110 (with a list of seven group IDs), but then errors messages appeared in the deCONZ log about an invalid If memory serves, I manually created the bindings to the groups for OnOff and Level clusters in the Dimmer Switch endpoints 0x02 and 0x03 of the ubisys D1. I don't remember if I set I cannot seem find any code in the REST API plugin that maintains the bindings, though. Does Phoscon maintain the bindings for the C4? If so, using what REST calls? I've been thinking about making |
|
Fixed the
Added support in homebridge-hue. |
|
Thanks for your very verbose comments! For what it is worth, this is really enlightening to understand how to modify the code and how to go about adding new switches/devices of my own going forward, hopefully. |
|
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. |
|
Still need to create and assign groups on pairing. Also, still need to combine the resources into one with |
|
Yes we have several of these remotes now which control multiple groups. innr, Paulmann, Paul Neuhaus and Müller Licht. It's a tricky problem, even simple remote with just one group are hard to maintain since the group ids might change for various reasons. |
|
ubisys |
|
So, I've just paired my RC110 with deconz Version 2.05.60 w/firmware 26320500 by adding a new "Other" switch.. What happened is that the paring apparently worked, but Phoscon did not show any indication of that. The API had several (!?) RC 110 listed under sensors. one of them showed updated timestamps when pressing the 1-6 buttons. The power button of the remote now turns on/off EVERY light in deconz.. @manup can you estimate when the remote will be properly supported? And properly configurable via Phoscon? Thanks |
|
So, Then in the GUI I dragged the on/off entry of the first table to the source field. When I enter a random group name it won't let me bind because the button remains disabled. What groups is this thing looking for? Here is a screenshot: There is a add/remove group at the top of the left panel. Do I have to create soemting there? |
|
You need to enter the id (in hex) of the ZigBee group. Note that a ZigBee group is more like a multicast address than a physical object. “Adding” a group is telling a light to listen the corresponding address. Binding a switch to a group is telling the switch to send commands to that address (irrespective whether any light is actually listening). The REST API plugin polls each light for the groups it listens to, and creates the |
|
Thank you for getting back to me. I created a couple of empty groups with Phoscon, e.g. one that received the ID 9 (retrieved from REST API) I entered 0x0009 as bind destination and then executed it. It hang for a bit but after I woke the remote by pressing (-) it said success. I assigned the first three on/off things to my new groups. Shouldn't the first 3 buttons now turn the new groups on/off? |
|
You created a binding for endpoint 0x04, so that’s for button 2 when the switch is on the light setting. If the binding succeeds, the corresponding ZHASwitch resource’s It’s a while since I played with this, you might also need to bind the Level Control cluster. And Scenes on the first endpoint. |
|
Ok, so I added bindings to each on/off thing in the list to separate pre-created groups. When clicking through the buttons now I see that one For the rest nothing group related happened unfortunately and except for one other zhaswitch there were not even buttonevents registered. |
|
Shouldn't the number in the on/off cluster increase with each binding?
|
|
Here's what the REST api shows: |
|
The number in the cluster list shows the number of attributes, typically 0 for client clusters. Looks like the bindings didn’t succeed for the other endpoints. The remote is a deep sleeper, so the sequence of waking it and pressing bind is somewhat delicate. I don’t trust blindly the status reported by the GUI - always verify through If memory serves, the light on the remote should blink when it sends a command. If it doesn’t, it might help to remove and re-insert the batteries. And double-check the batteries. |
|
I removed the remote today along with all zwaswitches and even purged the deleted items from the DB. After re-pairing everythin was back to square one. So I started creating group bindings for the 6 light buttons again. I found that the config.group entry only appeared after binding the level control cluster of each endpoint. Binding the on/off cluster did not do anything visible. Is it still necessary behind the scenes? The only problem child is the scenes mode now. Thanks for your support! |
|
According to my notes above, #635 (comment), you need to bind the OnOff cluster on the first endpoint and the Level Control cluster on the other endpoints. |
|
Yeah, I tried that dozens of times now, but binding the onoff cluster just does not work for the first endpoint. (it also did not work for the other endpoints). Pressing "unbind" always reports "failed: no entry" so it is apparently not binding the cluster at all. Binding to the level control cluster for the other endpoints worked fine though.. Once I understood that only that is necessary to produce the group assignment I went through the 6 buttons in no time. Is there another trick involved? |
|
You might try and add the group to the first endpoint using the Groups cluster, see #635 (comment). |
|
Aah, binding with the previous way did not work for the groups cluster (there are 2 with the same name) so I used the editor fields on the first "Groups" cluster.
This finally worked. One open issue that I also had before all of this: What can this be? They do work in Lights mode, just not in Scenes mode.. |
|
Odd. Either a hardware failure (but they do select the right group in scenes mode?) or your remote is sending different commands than mine. Could you check if the Date Code and SW Build ID match my screenshot above? If the remote is sending something, there should be messages in the deCONZ log about no button map entry found, with the info needed to add them. |
|
Yes, in the log I see these messages for buttons 4,5,6: 13:37:32:203 no button handler for: RC 110 ep: 0x01 cl: 0x0008 cmd: 0x04 pl[0]: 0x99 What can I do with that now? Regarding Date code and SW Build id it looks like my remote has a newer software and a lot of empty fields in the basic cluster:
EDIT: after clicking "read" again, it filled up:
|
|
These are the same values as in the button map. I have no clue why they’re not matched (and moreover, why 1, 2, and 3 are matched). |
|
Above commit creates groups for all seven ZHASwitch resources and sets up the bindings for all but the first resource. Now (after re-pairing) all buttonevents should work, but the scenes commands work on all lights, rather on the group associated with the first ZHASwitch resource. The first 0x01 endpoint doesn't accept bindings. Instead, it needs a group assignment, i.e. an Add to group command to its Groups server (!) cluster. @manup, I'm not sure how to implement this. There is a task to add a lightnode to a group, but this is a sensornode. |
|
The remote sends hard-coded commands that cannot be changed. If you want to use the buttons differently, leave the groups empty and create deCONZ rules for the corresponding buttonevent values. |
|
Ok thanks for the answer on question on the way to delete the default behavior of the innr endpoints via deconz. Are all the remote controls using the same hardcoded values to trigger the on/off of all the endpoints? Meaning if I would buy another remote (non innr) would the on/off button trigger again the on/off for the innr endpoints? |
|
No, what commands each remote send is determined in their firmware. Typically, you can only change the group (through a binding). Professional grade remotes (like ubisys) can be configured, but those are a different price range. |
|
Is there a way to use the RC110 with the WebUI of deconz? |
|
To answer myself partially. Found some answers here: #1939 (comment) |
|
I am very sorry to post a little off topic here, but I am unable to find any way to contact @ebaauw or one of you other guys directly. Do anyone of you know about SmartThings Device Handlers, and are able to provide a device handler for this remote (RC 110)? |
Hi
just saw that Innr offers a Zibee Remote, the "RC 110" which apparently can control the new innr plugs either directly or indirectly (using a bridge).
See here: https://shop.innrlighting.com/en/shop/49/remote-control
Is the RC 110 supported by deconz?
This thing would be a good replacement for the old 443 mhz remotes and even more versatile that the available zigbee remotes - if the buttons/actions are customizable.
Thank you
The text was updated successfully, but these errors were encountered: