[SOLVED] Unexpected rule behavior (rollershutter)

[Selter]

Hi there,

The rule below triggers but does strange things when the rollershutter isn’t in 0% position.

Initial situation today:

The rule should close the rollershutter at sunset or if test_rollo button is pressed (which both works fine in case the rollershutter is at 0%).

rule "Rollladen WZs schliessen"                                               
    when
        Channel 'astro:sun:r-wzs:set#event' triggered START or
        Item test_rollo received command ON
    then    
        if (EG_wzsued_r_SwitchDimmer.state < 100 && EG_wzsued_r_MeterWatts.state < 20) {
            EG_wzsued_r_SwitchDimmer.sendCommand(ON)
            logInfo("ROLLLADEN", "--> WZs geschlossen")
            Thread::sleep(100)
            postUpdate(EventLog, "Rollladen WZs geschlossen")        // eventlog.rules
        }
        else {
            return
        }
        
end

But this is the outcome:

[ome.event.ItemCommandEvent] - Item 'test_rollo' received command ON
[vent.ItemStateChangedEvent] - test_rollo changed from OFF to ON
[ome.event.ItemCommandEvent] - Item 'EG_wzsued_r_SwitchDimmer' received command ON
[INFO ] [pse.smarthome.model.script.ROLLLADEN] - --> WZs geschlossen
[nt.ItemStatePredictedEvent] - EG_wzsued_r_SwitchDimmer predicted to become ON
[vent.ItemStateChangedEvent] - EG_wzsued_r_SwitchDimmer changed from 58 to 100
[vent.ItemStateChangedEvent] - EG_wzsued_r_SwitchDimmer changed from 100 to 58
[vent.ItemStateChangedEvent] - EG_wzsued_r_MeterWatts changed from 0.3 to 0.5
[vent.ItemStateChangedEvent] - EG_wzsued_r_MeterVoltage changed from 232.5 to 232.9

Obviously the rollershutter jumps from 58 to 100 and back to 58 within one second. Which leads to that it isn’t moving at all.

[rossko57]

You didn’t tell us how your Item is defined, but let’s guess it’s a Dimmer type?

@Selter

Obviously the rollershutter jumps from 58 to 100

That is a result of

@Selter

[nt.ItemStatePredictedEvent] - EG_wzsued_r_SwitchDimmer predicted to become ON

Predictions like that come from the autoupdate feature. Because real devices may respond slowly (or not at all), autoupdate listens for commands to an Item and makes an educated guess at the likely outcome. The prediction is applied to the Item’s state to speed up the apparent action for a nicer UI experience.
In this case, commanding ON to a Dimmer predicts 100%.

So, if you are getting reasonable updates from a real device, you will want to disable autoupdate for this Item and get rid of the prediction.

@Selter

Which leads to that it isn’t moving at all.

No, that’s not the whole reason. Changing from a predicted 100 to a reported real position of 58 sounds correct to me - you’ve only just sent the command, so it won’t have moved far yet.
You need to think about getting more updates later on when the device has had tiime tp physically move.

How to go about that depends on your mystery device.

[Selter]

@rossko57

You didn’t tell us how your Item is defined, but let’s guess it’s a Dimmer type?

You are right - it’s a dimmer (the device is a Philio PAN08 Z-Wave Rollershutter):

Dimmer   EG_wzsued_r_SwitchDimmer       "Rollladen WZsüd [%s]"                              <rollershutter> (gM,Grollo,Gwz,Gzwave)     {channel="zwave:philio_pan081a_00_000:controller:node14:switch_dimmer"}

@rossko57

you will want to disable autoupdate for this Item and get rid of the prediction.

How can one do this?

[rossko57]

It’s like a binding option on the Item

Dimmer EG_wzsued_r_SwitchDimmer "Rollladen WZsüd [%s]" <rollershutter>  (gM,Grollo,Gwz,Gzwave) {autoupdate="false, channel="zwave:philio_pan081a_00_000:controller:node14:switch_dimmer"}

This is only about that prediction and the effect on the state that you noted. If your shutter isn’t working or doesn’t report its final position, its not a fix for that.

[Selter]

I did another test with the option autoupdate="false"

Unfortunately there was (almost) no impact.

Initial situation:

After switching test_rollo to ON this was the outcome:

[ome.event.ItemCommandEvent] - Item 'test_rollo' received command ON
[vent.ItemStateChangedEvent] - test_rollo changed from OFF to ON
[ome.event.ItemCommandEvent] - Item 'EG_wzsued_r_SwitchDimmer' received command ON
[INFO ] [pse.smarthome.model.script.ROLLLADEN] - --> WZs geschlossen
[vent.ItemStateChangedEvent] - EG_wzsued_r_MeterWatts changed from 0.3 to 0
[vent.ItemStateChangedEvent] - EG_wzsued_r_SwitchDimmer changed from 60 to 59
[vent.ItemStateChangedEvent] - EG_wzsued_r_MeterWatts changed from 0 to 0.2
[vent.ItemStateChangedEvent] - EG_wzsued_r_MeterPowerfactor changed from 0.97 to 0
[vent.ItemStateChangedEvent] - EG_wzsued_r_MeterCurrent changed from 0.62 to 0
[vent.ItemStateChangedEvent] - EG_wzsued_r_MeterVoltage changed from 223.5 to 223.7

The rollershutter only moved 1% up - which is also the wrong direction.

In the next setup I’ve altered the sendCommand value from ON to 100

This seems to work …

[ome.event.ItemCommandEvent] - Item 'test_rollo' received command ON
[vent.ItemStateChangedEvent] - test_rollo changed from OFF to ON
[ome.event.ItemCommandEvent] - Item 'EG_wzsued_r_SwitchDimmer' received command 100
[INFO ] [pse.smarthome.model.script.ROLLLADEN] - --> WZs geschlossen
[vent.ItemStateChangedEvent] - EG_wzsued_r_MeterWatts changed from 0.7 to 138
[vent.ItemStateChangedEvent] - EG_wzsued_r_SwitchDimmer changed from 60 to 58
[vent.ItemStateChangedEvent] - EG_wzsued_r_MeterWatts changed from 138 to 138.4
[vent.ItemStateChangedEvent] - EG_wzsued_r_MeterPowerfactor changed from 0.97 to 0.96
[vent.ItemStateChangedEvent] - EG_wzsued_r_SwitchDimmer changed from 58 to 70
[vent.ItemStateChangedEvent] - EG_wzsued_r_SwitchDimmer changed from 70 to 80
[vent.ItemStateChangedEvent] - EG_wzsued_r_MeterCurrent changed from 0.62 to 0.63
[vent.ItemStateChangedEvent] - EG_wzsued_r_MeterVoltage changed from 223.5 to 224.2
[vent.ItemStateChangedEvent] - EG_wzsued_r_SwitchDimmer changed from 80 to 90
[vent.ItemStateChangedEvent] - EG_wzsued_r_MeterWatts changed from 138.4 to 1.1
[vent.ItemStateChangedEvent] - EG_wzsued_r_MeterWatts changed from 1.1 to 0
[vent.ItemStateChangedEvent] - EG_wzsued_r_SwitchDimmer changed from 90 to 100

There is obviously a difference between ON and numbers under certain circumstances.
Do you know the reason?

[rossko57]

@Selter

There is obviously a difference between ON and numbers under certain circumstances.

Yep, that’s up to how the binding handles it. What are you expecting to happen with command ON ?
Now that you’ve revealed this is a zwave device, you’ll probably be interested in this relating to PAN08

Z-Wave / OH 2.4: Roller Shutter PAN08-1a not invertible

Just to let interested people know: I run the latest Z-Wave Binding (2.5.0 Snapshot available here: https://ci.openhab.org/job/openHAB2-Bundles/lastStableBuild/org.openhab.binding%24org.openhab.binding.zwave/artifact/org.openhab.binding/org.openhab.binding.zwave/) now, which includes the change mentioned above and it works as expected. As a side effect, I have a lot less “noise” in the log files. Obviously the cleanup and changes done by @chris helped a lot. Many thanks for that, Chris! …

[Selter]

@rossko57

What are you expecting to happen with command ON ?

I did expect the opposite behavior as for command OFF
ON should close the rollershutter to 100%

Since the simple rule below rule works as I expect, I thought it should be for the rule in post #1 as well (in the opposite way).

rule "Rollladen Mo-Fr AUF"
    when
        Time cron "0 30 7 ? * MON,TUE,WED,THU,FRI"    
    then
        sendCommand(Grollo, OFF)
        postUpdate(EventLog, "Rollladen geöffnet - Wochentag")        // eventlog.rules
end

[rossko57]

Okeydoke, I’m not at all sure what to expect.

Maybe add a zwave tag to your post to attract attention, but the advice might well be to upgrade your zwave version to get proper Rollershutter type support.

[Selter]

@rossko57

I’m not at all sure what to expect

I’m almost too - feel like my brain has been twisted

[shutterfreak (Olivier Biot)]

@Selter

There is obviously a difference between ON and numbers under certain circumstances.

There are several primary switch types as defined by Z-Wave, e.g. up/down, open/close, on/off. They are implemented by the device manufacturers depending on the purpose of the Z-Wave device.

It’s a tad counterintuitive to use ON and OFF commands to open and close roller shutters so I think you might be using the wrong primary switch commands to operate your roller shutters.

You can check the node.xml file generated by the Z-Wave binding to check the supported primary switch type (and associated primary commands). These node.xml files are stored in the zwave folder under $OPENHAB_USERDATA. On a Linux-based system this translates to the folder /var/lib/openhab2/zwave.

In this folder, each Z-Wave node identified by the Z-Wave binding should have an XML file with the following name format:

network_NNNNNNNN__node_X.xml

Replace NNNNNNNN with the hexadecimal representation of the 4-byte Z-Wave network identifier (in lowercase), and replace X with a 1-byte nonzero integer representing the node ID (in your case, X = 14). The primary controller always has node ID = 1.

The capabilities of a Z-Wave device are expressed in command classes. A dimmer switch such as a roller shutter controller node is translated in Z-Wave terminology as a multilevel switch (it potentially supports several positional levels whcih can be reached e.g. by pressing the up or down button until the desired level has been attained). Look in your network_NNNNNNNN__node_X.xml files for the COMMAND_CLASS_SWITCH_MULTILEVEL definition:

<entry>
    <commandClass>COMMAND_CLASS_SWITCH_MULTILEVEL</commandClass>
    <multiLevelSwitchCommandClass>
        <version>3</version>
        <instances>1</instances>
        <control>false</control>
        <versionSupported>3</versionSupported>
        <switchTypePrimary>CLOSE_OPEN</switchTypePrimary>
        <switchTypeSecondary>UNDEFINED</switchTypeSecondary>
        <isGetSupported>true</isGetSupported>
    </multiLevelSwitchCommandClass>
</entry>

In the example above, you can see that the primary switch type (switchTypePrimary) is defined as CLOSE_OPEN. This translates to: “this device understands the OPEN and CLOSE commands”.

To quickly check the primary switch types in use in your Z-Wave nodes, you can run the following Linux commands:

$ cd /var/lib/openhab2/zwave
$ grep switchTypePrimary *

If you’re interested into Z-Wave specifics, then you may want to read the following:

Z-Wave devices supporting the SWITCH_MULTILEVEL command class should support at least the following positions:

1. 0 (0) - fully closed (*)
2. 0xFF (255) - fully open (*)
3. 0xFE(254) - position undefined (e.g., after a power cut, or in cases the device is only end point aware and the position is somewhere in-between end points such as ‘half open’)

If your Z-Wave device supports positional awareness, then it also supports positions in the range 0x01 (1) → 0x63 (99), but maybe in discrete steps (e.g. every 10%).

(*) The Z-Wave binding allows you to invert the states

The Z-Wave binding takes care of translating the OpenHAB states into Z-Wave states and the other way round. So for you, it’s important to understand that valid OpenHA2 commands are numbers between 0 and 100 (percentage values) and the primary switch type commands (in my example, the OPEN and CLOSE commands).

In addition, there’s also the REFRESH command that you can send from OpenHAB2 to any Z-Wave node through the Z-Wave binding. When a Z-Wave Item receives this command through the binding, it effectively instructs the binding to query the state (in our case: the position of the roller shutter). recent versions of the Z-Wave binding will report UNDEF as state to OpenHAB2 in case the Z-Wave node returns 0xFE (254 in decimal) as state. This can be used e.g. in rules.

[Selter]

Hi Olivier,

Thank you for the detailed explanation.

So since the switchTypePrimary is defined as DOWN_UP in my case, the correct commands would be DOWN and UP - besides the percentage values, right?

network_d2b57b5a__node_14.xml:              <switchTypePrimary>DOWN_UP</switchTypePrimary>

[rossko57]

Except that you’ve defined your Item as a Dimmer type, which accept ON/OFF commands.
You’d want to use Rollershutter type instead for UP/DOWN.

[shutterfreak (Olivier Biot)]

@Selter

Hi Olivier,

Thank you for the detailed explanation.

So since the switchTypePrimary is defined as DOWN_UP in my case, the correct commands would be DOWN and UP - besides the percentage values, right?

network_d2b57b5a__node_14.xml:              <switchTypePrimary>DOWN_UP</switchTypePrimary>

That is correct!