Looping Bug?

[dale]

I have a new installation of CMX (3.13.8 b3154). it is set up with a GW1000 and one sensor (WH32) mounted outdoors. I'm testing until a Ambient station arrives. I have configured CMX with "no sensor check" enabled since I don't yet have the full set of required sensors. I noticed that on the second day of operation if I try to examine the day file data log I get an error that says: "DataTables warning: table id=dayfile - Invalid JSON response. For more information about this error, please see http://datatables.net/tn/1"

I then looked in the data directory and did not find a dayfile like I'm used to seeing in Cumulus 1 (should I find one?). I looked in the MXdiags directory and found 11 log files (one every 10 minutes, my recording period) each about 2 GB in size. The log files contained millions of repeating lines (with the time gradually growing) all saying:

Code: Select all

2021-11-13 09:40:01.651 ***Error: Daily values are still at default at end of day
2021-11-13 09:40:01.651 Data not logged to dayfile.txt
2021-11-13 09:40:01.651 Dayfile.txt opened for writing
2021-11-13 09:40:01.651 ***Error: Daily values are still at default at end of day
2021-11-13 09:40:01.651 Data not logged to dayfile.txt
2021-11-13 09:40:01.651 Dayfile.txt opened for writing
2021-11-13 09:40:01.651 ***Error: Daily values are still at default at end of day
2021-11-13 09:40:01.651 Data not logged to dayfile.txt
2021-11-13 09:40:01.651 Dayfile.txt opened for writing
2021-11-13 09:40:01.652 ***Error: Daily values are still at default at end of day
2021-11-13 09:40:01.652 Data not logged to dayfile.txt
2021-11-13 09:40:01.652 Dayfile.txt opened for writing
2021-11-13 09:40:01.652 ***Error: Daily values are still at default at end of day
2021-11-13 09:40:01.652 Data not logged to dayfile.txt

This seems like a bug. I restarted CMX and the loop stopped, but I suspect it may start again at midnight when it tries to do rollover processing.

Is this because I do not yet have the minimum set of sensors required?

What is causing this? How can I fix it?

UPDATE:
About an hour after the restart I noticed this error in the logfile:

Code: Select all

2021-11-13 12:30:45.189 System.IO.FileNotFoundException: Could not find file 'C:\CumulusMX\data\dayfile.txt'.
File name: 'C:\CumulusMX\data\dayfile.txt'
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.StreamReader..ctor(String path, Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize, Boolean checkHost)
   at System.IO.StreamReader..ctor(String path, Encoding encoding)
   at System.IO.File.InternalReadAllLines(String path, Encoding encoding)
   at System.IO.File.ReadAllLines(String path)
   at CumulusMX.WeatherStation.GetDayfile(String draw, Int32 start, Int32 length)

What should be creating the dayfile.txt?

[mcrossley]

Yes it's a bug - I didn't recall ever seeing that message before(!), but I found it and it is in a loop that should retry twice then exit which obviously was not working. It is the NoSensorCheck causing the retry counter to never be decremented. Now fixed for the next release.

It appears CMX is coded such that it will not create a dayfile.txt entry at the end of day if the core values are missing - actually it only checks the days high and low temperatures.

The way MX is currently coded the core data values cannot be "null" so if it did create a dayfile entry it would record values like 999 for the high temp and -999 for the low temp, same other missing sensors.

[dale]

Until the records are created for the various months, the highs and lows show up as -999 (high) and 999 (low), as expected. So does it cause problems to write the dayfile with those values for the core sensors that do not exist?

[mcrossley]

Honest answer is I don't know.

I'd have to try and see what happened. That will not be in any production release obviously.

Longer term the answer is to allow for null values - be they actual nulls (i.e. no value at all) or "invalid" values. But there is an awful lot of code to check that it will be handled correctly everywhere.