Support for Innr Remote RC 110?

[jo-me]

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

[ebaauw]

Is the RC 110 supported by deconz?

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.

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.

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 buttonevent values 1002, 2002, 3002, 4002, 5002, 6002, 7002, 8002, and 9002). You would be able to specify custom actions using deCONZ rules.

[l-mb]

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 ;-)

[kasteleman]

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> .

[l-mb]

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.

[kasteleman]

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>.

[l-mb]

Don’t know about the coding part. You can’t put it in a group like a HUE Dimmer for example?

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.

[ebaauw]

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 config.group of the corresponding ZHASwitch resource?

[ebaauw]

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 buttonevent div 1000 still indicates the button, and buttonevent mod 1000 the action.

[ebaauw]

OK, I got the REST API to create a single ZHASensor resource and to generate the buttonevent when pressing a button:

{
  "config": {
    "group": "4102",
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "138fd8c4067c6132b1a7dab4f9c38967",
  "manufacturername": "innr",
  "mode": 1,
  "modelid": "RC 110",
  "name": "innr remote",
  "state": {
    "buttonevent": 27003,
    "lastupdated": "2018-09-29T20:48:39"
  },
  "swversion": "0x21000e46",
  "type": "ZHASwitch",
  "uniqueid": "00:15:8d:00:01:0c:44:37-01-0006"
}

I haven't yet figured out how to setup the bindings to the groups. Also config.group is overwritten with the group that is (manually) bound to the endpoint corresponding to the last button pressed:

{
  "config": {
    "group": "4097",
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "d867523eeb6bf9da8753f4acc06e8a57",
  "manufacturername": "innr",
  "mode": 1,
  "modelid": "RC 110",
  "name": "innr remote",
  "state": {
    "buttonevent": 10002,
    "lastupdated": "2018-09-29T20:49:39"
  },
  "swversion": "0x21000e46",
  "type": "ZHASwitch",
  "uniqueid": "00:15:8d:00:01:0c:44:37-01-0006"
}

[ebaauw]

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 /groups resources), add these to the remote's controller endpoints, and set config.groups to a list of these seven groups. I'm not sure if Phoscon can handle that, @manup - maybe it would be better to use seven ZHASwitch resources (each with only one group)?

[ebaauw]

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 config.group containing a list of groups instead of a single one, so I changed to exposing the remote as seven ZHASwitch resources. After manually binding each endpoint's Level cluster to the corresponding group, the REST API plugin sets config.group and creates the corresponding group when receiving the command!

Here's the /sensors resources:

  "9": {
    "config": {
      "group": "4096",
      "on": true,
      "reachable": true
    },
    "ep": 1,
    "etag": "038a8aa3aa9a4a5ebba740e6e907d1da",
    "manufacturername": "innr",
    "mode": 1,
    "modelid": "RC 110",
    "name": "RC 110 9",
    "state": {
      "buttonevent": 1002,
      "lastupdated": "2018-09-29T23:35:52"
    },
    "swversion": "20161014",
    "type": "ZHASwitch",
    "uniqueid": "00:15:8d:00:01:0c:44:37-01-0006"
  },
  "10": {
    "config": {
      "group": "4097",
      "on": true,
      "reachable": true
    },
    "ep": 3,
    "etag": "038a8aa3aa9a4a5ebba740e6e907d1da",
    "manufacturername": "innr",
    "mode": 1,
    "modelid": "RC 110",
    "name": "RC 110 10",
    "state": {
      "buttonevent": 3002,
      "lastupdated": "2018-09-29T23:33:37"
    },
    "swversion": "20161014",
    "type": "ZHASwitch",
    "uniqueid": "00:15:8d:00:01:0c:44:37-03-0006"
  },
  "11": {
    "config": {
      "group": "4098",
      "on": true,
      "reachable": true
    },
    "ep": 4,
    "etag": "038a8aa3aa9a4a5ebba740e6e907d1da",
    "manufacturername": "innr",
    "mode": 1,
    "modelid": "RC 110",
    "name": "RC 110 11",
    "state": {
      "buttonevent": 3003,
      "lastupdated": "2018-09-29T23:33:50"
    },
    "swversion": "20161014",
    "type": "ZHASwitch",
    "uniqueid": "00:15:8d:00:01:0c:44:37-04-0006"
  },
  "12": {
    "config": {
      "group": "4099",
      "on": true,
      "reachable": true
    },
    "ep": 5,
    "etag": "038a8aa3aa9a4a5ebba740e6e907d1da",
    "manufacturername": "innr",
    "mode": 1,
    "modelid": "RC 110",
    "name": "RC 110 12",
    "state": {
      "buttonevent": 2003,
      "lastupdated": "2018-09-29T23:34:34"
    },
    "swversion": "20161014",
    "type": "ZHASwitch",
    "uniqueid": "00:15:8d:00:01:0c:44:37-05-0006"
  },
  "13": {
    "config": {
      "group": "4100",
      "on": true,
      "reachable": true
    },
    "ep": 6,
    "etag": "038a8aa3aa9a4a5ebba740e6e907d1da",
    "manufacturername": "innr",
    "mode": 1,
    "modelid": "RC 110",
    "name": "RC 110 13",
    "state": {
      "buttonevent": 1002,
      "lastupdated": "2018-09-29T23:34:49"
    },
    "swversion": "20161014",
    "type": "ZHASwitch",
    "uniqueid": "00:15:8d:00:01:0c:44:37-06-0006"
  },
  "14": {
    "config": {
      "group": "4101",
      "on": true,
      "reachable": true
    },
    "ep": 7,
    "etag": "038a8aa3aa9a4a5ebba740e6e907d1da",
    "manufacturername": "innr",
    "mode": 1,
    "modelid": "RC 110",
    "name": "RC 110 14",
    "state": {
      "buttonevent": 1002,
      "lastupdated": "2018-09-29T23:34:51"
    },
    "swversion": "20161014",
    "type": "ZHASwitch",
    "uniqueid": "00:15:8d:00:01:0c:44:37-07-0006"
  },
  "15": {
    "config": {
      "group": "4102",
      "on": true,
      "reachable": true
    },
    "ep": 8,
    "etag": "038a8aa3aa9a4a5ebba740e6e907d1da",
    "manufacturername": "innr",
    "mode": 1,
    "modelid": "RC 110",
    "name": "RC 110 15",
    "state": {
      "buttonevent": 1002,
      "lastupdated": "2018-09-29T23:34:52"
    },
    "swversion": "20161014",
    "type": "ZHASwitch",
    "uniqueid": "00:15:8d:00:01:0c:44:37-08-0006"
  }

and here's the corresponding /groups resources:

  "4096": {
    "action": {
      "bri": 127,
      "colormode": "hs",
      "ct": 0,
      "effect": "none",
      "hue": 0,
      "on": false,
      "sat": 127,
      "scene": null,
      "xy": [
        0,
        0
      ]
    },
    "class": "Other",
    "devicemembership": [
      "9"
    ],
    "etag": "038a8aa3aa9a4a5ebba740e6e907d1da",
    "hidden": false,
    "id": "4096",
    "lights": [],
    "lightsequence": [],
    "multideviceids": [],
    "name": "RC 110 9",
    "scenes": [],
    "state": {
      "all_on": false,
      "any_on": false
    },
    "type": "LightGroup"
  },
  "4097": {
    "action": {
      "bri": 127,
      "colormode": "hs",
      "ct": 0,
      "effect": "none",
      "hue": 0,
      "on": false,
      "sat": 127,
      "scene": null,
      "xy": [
        0,
        0
      ]
    },
    "class": "Other",
    "devicemembership": [
      "10"
    ],
    "etag": "038a8aa3aa9a4a5ebba740e6e907d1da",
    "hidden": false,
    "id": "4097",
    "lights": [],
    "lightsequence": [],
    "multideviceids": [],
    "name": "RC 110 10",
    "scenes": [],
    "state": {
      "all_on": false,
      "any_on": false
    },
    "type": "LightGroup"
  },
  "4098": {
    "action": {
      "bri": 127,
      "colormode": "hs",
      "ct": 0,
      "effect": "none",
      "hue": 0,
      "on": false,
      "sat": 127,
      "scene": null,
      "xy": [
        0,
        0
      ]
    },
    "class": "Other",
    "devicemembership": [
      "11"
    ],
    "etag": "038a8aa3aa9a4a5ebba740e6e907d1da",
    "hidden": false,
    "id": "4098",
    "lights": [],
    "lightsequence": [],
    "multideviceids": [],
    "name": "RC 110 11",
    "scenes": [],
    "state": {
      "all_on": false,
      "any_on": false
    },
    "type": "LightGroup"
  },
  "4099": {
    "action": {
      "bri": 127,
      "colormode": "hs",
      "ct": 0,
      "effect": "none",
      "hue": 0,
      "on": false,
      "sat": 127,
      "scene": null,
      "xy": [
        0,
        0
      ]
    },
    "class": "Other",
    "devicemembership": [
      "12"
    ],
    "etag": "038a8aa3aa9a4a5ebba740e6e907d1da",
    "hidden": false,
    "id": "4099",
    "lights": [],
    "lightsequence": [],
    "multideviceids": [],
    "name": "RC 110 12",
    "scenes": [],
    "state": {
      "all_on": false,
      "any_on": false
    },
    "type": "LightGroup"
  },
  "4100": {
    "action": {
      "bri": 127,
      "colormode": "hs",
      "ct": 0,
      "effect": "none",
      "hue": 0,
      "on": false,
      "sat": 127,
      "scene": null,
      "xy": [
        0,
        0
      ]
    },
    "class": "Other",
    "devicemembership": [
      "13"
    ],
    "etag": "038a8aa3aa9a4a5ebba740e6e907d1da",
    "hidden": false,
    "id": "4100",
    "lights": [],
    "lightsequence": [],
    "multideviceids": [],
    "name": "RC 110 13",
    "scenes": [],
    "state": {
      "all_on": false,
      "any_on": false
    },
    "type": "LightGroup"
  },
  "4101": {
    "action": {
      "bri": 127,
      "colormode": "hs",
      "ct": 0,
      "effect": "none",
      "hue": 0,
      "on": false,
      "sat": 127,
      "scene": null,
      "xy": [
        0,
        0
      ]
    },
    "class": "Other",
    "devicemembership": [
      "14"
    ],
    "etag": "038a8aa3aa9a4a5ebba740e6e907d1da",
    "hidden": false,
    "id": "4101",
    "lights": [],
    "lightsequence": [],
    "multideviceids": [],
    "name": "RC 110 14",
    "scenes": [],
    "state": {
      "all_on": false,
      "any_on": false
    },
    "type": "LightGroup"
  },
  "4102": {
    "action": {
      "bri": 127,
      "colormode": "hs",
      "ct": 0,
      "effect": "none",
      "hue": 0,
      "on": false,
      "sat": 127,
      "scene": null,
      "xy": [
        0,
        0
      ]
    },
    "class": "Other",
    "devicemembership": [
      "15"
    ],
    "etag": "038a8aa3aa9a4a5ebba740e6e907d1da",
    "hidden": false,
    "id": "4102",
    "lights": [],
    "lightsequence": [],
    "multideviceids": [],
    "name": "RC 110 15",
    "scenes": [],
    "state": {
      "all_on": false,
      "any_on": false
    },
    "type": "LightGroup"
  }

[manup]

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.

[ebaauw]

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.

Sounds familiar - I did the same in homebridge-hue.

For the ubisys C4 which also can control 4 groups the implementation is different, I think config.group contains a string list (?) — which should better be a json array.

Yeah, I saw config.json for my ubisys D1 contains two group IDs separated by a comma:

{
  "config": {
    "group": "230,240",
    "mode": "momentary",
    "on": true,
    "reachable": true
  },
  "ep": 2,
  "etag": "889ac780dcf77135f497dfeecb13702a",
  "manufacturername": "ubisys",
  "mode": 1,
  "modelid": "D1 (5503)",
  "name": "Dining Room Table",
  "state": {
    "buttonevent": 2002,
    "lastupdated": "2018-09-21T22:36:40"
  },
  "swversion": "20171108-DE-FB0",
  "type": "ZHASwitch",
  "uniqueid": "00:1f:ee:00:00:00:19:63-02-0006"
}

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 config.group value. Also, the REST API only create/removes the groups automatically, when config.group contains a single group ID. I commented out the code for the list of group IDs, so it will be easy to change that.

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 config.group by hacking the database or if the REST API set it automatically. There's still something missing, though, the devicemembership of these groups is empty.

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 config.group updatable through the REST API, for an easier way to maintain the bindings. For the battery-powered RC 110, we probably need to use config.pending. This logic will become very complicated if config.group is a list of group IDs (or a JSON array of group IDs).