I have made several automations in Node Red and they all work fine. The most recent one is where I use a motionsensor and trigger a light to turn on - depending on which part of day it is, the dimming interval is different. When I enter the room it now takes around 3-4 seconds before the light turns on, which I think is too long. I have tried to make the automation just to turn on when movement, but that is the same latency.
When I used YAML the automation ran in about 1-2 seconds. It might not sound as much of a difference, but in real world it is very noticable.
Can anyone recognize that Node Red is slower than YAML? Is there any way to optimize so the lag time will be reduced?
First I tought I could program all my buttons for all lights with it, but every push resulted in a âlagâ of 3 seconds or so to turn them on or off. Since then, Iâve made everything with Hass.ioâs âautomationsâ yaml file, which has no âlagâ at all.
I think NodeRED also gives a massive overhead over Hass.io itself. The entire Hass.io is slower to restart with it enabled (60 sec vs 120 sec).
Iâve started using NodeRED as well and I dont see that lag?. do you have many other services running in your Pi? have you monitor the load on you cpu?
I wonder if it will help to move NodeRED to a diferent pi
I just did a very user specific measurement of responsetime.
I have my motionssensor to turn on or off a light using only the binary.sensor - meaning no additonal rules on top of it, just simple turn on or off.
I measured the time from the green light flashing on my motionsensor until the light came on. I also measured from I entered the room until light came on, but the end result was the same.
In YAML it took on average 1,2 sec to turn on.
In AppDaemon it took on average 2,9 sec to turn on.
In Node Red it took on average 5,5 sec to turn on.
I did miss the stop timer once for AppDaemon, so I actually think the responsetime is a little bit faster than above.
In real world YAML and AppDaemon seemed almost equal, but Node Red feels significantly slower, which the measurements also support.
Non-pi user here chiming in, I switched some light automations triggered via motion over to NodeRed and tested the response time when I initially did it, no change. I had it also triggering a WiFi light (over MQTT) and one over Zigbee just to make sure it wasnât the end point. I also have a few motion sensors triggering into the pool to test to make sure it wasnât a delay on the motion sensor either. Of course the Zigbee light was usually slower than the Sonoff WiFi light, but I havenât seen any noticeable delay, itâs damn near instant and hard to measure. I did notice after the recent 0.73.2 upgrade that it was taking 3-4 seconds but a restart of the NodeRed container fixed the issue, not sure if something was hung up.
I have a pi 3 non plus with ha, openhab, deconz and node red and since Iâm doing rules with node red is instant. Which connector do you use? Iâm using the web socket version.
Openhab did not have web sockets and itâs a huge difference as I donât need to poll anything it just arrives by magic. I realized that when started using web sockets in node red with deconz.
I would be curious to see if someone that is having performance issues would have NodeRed monitor a MQTT topic that the sensor would publish to see. Or if the sensor doesnât have MQTT, have HA post the state to MQTT. Might help determine where the delay is happening?
I have had slowness issues on hassio. I wonder how may of you guys are using SSL and or port forwarding for HA?
if so do you have internal DNS setup for the external address? If not like I was your going through your router and back in on the external IP between NR and HA. This was introducing a delay for me.
My router does not support adding DNS entries so for me i remove SSL off everything and setup NGINX for external access. I then changed the NR configuration node for HA to http://127.0.0.1:8123.
I had to give NR a restart for it to take effect for some reason
I moved my Node-Red onto a dedicated RPi a while back and have not had any long repsonse times since.
At the time the Node-Red and HA was running on the same RPi I realized some longer response times as well. This was mainly after I had done several noder-red deployâs (more than 20 times) during debugging or testing activities. After a full restart of the RPi the long response times were usually sorted.
I run HA on a HP micro server in a linux container (LXC not docker) and NR as another container. It is not exposed to the internet.
I use a combo of Hue motion sensors and Xiaomi motion sensors that I have in practically every room and as soon as I walk in the lights come on - whether that be a single colour or hue scene (I use predominantly hue bulbs, though I have a couple of lights hanging off Sonoff S20 sockets using mqqt). I am currently using the HA LLAT node (not websockets) for connection back to HA as the websocket one seems to work for an hour or two then go stale in my environment.
What I did notice is that i used to use a node called Hue Magic in NR to do all the automations and the response time was 3-4 secondsâŚway too slow for walking into a room. I now use the HA node for everything and it is pretty instant. It is âwife proofâ in that she never reaches for the switch so that in my book is ok
Hello, I suffer from the same issue (3-4 second response time when pressing a switch is not ok).
I am using Node-Red in a docker alongside Hassio running on a XU4. Bu default I use the home-assistant nodes (not sure if they are web nodes or not).
Yes that is the one - I have tried moving to the web socket one a couple of times but I keep having timeout issues so have stuck with that one. I know it is not being actively updated, but it works
I seem to have shaved quite a few seconds by moving the MQTT broker to MosquitoâŚ
It looks like the move to LLAT will require me to âredoâ the automation flows (due to conflict with existing websocket package)
