GW1000 - Temp spikes

[rogerthn]

But can you post the log file anyway - I'd like to just check the raw data coming from the GW-1000

Did the Ecowitt software/web site also record the spike?

I did not have any extra logging enabled when the spike happened.
There are some records like below in the log, enclosing the log.

Code: Select all

2020-07-11 11:16:09.290 2020-07-11 11:16 60.000 "High temperature" 2020-07-09 12:41 19.900

2020-07-11 11:16:09.436 2020-07-11 11:16 55.029 "High dew point" 2020-07-05 14:03 16.293

20200711-082827.txt

Should I turn on extra logging again?

I'm not sending anything to Ecowitt and besides CumulusMX I do have WS View on my mobile to configure the gateway.
No records that I can find in the app
PS
I do have Domoticz getting data from the WS as well but nothing strange recorded using 5 minutes log interval

[mcrossley]

Again a suspiciously round number of 60C in that data spike - I've asked Ecowitt if it has any special meaning that they have not documented.

Meantime, the next release should have spike removal and sensible range checking enabled for the basic values (temp, hum, wind, rain) for all stations.

[rogerthn]

Again a suspiciously round number of 60C in that data spike - I've asked Ecowitt if it has any special meaning that they have not documented.

Meantime, the next release should have spike removal and sensible range checking enabled for the basic values (temp, hum, wind, rain) for all stations.

Thanks for your "extreme customer focus" <3
Running sudo mono CumulusMX.exe -debug with Debug logging and Data logging enabled, I will restart when the log file gets BIG

PS
The information for Debug logging and Data logging says

Enable extra diagnostic logging to the MX diags files. Changing setting here affects current session only
Enable diagnostic logging to the MX diags files of data transfers from the station. Changing setting here affects current session only

Current session as in ?

[water01]

The time that your loaded version of CumulusMX that is running from start to Ctrl+C = Current Session i.e. the last complete run of the program.

[rogerthn]

The time that your loaded version of CumulusMX that is running from start to Ctrl+C = Current Session i.e. the last complete run of the program.

That was my assumption but I was fooled by the fact that running with -debug does set them

[mcrossley]

That was my assumption but I was fooled by the fact that running with -debug does set them

Only for the current session - but importantly it enables the logs right from the start as if they had been set in the ini file.

[mcrossley]

PS: @rogerthn - could you change the weather station model type in your profile - the WMR88 is a bit confusing!

[rogerthn]

PS: @rogerthn - could you change the weather station model type in your profile - the WMR88 is a bit confusing!

Done
The old https://www.rogerthn.se/weather2 is still running Cumulus v3.0.0 (3038)
Signature and avatar will be updated shortly

[rogerthn]

One more, now with debug enabled.
2020-07-21 16:29:59.217 2020-07-21 16:29 60.000 "High temperature" 2020-07-18 16:14 22.800
Enclosing zipped 20200721-084119.txt

20200721-084119.zip

To fix I did as below.
All Time Records Editor
Monthly Records Editor
This Month's Records Editor
This Year's Records Editor

Stop CumulusMX, edit CumulusMX/data/today.ini and CumulusMX/data/Jul20log.txt
Start again sudo mono CumulusMX.exe -debug
Edit of Jul20log.txt is the most tricky part, would it be OK to remove the faulty line i.e. in this case
21/07/20,16:30....................

Any comments regarding my "fix"?

[mcrossley]

The fixes seem OK.

Ecowitt have asked me to check something with the people seeing these 60°C "spikes"...

Could you please help ask the user whether he also has a single outdoor temp and humidity sensor?
Please try to go to the Sensor ID page on the WS View app and disable the T&H sensor. Then check whether the 60C will still appear.

InsertPic_.png

As this problem seems quite rare I'm not sure how we will know if this fixes anything?

[mcrossley]

Actually, it looks like both of you already have the T&H sensor disabled

@rogerthn thanks for the log, it confirms that the GW1000 is definitely sending incorrect data, and it's not Cumulus's decoding of it that is the problem.

I've reported back to Ecowitt, I await their response...

[rogerthn]

Actually, it looks like both of you already have the T&H sensor disabled

@rogerthn thanks for the log, it confirms that the GW1000 is definitely sending incorrect data, and it's not Cumulus's decoding of it that is the problem.

I've reported back to Ecowitt, I await their response...

Thanks!
I've also seen some unexpected SolarRad = 0 this afternoon

Code: Select all

MariaDB [Cumulus3]> SELECT LogDateTime, SolarRad FROM Realtime WHERE LogDateTime>'2020-07-25 12' AND SolarRad=0 ORDER BY LogDateTime DESC;
+---------------------+----------+
| LogDateTime         | SolarRad |
+---------------------+----------+
| 2020-07-25 20:47:09 |      0.0 |
| 2020-07-25 20:23:08 |      0.0 |
| 2020-07-25 20:17:38 |      0.0 |
| 2020-07-25 20:16:28 |      0.0 |
| 2020-07-25 20:13:28 |      0.0 |
| 2020-07-25 19:26:48 |      0.0 |
| 2020-07-25 19:12:48 |      0.0 |
+---------------------+----------+
7 rows in set (0.03 sec)

Enclosing log file

20200723-084541.zip

I've tried and failed to decode it
If you find the time?
Best Regards
Roger

[mcrossley]

Again the GW1000 is sending a zero value - it may do this if it has lost sensor data of course, rather than continuing with the last reading until either it declares the sensor "lost" or it gets a good reading again.

I looked at the 19:12:48 values and there was just one packet with zeros in it.

[rogerthn]

Thanks again.
I've now disabled all sensors except the 2 that I have, it might not make any difference but ...

Comparing 3 Received lines, 2020-07-25 19:12:31.039, 19:12:41.072 and 19:12:51.106 I can see that "data columns" 34 and 35 both are 0 for 19:12:41.072
I do have SolarRad in Grafana to compare it with my solar cells production, might consider some "sanity checks" before adding data to MariaDB to avoid spikes as shown below

Annotation 2020-07-26 095644.png

[mcrossley]

Another ask from Ecowitt...

Could you please also help ask the following:
1. Whether they are using the latest GW1000 firmware and WS View app.
2. Whether they can send us a screenshot of the Live Data to show the 60C.
3. Whether they can send us their ecowitt station link on ecowitt.net.