Just signed up for an account on here to let you know that you’re correct, the functionality is, in fact broken.
Your usage is consistent with the documentation.
You can also confirm that it’s an issue with the software by trying the example query that is included in the documentation for “Send a message to an MQTT endpoint”:
message: "wake up",
Just change the broker to be some IP address on your network and the standard 1883 port and you’ll get the same error. Using
tcpdump on the target machine (running the MQTT broker) will confirm that InfluxDB does not even attempt to open a network connection.
It’s also worth mentioning that the
mqtt.to function is also broken in much the same way except that it returns success even though it never attempts to contact the MQTT broker. It’s unclear as to when
to() should be used versus
publish(). The blog post on the topic (written by @davidgs) uses
to(), and the documentation on to() (hxxps://docs.influxdata.com/flux/v0.x/stdlib/experimental/mqtt/to/) does not provide any guidance.
The only thing I’ve found that might work around this, depending on your use case, is to send all data to MQTT instead of InfluxDB and then have InfluxDB grab data from MQTT (hxxps://docs.influxdata.com/resources/videos/using-mqtt-and-influxdb-for-iot/). This only works if you want MQTT to get the exact same data stream as InfluxDB. If the goal was to do processing and only output a subset of the data, or aggregate information, this workaround won’t work at all.
Even where it does work, if there’s ever a problem with the MQTT broker, that data is lost. It’d be far preferable to have the data goes to the database first to make sure there’s a historical copy.
In summary, this workaround is a much poorer solution to the problem than getting the code and documentation fixed, if it is even viable at all. Unfortunately neither the error message (for the
publish() method), nor the lack of any error message (for the
to() method) are enough to tell users where the problem lies.