MQTTSubscribe throws ValueError: start time is greater than stop time when MQTT message timestamp equals loop packet timestamp

[n7qnm]

WeeWX crashes with an unrecoverable exception when an MQTT message arrives with a dateTime exactly equal to the current loop packet timestamp, causing get_accumulated_data() to build a zero-width TimeSpan.
Environment:
WeeWX 5.3.1
MQTTSubscribe 3.1.1
Binding: loop
Driver: WeatherFlowUDP (hardware record generation)
MQTT sources: rtl_433 individual-type messages
weewx.conf
ignore_start_time = true
adjust_start_time = 2

Error in sylog:
ValueError: start time (1777676342) is greater than stop time (1777676342)

With some help from claude, this looks like an OK workaound
if start_ts >= end_ts:
start_ts = end_ts - 1

[bellrichm]

Did you try ignore_end_time and/or adjust_end_time?

[n7qnm]

Have not tried those (yet)

…

________________________________ From: Rich Bell ***@***.***> Sent: Wednesday, May 6, 2026 12:19 PM To: weewx-mqtt/subscribe ***@***.***> Cc: n7qnm ***@***.***>; Author ***@***.***> Subject: Re: [weewx-mqtt/subscribe] MQTTSubscribe throws ValueError: start time is greater than stop time when MQTT message timestamp equals loop packet timestamp (Issue #10) [https://avatars.githubusercontent.com/u/21961075?s=20&v=4]bellrichm left a comment (weewx-mqtt/subscribe#10)<#10 (comment)> Did you try ignore_end_time and/or adjust_end_time? — Reply to this email directly, view it on GitHub<#10 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGDARKNKZVARTRSACDIBAUD4ZOF4DAVCNFSM6AAAAACYOAQSKKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGOJRGE3TINRZGA>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[n7qnm]

OK - no more crash; but seeing these:
90 seconds
2026-05-14T20:21:21.223719-07:00 weather weewxd[37633]: ERROR user.MQTTSubscribe: (Service-37633) 1778815500 Ignoring packet has dateTime of 1778815277.000000 which is prior to previous packet 1778815278.000000
2026-05-14T20:22:21.213723-07:00 weather weewxd[37633]: ERROR user.MQTTSubscribe: (Service-37633) 1778815500 Ignoring packet has dateTime of 1778815337.000000 which is prior to previous packet 1778815338.000000

[n7qnm]

weewx@weather:~$ grep -A 10 '[[topics]]' /home/weewx/weewx-data/weewx.conf
[[topics]]
# Units for MQTT payloads without unit value.
# Valid values: US, METRIC, METRICWX.
# For more information see, http://weewx.com/docs/customizing.htm#units
# Default is US.
unit_system = US
ignore_start_time = true
adjust_start_time = 2
ignore_end_time = true
# ionizing radiation
[[[Radiation/uSv]]]

[bellrichm]

The WeeWX driver you are using is sending “out of order” loop packets. While technically this is allowed, it may cause problems. For further information see, https://groups.google.com/g/weewx-user/c/_zILpHe6ptQ/m/Gi557PJ0AAAJ

MQTTSubscribe can suppress this message. I will work on writing up instructions for how to do this. But, I am not sure what, if any, side effects you might see. I guess if all is working now, with the message being logged, then suppressing it should be fine...
rich

[bellrichm]

Alternative 2:
Continue to use your workaround until I can rework MQTTSubscribe’s time processing.

[n7qnm]

Ok- I'm getting data from 3 sources, a WeatherFlow Tempest, which uses Weatherflow UDP as the "driver", MQTT subscribe for data from 433Mhz sensors via RTL_433, and a PurpleAire AQI sensor via weewx-purple.

Is it valid to assume that MQTTSubscribe is only complaining about packets it generates, or is it possible that a loop packet from PurpleAire or WeatherFlow UDP arrives and then MQTT sees a "earlier" packet from its feed?

Would debug output be helpful?