Guys, we need your feedback. We've created a small PoC to provide you the UMH Lite stack as a single docker container. Simply run a

docker run [...] -e AUTH_TOKEN=yyy -e MQTT_BROKER=10.13.37.123:1883 [...]

and you would be able to deploy protocol converter & custom data flow components from the Management Console and send data to MQTT broker (e.g., a full UMH classic instance). Current Resource Usage for a UMH Lite incl. one protocol converter subscribing to ~80 tags is around half a CPU and 1GB RAM, which should make this work on almost all edge devices. It should also work on arm. If this is well liked, then we could also put the "UMH Classic" in there. It would only make sense for PoCs or smaller use-cases. Would you like to see that in action? Give us a thumbs up or down 🙂

i would like to test this, i have a very good usecase for this with modbus tcp

Yes, that would be great! Maybe not today, so that today I can focus on improving the PoC a little bit 🙂

Hi, I want to give this a try as well. I have my container running: and I've set the environment variables. Can you provide a bit more info about how to configure the protocol converter and custom data flow component in the managemetn console?

@Denis how did you know what image to pull? is it on dockerhub already?

I just pulled jeremytheocharis/rocky-systemd-test:latest from the screenshot, but now that I think of it, maybe it's not the correct one?

is that a production worthy solution?

depends on what you mean with production. I would say that we should test it, and I assume it will be enough for most deployments. for our enterprise customers we would always recommend to install it "properly", but I assume for most people the docker method could be enough

for a 99% uptime solution. i can imagen kubernetes deployment being harder to maintain I would use the docker solution in this way: 1. having multiple UMH lite's collecting data on the edge (modbus, opcua,...) from a docker container (lots of support by edge devices) 2. having a factory wide (ubuntu) VM with full UMH (the regular kubenetes install script) 3. (optionally) having a company wide UMH (enterprise version due to higher uptime requirements)

That was also exactly our idea! Some small adjustments: - there should be no difference for the maintenance effort for using Kubernetes, as long as you don’t start modifying it yourself, deploying your own workloads, etc. The advantage of a package like UMH is, that we can develop it to be maintenance less for all the common use cases and test it through automated tests. I think on average we install UMH internally 100-150 times per day, automatically through all of our automated tests - Switch out Ubuntu to Rocky Linux (OSS as well, but more stable API as it is based on RHEL) - depending on the requirements also have a High Availability Cluster for the factory level - the ability to add multiple UMH Instances into a single account is going to be an Enterprise feature. Right now we don’t enforce it, but we will in the future. Also, we will never take features out of the Community Edition for existing users, so if it works now it will also work in the future. But I would not count on that for future deployments Also we needed to fix issues with our backend yesterday and therefore the Modbus and UMH Lite are still stuck in our merge queue. Will try to get them out today.

I get why you recommend rocky linux but i'm more familiar with Debian based systems (apt-get install,... 😍 ); is it really that much more stable?

it is not more stable in the sense it runs better, but more stable in the sense that there are less changes between versions. and if there are changes, they are well documented with clear upgrade paths. this does not matter if you run it for 1-3 years, but they matter if the system needs to run 10+ years