In Wall Switch, Dimming percentage: Triggering Events

Designer 2.5
1

I would like to forward the dimming percentage from an in wall Leviton dimmer switch (zwave) to a bunch of other devices in the network.

I have the following rules created, and the ON and OFF events are triggered and forwarded correctly. However, when the dimming percentage is changed on the wall switch, it does not trigger any events in the rules engine (according to the logs).

Here is my code; Node 16 is the in wall dimmer, Node 15 is the slave device that should mirror the switch.

package org.openremote.controller.protocol

global org.openremote.controller.statuscache.CommandFacade execute;

global org.openremote.controller.statuscache.SwitchFacade switches;

import java.util.*;

import java.util.regex.*;

rule “Forward Mood Switch Turn Devices On”

when

Event( source == “Node 16 On/Off”, value == “on” )

then

execute.command(“Node 15 (ON)”);

end

rule “Forward Mood Switch Turn Chandelier Off”

when

Event( source == “Node 16 On/Off”, value == “off” )

then

execute.command(“Node 15 (OFF)”);

end

rule “Forward Mood Switch Match Dim Level”

when

Event( source == “Node 16 On/Off”, value == “on” )

Event( source == “Node 16 Dimmer”, $val : value )

then

String valStr = $val.toString();

if (valStr != null )

{

execute.command( “Node 15 Dimmer”, valStr );

}

end

``

I cannot figure out why the rule is not being triggered.

Thanks

2

There are plenty of people that will agree that I'm no expert, so don't take this answer as anything more than a guess...

Would this work ???

    rule "Forward Mood Switch Match Dim Level"
        when
        
        Event( source == "Node 16 Dimmer", $val : value )
    then
        String valStr = $val.toString();
        if (valStr != null )
            {
            execute.command( "Node 15 Dimmer", valStr );
            }
    end

3

Or is it (assuming you're naming convention) that the ExecuteCommand is trying to push a value into a sensor?
Rather than a command?

rule "Forward Mood Switch Match Dim Level"
    when
        
        Event( source == "Node 16 Dimmer", $val : value )
    then
        String valStr = $val.toString();
        if (valStr != null )
            {
            execute.command( "Node 15 Dimmer Set", valStr );
            }
    end

4

I agree my naming convention isn’t the best, but the “Node 16 Dimmer” is a command. I am not worried about that part yet since the rule isn’t even being triggered.
I added the Event “on” portion so the controller wouldn’t turn the slave device on when it is suppose to be off (even if a slider is changed in the app), however the rule is not triggered even without this event.

5

Usually in my experience on the LHS of a rule, the source has to be a sensor and on the RHS when the rule gets triggered, it is a command.

If your “Node 16 Dimmer ” on the LHS is indeed a command, it may not work. It may need to be a sensor that will have a value assigned to it. You cannot have a value assigned to a command.

6

The rule seems OK to me as long as you have defined “Node 16 Dimmer” sensor. The easiest way to check it is to have a label linking to this sensor and see if its value changes correctly.

7

I have cleaned up the naming a bit.
rule “Forward Mood Switch Match Dim Level”

when

Event( source == “Node 16 On/Off”, value == “on” )

Event( source == “Node 16 Dimmer”, $val:value )

then

String valStr = $val.toString();

if (valStr != null )

{

execute.command( “Node 15 Dim”, valStr );

}

end

``

“Node 16 Dimmer” is a sensor (verified through the android app)
“Node 15 Dim” is a command.

I still am not getting a trigger in my rules.

I have also tried using a Level function instead of an Event, but I couldn’t get the required class included without library compile errors.

global org.openremote.controller.statuscache.LevelFacade level;

``

Causes package null errors.

Nathan

8

Just a thought.

Michal pointed out an interesting detail on a different forum topic....

The sensor you have created for the dimmer level, is it a "LEVEL" or "RANGE" type, or did you use a "CUSTOM" type.

"LEVEL" & "RANGE" are integer
"CUSTOM" are string.

(I don't know if this will make a difference, but it might)

On a similar theme, I had a set of rules that didn't work recently which turned out to be that I'd used a lower case S, where it should have been in upper case.

9

The sensor is a LEVEL type. I have a feeling it would work with Level() instead of Event() but I can’t get the includes to compile.

Nathan

10

As a test...

Have you tried using an in-memory command and sensor to display any output in your UI ?

11

In a similar way..

Have you looked at the ...../logs/rules/rules.log file to see if there are any issues?

12

Looking at the rules log is how I am determining that there is no trigger for the rule event. There is nothing else of interest in there. The examples in Github don’t seem to work for me with the current version: https://github.com/openremote/Documentation/wiki/Advanced-Rule-Examples

I wish there was a better wiki explaining the differences between: include, package, global, etc, as it relates to OpenRemote.

Nathan

13

Can you create second sensor which uses the same command but now of the type Custom? Then you can trigger the rule with this one. Personally I have a little experience with other types of sensors than custom in rules. When I need another sensor type for UI then I create double sensors, one for rules of type Custom and the other one for the UI.

14

For anyone else who lands on this thread, I changed the includes as follows to fix the drools errors:

package org.openremote.controller.model.event

global org.openremote.controller.statuscache.CommandFacade execute;

global org.openremote.controller.statuscache.SwitchFacade switches;

global org.openremote.controller.statuscache.LevelFacade level;

import org.openremote.controller.protocol.*;

import java.util.*;

import java.util.regex.*;

``

As far as the triggering goes, after a long night of internet research, it appears the issue is probably with my switch. Apparently there is a design change in the Leviton DZ6HD that prevents dimming events from being read by the controller. I am not sure why OpenRemote wouldn’t be POLLING the switch for the dim level, I would have expected that to happen, and subsequently trigger the rule event.

Nathan