Rule Machine® Introduction

No, I just meant from the main UI. I have a feeling that my problem was actually that clicking a config or status link took me to the wrong place (/configure/1) and I just didn't notice. In which case, it was always working, and I just can't read my URL bar.

Can we get the ability to execute other web calls?

What is it that you want? Post and Get? As actions?

1 Like

YEs. Post and Get would be awesome!

I think that (http get) would allow me to get rid of my custom app and just use the RM to trigger my cameras running on my iSpy server. That would be nice.

Since we are talking about cool things to add.

Have you given much thought to introducing variables (like webcore) to help with notifications and reporting and elaborate conditional statements?


Frankly, no.

"Elaborate conditional statements"? Provide an example use case.

So, back in the webcore days I would take advantage of the variable features to establish variables that would change (mathematically) and then represent conditions.

A simple one, for example would involve setting a variable to capture average temperature over a period of time. So: (i) variable 1 = temperature at 12am; (ii) variable 2 = temperature at 2am.

Then I can average the two to determine whether into the main variable ex (avg. temp).

If avg. Temp. drops below 70 degrees then turn on heater.

Alternatively... you could capture temperature at a time #1 and set that as the variable and then capture a temperature at time #2 and if the difference is greater than a number trigger an action.

I did this with rain (HE does not have rain measurement yet), but I would turn on the lights outside if it began raining and the test for rain would be calculating the amount of rain over a period of time and storing that as a variable to turn on the lights. Then if rain amount average over a period of time would fall below that level I would turn off lights.

There are many use cases and believe me your clever customer base can think of many many more.

I guess simply put, you have private booleans in RM which are nice, but nowhere nearly as powerful as variables.

Another nice use condition is that you could store variables for messaging purposes. Right now, I have an alert if a door is left open and the message/announcement is "The door has been left open - [device name]"

If I captured the device(s) as a variable the message would say "The [device name] has been left open".

It would literally put RM on par with Webcore and eliminate any possible need for webcore in the HE environment

PS - I no longer run webcore and am committed to automating through RM

This would go beyond just variables, but also entail doing computations based on variables and other values. Same with your example of a delta exceeding a value.

So it seems that what you are describing is a desire for a computational abstraction that includes variables. Just pointing out that that's a good deal more than the idea of a variable such as you describe for the messaging use case.

WebCore essentially created an interpreted programming environment on top of Groovy, which is itself an interpreted programming environment running on top of JVM. The result is unwieldy, IMO. Rule Machine attempts to strike a different balance with basic functionality. I'm not keen on adding complexity to something that most users already find complex. Having said that, I will think about your suggestion.

I have the same situation, wishing to average some Lux measurements. My plan was to write a small app as soon as I learn how, Right now I working on DHs.
In my mind the app should be simple:

  • Initialize a state variable to 0
  • Trigger the app when readings are to be taken either by RM or RunIn
  • Take reading
  • Average
  • Update state variable
  • With another RM trigger do what you need to on the state variable. Hmmm I've not looked to see if RM will trigger on a state variable.


State variables are private to the app they belong to, What you'd have to do is use a virtual device. For example, you could have a virtual lux device, and set it to the average lux value. Then RM could trigger off that device.

Understood. Webcore is a beast for sure. Even capturing the state of a device to later use the state in a notification would be helpful.


Thanks, That's the way I will go. Now if I could only get my Fibaro RGBW going I could use the inputs to test the average function.


RM does capture the device that causes a trigger or rule evaluation, and it is available to a notification. By virtue of the rule or trigger logic you know something about it's value. You're saying you need its actual value also?

For example, for any binary sensor, you know precisely its value. For something like temperature or lux, you know that it just crossed some threshold you put in the rule, e.g. temp < 30.

A variable example (without calculations)

I have multiple temperature sensors upstairs in my home and create a rule that says if any of sensors A, B or C temperature < 60 then turn on upstairs A/C and play notification: "I've turned on the upstairs A/C because [sensor (A, B or C)] turned on.

You could even make the rule more complicated so that, depending on which sensor drops below 60, you could turn on the heat upstairs, or downstairs or both. . . But the notification would be instructive "I turned on [device] because [sensor A, B or C . .] reported a temperature below 60 degrees.

Even cooler. . .

You could take the average of several sensors in an area, say upstairs and then use that as the condition (but you addressed sensors).

My point is RM really works great, but sometimes when you build a complex rule with multiple (and practical) trigger points you need a notification to understand why the Rule ran. Variables can streamline that.

@JohnRob - Another option would be to use a custom Driver for your Lux device. Within that custom device you could add some user preferences to enable averaging. This way, the illuminance attribute that is exposed would already have the appropriate averaging/filtering applied. Lots of options available.

What result?


Thanks for the suggestion. However my Lux sensor is part of an Aeon Multisensor 6 where the DH is built in (so no tweaks).
So for now I'll stick with the small app.


I looked at the available virtual devices and for my Lux I could use the dimmer device. I could also use the temperature device.

However I would be nice to have a virtual device that reported arbitrary units with a range limited by Groovy (both + and -). It could be a catch-all.


The simplest virtual Driver for Illuminance would be something like the following. This very simplistic device assumes that a Parent App or Parent Device issues a proper child.sendEvent() call to update the device's internal illuminance attribute. You could add a parse() routine if desired, to allow the parse() command to be called by an external app. The parse() routine would need the lux value passed in so the driver code can parse it. You could then implement averaging directly in the virtual device's parse routine before calling sendEvent() internally.

 *  Virtual Illuminance Sensor
 *  Copyright 2017 Daniel Ogorchock
 *  Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
 *  in compliance with the License. You may obtain a copy of the License at:
 *  Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
 *  on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
 *  for the specific language governing permissions and limitations under the License.
 *  Change History:
 *    Date        Who            What
 *    ----        ---            ----
 *    2018-07-18  Dan Ogorchock  Original Creation
metadata {
	definition (name: "Virtual Illuminance Sensor", namespace: "ogiewon", author: "Daniel Ogorchock") {
		capability "Illuminance Measurement"
		capability "Sensor"

def installed() {

You can't really have a generic device, as each device needs to implement at least one Capability. Each Capability defines the attributes and /or commands that the device must implement. A generic device would not be very useful to anything other than your own custom apps. Standard apps cannot take much advantage of custom attributes or commands (with a few notable exceptions.)

Where do we find the url. If I choose local endpoint i am never presented with the url.

Download the Hubitat app