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.