Kinda wish I hadn't figured it out though, since I was currently already doing this simplified version via the average app in hubitat and sending the virtual device average into node red, now it looks like I get another project of creating all this in node red and further reducing activity on the actual hub by having node red doing the math calculations instead of the hub.
EDIT: I may have to play around with this before fully switching as it may appear on node red start up the virtual device may be way off "until" each device reports once, which I don't currently have that issue using the average app. I may have to try and figure out how to do an inject node in front of each device on start up of node red.
A little heads up, after I spent most of the night creating it in node red (moving it from the average app in hubitat) I noticed for some reason the calculator seems to be a bit off (in one of the two locations, I believe node red as hardly any of the individual temps were as low as that lower output) with a larger amount of sensors to calculate.
I've been using the average app for over a year which is averaging 39 temp sensors, when I did all this through node red dividing the function output by 39 it was 5 degrees lower than what the average app has been and currently putting out (and what all my current node red thermostat logic is based off of) so for some reason instead of dividing by 39 I had to set it at dividing by 35.15 to match the average currently being put out.
I'm sure this is less affected with less amount of sensors to calculate, but thought I'd mention it to keep in mind of, if adding a lot of sensors. I'm going to monitor this output in grafana for a couple days before fully switching over.
Sadly, I have to report this is the case and this dog won't hunt in node red. I'll have to leave the averaging up to hubitat, because even with attempting an inject node at node red start up I still think my heater would briefly kick on, which can't be happening.
The Green line is the current Hubitat averaging temp data that I've been using over a year. The Yellow line is the newly created same data done via variables in node red. I started a firmware update and reboot of my NAS which runs node red at 12:28 it took 10 minutes to reboot, and after reboot the variable output was 4.75 degrees which would tell the heater to kick on.
38 of my 39 temp sensors update every 5 minutes, but it still took 28 minutes from startup until the variable output was in sync with the current hubitat average.
Have to think up a better way, until then sticking with using the hubitat average app.
You should stick the values in a flow variable, configure node-red to use persistent storage for variables, and then use inject node(s) that run once on restart.
The inject node technique is the standard way to re-init logic on a node-red restart.
I'm not quite that knowledgeable on how to accomplish that. about 95% of my node red education so far has come from you, and we haven't gotten to that class yet...lol
(EDIT: When initializing a large number of items, I like to stick random delays in there to distribute the loading on the hub data requests. Might not be needed in your case)
To setup persistent storage of variables you have to edit the settings.js file for node-red, though. Can't do it from the UI, you have to do it from the command prompt/terminal.
There is a section for it in the file already, it is just commented out. Mine looks like this:
Note that you don't HAVE to use persistent storage at all for this specific use case, though, if your initialization works correctly/100% of the time (which it really should).
I always have my context set to persistent as I do have some variables I need to survive a reboot/restart.
I was afraid you were going to say that, I can figure that out it will just take awhile. That was one reason I change the Node Red from the rPi to the nas was the linux station on the nas you could install the node red app, instead of doing it via command line. Might pick at this later, no hurry in transitioning as it's working now.
I've been playing around with this for a bit now. One thing I've found that this works great for TTS just about all the way around. As far as the "returning to playing music" after a TTS, for some reason I've noticed that if you use "Sonos Radio" via the Sonos App as your source before the TTS, it doesn't seem to have any problem restoring what you were playing and the volume level.
Now if your source is Spotify or Pandora (only other 2 I tried) then it pretty much stops after a TTS and doesn't restore.
As long as I remember to stay with the Sonos Radio, this issue is fixed.
It's relatively new, but it works great and it's nearly instantaneous when reporting wifi connection events. They also have a discord and are a great bunch as far as I can tell (only joined once so far)
Following up here to say that this one might not be ready for prime time. I'm continuing to test, but I'm not sure if it's on the node or UDMP side.
UPDATE: I'm back to using this. There is what I'm assuming to be a maintenance window on my UDMP around midnight where the websocket becomes unresponsive. Once that window ends, all resumes. I have a inactivity trigger on it that reverts back to the old interval based process until it comes back and that seems to be working well.
