That makes sense.
So as you said yesterday, the only way to rebuild the entire cache is to restart node-red. Otherwise cache values only get updated 1-by-1 as new events are received.
Once a node is communicating, there is no way to manually trigger/force a value to get refreshed from the node-red side.
Obviously doing something that causes an event to be created on the device in Hubitat would then refresh node-red via the new event being received.
You can probably send a fake event to your node red endpoint http://localhost:1880/hubitat/webhook and that's it
Thanks for the clarification.
In that case, I think the feature request posted yesterday is worded correctly / still a good idea.
yes I created an issue to keep track
And, for manually rebuild cache, sending systemStart from NR to the webhook endpoint would rebuild all caches
Yes, I see. Thank you! I should have done that myself. 
For clarity to others, that is AFTER the new feature is implemented (not today in 0.0.32). 
So last question on synchronization @fblackburn 
I see a few scenarios where data could become out of sync:
Thanks!
There is no persistent communication between NR and HE (it's not a websocket). It makes impossible to detect if an event is lost on the network. Moreover, if your HE is under heavy load and doesn't send event on webhook (I don't know how it's designed and if it's possible), then you may be not noticed too
But if you need all this redundancy and security it's maybe a sign that you should build you solution from only thing you control 
If you talk about separate action (add OR delete):
If you talk about adding AND deleting AND re-adding device without restarting NR, then yes you may have a cache issue .... but hey ... stop messup with your device
To be able to better handled these scenarios, Maker API would need to send some signalling messages (What can be against the webhook device event concept ...)
maybe it should be interesting to move to websocket ...
Thanks! I don't think there is anything wrong with how it handles intermittent communication loss. I just wanted to understand what it did in each scenario.
Really, if someone does care about refreshing the cache on loss of comms, after the systemStart logic is in place they could have a watchdog value in Hubitat and a timeout in node-red that refreshes this via web call.
Do you mind sharing your thermostat flow? I'm happy with my Ecobee and using it's sensors for the Master Suite HVAC but I have a GoControl for rest of house and would like to use external temp sensors with that also.
Once i have my hub power supply issues sorted
I will try this and the rest of @erktrek function node
Thanks to you both!
Well, if you have a gocontrol gctbz48 you can just bias the thermostat reading to match another reference temperature (if you are using my enhanced driver - not available in the in-box or bcopeland driver versions).
Or if you have a thermostat you can't bias the temperature on, then you would just have to play games with the setpoint (raise/lower) to get the target temp to what you want using 'notch controller' techniques. Which is just a fancy way of saying on a fixed time basis (or fixed delta basis) check temp sensor vs thermostat temp and raise/lower SP by 1. Wait, repeat.
For example, in this flow I average 3 temps during the day, but only average the 2 bedroom temps at night. And apply that temp as a bias on the thermostat temp.
One of the rare times I use a function node, but it was really necessary for this calc:
In this one I just average two temps all the time and use that as the bias on the thermostat:
Function node for that 2nd flow:
I would guess @aaiyar is doing something remotely similar (biasing the thermostat temp to match a temperature sensor).
Thank you. I never would of thought of utilizing the Bias adjustment.
Nope. Something much simpler. I set the thermostat temperature to 3 degrees lower (or higher for heat)) than the temperature registered at the thermostat, and then turn the thermostat off when it reaches the 1 degree lower (or higher) than the desired temperature (based on sensor avgs).
And this process kicks off again when the temperature is higher (or lower for heat) than the desired temperature by 1 degree F.
The house has remained comfortable with this approach (I shoot for 71-21 F). Rel. humidity remains around 55%. And the average heat-pump run times is 24 minutes .....
I imported your Thermostat controller flow into my Node Red and the first thought when I saw it was definitely NOT SIMPLE!!!! 
Thank you for sending.
Its busy. But its simple. There's stuff in there to remind to change the filter and clean the AC drain. So it's busy as hell.
I stand corrected. 
You went the notch controller route.
Just a further clarification... if that or some other webhook action failed after NR has been running for sometime then it doesn’t force a cache rebuild , it just continues with the existing cache which could now be out of synch, which is not an issue, just need to know ?
Can my NR flow be informed a webhook action failed .. i.e. a trigger ? Such that I could kick off a systemStart if it was critical.
I do appreciate that you don’t know it’s failed until your webhook fails and that heartbeat timers with a sequential number are a better way to solve this. I’m fortunate in my MQTT app that it’s a permanent socket so I can resynch immediately should it break.
PS I have no need for this resilience or cache validity at the moment so don’t worry, but I do just like to know what device ‘state’ I can depend upon in my system as it expands.
Is anyone else having this problem? Missing server? Nothing working at the moment and I have restarted my Hubs and Node Red? I don't know what I'm missing? Thanks
Nope, no issues here.
Only "server" node I have ever had on my system (that I can think of) was in the Home Assistant node set. Have you ever had that on there, or recently added/removed it?
No problem here either
Download the Hubitat app
