[BUG] Day Mix/Max Values in Tiles Do Not reset at Midnight

[gary-hammer]

Describe the bug
In v3.3.0 and all earlier versions, the max value on any tile does not refresh at midnight. If I manually refresh the page, correct min/max values are shown.

To Reproduce
Steps to reproduce the behavior:

1. Leave the website up past midnight
2. Check in the morning
3. Look at temp or apptemp
4. See error

The mix/max values should be reset for the new day.
This is really noticeable with the weather we've had this summer.

[Daveiano]

Hi Gary,

I implemented this and it would be great if you could test this out if you got some time!

I attached an updated file: live-updates.zip. Please de-compress and copy the file to the dist/ folder inside the public_html folder. Then, reload the page (best would be reload without cache, most likely via Strg+R). I added a small message, to verify you got the right file, when you reload the page you should see this:

[gary-hammer]

I have installed the file and I do get the test message after reloading.
Now, just to wait until the morning.

Gary

[gary-hammer]

When I installed the new file, I restarted WeeWX (not really required) and CTL-F5 to refresh the browser cache.
I got the 'test' popup and saw that all min/max were reset to current values. No real issue unless this happened every time there is a refresh/reopen.
This morning, I see that min/max was reset for all except App Temp which somehow got yesterday's values.

[Daveiano]

I got the 'test' popup and saw that all min/max were reset to current values. No real issue unless this happened every time there is a refresh/reopen.

A bug, I wasn't aware of, but I fixed it, attached is an updated file (the message is now "test 2").

This morning, I see that min/max was reset for all except App Temp which somehow got yesterday's values.

That seems a bit odd, does Apparent Temperature gets regularly updated on MQTT updates? For every observation that's in the message which arrives on a new day, the min and max values will be set to the current value. So if appTemp does not get reset, it seems that it was missing from that MQTT message. Any idea how this could be the case?

Can you subscribe to your MQTT Broker and watch for appTemp in the messages?

[gary-hammer]

Test 2 fixed wiping the min/max values on refresh.
I'm looking at the loop values (weather/loop) from MQTT and see no app_temp, but it is in the parent, weather. Looks like that is the archive as it is created on the 5 minute mark.

Let's see what happens in the AM

[Daveiano]

That means appTemp is never updated, right?

I guess the topics weather/obsType (like weather/appTemp) are generated by default, but the values should also be included in the loop topic. I don't know why that's not the case here.

Do you have any special/overridden MQTT config in weewx.conf?

[gary-hammer]

No, the value is there, just not when you are expecting it.
I have it displayed and it changes.
What doesn't happen is the min/max reset.
And that is correct if I refresh the page.

[gary-hammer]

I'll double check the MQTT config in the morning, but there isn't any customization.

[Daveiano]

No, the value is there, just not when you are expecting it.

Ah, I think I got you now. So appTemp is updated via MQTT but the value is not present in every LOOP packet, right? And its especially not available in the first message after 0:00, that's why its not updated.

Ok, I did not think about this when I added the min/max reset, I will send you an updated file for further tests, probably tomorrow!

[gary-hammer]

Let's hold off on changes.

I need to investigate the differences between the WLL and console logger.
Currently this skin is run on WeeWX 5 on a separate server. It uses my WLL as data source. Some values must be associated with the archive packet and only appear on the 5 minute mark. AppTemp is one and it is there at 5 minutes 16 seconds (00:00:16, 00:05:16, 00:10:16)
I have a 'main' machine that runs WeeWX 4.x. It uses a console logger as the feed and updates every 2.5 seconds.
That machine run Belchertown skin and has immediate update of appTemp when something like wind changes.
That's because this machine provides this value in the loop packet every 2.5 seconds.

Let me see if I can use the 'production' machines MQTT on the test machine's skin.
Just to see if this is the issue or something with the reset of the skin itself.
I don't know, the production machine is TLS/SSL and the test is not. But I'm off to find out.

[gary-hammer]

It is not possible to use the secure ws with unsecure page.

[Daveiano]

It is not possible to use the secure ws with unsecure page.

It is! The other way around is not possible: Using insecure MQTT WS with a secure page. I am testing with such a setup: Insecure page with secure WS, without any problems.

Currently, the min/max values are reset for every observation, that is included in the first messages on a new day. I was wondering if your setup is causing this, so its an exception or if this could be a common behaviour that not all observations are included?

[gary-hammer]

I'd be interested in your test setup as I was not able to get a connection to my other, secure mosquitto server.

In any event, the feed from the WLL is not providing appTemp in every loop packet. It could be the driver, it could be the WLL. Either way, it is only there on the 5s

Here's some info on the feed:
https://weatherlink.github.io/weatherlink-live-local-api/

[Daveiano]

I am just using my secure production Server for local testing:

[[mqtt]]
        mqtt_websockets_enabled = 1
        mqtt_websockets_host = "mqtt.weewx-hbt.de"
        mqtt_websockets_port = 9001
        mqtt_websockets_ssl = 1
        mqtt_websockets_topic = "weather/loop"

Page is simple HTTP, no https:

---

In any event, the feed from the WLL is not providing appTemp in every loop packet. It could be the driver, it could be the WLL. Either way, it is only there on the 5s

I could imagine that this is not the only way something like this could happen. Here is another test file (the message says "test 3"), please test this one out. It should hopefully also reset appTemp (I got no time for testing, yet).

[gary-hammer]

Ah, I was attempting to use it but locally (.lan not the public address).
I won't change it now as we want to see how test 3 performs with the WLL.

I'll update in the AM.

[gary-hammer]

Min/max reset overnight.
Everything else seems to have reset as well.
We even had rain yesterday for testing.

Unless you need it for tracking, feel free to close this.

Gary

[Daveiano]

Great! I will then close this issue for now, the change will be included in the next 3.4.0 update, feel free to open another issue if you encounter any problems!

[gary-hammer]

Reopening this.
The max rain rate does not reset. The min may not but as it normally zero hard to tell.
That wasn't noticeable until now.
I have verified that all other min/max seem to be resetting.