yes thats odd, I tried to understand, but I’m not risking any more brain damage looking at too much Erlang code (you saw what happended when I felt clever looking at the cli code).
Over the weekend sometime I’ll write some working sample code. I need:
Seems to work here for me. I think. Assuming it is still using IPv6, which I think it is.
1.4.0 builds fine for me. But quicer won’t build with a recent version of cmake. See the bug report above.
Also (as per diff I posted above) I believe for 1.4 if you set the BUILD_WITHOUT_QUIC environment variable, quic will be completely disabled. No tested. Which might be a good thing, it tends to slow down compilation, and I don’t have any use for it.
At one stage I got warnings that emqtt wasn’t listed as a dependency, which was weird. I deleted the deps and _build directories and downloaded again, and this warning disappeared.
Publishing an empty string "" to a topic seems to result in my mosquitto server complaining about the topic being invalid and disconnecting the client.
1626496705: Client robotica-canidae sent topic with invalid UTF-8, disconnecting.
Despite the error mentioning the topic, it appears to be the data which triggers this.
I believe sending an empty string should be fully supported (it is the way to delete a retained message), not sure what is going on here.
This only happens with the emqtt client.
From a different version of the server I get:
1626498034: Client test_client disconnected due to malformed packet.
Never mind, somehow I got my topic and data parameters reversed 
Makes sense now, an empty topic string is not allowed.
I have been using tortoise in production for a while now, without any major issues. The latest release fixed some of the problems we have had. Our use case is very simple, so maybe that is why we haven’t hit any of the problems you described
This is the one problem I have with emqtt - no up-to-date hex packages:
https://github.com/emqx/emqtt/issues/133
Which means in turn I can’t upload anything that depends on it to hex either
Thank you very much for making the emqtt wrapper. I would like to use it for an elixir / phoenix iot project subscribing to a vernemq broker from an elixir backend. Unfortunately i can’t get it running. I always get the following error message:
** (Mix) Could not compile dependency :quicer, “/home/abe/.mix/rebar3 bare compile --paths /home/abe/Code_Linux/mde/mqtt_test/_build/dev/lib/*/ebin” command failed. You can recompile this dependency with “mix deps.compile quicer”, update it with “mix deps.update quicer” or clean it with “mix deps.clean quicer”
Any suggestions would be highly appreciated. 
quicer should build… But you probably don’t need it. Try setting the BUILD_WITHOUT_QUIC=true environment variable. Requires a recent version of emqtt, I suspect the latest version on hex doesn’t have this. Personally I wish this was the default, I generally don’t need quic support.
I have found that with all my applications I have needed to subscribe from dynamic processes. e.g. live views, scenic views, etc. And all my projects use the same code (but different versions) to handle dynamic subscriptions from different processes. So I might end up including this, or something like it in MqttPotion also:
https://github.com/brianmay/scrooge/blob/main/lib/scrooge/mqtt_multiplexer.ex
I just noticed some things should be configurable that are currently hard coded (e.g. client_name = PenguinNodes.Mqtt).
Am having second thoughts on using emqtt. Randomly the connection keeps going down. Client:
10:28:29.066 [warn] [MqttPotion] Disconnect received: reason :shutdown, properties: :ssl_closed
10:28:29.067 [info] Got disconnected :shutdown :ssl_closed.
10:28:29.068 [warn] [MqttPotion] Got Exit
10:28:29.116 [info] [MqttPotion] Connected #PID<0.19392.1>
10:28:29.116 [info] Got connected.
Server:
1660645709: Client robotica-nerves-c775 has exceeded timeout, disconnecting.
1660645709: New connection from 2001:44b8:4112:8a10:ba27:ebff:fe5a:9220:52780 on port 8883.
1660645709: New client connected from 2001:44b8:4112:8a10:ba27:ebff:fe5a:9220:52780 as robotica-nerves-c77
5 (p5, c1, k30, u'robotica').
Still investigating this. But really wish I didn’t have to debug mqtt libraries.
At first I thought maybe emqtt isn’t sending the keepalive packets. So added some debugging, in emqtt, it seems to be working fine. But then it stopped crashing on the test system also.
Also seeing an unrelated process - one that publishes messages using MqttPotion.publish which is just a call to GenServer.cast - hang for long periods of time when the above happens. Which doesn’t make any sense. I used cast precisely to prevent mqtt errors interfering with the process that wants to publish messages.
Or maybe just a coincidence that my process stopped working at the same time. Will add more debug statements to try to work this out. But debugging random intermittent faults is painful.
So far I have noticed that if there is any error in the connection, the emqtt process exits. Which means any packets in transit will get lost, even if they have qos==1 or qos==2. Or maybe I am suppose to i implement these myself. Without good documentation this is somewhat confusing.
Will keep trying but wondering if I should rewrite this in some language that has good mqtt client support.
Looks like another client with the same ID coming in, kicking the old one out.
But the “timeout” error message is odd.