So, it happened again. Here is how the events seem to have unfolded, based on the logs:
*** The last HTTP request seems to have gone out at 16:26 (so, before data stopped flowing) - there were no more HTTP requests after that - it was the last appearnce of http or HTTP from the weewx process in the logs: Jun 10 16:26:12 mythtv2 weewx[206240] DEBUG urllib3.connectionpool: http://vanta gevieww.lan:80 "GET /v1/current_conditions HTTP/1.1" 200 None *** The last every-5-minute record update was at 16:40 CDT Today: Jun 10 16:40:16 mythtv2 weewx[206240] INFO weewx.manager: Added record 2021-06-10 16:40:00 CDT (1623361200) to daily summary in 'weewx' *** UDP packets continued until 16:43, after which they stopped (presumably because the WLL box was in need of an HTTP "tickle"_ Jun 10 16:43:14 mythtv2 weewx[206240] DEBUG user.weatherlink_live.davis_broadcast: Received 394 bytes from ('192.168.42.75', 25447) Jun 10 16:43:14 mythtv2 weewx[206240] DEBUG user.weatherlink_live.packets: Trying to create UDP conditions packet Jun 10 16:43:14 mythtv2 weewx[206240] DEBUG user.weatherlink_live.data_host: Received new broadcast packet Jun 10 16:43:14 mythtv2 weewx[206240] DEBUG user.weatherlink_live.mappers: THMapping[['1']]: Observation not found in packet Jun 10 16:43:14 mythtv2 weewx[206240] DEBUG user.weatherlink_live.mappers: THIndoorMapping[[]]: Observation not found in packet Jun 10 16:43:14 mythtv2 weewx[206240] DEBUG user.weatherlink_live.mappers: BaroMapping[[]]: Observation not found in packet Jun 10 16:43:14 mythtv2 weewx[206240] DEBUG user.weatherlink_live.mappers: RainMapping[['1']]: Mapped: rainSize=0.01 Jun 10 16:43:14 mythtv2 weewx[206240] DEBUG user.weatherlink_live.mappers: RainM << SNIP more of the above >> Jun 10 16:43:14 mythtv2 weewx[206240] DEBUG user.weatherlink_live: Emitting push (broadcast) packet Jun 10 16:43:14 mythtv2 weewx[206240] DEBUG user.weatherlink_live.service: WllWindGustService: Updating record with dict: {'windGust': 2.62, 'windGustDir': 106} Jun 10 16:43:14 mythtv2 weewx[206240] DEBUG user.weatherlink_live: Waiting for new packet Jun 10 16:43:49 mythtv2 weewx[206240] message repeated 7 times: [ DEBUG user.weatherlink_live: Waiting for new packet] After that, no more UDP packets were flowing, and the WLL driver repeated the waiting for packet message from then on (this time is as I am posting) Jun 10 20:09:25 mythtv2 weewx[206240] message repeated 4 times: [ DEBUG user.weatherlink_live: Waiting for new packet] My diagnosis is that the most likely cause was that WLL didn't receive a needed HTTP request to keep data flowing, because either the WLL driver didn't send it for some reason, or the connection attempt failed or some such. Perhaps a cure/workaround would be this: one expects to see those UDP packets about every two seconds. If 15 (or maybe 30) have gone by, generate an error log entry and send an HTTP request - all one would have to do is put a counter in the place where it is issuing the Waiting message (regardless of whether debugging was enabled or not) . Also, if the code is relying on an HTTP TCP connection staying open between requests, it would be better to open a new TCP connection for each request (I haven't looked at the code.) JRJ On Wednesday, June 9, 2021 at 1:30:17 PM UTC-5 [email protected] wrote: > @JRJ: So, you're saying that WeeWX stopped generating reports but data > still was recorded in the database, correct? > If yes, it seems unlikely that it's a driver issue and more on the weewx > engine's side. > > [email protected] schrieb am Mittwoch, 9. Juni 2021 um 20:22:01 UTC+2: > >> @chris: yes, indeed, the issue on my system was that weewx stopped >> producing reports (and also there were no reporting-related messages in the >> log. I do am now running with debug set to 1 in the config. >> >> JRJ >> >> On Wednesday, June 9, 2021 at 12:09:08 PM UTC-5 [email protected] wrote: >> >>> JRJ: >>> >>> Are you saying that weewx stopped generating reports? My weewx stopped >>> generating reports, with no error messages, at 4:00 AM. Restarting service >>> weewx did not fix it. Rebooting my raspberry pi DID fix it. So, I added a >>> crontab entry to reboot my raspberry pi each morning: >>> 5 4 * * * /sbin/shutdown -r now >>> >>> So far, it has not happened again. I'm using a WMII, with serial port >>> connection, using Python3 and the latest version of the driver from >>> JayJaeger >>> >>> Chris Shaker >>> >>> On Wednesday, June 9, 2021 at 5:46:52 AM UTC-7 [email protected] wrote: >>> >>>> @michael: It should not be related to the SCP upload, which continues >>>> even after weewx has gone "night night". It is running from a cron, not >>>> under weewx. It merely copies the generated HTML/graphics up to another >>>> machine. It runs every 17 minutes. If it were, say, locking up a file >>>> and causing a report to fail there ought to be a message from Python about >>>> that, and there are no such messages. This same SCP was running with >>>> weewx >>>> version 3 for many months without issues - originally every 15 minutes, I >>>> changed it from 15 to 17 yesterday to put it out of sync from the report >>>> generation a bit it after the second failure, just in case. >>>> >>>> [It did occur to me to add a little mod akin to the RSYNC present in >>>> weewx itself, or to cut over to using then RSYNC under weewx after the >>>> rest of this gets straightened out.] >>>> >>>> I also verified that all of the files and directories are owned by and >>>> have the same group as the weewx process, and they are, so it should not >>>> be >>>> an issue of file permissions during report generation, either. >>>> >>>> Regarding the dev release driver, sure, I'll give that a try, and turn >>>> on more logging later today. >>>> >>>> JRJ >>>> >>>> On Wednesday, June 9, 2021 at 1:40:52 AM UTC-5 [email protected] >>>> wrote: >>>> >>>>> Nah, the logging level change doesn't matter, I've published a dev >>>>> release a few days ago making exactly that change. >>>>> >>>>> I'd suggest you to try the new driver version anyway since I also made >>>>> some changes regarding the HTTP interaction with the WLL. You should also >>>>> enable debug logging so we get a more exhaustive look into what's going >>>>> on. >>>>> >>>>> My suspicion is that something's wrong with the report generation or >>>>> the SCP upload. Was the last iteration of the report actually uploaded >>>>> correctly? >>>>> >>>>> >>>>> >>>>> vince schrieb am Mittwoch, 9. Juni 2021 um 06:10:01 UTC+2: >>>>> >>>>>> On Tuesday, June 8, 2021 at 12:43:44 PM UTC-7 [email protected] wrote: >>>>>> >>>>>>> (Note: I did "tweaked" the WLL driver code to suppress the >>>>>>> "Emitting poll/(broadcast) messages by changing those two log calls to >>>>>>> "log.debug"). >>>>>> >>>>>> >>>>>> I'd suggest running the unaltered driver and especially in this case >>>>>> so you get the maximum logging so the author can help you. >>>>>> >>>>>> If you start changing his code, eventually it'll be "you changed it, >>>>>> you own the results good or bad" when he can't recreate the issue >>>>>> because >>>>>> your code has diverged from the authoritative version. >>>>>> >>>>>> -- 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/fcbe0e07-b981-41e2-8479-119dc8f8de1cn%40googlegroups.com.
