Additional info. WeatherDisplay parallel reading output from the Tempest-hub, same as Domoticz reports fixed values since that time, also with actual time-stamp, not the 'freezing' as for WeeWX.
Op donderdag 9 juni 2022 om 19:46:04 UTC+2 schreef Ton vanN: > Some 24 hours ago I observed a 'freezing' of the WeeWX-picture at > https://vannwnhzn.nl/WeeWX0/index.html > Still continues. > > First thought is that upload for the html-file has stopped. > Because for upload using the FTP-function in WeeWX, implicitly it means > that WeeWX has to be checked. > Observation in WeeWX is that all files of WeeWX still get actual > datestamp, but contents have completely been frozen on approx. June 8th, > 16:25 > Restart of WeeWX (regardless of route) has no effects: no further visible > processing. > > This afternoon (as second thought) the penny dropped that this was also > the time that Weatherflow_Tempest as datafeeding sensor through UDP went on > strike: > Tempest hub shows red light, meaning that the dataflow from the sensor (or > the hub itself) has problems. > Also see at the Weatherflow-server that data & display has been frozen at > the time mentioned above. > Locally in Domoticz I see that since that time the data from the > UDP-sniffer is also solid as a rock. > Hard reset of the Tempest hub has no effect. > > *Question:* > is it correct observation that when an interface-driver of WeeWX has no > inputs with changing time-validity, then all subsequent dataflows also stop > & freeze? > *Or* is this apparently simultaneous event just an unhappy coincidence? > *Or* some aspects specific for the Tempest hub & interface-driver? > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/7e792e16-03e4-486d-b2db-a6ad16b7e2a9n%40googlegroups.com.
