Cumulus Support

Regarding Dewpoint, I think the problem may possibly be the opposite, CMX *is* calculating it, but with no data it is giving the answer as zero. It should really flatline like the other values - I'll check that.

Regarding rebooting, I can look into this. Obviously it would have to be optional.

Hi Hans and Mark

I have just replicated the error on reboot startup with the debug mode switched on and the log files are attached.

The initial stop and reboot has the ServiceCosoleLog OLD and 104441log file

The second stop CMX and start CMX has the ServiceconsoleLog and 104828 log file.

All the stop start actions are with the systemctl process.

You can see that the faulty logs are very sparse in information and previously CMX always restarted after a reboot. Looking at the systemctl process it seems to have changed so I expect I will have to sort it out locally.

Hi Andy,

That is really odd, it stops mid-way through reading the cumulus.ini file. The next message in your log should be "Reading Cumulus.ini file completed"

There is nothing in that process that I could see that would hang.

Is the CMX process still running after the logs stop, or has it been killed?

Hi Mark

I just re stopped CMX and ran a reboot and checked the CMX admin site, it was completely dead. The log file again stopped at the 334kb load level as per the previous test.

I tried to just restart CMX but no movement, then again ran the stop command followed by the start command and all runs happily.

So there seems to be some residual activity in CMX after a reboot but before the stop command. Strange!

If you have a GUI on your rPi you could run htop and see if the process is still listed.

Otherwise from the command line you could use > ps aux | grep -i CumulusMX

Hi Mark

I just stopped CMX and rebooted the RPI and a check on HTOP showed that none of the CMX apps were working, I had CUtils trying in vain to find CMX and all the usual RPI software running.

On stop and start CMX HTOP showed CMX apps working just fine.

Is this really a problem/bug in your normal magic software?

With regard to the new RPI image (Raspberry Pi Image for Cumulus MX 3.16.0), I can report that it works on Raspberry Pi model 3 as indicated. However, CumulusMX fails to start if the image is loaded onto a Raspberry Pi Zero W (original version) as shown below. I acknowledge the comment on the software release page that the image may not work on all models.
Is there a link to the previous RPi mage as I haven't been able to find one.

NigelG

Just found the link to the previous RPi version.

On the old pi zero I think you will have to uninstall mono-complete, then install it again. It will take a looooong time to install on the original pi zero.

sudo apt remove mono-complete
sudo apt install mono-complete

HansR wrote: ↑Sun 01 May 2022 9:42 am but still think an automatic reboot originated by CMX might solve this type of problems.

@Mark: If so, then only as an option !!
@HansR: In your personal setup that may be OK - others (like myself) may have also other applications connected to the gateway and an unexpected reboot might cause other issues. I would not want CMX to issue a reboot without me explicitly wanting this.

Well, that's OK if it is an option isn't it?

On my old RPi Mono Install does a lot of recompiling. Cause given: LLVM disabled due to missing SSE4.1...
Maybe the reason why the precompiled CumulusMX package fails on older RPis?

And, by the way, so far no issues noticed.
3182 is running with the GW1000 API without any issues so far and without a GW1000 reboot. For the GW2000 + WS90 + WH40 and for two other GW1000 (one still on Firmware 1.6.8 and the other on 1.7.2).

Just another question regarding a phenomenon I already observed earlier, so it's not a 3182 (only) affair.

I own a Blake-Larsen SunRecorder and CMX picks up its readings. The sun hours are not reported into the Ecowitt cloud.
However, on a backfill from the Ecowitt cloud at startup, somehow sun hours appear in the log files which do not match the SR reading. Usually these new values are higher values than the B-L SR readings for the day and minute entries concerned (I can tell from my CMX backup installation and from the SR logs). I assume that CMX does some sun hour calculation when creating the month log entries. Could this be suspended with a switch - or automatically when the B-L SR is registered to CMX ?

My logs after a refresh install of 3182.

EDIT: If I turn off Auto Discovery for the Ecowitt, enter the GW1000's IP address, and clear out the MAC address under "Ecowitt Local API Settings", it works.

Buford T. Justice wrote: ↑Sun 01 May 2022 7:15 pm My logs after a refresh install of 3182.

EDIT: If I turn off Auto Discovery for the Ecowitt, enter the GW1000's IP address, and clear out the MAC address under "Ecowitt Local API Settings", it works.

does it also work when you only switch off the autodiscovery and enter the GW1000 IP address but leave the MAC address in the Ecowitt Local API settings ?
Or does it have to be all three in order to work (which would astonish me as mine works and the backfill is done - without a MAC there the backfill wouldn't work )