Only that I missed that one!!! 
- looks good have to check it out.
You know - I have stayed away from the output 1 for some inexplicable reason.. only use #2 - will have to revisit.
It seems I am prone to over-engineering things which might mean I'm compensating for something 
. Thank goodness that refactoring is easy with NR.. thanks!
Funny. I literally have never used any output other than #1 from a stoptimer node.
1 Like
I think it was my mindset when I really started getting into things NR. Once I went down that path.. and as long as things were working just kept going.
edit1: thats why I am extremely grateful to have this forum and the different perspectives/experiences/expertise people bring.
edit2: After looking at it some more by not using #1 I lose the message, which in hindsight may be bad NR form. I do use #2 to tell me if the timer expired or has been stopped which I find very useful for my sequences.
1 Like
Simple! I'm not sure if I just completely didn't think about doing it that way, or if it was because I liked the idea of having a fancy message like "The sensor's last temperature update was x minutes ago." hehe 
I started looking for the easiest way to calculate an interval between 2 timestamps, and then just found that interval-length node.
The number of times I look at something I did a while ago, and wonder "Why did I do it that way?" (eg. barely a day ago when I chose the interval-length node vs a simple stoptimer 
)
I'd love to know what line of thinking brought you to using the 2nd stoptimer output vs the 1st. I, like @JasonJoel, also only ever use the 1st, but that's probably because that's how I first saw it used in an example.
So the reason was/is I can differentiate between timer expired or stopped (I use the "stop" command to halt a timer on occasion) and control things from there. I wasn't too concerned about the original message.
here is a simple hard-coded non-subflow example:
warning this is totally untested but generally matches my past approach to these things.
edit: I guess I could also test for "msg._timerpass" == true or not exists but I kinda prefer checking for payload "stopped"..
Should a Full Deploy cause all of the Hubitat devices to initialize? I was having issues where the devices were initializing any time that I did even a Modified Flow Deploy and I think I narrowed that down to the SmartThings palette that has now been deleted. However, I noticed that it does initialize all of the devices on Full Deploy still but didn't remember if that was normal.
Also, in my logs, I get this at the beginning but I can't figure out what it might be:
The error says "listen EACCES: permission denied 0.0.0.0:80". I searched flows for any reference to EACCES and 0.0.0.0 and nothing is found.
The full deploy im not sure about, but for
Do you have the node-red-contrib-amazon-echo palette installed?
I've seen this error relate to that palette, and the port 80 not being able to communicate with Amazon alexa
I think I get this as well. I looked at the terminal window during a "modified Nodes" deploy and noticed all my devices were being initialised. Should it? (I dont have smartthings palette installed; never have). I am still a little confused about it, just not had the time to investigate.
I DO!!! Thank you! Its on my Experimenting Tab and I forgot that it had this error until you said something. Thank you.
1 Like
All good...
Just remeber seeing that error, while looking up that same node and trying to get it work!
1 Like
Does anyone have any examples of thermostat scheduling and / or control via Node-Red they wouldn't mind sharing? I'm currently working with a Honeywell T-6 Pro Z-Wave and wanted to see what everyone else was doing for control via NR.
And you would be correct in saying there were some references to thermostat control. It's apparent I can't spell when searching 
and also apparent that I'm in way over my head with some of the stuff @JasonJoel had posted above. Unless anyone has something a little more Pre-K to share I'll stick with the Thermostat control from HE and play around in NR as I pick things up.
And thank you for pointing out the above references, I apparently couldn't spell thermostat to save my life earlier when I was first looking. lol
I do, and will post it in a bit.
Mine is very simple though, and currently doesn't do anything with presence as I made it post-COVID and someone is always home so I didn't bother. And further, in the summer I need to run the AC at desired setpoint pretty much 24/7 for it to keep up so intentionally don't set it higher when not home.
I'll add in some heat/cool mode switching in the fall when temperatures require both modes, and away mode handling in the winter when I have make-up capacity. I already know how I'm going to do it without it turning into a huge complex mess.
1 Like
Mine is done with HA nodes but could be used as a jumping off point and switched to HE. It controls my Daikin mini split and 15 Sinope baseboard thermostats. It's based off of house mode (from mode manager), outside temp, and time of day to do things like turn up the heat in the dining room at supper time if we're home and it's below a certain temp, or turn up the heat in my daughters room when it's her bedtime.
It also turns it all off if a door or window is open for 5mins and starts again when closed.
Import Code (Too long for forum post limit)
https://pastebin.com/dqvUFqXK
1 Like
Yup, just depends on how complicated you need it. I've never had reason or need to bias it off of outside temp, but I know many like to do that.
The only purpose for outside temp is to change it from heat/auto/cool. I've considered adding an "extreme heat" and "extreme cold". Sometimes when it's -40 outside, even when it's set to 20 inside it can still feel a little cold.
1 Like
Thanks @JasonJoel and @MRobi
I'll look at what both of you posted and start piecing my own together.
