Page 2 of 3

Re: Temp spike removal not working

Posted: Mon 13 Jul 2020 2:49 pm
by rogerthn
mcrossley wrote: Mon 13 Jul 2020 12:50 pm 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

Re: Temp spike removal not working

Posted: Mon 13 Jul 2020 9:05 pm
by 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.

Re: Temp spike removal not working

Posted: Tue 14 Jul 2020 7:43 am
by rogerthn
mcrossley wrote: Mon 13 Jul 2020 9:05 pm 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 ?

Re: Temp spike removal not working

Posted: Tue 14 Jul 2020 8:42 am
by 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.

Re: Temp spike removal not working

Posted: Tue 14 Jul 2020 9:37 am
by rogerthn
water01 wrote: Tue 14 Jul 2020 8:42 am 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 :bash:

Re: Temp spike removal not working

Posted: Tue 14 Jul 2020 10:45 am
by mcrossley
rogerthn wrote: Tue 14 Jul 2020 9:37 am That was my assumption but I was fooled by the fact that running with -debug does set them :bash:
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.

Re: Temp spike removal not working

Posted: Tue 14 Jul 2020 11:10 am
by mcrossley
PS: @rogerthn - could you change the weather station model type in your profile - the WMR88 is a bit confusing!

Re: Temp spike removal not working

Posted: Tue 14 Jul 2020 11:39 am
by rogerthn
mcrossley wrote: Tue 14 Jul 2020 11:10 am PS: @rogerthn - could you change the weather station model type in your profile - the WMR88 is a bit confusing!
Done :D
The old https://www.rogerthn.se/weather2 is still running Cumulus v3.0.0 (3038)
Signature and avatar will be updated shortly :P

Re: Temp spike removal not working

Posted: Tue 21 Jul 2020 5:09 pm
by 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"?

Re: GW1000 - Temp spike removal not working

Posted: Sat 25 Jul 2020 5:55 pm
by 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?

Re: GW1000 - Temp spikes

Posted: Sat 25 Jul 2020 6:36 pm
by 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...

Re: GW1000 - Temp spikes

Posted: Sat 25 Jul 2020 7:26 pm
by rogerthn
mcrossley wrote: Sat 25 Jul 2020 6:36 pm 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

Re: GW1000 - Temp spikes

Posted: Sat 25 Jul 2020 8:03 pm
by 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.

Re: GW1000 - Temp spikes

Posted: Sun 26 Jul 2020 8:02 am
by 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

Re: GW1000 - Temp spikes

Posted: Mon 27 Jul 2020 3:12 pm
by 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.