Motion has always caused me a few problems in NR, but this is supposed to work. Unfortunately my “Away Mode Off?” and “Evening Mode On?” current state nodes are sometimes (but not always) blocking my messages, despite the states being correct in Hass. I debug with inject and debug nodes and arrive at the same result.
Has anyone else had a similar experience where a current state node blocks a message incorrectly? I can’t for the life of me figure out what’s going on. Help!
There was a major update to the NR module second half of last year that caused a lot of problems for me. I had the same issues where I knew the state was correct and NR would process it differently. It turned out that the version update, despite the nodes being pretty much identical, had some kind of background change that affected it. I basically had to go through a replace every single Hass node with a new one to get it to work again. And by replace, I mean, drag and drop brand new “current state” blocks, for example, and mirroring the contents of the old one, then putting it in place of the existing one. PIA but no problems for a long time now.
Don’t know if this is your case, but if you have had flows that used to work, experiment with replacing the nodes in a few flows and see if it changes.
EDIT: On the page from the forked version you linked, it says this:
Project status
Project is going through active development and as such will probably have a few 'growing pain' bugs as well as node type, input, output and functionality changes. At this stage backwards compatibility between versions is not a main concern and a new version may mean you'll have to recreate certain nodes.
Just a suggestion for using Node-Red and Home Automation in general:
Use Telegram bots for very quick messaging/logging/interact. I have 3 separate Telegram-bots with 3 different ‘ring-tones’. For example:
Bot 1, just for logging, no sound, no popups.
Bot 2, state changes, like house state from home to away, just a beep sound when message arrives.
Bot 3, alarms and critical messages, off course with a lot of noise and actual camera pictures from the breached zone.
I’m using this for more then 3 years now and it is very, very fast. You can also create Telegram buttons and menu structures to send commands. For example for checking who is at home, check the alarm/temperatures, and so on.
The interaction, in my case, is done by MQTT communicating with several Home automation systems like Athom Homey, Fibaro HC2 and planning Home Assistant (new to me).
Their are several nodes available, install node-red-contrib-chatbot to your Node-Red palette.
This is also for usable for Facebook Manager, Slack, Viber and Smooch.
I started using node-red last week. I’m still learning and having some problems, but THIS would be really cool. I hope youre going to create some sort of tutorial.
You hold down the button and the light dims/brightens gracefully (it transitions over 0.5s intervals, with fibonacci increments/decrements). The longer you hold the button down, the faster it dims/brightens. It alternates dimming and brightening. If the light is off, and you hold the button, it will brighten slowly from 1%.
I have tested it with LIFX and Lightify bulbs (single and groups) with satisfactory results.
Well I’m using a different fork. It should be backwards compatible with upstream, but in case it doesn’t work, that may be why. Are you able to access msg.data.attributes.* from a current state node (override ticked) in the normal fork?
Also, I modified it a bit. It will pause just under two seconds before the light turns off in order to give you a little reaction time if you want to leave the light at the dimmest point. I also added some comments in case you’re interested. Also look at “IMPORTANT” if you have anything other than LIFX lights.
At the end of this flow I also plan to turn on a “Manual Override” input_boolean for each light. I use motion sensors and Flux and if anyone alters the brightness I want the lights to respect that until sunrise.
Anyone notice some lag - 3-5 seconds for lights and such to go on after a motion is triggered? I’m using the Hue component to manage all my motions, bulbs and remotes. They’ve always been pretty instant, but since moving the community Node-Red from the notorious version, things have become more delayed.
I’m using the proper URL for the Home Assistant server in the configuration node field: http://hassio/homeassistant
I had a similar experience, it was actually so slow that my wife rendered it unusable. This combined with some reliability problems moved me to appdaemon which in my case is a lot quicker to respond. I do like the way flows work in Node Red so if the speed at anytime improves I might give it a second try.
I have as well migrated all my automation onto Node-Red and have now much more complex flows than ever been possible with the HA automation.
I as well have noticed that sometimes the Node-red response is getting much slower. I have now scheduled a daily reboot of HA and the responses are as good as with the HA automation.
However, I don’t want to have the dependency between HA and Node-Red and currently testing to migrate to a dedicated Node-Red RPI. First trials are showing very quick responses, even faster than HA but I have to migrate all my flows before going for a final verdict.
Anybody else migrated Node-Red to a dedicated RPI ? … Andy advise/tips ?
… have now implemented basic messaging via telegram … and works perfectly!
