This page last changed on Jan 12, 2014 by ptruman.

Lo all

If I have a straight forward button (not a switch), can I tie a drool to it?

I have a fire which has the following commands:

ON/UP (same command)
DOWN
OFF

Because On and Up are the same, I can "light" the fire by pressing On or Up within OR. If I use a switch for On/Off, but press Up, the switch state is wrecked. I could use a drool to update an IMVC sensor value, but can't see an example to fire a drool on a button?

Clues?

NB : I actually went a bit mad and created three sensors - one for the overall fire state (on/off) and one for if someone was pressing Up or Down - to only executed Up/Down if the fire was on. However, to avoid a loop, I have to execute fire up/down AND then reset the sensor of the up/down button - and that seems to get "stuck" within OR - hence wanting to just pick up a button press, so I can do once test and one command, not two tests and two commands....

Posted by ptruman at Jan 12, 2014 14:30

How about using a slider on that ImVC Sensor (make it of type:range).

Posted by pz1 at Jan 12, 2014 14:42

At this stage, UI events are not exposed to the rules engine, so you need to work through a variable with virtual commands.

Pushing the button triggers a command that sets the virtual command to On.
Via a sensor on that virtual command address, have a rule triggered when value goes to on.
In the rule, do whatever you have to do, then reset virtual command to Off.

Posted by ebariaux at Jan 12, 2014 14:45

sensor on that virtual command address

In a sensor I can select the name of a command, not the address of a virtual command. I still am a bit confused about the role/prpperties of adresses in virtual commands.

Posted by pz1 at Jan 12, 2014 14:55

I did exactly that, but it seems to jam (esp. if I set the button to allow being "held").

Posted by ptruman at Jan 12, 2014 14:57

Won't work unfortunately.

This is an IR based target device, and the IR emitter is a bit "hit & miss", so there is no guarantee the value you 'set' is the value you 'get'. Basically it comes on "full" and you can adjust it down (then back up) but no way (other than using your eyes) of telling the setting, and if the IR emission from the iTach doesn't process, your sensor is out of whack.

The only thing that works is 'spamming' on and off which guarantee it's on/off - but fine adjustments are a pain.

Posted by ptruman at Jan 12, 2014 14:59

Sensors use commands to "get" a value - so if you are using a Hue light, you can issue the relevant HTTP get and use JSON to extract the value (brightness value for example).

With IMVC, you need at least an on, off and status command. Then you wire the sensor to use the status command, typically as a switch. That will then tell you wether it's "on" of "off". Link with drools to execute commands when the switch (and therefore IMVC value) changes and you're away.

I use exactly this to give 'state' to LightWaveRF devices

Posted by ptruman at Jan 12, 2014 15:01

The address of a virtual command is a bit like the name of a variable (or property).
You can't access the variable directly, you need to go through a getter or a setter.
Those are the commands you need to set and read the value.

The sensor reads the value of the variable with a given name (virtual command at a specific address) via the getter (the read command).

Posted by ebariaux at Jan 12, 2014 15:10

Weird, I thought we used that in the past.
If I get a bit of time (can't promise), I'll try to reproduce.

Posted by ebariaux at Jan 12, 2014 15:11

I can't see any logs, but given I'm using an iTach, I can see when the event gets to it (LED lights) - single presses are fine, but holding it seems to 'clog' after about 3 or 4 command iterations and it stops.

Posted by ptruman at Jan 12, 2014 15:14

I take it that the button is set to repeat then.

What I could see happening is some form of race condition or issue with timings of events.
All rules execution happens in a single thread, and if the command you're triggering is an iTach command, it can take a bit of time to execute, "locking" that thread during this time.

As a test, could you replace the iTach command execution in the rule with a debug statement:

System.out.println("Should execute command");

This should be immediate so not cause any timing issue.

Posted by ebariaux at Jan 12, 2014 15:23

My suggestion was intended to let the rule(s) do things as a response on value changes in the virtual slider. But indeed as you say due to the nature of this IR thing it won't work. (As you can in my private space I do know a bit about ImVC's)

Posted by pz1 at Jan 12, 2014 15:41

I'll check. That may be it, as another (separate) iTach command from the same emitter still seems to work.

Posted by ptruman at Jan 12, 2014 15:42
Document generated by Confluence on Jun 05, 2016 09:35