Steinel L 810 LED strangeness

Hi, I’ve been using OH for a few years but only with a small number of fairly simple zwave devices and not much automation. The recent release of OH3 has inspired me to take it a bit further.

I’ve had a Steinel L810 lamp above my front door for a while but it was just in dumb mode since it was too flaky when I included it onto my zwave controller and I had no time to work out why. I’ve now loaded the current Openhabian with OH3 on an old rpi to try and figure out if I can control it reliably or if its firmware is just too rubbish to bother with. It’s also a good way to dig a bit more deeply into OH and find out what else I can do with it!

So far, I can only confirm that it is definitely flaky :

  • The debug log is showing state updates to channels which are not reflected in the UI or the persistence charts.
  • The device has a config param to set the light level above which the motion sensor is ignored. If I set this to anything less than 2000 (the level that permanently ignores the motion sensor) the zwave network is flooded with state updates from endpoint 2 (the motion sensor EP) at a rate of about 10 per second.
  • Neither of the dimmer channels update properly with the current lamp level.
  • There is only 1 light sensor channel on the root endpoint and it never updates.
  • All the Association groups are automatically linked to the controller and it’s not possible to unlink them in the UI

A search in the OH forum comes back with a fair number of people having issues with Steinel devices so I am not sure how much time it’s worth spending on this thing but before I jumped into the logs too deeply I did a quick comparison of the database definitions for Steinel devices and my device xml file.

I found some strangeness but I’m not sure how relevant it is :

  • All association groups seem to be linked to the controller by the database definition. I haven’t seen this often and the other Steinel devices which seem to share pretty much the same firmware only have the lifeline group associated with the controller.

  • Similarly, other devices in the same same Steinel product group have a channel mapped to COMMAND_CLASS_SENSOR_MULTILEVEL_V4 in endpoint 3 (ambient light sensor). The definition for this device only has a channel mapped in the root endpoint.

  • The root endpoint has a channel mapping for COMMAND_CLASS_SENSOR_BINARY but this command class is not in my xml file and the Steinel documentation also indicates that it is not present in this device.

  • Some of the supported versions in my xml file do not correspond with the _V? references on the database definition for the root endpoint. I suppose this is not critical but for info they are :


I’m happy to do the database update but, as I said, I’m not sure if any of these differences have any relevance so it seemed like a good idea to post this first so that someone who knows more than I do can tell me if it makes sense to request a database change or not.