Some (hopefully) clarifying information.
Current when MQTTSubscribeService is ‘given’ a loop packet to augment with MQTT data, if the timestamp in the loop packet is less than the previous one. - MQTTSubscribeService logs it as an error. - MQTTSubscribeService ‘ignores’ the loop packet. Does not attempt to augment it with any MQTT data and ‘passes it back’ to WeeWX unchanged. - WeeWX continues to process the loop packet as-is. When MQTTSubscribeService (finally) receives a loop packet with a timestamp greater than or equal to the previous timestamp. It will augment it with any MQTT data received since the previous ‘good’ packet. I’m looking at adding an option that would allow MQTTSubscribeService to update packets with timestamps less than the previous one. This would give the processing choice to the user of MQTTSubscribeService. rich On Saturday, 16 May 2026 at 06:09:54 UTC-4 [email protected] wrote: > > Some more background: > > On a new loop packet event, the first thing that MQTTSubscribeService does > is check if the timestamp of the current packet is greater than the > timestamp of the the previous packet. If it is, MQTTSubscribeService logs > an error and ignores the packet. > > I’ll be the first to admit that the time processing of > MQTTSubscribeService needs to be reworked. But, based on this conversation, > https://groups.google.com/g/weewx-user/c/_zILpHe6ptQ/m/Gi557PJ0AAAJ; > while it is ‘legal’ for a driver to submit out of order packets it is > probably not a good idea and depending on the data may cause problems. > > I’ve thought a bit more about this and looked a bit more at > MQTTSubscribeService’s code. At this time I think the best I can do is > suppress this message and ignore the packet. At some point a deep dive into > the time processing and perhaps add an option to ignore timestamps in loop > packets (aka process out of time order packets). > > rich > On Friday, 15 May 2026 at 18:09:06 UTC-4 Clay Jackson wrote: > >> Hi - l have an "interesting" use case. >> >> I have a WeatherFlow Tempest for a station, and am using the >> WeatherFlowUDP driver for my "main" sensors. I ALSO have a bunch of 433 >> Mhz sensors that I'm reading via MQTTSubscribe and a PurpleAir AQI sensor >> read by the Purple extension. >> >> I'm having a problem that I'm already discussing with Rich Bell (author >> of MQTTSubscribe) where one of the MQTT packets arrives with a timestamp >> that is 1 second BEFORE a previously recorded timestamp and gets rejected. >> The way I read this Accumulators · weewx/weewx Wiki >> <https://github.com/weewx/weewx/wiki/Accumulators>; what's happening is >> that the prior packet is, or could be, outside the timespan of the current >> accumulator. Here's the error: >> 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 >> >> First, is my assumption about the cause of the error correct? And then >> second, is there any way to avoid this when using multiple asynchronous >> data sources? >> >> Thanks! >> >> Clay Jackson >> >> >> >> -- 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 visit https://groups.google.com/d/msgid/weewx-user/e491bcfe-ccc0-4fd9-ab4b-7be4ad92030en%40googlegroups.com.
