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.
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?
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.
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.
@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.
@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.
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.
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.
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
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
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)
Well that is awesome, I am now looking forward to building more rules
(I saw that option, but seems like I didn’t understood what it meant before I started messing with the rules)
Thanks! @rgerrans
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.
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.
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.
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…
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.
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.
)…Done