dustin / mqtt-hs

Haskell MQTT client.

mqtt

An MQTT protocol implementation for Haskell.

Client Examples

Publish

import Network.MQTT.Client
import Network.URI (parseURI)

main :: IO ()
main = do
  let (Just uri) = parseURI "mqtt://test.mosquitto.org"
  mc <- connectURI mqttConfig uri
  publish mc "tmp/topic" "hello!" False

Subscribe

import Network.MQTT.Client
import Network.URI (parseURI)

main :: IO ()
main = do
  let (Just uri) = parseURI "mqtt://test.mosquitto.org"
  mc <- connectURI mqttConfig{_msgCB=SimpleCallback msgReceived} uri
  print =<< subscribe mc [("tmp/topic1", subOptions), ("tmp/topic2", subOptions)] []
  waitForClient mc   -- wait for the the client to disconnect

  where
    msgReceived _ t m p = print (t,m,p)

mqtt-hs's Issues

Inbound alias resolution can sometimes fail due to ordering

It's possible for a broker to send aliased QoS 2 messages such that the first message defines an alias and the rest use it, but the notification is ready for one of the latter messages before the alias definition is stored.

Inbound messages are processed asynchronously and can fall out of order when there's a large number inbound. The right thing to do is probably to make this all be synchronous and preserve ordering. The actual message processing itself should still be asynchronous so user code doesn't block processing, but I don't need to keep QoS 2 processing state in threads, and I don't need to asynchronize the inbound processing so early.

Connect To MQTT with a different Config for URI

I see the only option in this library is to use the connectURI to actually connect to the MQTT, is it possible to expose a general connect option where we can manually fill in the required information for the connection? Thanks. I am new to Haskell so I can try to implement this in a PR if you think it would be beneficial.

0.8.2.3 ?

Hi,

Apparently a version 0.8.2.3 was deployed on Hackage and Stackage a couple days ago, however it appears the last visible commit here happened about 2 months ago.
The cabal file I see here says 0.8.2.2.

Is this intentional ? I'm trying to confirm nothing was compromised here.

How to set PropAuthenticationMethod and PropAuthenticationData

Sorry. I've found the solution.

For TLS connections, how can I set TLSSettings?

e.g. for setting custom CA certificates to use.

From what I can tell, this library uses tlsClientConfig, which only uses the TLSSettings default value.

Use uri-bytestring instead of network-uri?

Using uri-bytestring would be much better for constructing URIs. See for example: haskell-servant/servant#139

https://hackage.haskell.org/package/uri-bytestring-0.1.5/docs/URI-ByteString.html

Fix package on nixpkgs

The package is still broken on nixpkgs due to #16.

I have fixed the problem for my personal deployments so this is not urgent, but I would prefer to upstream the change. There are two options:

• You could release a new version which includes the fix
• I could jailbreak the package on nixpkgs (this would make the solver ignore all version bounds)

I'm fine with either option, but if we apply a jailbreak to the package I can't help with future version bumps (I wouldn't notice them).

Namings

Just a mild annoyance, but the naming is quite confusing:

• this repo is named "mqtt-hs"
• Hackage name is "net-mqtt"
• Module name is "Network.MQTT"

It would nice to harmonize the namings.

Try to reconnect to broker on unexpected disconnect?

Hello,

Thanks for maintaining this very useful package.

When we restarted our broker the other day, we realised net-mqtt didn't reconnect.

I was wondering whether it would be feasable for net-mqtt to try to reconnect, and maybe republish messages that didn't get a PUBACK from the old broker connection?

Judging by this, paho-mqtt seems to have logic to reconnect, although I'm not sure what guarantees you get in such a case.

Support over http proxies

Hey, Dustin! I was wondering if there were any plans on adding http proxy support for port 1883. I work behind an enterprise proxy and it seems like the application hangs on connectURI because of the proxy issue. I know that the golang library has proxy support.

https://github.com/eclipse/paho.mqtt.golang

Wondering if we could add it here as well?

Thanks!

Unable to parse packets from an EMQ X broker with QoS > 0

How to reproduce

• Run the emqx 4.4.4 docker container
• Modify the URI in app/example/Main.hs so that the client connects to mqtt://localhost:1883.
• Run the example.

Expected behaviour

The same as when using the mosquitto broker.

Actual behaviour

The client disconnects after publishing the first message with QoS > 0

Notes

It appears that parsePacket (Network.MQTT.Types) results in

ParseError {errorContexts = ["240"], errorMessage = "Failed reading: satisfy", errorPosition = 1:90 (89)}

(when called from doSrc in Network.MQTT.Client) causing the client to disconnect.
Adding an UnknownPkt constructor prevents the error (but doesn't solve the problem, of course).

I'm not yet sure if EMQ X is sending bad packets, or if the issue is on net-mqtt's side...

Thread blocked indefinitely

Hi,
Running the most basic example from https://github.com/dustin/mqtt-hs/blob/master/app/Main.hs.
I am getting thread blocked indefinitely in an STM transaction caused by
print =<< subscribe mc [("tmp/topic1", QoS0), ("tmp/topic2", QoS0)]
Am I missing something?
GHC - 8.6.5

Add to Stackage?

Hi, it would be great if you could add this library to Stackage so that we can all keep an eye on its stability.
If you are too busy to maintain it I offer myself as co-maintainer.

Export `Filter` and `Topic` constructors

Would it be possible to export the constructors for Topic and Filter? The mkTopic :: Text -> Maybe Topic is the only method provided by the API as of now for creating a topic, but there are some cases where I'd like to create a Topic without handling the alternative Nothing case since I'm certain the Text string does not contain any reserved characters.

I believe exporting the Topic and Filter constructors with a cautionary note and a strong suggestion to use mkTopic where possible would be an improvement to the package.

Async callbacks are problematic when receiving ordered messages

I have run into the problem where received messages are sometimes handled out of order, due to the fact that all callbacks are invoked asynchronous (similar to #12, but in my code).

While asynchronous callbacks might be correct for some use cases, they will randomly break every use case that relies on ordered messages. They are also problematic when messages arrive at a rate that is higher than what can be processed by user code.

I think the library user should be responsible for forking during the callback when it is required. Alternatively MessageCallback could be extended to have async- and synchronous variants.

And also thank you very much for writing this library!

mqtt-hs for an MQTT server

Hi,
what would it take to create a haskell MQTT server using mqtt-hs?
i have an REST API server using mongo as a database.
I added some time ago some MQTT endpoints to the server, using mqtt-hs.
It is just filtering MQTT requests, then forwarding them to a Mosquitto backend: https://github.com/Waziup/waziup-api/blob/master/src/MQTT.hs

However, I would like to get rid of the Mosquitto. How complex would that be? I guess I have to implement features such as maintaining a list of subscribers. I don't need the full MQTT specification, just what it takes to make a small REST + MQTT API server, with a mongo backend.
Any chance to have a library "mqtt-broker-hs" sometimes, handling the requests (like Mosquitto)?
Thanks

How can I set the clientId?

Where can I ask questions about this package?

Maybe the source of my problem is a lack of understanding of mqtt..
The mqtt broker is mosquitto. Some not Haskell processes publish message on the broker.
Every week I want to log in and get all persistent messages for a topic and then disconnect. The broker should persist the messages from that week.
The Haskell client logs in (Qos2 and _cleanSession=false, protocol50, _retainHandling= SendOnSubscribe) and subscrices to the topic.
Every time I log in I get another assigned client identifier and the broker starts a NewSession. That's not what I want. To get old persistent messages the clientId should stay the same?
Where can I set the clientId?
I wonder whether I have to subscribe after the first time. The broker should know what to send, without subscribing by the client, or...?

Thanks,
Kees

ReadMe contains missing #pragma directive line

this line should be added
{-# LANGUAGE OverloadedStrings #-}
to the 2 examples (Publish and Subscribe )in the Homepage and ReadME

without this line does not compile ;(