Steinel RS LED D2 Zwave : properties of things are not allowing values which are allowed according to overview

Tags: #<Tag:0x00007fc8f4b61420> #<Tag:0x00007fc8f4b612e0>

I installed the Z-Wave controlled smart (indoor) light Steinel RS LED D2 ZWave When I tried to change one of the Z-Wave properties of the thing-instance, I got following : “Please review the configuration and correct validation errors”. I see there are following fields that are treated as being incorrect, while the explanation of the property just below indicates that value should actually be ok. See below…
What can be done about it ? I can’t modify any value, it won’t let me…

  • 6: Brightness measuring interval [min]
    current value: 0
    Error text (translated from Dutch): Value should be greater than or equal to 5.
    (only SLAMP)
    Overview
    Interval for measuring ambient light when lamp is on (lamp switches off briefly and measures). 0 = function is off. The info in the overview says that 0 is ok.

  • 11: On behaviour (timeout)
    Current Value: 255
    Error message (translated from Dutch): Value should be smaller than or equal to 209.
    ON_BEHAVIOUR
    Overview
    Behaviour after BASIC ON (and similar commands).
    If a transition (even with zero change) with a non-default duration is to be processed, the transition cannot be interrupted by any motion event in any case.
    0 = Lamp/relay is switched on and remains so until any new motion event (local or remote) is received. It then works normally via current motion evaluation.
    Notice – during the day, this mode cannot be ended remotely due to motion events not being transmitted – only via local motion sensor if enabled.
    1 - 209 = Lamp/relay is switched on and remains so until after a specified timeout once a new motion event (local or remote) is received. It then works normally via current motion evaluation.
    Timeout:
    1…100 – 1 second (1) to 100 seconds (100) in 1-second resolution
    101…200 – 1 minute (101) to 100 minutes (200) in 1-minute resolution
    201…209 – 1 hour (201) to 9 hours (209) in 1-hour resolution
    Notice – during the day, this mode cannot be ended remotely due to motion events not being transmitted – only via local motion sensor if enabled.
    210 - 254 = Reserved
    255 = Lamp/relay is switched on for TIME (cfg 1). It does not wait for a motion event and works normally via current motion evaluation. ==> Value 255 seems ok

  • 16: Motion Off behaviour (timeout)
    Current value: 0
    Error Message: Value should be greater than or equal to 2
    MOTION_ DISABLE
    Overview
    Motion disable timeout after BASIC SET to motion endpoint when the inter-
    nal motion sensor is not used for evaluating the behaviour of the lamp (SLAMP)
    relay (SPIR) and groups 2 and 3. Events are, however, still transmitted to the
    Lifeline, and the device can be controlled via remote motion sensors.
    0 = BASIC SET to motion sensor endpoint ignored, BASIC to root is
    mapped to relay endpoint, (SPIR) motion sensor still enabled
    1 - 209 = Internal motion sensor is disabled for specified timeout after BASIC
    SET 0x00 to motion endpoint.
    Timeout:
    1…100 – 1 second (1) to 100 seconds (100) in 1-second resolution
    101…200 – 1 minute (101) to 100 minutes (200) in 1-minute resolution
    201…209 – 1 hour (201) to 9 hours (209) in 1-hour resolution
    210 - 254 = Reserved
    255 = BASIC SET to motion endpoint ignored, motion sensor still disabled.

This isn’t detected as an error, but it did appear strange:

  • 2: Control: Key01
    Current Value: Controller
    Feedback just below the value : On/Off control (Never ever add controller, only third-party devices!)
    Overview:
    Group 2 is used for directly controlling Z-Wave devices via BASIC SET commands through the evaluation of movement and light, as with internal use (so that all of these devices work together).
    This is intended for use especially with third-party devices that do not implement reactions for motion events.
    BASIC_SET and similar Z-Wave commands are not retransmitted intentionally to slaves and must be sent to slave devices via the controlling device simultaneously.
    Only for use in master-slave system, multi-device control is not possible.

Are you using text based Things? Although that can be done it is discouraged because of the great chance for errors.
Automatically discovering Things is the main supported method.

If you’re using the web UI, unfortunately it’s not possible to properly configure most ZWave devices due to a bug in the UI.

I’ve created an issue for this -:

I use everything with the UI indeed, didn’t create anything with textfiles, everything automatic.
I just wanted to point out that the value checks are not in line with the allowed values according to the specs of that specific device.
I thought it would be a matter of adapting something in the database-entry of that specific device, setting the performed value checks so that they conform to the actual device specifications.

Also, the last value (2: control: Key01) was set default to “controller”, and the info below said it should never be “controller”. The system doesn’t flag it as a mistake, but I wonder what the effects are.

Is there any workaround that I can do to change some values at least ?
Like edit a text file somewhere. So far it is the only device I have suffering from this.
The UI won’t let you save anything unless you fix the errors it detected (which don’t appear to be an error at all if I read the specs).

Value limits for configuration are usually set according to the vendor documentation if available. I do know vendor manuals are not without error.

@chris can verify but the database entry appears to have issues. All groups are set to controller. Perhaps I can look at it later if he concurs.

1 Like

Yes, there are a few errors. Firstly, there is no such thing as group 0 - I don’t think the protocol allows this, so this should be deleted as it could cause issues. Secondly, this is a ZWave+ device, so the lifeline should provide pretty much all information required by the controller. Sometimes this might not be the case, but I agree with @Bruce_Osborne that we shouldn’t set the other association groups to report to the controller by default.

Updated database entry.
The description for Group 2 even said not to include the controller :roll_eyes:

1 Like

How can I get the changes you made on my side please ?

What version of openHAB are you running? It is in the latest openHAB 3 SNAPSHOT build of the binding. Currently it appears OH2 binding snapshot builds are broken.

You can manually install the binding either by using the script or following the manual instructions in the README.

Zigbee and Z-Wave manual install script - Tutorials & Examples - openHAB Community

openHAB 3.0.1

1 Like

The database entry should be in the latest OH3 snapshot. I know there are issues with OH2 snapshots.