[SOLVED] Unexpected rule behavior (rollershutter)

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"                                               
        Channel 'astro:sun:r-wzs:set#event' triggered START or
        Item test_rollo received command ON
        if (EG_wzsued_r_SwitchDimmer.state < 100 && EG_wzsued_r_MeterWatts.state < 20) {
            logInfo("ROLLLADEN", "--> WZs geschlossen")
            postUpdate(EventLog, "Rollladen WZs geschlossen")        // eventlog.rules
        else {

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.

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

That is a result of

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.

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.

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"}

How can one do this?

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.

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?

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

I did expect the opposite behavior as for command OFF :wink:
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"
        Time cron "0 30 7 ? * MON,TUE,WED,THU,FRI"    
        sendCommand(Grollo, OFF)
        postUpdate(EventLog, "Rollladen geöffnet - Wochentag")        // eventlog.rules

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.

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

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:


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:


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:

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.

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>

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.

That is correct!