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 :
COMMAND_CLASS_SWITCH_MULTILEVEL_V3 - V4 in xml
COMMAND_CLASS_ZWAVEPLUS_INFO_V1 - V2 in xml
COMMAND_CLASS_MULTI_CHANNEL_V2 - V4 in xml
COMMAND_CLASS_MANUFACTURER_SPECIFIC_V1 - V2 in xml
COMMAND_CLASS_FIRMWARE_UPDATE_MD_V1 - V3 in xml
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.