I want to add that the relay server is never handling any customer secrets (so a low value target), and we have techniques in place to reduce the probability of DoS (increase the cost to the attacker).

So even if someone would be able to break into the server through the small attack surface, he would not be able to change any setting on any of our customer's devices. Or even read any status either. Of course, if someone can break into our server, the DoS is inevitable, but so far this never happened.

One criticism I have with elixir is the lack of typing (they are working on it now, but I have yet to use it). So yes, I think gleam would be nice. But when we started, it was not even version 0.1 (and I had not heard of it)

I suppose we can have a mixed language project, with erlang, elixir and gleam. Not sure about the practicality of it though

Amazing work, and certainly for such a tentacled project good enough is good enough. I only brought up Gleam vs. Elixir because I am going to pick one to learn this year. I've played with LFE too, and as I wrote earlier, I played with Erlang for a bit.

Main developer here.

We use MQTT a lot, it is really a central piece of our architecture, but Elixir brings a lot of benefits regarding the handling of many processes which are often loosely coupled. The BEAM and OTP offer a sane approach to concurrency and Elixir is a nice language on top. Here is what I find the most important benefits:

- good process isolation, even the heap is per process. This allows us to have robust and mature code running along more experimental features without the fear of everything going down. And you still have easy communication between processes

- supervision tree allows easy process management. I also created a special supervisor with different restart strategies. The language allows this and then, it integrates as any other supervisor. With network connections being broken and later reconnected, the resilience of our system is tested regularly, like a physical chaos monkey

- the immutability as implemented by the BEAM greatly simplifies how to write concurrent code. Inside a process, you don't need to worry about the data changing under you, no other process can change your state. So no more mutex/critical sections (or very little need). You can still have deadlock though, so it is not a silver bullet

Hey it's nice to see a very successful business in Belgium in this space!

I work at the university and we build acquisition systems with exotic cameras and screens, do you think we could meet one time to discuss possible (commercial and research) projects ?

Have you looked at stuff like NATS/Jetstream instead of raw MQTT?

MQTT is used for messaging between processes on the embedded device itself, which can be the remote control panel, or a camera node. The panel itself is driven by a microcontroller which gets all the parameters to display and request changes through MQTT. If the camera is controlled locally, like on a LAN, then another process picks up the action and handles the communication with the camera. If the camera is remote (over cellular for example), we don't rely on the bridging functionality that some MQTT brokers provide but rather use Elixir sockets to send the data over. Typically parameter changes would be sent towards the camera and new status would be populated back to everyone. In most cases it's been a single control room, sometimes 2 at different locations, and one camera site so the needs for a wide distributed architecture hasn't been felt yet.

One of the next steps would be to have a real cloud portal where we could remotely access cameras, manage and shade them from the portal itself. In this context we have been advised to look at NATS. Remote production or REMI is now getting more traction and some of our clients handle 60+ games at the same time from a central location. That definitely creates new challenges as centralizing everything for control is a need but keeping distributed processes and hardware is key to keep the whole system up if one part fails.

Which MQTT library are you using? Did you roll your own?

I ask because we’ve taken up Elixir and we use MQTT (also with a custom RPC on top) to coordinate ag irrigation. But I’ve been very frustrated with the state of MQTT implementations on Elixir (or lack of good documentation). I’m wondering if I’ve just missed an obvious one. We currently use a fork of Tortoise, but it has some issues.

Feel free to contact me, details in profile.

We also use a fork of Tortoise, wrapped in some easier to integrate code (for our use case).

At first, we used an erlang lib emqtt, but it was left unmaintained and then removed from github. We had to switch to something else. Not completely happy, but it works for us

Which version of emqtt are you referring to? We are successfully using 1.11.0 (with AWS IoT Core), which I believe is the "blessed" version for elixir.

I do not remember all the details, but I think it was during the transition from MQTT 3.1 to 5.0. We only use 3.1 and the 5.0 code was not yet finished, emqtt had a hard coded a dependency with an old lib, which we wanted to upgrade. There were no hex package, it was pulled from github. And then the repo on github disappeared (or maybe moved?)

I will have a look at this new package, it looks promising

Ah, yes - we are pulling from the tag on GH. However, I believe the hard dependency on the older version of gun was fixed recently. IIRC, that was what prevented a proper package at the latest version from being on hex.

I was able to update to the latest tag of emqtt on GH (1.14.4), which was not previously possible. I don't believe there are any blockers now to a package on hex.pm, so hopefully this is made available soon.