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

Lo all,

As per the WiKi page I've been working on, I have a LightwaveRF device, with on/off commands, and an IMVC command to track state, and a switch to show the state.

To cut a long story short, if you run the IMVC "Off" command, it updates the IMVC status and a drool rule is executed to actually run the "off" command and turn the device off.

I've just started using the REST API for a couple of things, and am manually calling the IMVC off command, which is working - however I've noticed the UI doesn't update - which I think it should once the IMVC changes, as the state is now "off"?

If I use REST to "click" the button, it works, but if I use REST to call the IMVC command, it doesn't. If I've used the native Lightwave app then the "state" would be out of sync with the UI, so the IMVC is safest to use, as it should update the UI/switch state accordingly?

I'm wondering if this is down to the fact that sensors and IMVC commands don't have polling intervals? (at least in the UI)

I hope the above is clear - let me know

What REST call are you doing to call the IMVC command ?

BTW: I guess that IMVC is "In Memory Virtual Command" ?

Posted by ebariaux at Jan 10, 2014 10:05

Yes IMVC is In Memory Virtual Command

I can't confirm that right now as I'm not at home, but it's the ID of the IMVC command, with "On" of "Off" at the end. The function works - it's updating the variable, and the drool rule triggers and executes the actual device on/off command.

Given the switch is based on the sensor, and the sensor uses IMVCs, if the IMVC is updated, the sensor should update also?

Posted by ptruman at Jan 10, 2014 10:54

Well, one thing is sure, I use IMVC based switches a lot and update their states from rules through execute.command(). Their state is reflected in the UI, so this path works. Perhaps if your rule is called through the REST interface you simply add execute.command(IMVC,"off") in the rule LHS and it will be shown in UI?

Posted by aktur at Jan 10, 2014 11:36

Perhaps if your rule is called through the REST interface

How is that done? I searched the site for an answer, but did not find one.

PS: I prepared a HowTo for ImVC. The draft is in my private space. Comments are welcome


Posted by pz1 at Jan 10, 2014 12:43

I'll check that tonight/tomorrow and let you know

Posted by ptruman at Jan 10, 2014 13:13

I've been writing a LightWaveRF doc for Juha/Pierre which is currently lurking at

That includes a bit on IMVC also
Maybe I can link mine to yours?

The REST API is here :

Posted by ptruman at Jan 10, 2014 13:23

Maybe I can link mine to yours?

Not yet, as it is still in my private space. I am waiting for Juha/Pierre to prepare an empty page, so I can move it from my private space. Should happen anyday I guess

Thanks for the "REST" link. I had seen it before, but apparantly searched with the wrong keywords this time.

Did not find an answer how a rule was called via it. Maybe I misinterpreted Michals remark.

Posted by pz1 at Jan 10, 2014 13:33

I think he means execute a command in the drools rule.

I AM doing that now (my REST API calls the Switch On/off, which has a rule set to monitor it, which updates the IMVC and executes the command).

My example of that is in my LightWaverF link (have a look), although the REST API link isn't (as that is for something else I'm working on - see my response to the speech integration thread) - but the IMVC/drools piece is done.

Posted by ptruman at Jan 10, 2014 13:48

Maybe I'm a bit pedantic here but I thought I would clarify the behavior of the REST API (and why my initial question of the API you were using).

The current API was mostly designed for communication between the OR consoles (a GUI interface) and the controller.
If you look at the "Send Write Command" calls, they're mapped to actions on the UI: click a button, toggle a switch, move a slider, make a gesture.
There is no API giving you direct access to commands, macros or rules.
The UI element is the entry point for these calls, which take its id as the key to know what to do.

That's why, when you wrote

if I use REST to call the IMVC command, it doesn't

, I was questioning which API you're using.
From your reply above, I understand that you're manipulating the UI switch, which eventually will trigger the associated on or off commands.
The id should then not be the id of the command, but of the UI switch.

Posted by ebariaux at Jan 12, 2014 14:39

Maybe I can link mine to yours?

The How To is public now here: OpenRemote 2.0 How To - In-memory Virtual Command Protocol

Posted by pz1 at Jan 24, 2014 14:07

I'd agree, you should use the switch (UI element) but there is a problem I was alluding to above

If I have a switch set to OFF, but then use a native (Non OR application) to change a device state you can cause all sorts of fun.

Imagine (as I have) my heating is controllable via OpenRemote, via LightWave.

I can use OpenRemote, OR Lightwave to control the heating. If I use Lightwave, then OpenRemote will be (rightly) unaware of the correct state of the heating, as it did not set it.

So - if I use OpenRemote to turn the heating OFF, then use LW to turn the heating ON - OpenRemote would still think the heating was OFF.

If I clicked the OpenRemote switch (which thinks it's off), it would send the "On" command. This would bring OpenRemote back in sync with the actual state, but I'd have to click it twice to force it off.

If I call the actual IMVC "Off" command, I know that OpenRemote WILL send the "send the off control via Lightwave", so the device WILL be off. If the IMVC was polled, rather than just event triggered (by a UI event) then it could bring the switch into the correct state regardless.

This works for Philips Hue, where an HTTP GET sensor polls, and sets a state. But IMVC doesn't allow you to set a poll interval.

It's an odd use case maybe, and technically only needs "two presses" to correct, but if you are not in line of sight to a device, and want to be reasonably assured it's off (or on), the IMVC->Command path is safest, but currently leaves the UI out of step.

Posted by ptruman at Jan 24, 2014 15:11

I'm sorry but I'm not following.

Why would polling the IMVC change anything? And what would it poll ?

The issue of state changing "behind OR's back" can't be fixed by changing anything in OR.
Either OR will receive a notification from the external system that the value change (e.g. KNX bus), either it call poll for state information from time to time (e.g. HTTP for Hue).

If you don't have that, then OR will not know about the state change.
IMVC is just in OR memory, so not link to anything external, so nothing to poll there.
The IMVC gets updated by OR, either via the UI, either via rules.
Updates via the UI is in fact the OR console calling the controller REST API to take an action.
You can call the same REST API yourself to simulate a UI change.

In your above example, if when LW turns the heating on, it would also use the REST API to turn the IMVC in OR to on, things would be in sync.

I don't know LightWave, but from a quick look at the HowTo in our Wiki, I see that it can report status back via UDP broadcast. That might be the best to keep things in sync.

Posted by ebariaux at Jan 27, 2014 10:02

"The issue of state changing "behind OR's back" can't be fixed by changing anything in OR."

You are indeed not following

I'm not on about fixing it in OR, but "catering for it".

This is a use case that will happen - as devices do have native apps (Lightwave allows for remote access to it's devices when away from home, as does Philips Hue) - so the easiest way to "guarantee" a state is set as directed, is to use dedicated on/off commands.

That creates ugly UI (two buttons), so switches are ideal - but prone to going out of step.

In my example, if LW turns the heating on, it does so natively, OUTSIDE OpenRemote. It does not use REST.
If I then use OpenRemote, the switch is out of sync. So if I want to use OR, I have to press the switch twice. Calling the switch via REST does not work, as I'd have to do that twice.

I have a "Master Off" macro which clicks a switch to turn things off, but if the switch is already "off" but the device is ON, the macro will 'work', but the desired state will fail as it will press it once and leave it 'on'.

So if I'm out, and turn the heating on with the native app, and then return home and click "Master off", the heating stays on. If I change Master off to call the IMVC off command, it works, but the UI remains out of step.

If I set the macro to call the IMVC off state, then the device off command is fired regardless, the state is set to off, and the only thing missing is that the UI is still out of sync, but the device/macro have performed as expected.

The current UI interface in this method is :

UI Switch (state) -> IMVC Command -> DROOL event (on or off) based on state of IMVC command

All I'm doing is :

IMVC Command -> DROOL event (on or off) based on state of IMVC command

If the Switch tracked the IMVC command, or we could have a sensor which polled IMVC, this wouldn't be an issue.

Eventually I hope to eliminate the native app by providing a Tasker interface which talks (when out of the house) via a secure/trusted channel, to REST.

Posted by ptruman at Jan 27, 2014 10:16

If the Switch tracked the IMVC command

That's what it's supposed to do, so that's what I'm not getting.

Let's say you're using 'A' as the address for the IMVC. You then have 3 IMVC commands: ON, OFF, STATUS
You have a sensor, using command STATUS.
You have a (building modeler) switch, using the above sensors and the ON and OFF commands.

In the UI, you have a UI switch, using the above defined building modeler switch.

This UI should always stay in sync with the IMVC value, irrelevant of the way it's value has been set: from buttons, from rules, from the switch...

If you want, you could send me an invite on your account (eric at openremote dot org) and I can take a look at how it's built.

Posted by ebariaux at Jan 27, 2014 10:38

I'm going to double check something later, but have a sneaking suspicion I have either (a) had something bizarre going on my server or (b) used "click" instead of "on" or "off" in the REST API which may cure this.

I do have another question though, but will post that on another thread

Posted by ptruman at Feb 10, 2014 13:18
Document generated by Confluence on Jun 05, 2016 09:37