Any recommendations on a MQTT client for Elixir?

GitHub - ryanwinchester/exmqtt: Elixir wrapper for emqx/emqtt · GitHub - interesting. No development for 2 years. But might be really good starting point.

Hmmm. Something weird with emqtt. exmqtt a lot of nice logic to handle gentle back-offs with retries if there is a connection fault. But none of this actually gets used.

Still not 100% clear what is going on. It appears that emqtt.connect(conn_pid) |> IO.inspect() returns and will print the error result. But if I have a call to IO.puts("xxxx") immediately following, it will never get called. Then the genserver process gets recreated 4 times.

Initially I thought maybe an exception is being generated and silently discarded. But I can’t see any evidence of this actually happening.

I think that the genserver process is silently getting killed by another process immediately after an error. And the supervisor recreates it 4 times, before the supervisor dies. Which is standard supervisor behavior. But the supervisor doesn’t print any messages about the process having died. But still is my most likely theory. Maybe the supervisor sees it as a normal exit, not an error exit, so doesn’t print anything.

If correct, this is a bit awkward, I want to process the errors myself, and not have my genserver killed.

If anybody else is interested in testing, I can publish my test code and it should be easy to reproduce.

My bad. Need to call:

Process.flag(:trap_exit, true)

Duh!

I would go with emqtt.
There seems to be zero documentation on the web how to use it with Elixir.
We should change that.

Here is a starting point. (connects to test.mosquitto.org with no auth and subscribes to # so you get lots of messages)

deps (latest - 1.4.0 - seems to be out of sync with the docs in readme)

{:emqtt, github: "emqx/emqtt", tag: "v1.2.0"},

some code

defmodule MqttHowto do
  def hello do
    opts = [
      clientid: "my_client_id",
      host: 'test.mosquitto.org',
      port: 1883
    ]

    {:ok, pid} = :emqtt.start_link(opts)
    {:ok, _} = :emqtt.connect(pid)
    {:ok, _, _} = :emqtt.subscribe(pid, %{}, [{"#", []}])

    recv()
  end

  def recv() do
    receive do
      message -> IO.inspect(message)
    end

    recv()
  end
end

yes please do that

See GitHub - brianmay/mqtt_potion: Elixir wrapper for emqtt · GitHub for what I have done so far.

Basically a fork for the existing exmqtt, with some improvements. Including writing a simple test client. Which is a layer on top of emqtt. Which seems to be the recommended approach based on feedback so far.

Going to have to rename the project so I have the option to upload to hex.pm - this name is already taken by what looks like a different project. Thinking maybe mqtt_potion or something.

Progress: receiving messages works, reconnect appears to work if server goes down. But not tested any of the publish or subscribe methods.

Also the disconnect method is perhaps a bit misleading, it is more like a ‘reconnect’ I think (not tested).

Probably should test what happens if the client makes requests and the connection is offline. Ideally this shouldn’t kill the genserver and error returned to client (if sync request).

Pull requests welcome

Looks like my first attempt to build emqtt in github actions was a little bit less then successful.

https://github.com/brianmay/exmqtt/runs/3064947467

[ 83%] Building C object CMakeFiles/quicer_static.dir/c_src/quicer_listener.c.o
cc1: error: too many filenames given.  Type cc1 --help for usage
cc1: error: too many filenames given.  Type cc1 --help for usage
cc1: fatal error: CMakeFiles/quicer_static.dir/c_src/quicer_queue.c.d: No such file or directory
compilation terminated.

Huh? Weird.

Do you think its worth the effort to build a wrapper?
Obviously there is very low demand for an Elixir MQTT-client.
You are forking a repo that received one like in two years…

I’d use emqtt directly. Some documentation how to do that would be really helpful.

I think there are Two questions here, which I will answer:

1. Why create a separate project?

I will face the same challenges regardless if I add the code directly to my project or not. Plus this way I am more likely to be able to get help, then if it it integrated into my project with numerous external dependencies. And I get to reuse the same code in my other projects.

There is at least one other open source software project I use that uses tortoise. Would be good to move these projects to something better supported. In fact based on the tortoise bug reports I see, I think there are a number of people who incorrectly feel that is the only option available. So demand might be higher then you think.

2. Why base on project that is 2 years old?

The code structure + my changes is very similar to what I would be used anyway, and similar to what my existing code already expects (being based on tortoise).

While your code certainly looks simple, I believe it wouldn’t try to gracefully reconnect if there is a connection error. In fact a connection error will kill the process that called hello - as I discovered earlier - because the emqtt process is linked, when the connection dies, it dies, which will in turn kill the calling process. As these are long running processes, that is important for me, and where most of the complexity lies.

Yes better documentation would be very useful. e.g. Took me ages to work out how to get mqtt over TLS working with peer verification enabled.

I wonder if emqtt supports IPv6? My suspicion is maybe not. As I believe my hostname I provided was getting translated to an IPv4 address, which is why the TLS peer verification wasn’t working.

Later: Looks like this issue was closed without actually fixing the problem
https://github.com/emqx/emqx/issues/768