MX on Linux: Difference between revisions

==Changing location of Cumulus==

#* On a Raspberry Pi, use the file manager to navigate to this file, right click the file named, and select "Geany's Programmers Editor".

Don't change any of the bit I just quoted. Note the mandatory parameter "-service", you must leave that untouched, but you can add -lang, -port, or -debug, as in table earlier after the -service as per example below.

Do change "/home/install/CumulusMX CumulusMX.exe".  Replace that with "CHOSEN PATH/CumulusMX.exe".

Technical user may do other edits on the file, these will be described later, for now save the changed file under a new name (so it won't be lost when you do a MX upgrade that replaces original file):

# Now type <code>sudo systemctl daemon-reload</code>, this tells "sytemd" that it needs to reload all service definitions because either one has changed, or a new one has been added

Novice users, skip this subsection.

Look at the '''[Service]''' part of the file quoted above.

This states Cumulus should use root for both the user it runs under and for the group permissions it uses. If you have the technical expertise, you might choose to run MX in a different user, if your weather station type allows MX to run in a different user. If so, replace the "root" in its two locations. You may also wish to add an extra line after the "Group" line <code>ExecStartPre=/bin/sleep 5</code>, this is to delay the starting of MX by 5 seconds while other services start (on a reboot of your computer) that might affect MX. (For some users, change 5 into 10, it all depends what else is being started).

Note that this delay on reboot in the [Service] part of the file is not enough of a delay to cope with the Raspberry Pi being switched off and later switched on, so this is why an edit is also needed in the [Unit] part of the file to fully cope with dependency on other services, so that will be described next. Look at the rest of the file, the '''[Unit]''' part.

If you are a technical user, you might decide to edit the [Unit] part of the file, you have to decide what is needed in your context, only you know what other services are started by systemd on your computer.

 

As an example, add a blank line after '''<nowiki>Documentation=https://cumuluswiki.org/a/Main_Page</nowiki>''' and in that blank line, type <code>Requires= time-sync.target  local-fs.target</code>. A standard raspberry pi computer does not have a real-time clock, so when you switch it on, the clock just continues from whatever the time was when it was switched off, as MX uses the time taken from your computer, all MX actions will use this "stale" time!

If the computer has online access, then it can look up the correct time online and adjust its clock. The extra line in the example should be added if we don't want MX to start until after systemd has asked for the time to be synced, and asked that the local file-system is made ready so MX can read/update/store files. Using "Requires" ensures these requesting events have happened before MX can start, if they fail, MX will not be started, this example has not specified a time that MX should wait for the other services to start!

#*# The '''time-sync.target''' specifies that the ''cumulusmx'' service requires the computer to have synced with either a real-time clock chip, or a time found on the internet (NTP), i.e. this will ensure that Cumulus obtains the correct time from the computer to control all its actions

#*#* If you are using a weather station type that does not time-stamp the readings it supplies to a Raspberry Pi, adding that target reference is important

#*#* A standard RPi does not include a real time clock chip (it can be added via connections available), therefore when the RPi boots it initially uses a dummy clock, and this sets the time to when the RPi was last running.

#*#* That means without this target being included, a newly booted-up RPi will tell Cumulus MX the time is just after when the computer was shut down, that might be very different to the true current time. It means your Cumulus MX on restarting will skip the catch-up of historic data (should your weather station settings make that available). Subsequent measurements will then get logged against the wrong time.