That’s a full rule to toggle all outdoor Sonoffs that control lights to turn ON/OFF when a Xiamio is pressed, double pressed, long press or long release.
May approach would be mostly the same, assign a “virtual” item like
Can you show me your your function node? Just tested it in my setup. I have a 4way RockerSwitch with 1 Channel per side and this function node returns one of the possible events on each output no problem.
Try it like this. If I get you right you dont actually need four but only three outputs on your function node. One for each case. Another question is do actually need the released event even? Else eve 2 would be enough.
var event = msg.payload.event;
var channel = msg.payload.channel;
if (channel === "velbus:vmbgp2:c5053467:24:input#CH3") {
if (event === "PRESSED") {
return [msg, null, null];
}
if (event === "LONG_PRESSED") {
return [null, msg, null];
}
if (event === "RELEASED") {
return [null, null, msg];
}
}
return null;
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
201
Hi
Thanks for your help.
There is a good use case for including the RELEASED events into this logic, as there are some situations where an action is needed when the button / input is pressed and another when it is released.
For example…
Start on Press
Stop on Release
What I am trying to create is a Generic Solution that I can save in a library and adapt for real world flows.
It looks like I can use either solution, but I can’t use both in the same IF Function.
The version with the IF Function to filter the button and a Switch to filter the button states, then with some triggers to reset the Debugs so that new events can be seen in the Flow, looks like this
That was a really good question. I have used both of them a couple of weeks and decided to go with node-red-contrib-openhab-v2. I hope that wasnt a mistake.
They are very similar, but a couple of smalls differences: node-red-contrib-openhab-v2
Does have a few more configurations, for example, “Event types”
It does miss an output, so you can use the out-node and continue to wire another node
Thanks for this post. Nodered is absolutely awesome. I migrated most of my rules already. Once I have grasped the concept the migration was extremely fast and the rules are even more reliable now.
@Kai - Nodered should be considered as standard rule engine for the next major openhab release.
@bummzulu
Node-Red is great and very useful as it has a number of integrations not available in openHAB.
Things like scheduling and heating control are easier to achieve
BUT node-red has great limitations too…
How do you check the state of an item INSIDE a function node for example?
How do you create a rule with a trigger like Member of gGroup changed ?
Very useful but not sufficient for a full home automation engine without serious fiddling
Actually both can be achieved over the rest api of openhab. You can for example create a sub flow that internally polls openhab regularly or just on deploy for the members of a group and updates a flow variable in the sub flow accordingly. This Array in the variable you can than use to filter an sse event stream from openhab. If you put both in a sub flow and use an environmental variable to construct the URL you have a reusable node where you just have to enter group name and you get any events inside that group. As for using the state of something inside a function, I either split it and use an http request in the midle to get the state. Or for item states I use alot I write them to flow or global variables on any change. The only trigger I haven’t been able to replicate is received update.
But yes their will always be the same limitations that everything else that communicates over the rest api or mqtt has. The internal Rule engine just has a deeper integration.
Best regards Johannes
Thats what makes it fun Especially in Nodered it’s so quick and rewarding to build/automate stuff and my description makes it sound more complicated than it really is.
I use a flow or global variable to check the item state within a function node. That is no fiddling for me.
Checking the group events might be more tricky but I have not used that so far.
I don’t want to bitch about openhab. I love it and it is the only open source project so far that convinced me to donate money regularly. Just wanted to point out that the great developer team might save time on developing as some really good solutions are already out there and they can focus on even more innovative things for the nexts major release.
Nodered is already included as an option in Openhabian were it comes ready with the Openhab nodes installed. That is as far as integration will go I’m afraid. I’m a big fan of Nodered and use it a lot but I can see the need for openhab to be an all in one Self sustained solution and Nodered can never become part of that as it is completely independent project which is outside of the control of the openHAB project. So it would create unnecessary dependency on another project. So I guess we will have to live with the limitations of the Rest api for now.
Best regards Johannes
its the best thing that can happen to noobs all over the world
but serusily , i was able to do some seruis workarounds with node-red, i am not sure OH is that
flexible , in node-red you can get things worng and still make it wrok
also its alwys good to have another way of doing things, when all goes bad