Hue wall switch module; LIDL Livarno Lux lights

[ebaauw]

• Support Hue wall switch module, see Hue wall switch module. #4566:
  • Add config.devicemode with possible values: "singlerocker", "singlepushbutton", "dualrocker", "dualpushbutton"; cf Hue API;
  • Enhance config.pending logic to handle updates of devicemode:
    • Change RConfigPending to DataTypeUInt16;
    • Clear pending on receiving the attribute report, instead of on queueing the Write Attributes;
    • Check whether end device is awake in writeAttribute().
  • Change logic for attribute reporting of Basic cluster for Hue devices;
  • Update general.xml with manufacturer-specific Device Mode attribute on Basic cluster;
• Don't expose unsupported state attributes hue, sat, and effect for LIDL Livarno Lux lights. See Issue on LIDL Livarno Lux light strip #4539 and Discord.
• Fix Hue dimmer (2021) being restored from database with wrong uniqueid, see Hue Dimmer Switch (2021 model) #4287.

TODO:

• Maybe add support for Identify through config.alert? Also missing for Hue dimmer switch family.

[ebaauw]

I think this is good to go.

Tested the Hue motion sensor: it still works as intended: all bindings and attribute reporting configurations are setup correctly, and config.pending works as intended:

$ ph put /sensors/17/config '{"delay": 10, "sensitivity": 2, "ledindication": true}'
{
  "delay": 10,
  "ledindication": true,
  "sensitivity": 2
}
$ ph get /sensors/17
{
  "config": {
    "alert": "none",
    "battery": 38,
    "delay": 10,
    "ledindication": true,
    "on": true,
    "pending": [
      "delay",
      "ledindication",
      "sensitivity"
    ],
    "reachable": true,
    "sensitivity": 2,
    "sensitivitymax": 2,
    "usertest": false
  },
  "ep": 2,
  "etag": "a212f51806b14e183a38586db1ed3783",
  "lastseen": "2021-03-14T10:37Z",
  "manufacturername": "Philips",
  "modelid": "SML001",
  "name": "Presence 17",
  "state": {
    "lastupdated": "2021-03-14T10:37:01.147",
    "presence": true
  },
  "swversion": "6.1.1.27575",
  "type": "ZHAPresence",
  "uniqueid": "00:17:88:01:04:b7:b0:a4-02-0406"
}

Observing the event log (18 and 19 are the ZHATemperature and ZHALightLevel resources):

Mar 14 11:37:39 pi5 dc_eventlog[791]: /sensors/17/config: {"delay":10,"ledindication":true,"pending":["delay","ledindication","sensitivity"],"sensitivity":2}
Mar 14 11:38:15 pi5 dc_eventlog[791]: /sensors/19/state: {"dark":false,"lastupdated":"2021-03-14T10:38:15.387","lightlevel":12354,"lux":17}
Mar 14 11:38:16 pi5 dc_eventlog[791]: /sensors/17/config: {"pending":["sensitivity"]}
Mar 14 11:38:16 pi5 dc_eventlog[791]: /sensors/18/config: {"ledindication":true}
Mar 14 11:38:16 pi5 dc_eventlog[791]: /sensors/19/config: {"ledindication":true}
Mar 14 11:38:16 pi5 dc_eventlog[791]: /sensors/17/config: {"pending":[]}

And checking the resource afterwards:

$ ph get /sensors/17
{
  "config": {
    "alert": "none",
    "battery": 38,
    "delay": 10,
    "ledindication": true,
    "on": true,
    "pending": [],
    "reachable": true,
    "sensitivity": 2,
    "sensitivitymax": 2,
    "usertest": false
  },
  "ep": 2,
  "etag": "ac37fc1c0b0e5c15bd202855dcdba726",
  "lastseen": "2021-03-14T10:38Z",
  "manufacturername": "Philips",
  "modelid": "SML001",
  "name": "Presence 17",
  "state": {
    "lastupdated": "2021-03-14T10:38:32.284",
    "presence": false
  },
  "swversion": "6.1.1.27575",
  "type": "ZHAPresence",
  "uniqueid": "00:17:88:01:04:b7:b0:a4-02-0406"
}

Interestingly, the motion sensor shows config.battery immediately after pairing, but the wall switch module doesn't. The motion sensor uses a Reportable Change of 0 (as does the Hue dimmer), but the wall switch one of 2. Maybe that's causing the report not to be sent when the config is set?

For reference:

Device	Min	Max	Change
Hue motion sensor	7200	7200	0
Hue dimmer switch	300	300	0
Hue smart button	900	900	2
Hue wall switch module	900	900	2

[Thomas-Vos]

The Hue Wall Switch Module is working for me with this PR, thanks Erik.

[manup]

Thanks, looks good as usual, just a few notes for future PRs.

[manup]

A note for later PRs: it would be good to add some defines for the manufacturer specific Hue Basic Cluster attribute ids 0x0032, 0x0033, etc to get rid of some magic numbers.

[ebaauw]

We use attribute IDs throughout the code, also for the standard attributes. Happy to change that, but that would be a biggie.

Of course (?) they are defined in general.xml. Would be nice if we can define/maintain them only once.

[manup]

These relate to "Clear pending on receiving the attribute report, instead of on queueing the Write Attributes;"?

I think the commented out lines can be removed in further PRs to nix some dead code.

[ebaauw]

Yes, just being over careful. And as I mentioned on Discord, Occupied to Unoccupied Delay isn’t reportable, so I kept the code for that attribute. Would really want to clear the pending on the Write Attributes Response, but I don’t think the API plugin handles these.

[ebaauw]

@manup, did you notice the change to WriteAttribute()? I think it’s OK, but it might have some negative effect on light sleepers with updatable config attributes that don’t use pending (like thermostats). Maybe we should introduce a “light sleeper” property to handle these devices as if they had Receiver on when Idle?

Also these new Hue devices use “Signify Netherlands BV.” as manufacturer name. The Hue bridge API shows this for the Hue old devices as well (even though the Zigbee attribute still read “Philips”). Do we want to change that?