I forgot to document a change in 1.0.6 : the openhab2-out node now doesn’t translate the input payload anymore to ‘ON’ or ‘OFF’. Maybe that explains the openhab2-out warnings.
I created a subflow with a function node containing following code and reuse it in front of several openhab2-out nodes:
switch (msg.payload)
{
case 0:
case "0":
case false:
case "false":
case "FALSE":
case "off":
case "OFF":
msg.payload = "OFF";
break;
case 1:
case "1":
case true:
case "true":
case "TRUE":
case "on":
case "ON":
msg.payload = "ON";
break;
default:
break;
}
return msg;
I’m not sending on/off, I’m sending a string/number that counts up from 1. Some other nodes are sending other Strings such as electricity cost. Have you tried the out node with the latest 2.2 snapshot? I’m worried the rest API formatting changed or something, because the error in node red is “request error ‘Error: Argument error, options.body.’ on ‘http://127.0.0.1:8080/rest/items/OH2_Watchdog/state’”
I’m still on a release version OH2-2.1 (I don’t want to run my home automation on non-release versions).
I’ll install the 2.2 snapshot on a separate machine to run some tests.
If it’s too much trouble for you to debug I can just switch to stable branch, unless others start reporting the same issue of course. I initially only meant to use the snapshot branch while oh2 was just coming out, but by now all the features I need are in stable
Thank you so much for the fast work! 1.0.8 is working great now. If it wasn’t dependent on OH2 version I’m surprised more people didn’t report a problem. I guess not many are using the write function?
The issue only happened where the payload was not a string, but e.g. a number.
And the issue has been introduced only a short while ago.
So probably most installations were not affected
it doesn’t personally bother me but just in case you want to know - it seems the write node no longer displays the current value/status under the node. It still has the green square but no value next to it. Maybe I’m imagining things and it never did this? I honestly can’t remember The input nodes definitely show a value under them
Hi Jon, sorry for the long delay …
The output node never showed the status of the node, only gave an indication of the last request to change the state.
I started with nodered to receive messages from Telegram and send it to openhab. But i dont receive in Openhab the message content i send in Telegram. I created a Telegram “receiver” and a openhabe “openhab2-get” object. I implement a debug node, too. If i send an message like “test” i see it in the debug screen, but i dont receive it in the openhab stringitem. What s wrong?
To answer it: 50-50
I’m playing around with node-red for a while and moved the automation part from OH there. It is indeed more convinient than the text files from Openhab.
However I have a few downsides which starts to annoy me more and more which makes me wondering how long I might stick to node-red.
event based handling. For my rules I commonly need a “are all doors closed” and similar which is quite tough to get working in NR. In terms of maintenance its a nightmare!
timeouts. Something like: if nothing happened for 10 minutes do … is surprisingly hard. Can be done but needs more tinkering than I expected.
inputs. The json data has no consitent structure. I constantly keep changing it to ensure it meets the right format for further handling
storage. Since I run NR my SD card is full every week. It seems NR keeps a lot of backups or … I haven’t figured out why NR is already GB in size…
complex rules are unreadable. There are very soon a web of lines and boxes. Workaround can be the link node or global variables. Its still a weakness which needs a workaround. Instead of tinkering my rules I feel more as a designer these days.
on start of node-red all OH items are pulled. This triggers rules even yet no actual event happened to the item. This bounce can be filtered but again needs several nodes for each OH input to make it work.
made for nerds. To use NR you need to have a programmer mind. I thought OH tries to address an end user with easy to use interface. NR is for me the expert edition.
As above is quite annoying to me I started to write functions. In essence it’s the same like oh text files - just on a web front-end.
I hope instead of using another engine which still doesn’t suit well we might spend those efforts on getting a proper rule engine done.
And finnaly a fear: node-red might replace entire OH the moment someone starts to develop nodes to communicate directly with zwave devices. If that happens OH would be basically obsolete.
timeouts. Something like: if nothing happened for 10 minutes do … is surprisingly hard. Can be done but needs more tinkering than I expected.
I found that setting a trigger node, were there is a delay like this:
storage. Since I run NR my SD card is full every week. It seems NR keeps a lot of backups or … I haven’t figured out why NR is already GB in size…
I think you must have use some kind of database function, it seems that the NR only makes one backup of my flow and the current.
complex rules are unreadable.
I made multible flows which could contain my flows: if you need more levels you can use subflows, but yeah it would be nice with more levels.
made for nerds. To use NR you need to have a programmer mind. I thought OH tries to address an end user with easy to use interface. NR is for me the expert edition.
You don’t need to use the NR interface, I prefer the OH with the easy cloud acess.
I think is nice that you are not bound to a special system for making your rules. I have been thinking about using some of the binding from home assistant and incorporate it into NR or maybe using their quit nice interface.
I don’t hav this issue on my setup with a lot of NR rules.
For complex rules you can install specialized node or make subflow.
In node-red I hav only 1 function node (with 5 lines, because I can find a node for encrypt a password to call Nissan carwings API)
NR is not perfect but it’s quite simple to use. But you need to add some others node (FSM, traffic, scheduler) …
Agreed. Some very early fiddling around shows a lot of promise. With node-reds MQTT support I see good things coming with home made sensors using ESP8266 etc
I tried Node-RED out a bit in the last days. Already made some progress but still lacking on some basics. Would be nice to get some practical advise:
What is the correct syntax to change the color of a color item to let’s say “red, 50% saturation and 50% brightness”. Let’s assume using the inject node on one end and the openhab node on the other side.
The input nodes definitely show a value under them
