This page last changed on Mar 26, 2014 by philatkin.

I'm running OR on a PC, with an Aeotec Z-stick currently controlling a TKBHome Plug socket.
The basics are working fine: I can build an interface that switches the plug on and off. Even this seemed over-complex: I had to create (it seems)

  • A device with Power ON, Power OFF and Power Status commands
  • An associated Power Sensor object, connected to the Power Status command
  • An associated Power Switch object, connected to the Power Sensor and the Power ON and Power OFF commands
    Is all this really necessary to control a device and report its status\?

With these definitions, the interface correctly reflected the state of the circuit when it was controlled by the interface. It did not react if I used the socket's local switch to control it. To achieve that, I had to write a rule that send the "Power Status" regularly.

One of the basic things I want to do is to have a circuit switch off automatically an hour after it's switched on. To achieve this it seems I need to define different rules that insert and then retract an object, as in the Advanced Rule Example. The code I have is below. I have checked that the "Switch" condition is correctly reporting the current status.

It's difficult to describe the behaviour of the code. The status appears to flicker between on and off, although the physical switch does not. The log seems to contain a variable number of "begun" "retracted" "begun" "retracted" entries for each update, and these are at odd intervals (3s sometimes; other times 1s).

Does anyone have any clues? Thanks, Phil

rule "Updater"
timer (cron: 0/1 * * * * ?)
when
eval (true)
then
execute.command("Power Status");
end

declare Running
isRunning: boolean
end

rule "Run"
when
Switch(source == "Power Sensor", value == "on") and not Running()
then
Running running = new Running();
insert ( running );
log("Running begun");
end

rule "RunOff"
timer (int: 10s)
when
Switch(source == "Power Sensor", value == "on") and
$running: Running()
then
execute.command("Power off");
retract($running);
log("Running: switching off");
end

rule "RunCancel"
when
Switch(source == "Power Sensor", value == "off") and
$running: Running()
then
retract($running);
log("Running retracted");
end

The status appears to flicker between on and off, although the physical switch does not.

This is perhaps caused by the "Power Status" command. The return value it gives is not stable. You should concentrate to get it reliable first.

Posted by aktur at Apr 01, 2014 09:36

Thanks, but the status seems completely stable until I add the 'Run...' rules.
Phil

Posted by philatkin at Apr 01, 2014 09:45

But why do you have the 'Run...' rules after all?

One of the basic things I want to do is to have a circuit switch off automatically an hour after it's switched on.

To do this you need just one rule:

rule "Switch off after 1 hour"
timer (int: 1h)
when
  Switch(source == "Power Sensor", value == "on")
then
  execute.command("Power off");
end
Posted by aktur at Apr 03, 2014 08:29

I really appreciate your help. However, I'm afraid I can't get this to work.

I have removed all the 'Run' rules and now have simply (imports and globals omitted):

rule "Updater"
timer (cron: 0/1 * * * * ?)
when
eval (true)
then
execute.command("Power Status");
end

rule "Switch off after 10 seconds"
timer (int: 10s)
when
Switch(source == "Power Sensor", value == "on")
then
execute.command("Power off");
end

Although I've tried many, many variations on this, I have never seen the switch turn off due to the rule.

  • With an empty rule file, I can control the power with the UI but it does not update if I override using the physical button on the socket;
  • With just the "Updater" rule, I can control the power with the UI and the UI updates if I override using the physical button on the socket. However, so long as the actual status is not as it was set by the UI, the UI is seen to flicker every second (but shows the actual status most of the time).
  • With both rules, the behaviour is indistinguishable from the previous case (no switch-off is ever observed).

So this appears to be simpler ... which is good ... but doesn't actually achieve my 'basic thing'. Can you tell me where to find some basic information about how Drools operates? I've looked at the jboos.org site but it was really difficult to get started that way. Equally, the OpenRemote documentation seems to give particular examples but not teach the principles on which to base variations.

Thanks again, Phil

Posted by philatkin at Apr 06, 2014 16:53

Phil, again I think that your problem is not stable sensor output which you confirm with:

With just the "Updater" rule, I can control the power with the UI and the UI updates if I override using the physical button on the socket. However, so long as the actual status is not as it was set by the UI, the UI is seen to flicker every second (but shows the actual status most of the time).

Seems that "Power Status" command returns not always good status. I don't understand this bit:

so long as the actual status is not as it was set by the UI

Why should this be of importance? In a good design it should not matter. However, the status should always be red from your device.
I've done this with EnOcean and WeMo switches and they always are stable and reflecting correct status without flickering. I've described how I've defined commands and sensors on my blog: http://mqlservice.net/openremote/2014/02/08/integrating-belkins-wemo-switch-and-motion-with-openremote/
and http://mqlservice.net/openremote/2014/03/08/integrating-eltakos-socket-switching-actuator-fsva-230v/

As long as the sensor output is not stable the timer(int: 10s) will be triggered every time the sensor changes value. You can try to change timer(cron: 0/20 * * * * ?) to update every 20s and note that the second rule will trigger.

Hope this helps.

Posted by aktur at Apr 06, 2014 18:28

To clarify "so long as the actual status is not as it was set by the UI".
My UI has an 'On' button, an 'Off' button, and a switch. If I control the power using any of these, the switch's state reflects whether the plug is on or off and is completely stable. If, however, I override the UI by pressing the physical button, then the 'actual status' is no longer 'as it was set by the UI'. (For example, the UI turned it off but the physical switch has set it on). Now, the switch shows the power as on for about 0.9s, then it flickers to off for about 0.1s, then on for 0.9s... If I reverse the situation (so the UI turned it on but the physical switch has set it off), then the switch shows off for 0.9s ...
Pressing the physical switch again, returns the actual status to what was set by the UI, and the flickering stops.

I'll take a longer look at your blog to see if I can improve my understanding. Thanks,

Phil

Posted by philatkin at Apr 06, 2014 19:24

Here's what is in zwave.log for two consecutive seconds while the switch is flickering:

DEBUG 2014-04-06 19:38:18,001 (Z-Wave): Building Z-Wave command
DEBUG 2014-04-06 19:38:18,001 (Z-Wave): Z-Wave command: command = status
DEBUG 2014-04-06 19:38:18,001 (Z-Wave): Z-Wave command: nodeId = 2
DEBUG 2014-04-06 19:38:18,001 (Z-Wave): Z-Wave command: paramValue = null
DEBUG 2014-04-06 19:38:18,001 (Z-Wave): Z-Wave command created successfully
DEBUG 2014-04-06 19:38:18,001 (Z-Wave): sending: 01 09 00 13 02 02 20 02 05 20 e2
DEBUG 2014-04-06 19:38:18,005 (Z-Wave): received: 06
DEBUG 2014-04-06 19:38:18,009 (Z-Wave): received: 01 04 01 13 01 e8
DEBUG 2014-04-06 19:38:18,009 (Z-Wave): sending: 06
DEBUG 2014-04-06 19:38:18,021 (Z-Wave): received: 01 05 00 13 20 00 c9
DEBUG 2014-04-06 19:38:18,021 (Z-Wave): sending: 06
DEBUG 2014-04-06 19:38:18,025 (Z-Wave): received: 01 09 00 04 00 02 03 20 03 00 d0
DEBUG 2014-04-06 19:38:18,025 (Z-Wave): sending: 06
DEBUG 2014-04-06 19:38:19,001 (Z-Wave): Building Z-Wave command
DEBUG 2014-04-06 19:38:19,001 (Z-Wave): Z-Wave command: command = status
DEBUG 2014-04-06 19:38:19,001 (Z-Wave): Z-Wave command: nodeId = 2
DEBUG 2014-04-06 19:38:19,001 (Z-Wave): Z-Wave command: paramValue = null
DEBUG 2014-04-06 19:38:19,001 (Z-Wave): Z-Wave command created successfully
DEBUG 2014-04-06 19:38:19,001 (Z-Wave): sending: 01 09 00 13 02 02 20 02 05 21 e3
DEBUG 2014-04-06 19:38:19,007 (Z-Wave): received: 06 01 04 01 13 01 e8
DEBUG 2014-04-06 19:38:19,007 (Z-Wave): sending: 06
DEBUG 2014-04-06 19:38:19,019 (Z-Wave): received: 01 05 00 13 21 00 c8
DEBUG 2014-04-06 19:38:19,019 (Z-Wave): sending: 06
DEBUG 2014-04-06 19:38:19,027 (Z-Wave): received: 01 09 00 04 00 02 03 20 03 00 d0
DEBUG 2014-04-06 19:38:19,027 (Z-Wave): sending: 06

Posted by philatkin at Apr 06, 2014 19:40

OK, I see now. So you have in fact always series of pules and the correct value is about 0.9 s. This has probably to do with your hardware but we can fix it with rules. Now I can reuse your running example with some filtering. Try the following:

declare Running
  isRunning: boolean
end

rule "Run"
timer (int: 750ms)
when
  Switch(source == "Power Sensor", value == "on") and not Running()
then
  Running running = new Running();
  insert ( running );
  log("Running begun");
end

rule "RunOff"
  timer (int: 10s)
when
  $running: Running()
then
  execute.command("Power off");
  retract($running);
  log("Running: switching off");
end

rule "RunCancel"
  timer (int: 750ms)
when
  Switch(source == "Power Sensor", value == "off")
  $running: Running()
then
  retract($running);
  log("Running retracted");
end
Posted by aktur at Apr 06, 2014 20:35
Document generated by Confluence on Jun 05, 2016 09:36