# Steinel L 810 LED strangeness **URL:** \ **Category:** Bindings\ **Created:** [March 7, 2021, 5:07pm UTC](https://community.openhab.org/t/steinel-l-810-led-strangeness/118520 "2021-03-07T17:07:57Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![FLEMOH](https://community.openhab.org/letter_avatar_proxy/v4/letter/f/f6c823/32.png) [@FLEMOH](https://community.openhab.org/u/FLEMOH)\ **Post date:** [March 7, 2021, 5:07pm UTC](https://community.openhab.org/t/steinel-l-810-led-strangeness/118520/1 "2021-03-07T17:07:58Z")
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.