Cumulus Support

First of all thank you Mark for the explanation in your beta thread - overall it is very extensive. I would add something more about the difference between dotnet cumulusmx.dll and mono cumulusmx.exe - that threw me a bit until I understood .net better.

I've created a basic docker image with ubuntu, .net and the other tools needed to run cumulus - anyone is welcome to test.

docker-compose Known issues
anything related to the beta release will apply here too
it used to be simple just to wipe the program location and move in place - however if you do that with an existing install UniqueId.txt will cause the same problems as reported by Mark - I would prefer this stashed somewhere else -- but if I really wanted to I guess I could mount the file??? not looked into it much yet.

Why am I using Ubuntu 23.10? While I'd normally use an LTS version, this one has native .net binaries for arm64 -- I'm probably going to go in the direction of alpine once I get a lay of the land with .net compatibility but this is just a test after all.

I have been using an unmaintained??????? dockerfile from Optoisolated - huge respects to them for giving me a foundation coming up 2 years ago -- it's heavily modified and hacked away but I leave his details there as a salute.

User and timezone set in .env - build.sh and Dockerfile included for source.

If someone is looking for a noobie introduction to docker - I suggest this set of scripts called IOTstack. Basically if you follow the instructions on the link, install IOTstack, install an app and close, you can then copy over the .env and edit the docker-compose.yml for cumulusmx and that's you ready to go.

https://willem-dekker.github.io/IOTstac ... g-Started/

I would NOT recommend ANYONE convert their data to this at this stage - even I haven't done that yet but it's a fun project for someone interested in learning.

With that thought in mind, I still maintain mono cumulusmx for arm and if someone wanted to have a go with that they would just change
to in the docker-compose.yml above the mono version has been downloaded 300 times apparently since I started it .... I don't think all those times were me (although maybe)

annnnnd

the dotnet container is now compatible with intel/amd cpus

https://hub.docker.com/r/nossieuk/mxweather/tags

full list of options above - latest is legacy arm. - dotnet-arm64 is beta arm and dotnet-amd64 is beta amd/intel.

My test amd machine, rno matter what I do still pulls latest regardless of how I have it setup - that might be why I never figured out the problem until now.

Anyone that tests, please let me know how you get on - especially the amd64 one -thanks.

dotnet images on pause until I can remap the uniqueid.txt

legacy-arm64 is what I use on stewartonweather and I believe legacy-amd64 should be fully working too.

Sad to say I’m already very nervous about this potential update.

I’m not technically competent with all these different updates and background changes. I had just got my head round how to update CMX 3 on my Rpi, as newer versions came out.

This new update looks like it may be a step too far for someone of my limited computer knowledge.

I may have to stick with CMX 3 or start looking for something easier to maintain. I’ll keep checking on progress though.


Regards
Martyn

I think of this as more a speedbump and I don't think you use docker - so you can ignore this element.

Converting over to the new method may not be the easiest - but I get the feeling in the longterm it will make it easier for most people.

Also - as the new process matures I think people will find easier ways of doing tasks such as conversion and things so don't lose hope.

Nottub wrote: ↑Tue 19 Mar 2024 7:37 pm Sad to say I’m already very nervous about this potential update.

I’m not technically competent with all these different updates and background changes. I had just got my head round how to update CMX 3 on my Rpi, as newer versions came out.

This new update looks like it may be a step too far for someone of my limited computer knowledge.

I may have to stick with CMX 3 or start looking for something easier to maintain. I’ll keep checking on progress though.

Tbh. I think if you bite through it will be easier for the user and technically better. Many problems were mono related and that is in the past now. So in short: bite through the apple and it will be better. It really will be. The technical competence required for mono or dotnet is equal, you just have to learn to make the change.

Dotnet is the future, mono is the past. It has been abandoned by its developers, there is no support when issues arise.
.NET 8 has long time support.
Having said that: no doubt things will change at some point in the future (no idea when): IT is not without change!

If you say I may have to stick with CMX 3 or start looking for something easier to maintain. I'd say CMX3 is the past, CMX4 is the future.

Nottub wrote: ↑Tue 19 Mar 2024 7:37 pm Sad to say I’m already very nervous about this potential update.

I’m not technically competent with all these different updates and background changes. I had just got my head round how to update CMX 3 on my Rpi, as newer versions came out.

This new update looks like it may be a step too far for someone of my limited computer knowledge.

I may have to stick with CMX 3 or start looking for something easier to maintain. I’ll keep checking on progress though.

The illusion of change is much bigger than the change itself. Yes, new technologies do give a lot of flexibility and different possibilities of running things. And of course there is a lot of enthusiasm around the new possibilities. Docker is just a one additional way of running CMX. If you haven’t needed it before, you probably don’t need it in the future either.

But as far as I have understood, there is not much of a difference between running CMX3 and CMX4. Earlier you had mono libraries on your RPi, now you just have newer .NET8 libraries instead of mono. You still can run CMX either manually or as a service. Also Mark has not suggested that the upgrade procedure from v4 build to a later v4 build would be any different than upgrading from v3 build to later v3 build. One time conversion of data is only necessary when upgrading from v3 to v4. So IMHO no need to worry, just wait patiently until the migration path is well established from the normal user’s point of view.