Cumulus Support

What causes this Dew Point spike to 0 Degrees?
This spike does not affect daily records. It is only in the graph not in Data Logs.
Using Cumulus MX to calculate Dew Point (station doesn't send this data)
Log interval set to 5 minutes.

Running latest MX build 3098.
Running on Raspberry Pi 4B (clean install not image)
Ecowitt GW1000 with WH32 as outside temp/hum sensor.

Was that point in the graph from live data - or was it generated at start up from the log files?

I suspect it may be a zero value for humidity in there somewhere?

mcrossley wrote: ↑Tue 29 Dec 2020 8:13 pm Was that point in the graph from live data - or was it generated at start up from the log files?

I'm not sure how to answer this question. I'm looking at the graph by going to Charts / Recent Charts.
This is a new install ...only been up for a few days.

I suspect it may be a zero value for humidity in there somewhere?

The GW1000's direct upload to WU and Ecowitt...No spikes there.

This is occurring on in Cumulus MX only. Not using Cumulus MX to upload anywhere at this time.

To be honest there is some Ethernet cabling issues at this site. Sending a cabling person out soon hopefully. The network at times will freeze momentarily. The connection between the Pi running Cumulus MX may struggle to communicate with the GW1000. Its like a flakey network. There is a long Ethernet run with a spliced Ethernet cable in the middle and the Ethernet ends are not terminated nicely and have extended bare straight wire instead of keeping the paired twists till the end. Also there are several connections not labeled and there may be a loopback causing broadcast storm. Dealing with a router and two switches (one POE) and the NVR and a bunch of other things on this network. Working remotely you routinely get kicked off or frozen every few minutes (5 or 10 minutes). There is also several video security cameras that are not on a separate LAN to the back of the NVR as would be best. This all needs to be fixed. New client headaches...but they are dragging their feet on accepting that the network is not right. IT nightmare stuff. Unbelievable how some people disrespect Ethernet cabling and think that as long as the pairs are the right color order that it should work.

So not the most ideal network....but I still regardless wonder if Cumulus MX would not be better able to deal with a network connection time out from the GW1000 and not produce 0 deg Dew Points.

galfert wrote: ↑Tue 29 Dec 2020 8:23 pm

mcrossley wrote: ↑Tue 29 Dec 2020 8:13 pm Was that point in the graph from live data - or was it generated at start up from the log files?

I'm not sure how to answer this question. I'm looking at the graph by going to Charts / Recent Charts.
This is a new install ...only been up for a few days.

So MX was running - in the current run session - at the time the zero occurred? The recent graphs are a combination of "live" data, and historic data derived from the logs for the period after start-up until the oldest "log derived" data has rolled off the graphs.

I'll have a look, but normally a network outage shouldn't produce that effect. MX will retain the last values it received until new values come in.

No Cumulus MX interface was not up on any browser at the time this occurred.

I just pulled it up from a local computer (the Pi's browser via VNC) and from my computer (remote via VPN) and I see the same spike.

I've checked the Pi resources and it is nice and idle. Only Pi-hole and a Backup application (Syncrify Rsync application) installed on this Pi. Backup was not running at the time of spike.

We are talking at cross purposes. Was Cumulus MX started before the spike and not stopped since?

Have you had a look in the MXdiags log for that time to see if there are any clues in there?

That is it! You nailed it. I did restart Cumulus MX at that time, I forgot that I did that. I had made some changes to the settings and I thought I needed to restart Cumulus MX for it to take effect.

This indicates that the spike occurred exactly when Cumulus was restarted.

pi@raspberrypi:~ $ systemctl status cumulusmx
● cumulusmx.service - CumulusMX service
Loaded: loaded (/etc/systemd/system/cumulusmx.service; enabled; vendor preset
Active: active (running) since Mon 2020-12-28 18:20:47 PST; 18h ago
Docs: https://cumuluswiki.org/a/Main_Page
Process: 28072 ExecStart=/usr/bin/mono-service -d:/mnt/Passport1TB/CumulusMX C
Main PID: 28073 (mono)
Tasks: 17 (limit: 4915)
CGroup: /system.slice/cumulusmx.service
└─28073 /usr/bin/mono /usr/lib/mono/4.5/mono-service.exe -d:/mnt/Pass

Dec 28 18:20:47 raspberrypi systemd[1]: Starting CumulusMX service...
Dec 28 18:20:47 raspberrypi systemd[1]: Started CumulusMX service.
Dec 28 18:20:54 raspberrypi mono[28073]: CumulusMX.exe: Service CumulusService s
lines 1-13/13 (END)

So is this a long term problem every time you stop and restart Cumulus MX? Is this a candidate for a future bug fix? Or is it merely cosmetic and should not affect any database data?

I had stopped and restarted it because for some reason even though I have enabled "Upgrade Available" (its a default setting now) it doesn't show up green in the Pi's Chromium browser. I thought it should light up and it doesn't. But I've since noticed that if I remote in via VPN and pull up Cumulus MX on my computer it does light up green. So there is some incompatibility with the Alarm lights in the Pi's Chromium browser.

I'll take a look it may be an issue with the order that MX is reading the data from the response. The derived values should be calculated after all the required relevant raw values have been read, but there may be an issue in there somewhere...

[speculation] So on the first data packet from the station, MX is calculating DP before decoding humidity say, on subsequent packets it works OK because the humidity is present from the previous packet.[/speculation]

mcrossley wrote: ↑Tue 29 Dec 2020 10:59 pm [speculation] So on the first data packet from the station, MX is calculating DP before decoding humidity say, on subsequent packets it works OK because the humidity is present from the previous packet.[/speculation]

And that indeed was the case, fixed for the next release.

Excellent! Amazing support. Thank you!

My excuse is that when I wrote that code, we were expecting the dew point to be provided by the GW1000 as it is documented, but then they decided not to provide it!

Very true. I'll back you up on that. They surprisingly left dew point in the documentation (even though it didn't work) until I pointed it out to them in August 2020. Then their engineers decided to remove it from the documentation, because it never was. Their thoughts are that the GW1000 API should be as efficient as possible and not calculate any values, and that it only send raw sensor data.

I see that version 3.9.4 build 3099 ...just landed and that it has this fix for dew point at startup. Thank you!