Node-RED as a rule/script engine for OpenHAB

rules
node-red
Tags: #<Tag:0x00007f1837cd2cc8> #<Tag:0x00007f1837cd2ae8>

(dalibor) #101

I am also considering to using node-red, I think in the long run is much much easier to have better control over the rules (and improve waf). I am still in the beginning of migrating to openhab from domoticz, and I am curious about mentioned “advanced rules”, f.eks. can node-red query some other sensors/information from openhab when it runs a rule?

Like “motion triggered, but tv/some switch is still on, do nothing”. Can it query state of “tv/some switch” from openhab, or does it need additional storage, in parallel openhab?

Also, is it “as easy” working with global variables or conditions (f.eks. having one script that determines and defines if living room is occupied), and sharing those conditions with other rules?
So that lights go off only after certain time, and only if the $livingRoomIsOccupied is 0, and only if $livingRoomIsLitt == 1 etc (each variable is defined on their own separate rules and sensors)?
Would these “globals” live in openhab, or persisted somewhere else or?

Thank you for the hard work on this.


(Rgerrans) #102

Yes, with the latest release of the OpenHab nodes you can trigger the lookup of an oh item state during a flow.

Yes, you can set global or flow specific variables using a Change node and use them in other flows through either Switches to check the variable or Change nodes to interject the variable value into a flow. You can also use link nodes to trigger events at the time a variable is updated.

Back to your first question, many times I’m just setting a tracking variable when an Item’s state changes rather then having to keep looking up a Item’s state.


(Rgerrans) #103

I’ve been out of town the last two weeks and am now getting back into finishing my migration. I thought I’d check in to see the status of the code changes?

Thanks.


(Rgerrans) #104

I’m now trying to pull the object topic out from the raw data:

6/25/2017, 7:54:32 PMnode: 5150a5e1.f5862c
msg.payload : Object
object
topic: "smarthome/items/Lock_GF_Living_Username/state"
payload: object
  type: "String"
  value: "Parents"
type: "ItemStateEvent"

I tried pulling the value of msg.payload.topic but using that similar syntex doesn’t give me the “smarthome/items/Lock_GF_Living_Username/state” I was looking for. Any other thoughts?

Edit: Nevermind, I was using the right “msg.payload.topic” just had an error in my change node.


(Peter De Mangelaere) #105

But this sounds like the behaviour that is implemented on channel1 of the openhab2-in node ?


(Rgerrans) #106

That is what I’m experiencing (Channel 1 being ItemStateChangedEvent) To follow-on, I think it would be helpful for a 3rd channel to capture the ItemStateEvent. I set up a switch on the 2nd channel to do so for now but would allow me to eliminate a step on some of my flows.

Edit: Also, I shouldn’t have grabbed that example. It’s more the integration of the switch into the openhab2-get node I was particularly interested in.

Thanks


(Rgerrans) #107

@Peter_De_Mangelaere I updated to the newest node-red today and now I’m getting 404 errors from the OpenHab node monitor. I’ve verified that I can get to the rest api from the /rest/items/ so not sure what’s causing the issue?

Edit: Nevermind, looks like a reboot solved the problem.


Node-Red Input node can not get Item state (OH2.1.0)
(Rgerrans) #108

@Peter_De_Mangelaere I’m definitely having issues after the upgrade to Node-red 0.17. the openhab-in nodes are not updating. I can trigger a get node and it pulls the right state but the in node shows a different state.

Edit: I switched the node configuration from localhost to 127.0.0.1 and now it’s picking up changes again. I’ll watch it to see if it freezes again.


(Frank) #109

I am seeing my STATUS messages being sent twice. Any ideas why this is?
This is my config for the eventbus:
broker=mybroker
commandPublishTopic=/myhome/in/${item}
statePublishTopic=/myhome/state/${item}
stateSubscribeTopic=/myhome/out/${item}
commandSubscribeTopic=/myhome/command/${item}/state

Everything else works fine, just the status is reported twice every time.


(Rgerrans) #110

That’s an issue with the mqtt event bus, not Node-RED. You can use rate limit or by exception nodes to filter them out. Or use the node add-on from this thread to get updates from the rest API instead.


(dalibor) #111

yay, got my first rule set up. It was super easy (not actually, it took me quite few hours to figure it all out, but only because I am new to openhab and node-red). But now it works as intended :slight_smile:
It is the rule that will turn on, and automatically turn off the wall plug after some time. In this case it is controlling my primitive “batteries charging station”

The switches on the wall are arduino MySensors (before xiaomi made nice-looking buttons for similar price), and they are controlling z-wave wall plug (TZ68, i think). And this is the rule taking click from the button, turning on wall plug, and at the same time setting the appropriate timer. If the buttons are pressed while the wall plug is running, timer would cancel and wall plug will turn itself off

Now the only consideration I have about using such long timers with node red, is that all rules are restarted if any rule is changed. F.eks. if I am making some other rule while my 4h timer is still running, the timer would reset, and my wall plug would continue to be on for ever. Which is kinda making it a bit unreliable now that I think about it. I guess one could/should make additional backup rule for critical things, but still. It would be nice if node-red would not reset ALL rules if you only change one of them…
Please provide any tips&tricks, as this is my first time with openhab, and with the node-red :slight_smile:


(Rgerrans) #112

I’m not home but I thought there was an option to only update modified flows.

If not, once you get all your rules setup you aren’t likely to be updating that often. You could see if flow or global variables survive a refresh. Otherwise if critical you could use OoenHAB virtual items as a sort of persistence to store key data in (like delay times).

Just a few thoughts.

Edit: @dakipro I verified this morning that you can change your deploy option to only deploy modified flows (or down to modified nodes if you wanted to get more granular)

image


(dalibor) #113

Well that is awesome, I am now looking forward to building more rules :slight_smile:
(I saw that option, but seems like I didn’t understood what it meant before I started messing with the rules)
Thanks! @rgerrans


(David Schulz) #114

I am loving Node-RED! I’ve been tinkering around with text rules for months now and while I got some things working, I could not get the syntax with reading the state of my HarmonyHub to trigger a rule for love nor money. A few minutes in with Node-RED and I solved one of the problems I had been struggling with.

Hopefully someone smarter than I can help me solve the following. I want to have a series of lights turn on in the living room on sunset. The lights above the TV should only come on if the current activity is one that doesn’t use the screen.

So I created this flow.

The timer node initiates the flow no problem. The lamp and the cabinet lights come on no problem. The TV lights do not come on even though the Harmony Hub reports the current activity as “PowerOff”.

The first of the three cases defined in the Current Activity switch PowerOff.

The following is the debug output from the debug node when the flow triggers this evening.

link: "http://localhost:8080/rest/items/harmonyhub_hub_HarmonyHub_currentActivity"
state: "PowerOff"

So the activity PowerOff matches the first case defined in the switch, why then does the switch not get turned on?

I’m using the msg.payload property successfully another flows to read the current activity from the Harmony Hub.


(Rgerrans) #115

You need to put in a Change node after your Harmony check to change your msg.payload to ON to trigger your light.


(David Schulz) #116

Thank you!

Obvious now you point it out. The flow was sending the harmony activity descriptors to the switch but all it can understand is On and Off. Hopefully all will work as expected this evening.


(David Schulz) #117

I have made the change you suggest and I’ll see if it solves the problem, but on reflection, I am not convinced. The Current Activity node exits if the current activity matches any of the node definitions. The openHAB out node is configured to pass a payload of “ON” to the switch.

I have just changed the current activity node from checking all rules to stoping after the first match. I’m not entirely sure if that will make a difference or not…


(Rgerrans) #118

Double check if you have the latest version of the OpenHAB node. There was a version that had issues with passing the in node command though if your other -out nodes are working that’s not the issue.

You can also add a debug after your activity check to make sure there isn’t a typo causing issues. The stop after first shouldn’t be an issue since your checks are all unique strings.

Also, there is a separate Harmony node within Node-RED that is working well for me.

One other thought is to make sure that your sending the right command to your TV light (i.e. switch vs dimmer). I use an injection node directly into a device to verify that I’m sending the correct payload.


(Rgerrans) #119

FYI, just stumbled on additional contributed nodes to help simplify home automation flows (for things like state variables): norelite - https://flows.nodered.org/node/norelite I will start experimenting with them and likely update this tutorial to incorporate their functionality in place of some of my workarounds (like stored variables).

@ThomDietrich This might be a nice add on to OpenHabian’s Node-RED library. Haven’t started working with it yet but looks pretty promising to simplify some of my flows.


( ) #120

If you say so, no problem on my side. Could you provide either an Issue Ticket or a PR?