Problem with nodes when internet not working. Discussion

This comes from a very recent post of mine....

(Wave to @Sean-McG)

So here's the existing way I was thinking I would mitigate such failures:

Quick walk through the machines:
TimePi - NTP, Voice, open weather.
TelePi - overall monitor of all machines.
BedPi - DHCP/DNS server. Real world controller.

TimePi
Voice flow
wait node. 30 seconds delay all messages.
(stuff)
tts node
play sound voice - local speaker
end signal
loop back to wait node to send next message

(Else where on same flow)
status node watching the tts node
notes status.
switch node to detect problems (aka if NOT OK)
change node - sets things up
signals to wait node to dump all queued messages
blocks any more messages getting through.

Which I actually did test and it worked. In my given situation at the time.
Granted there is also the open weather node on that machine too.

So, I stupidly lost my DHCP and DNS machine. (ANOTHER machine)
So the network was DOWN.

The machines were sending through messages indicating this.
(Not too many. I have filter nodes to stop the same message coming through twice.)

So at this stage:

I saw the DHCP machine die. BedPi :frowning:
Then the machine with the voice load went from 12% to like 70%.
Not too bad, but worrying.
It stayed there and I WAS getting (voice) messages. So not sure how bad the crash was or not.
I quickly went in and tried to stop all the logging.
Suddenly on TimePi
no response from server
Soon after dashboard refresh. NR had restarted. :confused:
Started again, repeat.

Tried copying old versions to the machine. No change.

Steve then suggested disabling the tts node.
BINGO!
That was it.
(Lost a bit of work, but....)

Now the open weather node is only used (automatically) once a day.
In the morning to give the weather at that time.
It wasn't morning and wasn't being called.

I could post extracts from the voice flow if you want.
But I think the main part would be the failure part.
The rest is kind of all over the place because there are a few other things happen between the reception of the message and it going to the tts node.
Nothing critical to this.
(Ok, I can have the messages prefixed with a notification bell/sound. If it is detected, that sound is played prior to the voice being heard)