CumulusMX sends 0 degree spike to WU on restart

[jpsc]

It doesn't get logged and it doesn't get sent to any of the other services. I've noticed it a few times, it doesn't always happen.

Zero spike.png

[steve]

What weather station type, and are you using rapid fire? It looks like the WU update timer is getting started before the temperature has been read for the first time. Can you confirm that you don't have NoSensorCheck=1 in Cumulus.ini?

[jpsc]

Maplin N96FY
Type=5

Using RapidFire
RapidFire=1

There is no NoSensorCheck line in the .ini

[steve]

It could be that the rapid fire timer gets started before data has been read, but it's odd that only temperature is affected, as all the data is read at the same time. As this happened recently, hopefully the diags file will still exist - could you zip up the MX diags folder and attach it, please?

[jpsc]

The air temp was the only one affected, the dew point was non-zero. I checked when I deleted the record from WU

[steve]

What was the time of that entry? It looks like just after 01:00, but on the start at that time, it read an archive entry and uploaded that, so it had definitely started reading data.

2015-12-15 01:09:17.806 Creating WU URL #1
2015-12-15 01:09:17.806 http://weatherstation.wunderground.com/ ... =updateraw

On the previous start, however, at 00:40, it didn't have any archive entries to read. I can how this situation might arise in that case, as it would start the rapid fire timer just after the data reading timer. As you're using a 1-minute logger interval, it makes this more likely; for larger logger intervals there would normally be at least one archive entry to read.

You have a kind of 'perfect storm' of 1-minute logger intervals, using rapid fire, and restarting Cumulus just after it was closed down. I still don't understand how it can only affect temperature, though, when all the data is read at the same time. It suggests that the problem isn't that it updated WU before reading any data.

Edit: looking at your table on WU, it looks like it happened at 01:07, before you restarted, when there was a problem reading data from the station. On that restart, it definitely didn't update WU before it had read data.

[jpsc]

You are right, I didn't look carefully at the log, and assumed it was the start that was the problem. It looks like a shutdown problem

Code: Select all

2015-12-15 01:03:01.156 Sending user and pass to CWOP
2015-12-15 01:03:04.157 Sending: EW8125>APRS,TCPIP*:@150103z5157.80N/00239.60W_316/000g002t049r000p005P000h92b10142eCumulusFO
2015-12-15 01:03:07.157 End of CWOP update
2015-12-15 01:03:37.948 The operation has timed-out.
2015-12-15 01:03:37.948 Error reading data from station - it may need resetting
2015-12-15 01:03:40.949 The operation has timed-out.
2015-12-15 01:03:40.949 Error reading data from station - it may need resetting
2015-12-15 01:03:43.949 The operation has timed-out.
2015-12-15 01:03:43.949 Error reading data from station - it may need resetting
2015-12-15 01:03:46.949 The operation has timed-out.
2015-12-15 01:03:46.949 Error reading data from station - it may need resetting
2015-12-15 01:03:57.945 The operation has timed-out.
2015-12-15 01:03:57.945 Error reading data from station - it may need resetting
2015-12-15 01:04:00.946 The operation has timed-out.
2015-12-15 01:04:00.946 Error reading data from station - it may need resetting
2015-12-15 01:04:03.946 The operation has timed-out.
2015-12-15 01:04:04.258 Error reading data from station - it may need resetting
2015-12-15 01:04:07.259 The operation has timed-out.
2015-12-15 01:04:07.260 Error reading data from station - it may need resetting
2015-12-15 01:04:10.415 The operation has timed-out.
2015-12-15 01:04:10.415 Error reading data from station - it may need resetting
2015-12-15 01:04:13.415 The operation has timed-out.
2015-12-15 01:04:13.416 Error reading data from station - it may need resetting
2015-12-15 01:04:16.416 The operation has timed-out.
2015-12-15 01:04:16.416 Error reading data from station - it may need resetting
2015-12-15 01:04:19.417 The operation has timed-out.
2015-12-15 01:04:19.418 Error reading data from station - it may need resetting
2015-12-15 01:04:19.418 Ignoring bad data: pressure = 8.20000000000005
2015-12-15 01:04:19.419                    offset = 0
2015-12-15 01:05:00.990 *** Data input appears to have stopped
2015-12-15 01:06:00.995 *** Data input appears to have stopped
2015-12-15 01:07:00.001 *** Data input appears to have stopped
2015-12-15 01:08:00.009 *** Data input appears to have stopped

I did not power off either the Pi or the station, I used Jan's shutdown script, copied over 3036 and restarted.

[steve]

So is this a problem with the shutdown script? There's no sign of MX being told to close, just the problem with communication with the station from 01:03:37.

[jpsc]

Looks that way, I'll try it a few times to see if I can provoke it again.

[jpsc]

This is proving difficult to untangle. We have had a few power cuts here recently, and I have a problem in that the Raspberry Pi boots up much faster than the broadband router, so when CMX gets started by the boot script, the RPi has not been able to contact a time server and so the clock is wrong.

All my log timestamps are therefore suspect.

Thanks for your help, this is obviously not a CMX problem at all.

[mcrossley]

Add a real time clock (RTC) to your Pi, I'm thinking of adding one to mine given the price.

http://thepihut.com/products/mini-rtc-m ... spberry-pi

http://thepihut.com/blogs/raspberry-pi- ... spberry-pi

[rogerthn]

This is proving difficult to untangle. We have had a few power cuts here recently, and I have a problem in that the Raspberry Pi boots up much faster than the broadband router, so when CMX gets started by the boot script, the RPi has not been able to contact a time server and so the clock is wrong.

All my log timestamps are therefore suspect.

Thanks for your help, this is obviously not a CMX problem at all.

Then the boot script should wait
Maybe something like below will do the trick?

Code: Select all

network=0
while [ $network -lt 5 ]
do
  ping -c 3 8.8.8.8 > /dev/null
  if [ $? -eq 0 ]; then
    network=$((network+1))
    echo Network count = $network
  fi
  sleep 3
done

[jank]

Isn't it, that also the raspberry Pi has a fake-hwclock programm installed to avoid exactly this Problem? From Time to Time the the Date will Be stored in a file which is being used for Time information at boot,in case Network isn't up?

By the way, the Start Script is already delaying at reboot.
When the Script is being started and system uptime is less than 120 seconds, I assume system is just booted and a 60 Second Delay Will Be made. It seem that 60 seconds are not enough.

[jpsc]

Add a real time clock (RTC) to your Pi, I'm thinking of adding one to mine given the price.

I may well do that, given the price, but if the internet is not there I have loads of other problems.

[jpsc]

Isn't it, that also the raspberry Pi has a fake-hwclock programm installed to avoid exactly this Problem?

It does get the date right, if it comes back on the same day. That is what made it worse for me, the time was reasonable looking in the logs, but a couple of hours out, which made untangling the archive update of Weather Underground a bit tricky.