This page last changed on Jun 15, 2013 by jmspooner.


I'm new so sorry if this has been asked but....

I run openremote on my linux server and currently I use some bash and php scripts to "fill in the gaps" around openremote, such as having spoken messages as a result of events, or sound effects etc.

Where I need to keep some info persistently stored such as "Its day time so pipe all sound effects to upstairs and downstairs computers" within openremote I setup a command that evecutes a shell script which takes two params, one being a var name the other being a value.. that var is then stored as a file in a temp directory on the server.... that way my other bash/php scripts which fill in the gaps such as the sound effect script can use those "stored persistent" variables to modify their behaviour.

So I was wondering if there are plans to store persistent vars within openremote and if so then even better if a shell interface is provided so external scripts/processes can use them? perhaps a shell command could be used or set them as environment vars?

Just some thoughts.


I'm not completely following the flow/idea - you would want to write a file from within OR (with some value in it) rather than using a shell script to do it?

Posted by juha at Jun 15, 2013 14:35

My idea is I have a small collection of bash and php scripts that do things I can't (currently) do in openremote. However those scripts may rely on the input of sensors handled by openremote.

So I guess really the sensors are the variables so either a means of querying them from the console or a means of having openremote support persistent variables which I guess could store their value somewhere a bash script can get to it would be good yes.

The goal is I do as much as I can in openremote because I love it! and as time progresses and features are added to openremote I can "hand-off" duties carried out by my scripts to openremote.

Also as openremote matures I can see a need for persistent variables being stored and used within the openremote environment.... such as only raising an alarm if the given sensor has failed 5 times in a row.... is that even possible at this time without some way of "counting" the failures?

Does that make my point?

Posted by jmspooner at Jun 15, 2013 15:15

Already a few simple crude but functional bash and php scripts are allowing me to do some cool stuff!

Here's what I'm currently doing after one day of tinkering:

1) Using my existing zoneminder as an automated door bell. When zoneminder detects motion on my drive a script of mine has the server play a "door bell chime". However my script ONLY plays the sound if I've got the doorbell feature switched on in my openremote UI.

2) Voice confirmation. IE when I turn on the doorbell function in openremote I have a voice say "doorbell on".

3) Voice and sound effects are pumped through the speakers of my server upstairs and my PC downstairs.

4) Voice and sound effects are muted on my server up stairs during daylight hours.

5) Using a bluetooth scanning script on my server, desktop pc and media pc openremote knows I'm in one of three rooms!

6) Nice indicator lights on my UI front page which light up green if my servers are up and running.

Posted by jmspooner at Jun 15, 2013 15:22

ah just discovered the REST API.... got some reading to do

Posted by jmspooner at Jun 15, 2013 18:23

Having looked over the REST API docs I can see how it works now.

Currently in my UI I have a button. The button looks to a "switch" the switch has an on and off command specified. Those commands look to two bash scripts I wrote, on sets a var in a var file to "on"... the other sets it to "off". Then there is a sensor which simply reads the var file thus I know the state of the on/off switch for the doorbell.

If its "on" then when zoneminder detects someone walking up my path then it triggers the sound a doorbell sound.

I can see if I used an X10 switch instead of storing a var then fine, it could all be done without storing a var in a text file on the underlying O/S.

However.... what if I want to keep it just to being a UI on/off switch with no physical switch in the real-world?

In that case openremote needs a switch object that "remembers" its own state and can be queried... which is what I mean by persistent variables.

Am I missing something major here?

Posted by jmspooner at Jun 15, 2013 18:54

I'll update this thread in case anyone happens across here looking for answers regarding variables.

I found the command type "In-memory virtual command".

It takes two params, 1st is "on", "off" or "status". That means set to on, set to off, get the current value.
The second param is a unique name for the virtual command which is essentially a variable name.

Using virual commands to store the states of meta-things such as is the doorbell sound feature switched on or off saved me having to store these states in external files and constantly read and write to them to update sensors. I quickly found that way can cause "too many open files" errors in java... that may of been a fault of my bash scripts or OR, I never figured it out.

If you have any external scripts that rely on knowing the value of the virtual commands then simply use the http OR REST API to get its value via a sensor that hooked into the virtual command (the sensor calls the virtual command passing the param "status").

I'm not sure given the name of this function what the original intention was in its design, but if it walks like a variable and talks like a variable then.... its a variable


Posted by jmspooner at Jun 18, 2013 08:42

This would be handy as a psuedo X10 switch state.
Send an X10 code for driveway light ON and then have the user interface reflect the state of the last command.

Posted by nwe at Jun 18, 2013 13:38

It is a typical use case for virtual commands yes. The downside is that in-memory state can get out-of-sync with physical device state if there are no means to request device status. Same issue you have with infrared typically. The variables provide some improvement to this situation but can still cause frustrating side-effects in the UI.

Posted by juha at Jun 19, 2013 11:47

You pretty much got it with the virtual commands.

Here's another example of using virtual commands in the context of KNX that doesn't provide status value from the actuator: Light switches in Cleaning Mode

Posted by juha at Jun 19, 2013 11:52

True, that is how it is in my current Home Automation app (Misterhouse). Every now and then MH gets out of sync with the X10 states, but I don't use X10 for critical things, manly for general lighting where it is quite obvious they are out of sync. In MH I do a ALL lights OFF at midnight and I do this 3 times per light output. The chances of them being out of sync after is rather remote.
So in this style of thing, something that is right 90% of the time is better than no state indication at all.

Posted by nwe at Jun 19, 2013 11:54

Ah thanks JUHA, X10, theres the use-case

I'd not realised X10 did not return a confirmation when a switch state is changed... hmm I'll have to re-think my X10/Z-wave choice when I go buy a controller. I was leaning away from z-wave as the kit seems more expensive. I'm yet to get round to reading up on both techs but I'm already sure the z-wave standard is newer and more advanced?

EDIT: scratch that, 5 mins reading and I'm going z-wave

Posted by jmspooner at Jun 19, 2013 13:53

I also have a need for persistent variables and the "in memory virtual command" does seem to provide some solution but then only for boolean type vars (on/off).
What if we want to store an integer or other type, this could be handy to store variables that can be changed in the UI and can be used in rules to create scenes.
It would be great if the functionality of the "in memory virtual command" would be extended to be able to store other data types.
However I wonder what happens to an "in memory virtual command" value when the OR controller loses power? Is the value stored on the device or is it really only "in memory".
An alternative (or rather extention) that could work to solve this would be to run a mysql database with a REST interface (see
With this REST we could create HTTP commands to do CRUD actions on the DB.

Posted by janver at Jan 15, 2014 10:20


Posted by janver at Jan 15, 2014 10:28

It seems that we are able to store other variable types in an "in memory virtual command", I just read this on

Then the question remains if the value survives a reboot, I'll try tonight.

Posted by janver at Jan 15, 2014 11:06

I just tried the persistence of an "in-memory virtual command" variable and the value does NOT survive a reboot so it cannot be used to store scene settings or other variables that should survive a powerloss.
I'll be looking into the phprestsql solution and replace all my "in-memory virtual commands" with that.
Any other suggestions are welcome...

Posted by janver at Jan 15, 2014 11:35

These variables will not survive a reboot. It seems the do survive a controller synchronisation action.
We do encounter some problems with rules after synchronisation lately (
The HowTo In memory Virtual Command is still under development. It will move to the public pages.

Edit: You beat me

Posted by pz1 at Jan 15, 2014 11:37

Thanks for your reply Pieter, I was actually doing something similar as is done in the Scheduled Scenes example (

So the scene is active while an in-memory var is "on".
Since an in-memory var doesn't survive a reboot the scene will not continue if there is a power loss so there is a clear need for a database (of some type).
Ideally there would be some type of virtual command that would store it's value.

Posted by janver at Jan 15, 2014 11:50

After some more consideration I will first try to access the database using shell commands.
Phprestsql looks like a good solution but it does require installing a webserver (apache/nginx) and php while accessing the database with shell commands only requires mysql making use of the command line tool:

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