MQTT timing

Does MQTT Poll for new information? I have a mosquitto instance setup on a different server. I use cloudmqtt for owntracks to report to. I have a bridge setup between my mosquitto instance getting data from cloudmqtt. That happens almost instantaneously. But it seems to take quite a while for the data to be sent over to HA. So I’m wondering what could be impacting the timing.

There is no prolling withing the protocol. The broker just passes on messages it receives. Of course, clients can set up some polling mechanism among themselves.

How long is quite a while?

I think I figured out what’s happening. When my local mosquitto server gets restarted (which was quite frequently while I was trying to get it working), it loses all the subscriptions. So nothing gets forwarded to HA when it gets something from the external cloudmqtt server. When I restart HA, it re-establishes all it’s subscriptions and information starts flowing again. HA needs to recognize that mosquitto has restarted and re-establish it’s subscriptions when connection is re-established. I seem to remember an option that did something like that (persistence I think), I’ll check into that more today.

The retain flag is what you are referring to, but I don’t know if that gets passed on between brokers.

No the retain flag is message based. It ensures that the latest messages are saved and delivered to any subscribers. The problem we are seeing is that when the mosquitto server is restarted, it looses the fact that HA has a subscription for the owntracks data so it doesn’t send any to HA when the mosquitto server comes back up.

What we need is for HA to realize that the link was lost and when it re-establishes the link, we need HA to re-subscribe to all events like it does when HA starts.

Its the job of the client (i.e. HA) to re-subscribe to all the topics it needs when the connection comes back up.

Yes, but HA isn’t. It could request a persistent session in which case the broker would save the transactions and tell HA about the old subscriptions when the connection is re-established.

http://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages

But either way, it’s not happening right. Should I file a bug report?

I think its a bug. I think I have noticed the behaviour before, but since I hardly ever restart the broker it hasn’t been a problem for me, so I rather left it for someone else to worry about.

Understood, and over the long term, that’s probably ok, it was just REALLY frustrating when we were trying to get the owntracks to broker to broker to HA communication working. We probably spent at least 2 or 3 days chasing things that were probably already configured right, because of this bug.

I had a problem with the broker last night (actually I think it was influxdb nightly cleanup using all the ram), with the result that HA was not longer subscribed to topics this morning.

So I had a look through the mqsquitto.conf documentation and found this

Badly designed clients may set clean session to false whilst using a randomly generated client id. 

Since I hadn’t specified a client id, it was randomly generated, so the persistence wasn’t working. It works correctly after specifying a client_id in configuration.yaml

Interesting. I had this same problem when I was doing some development. I found when I restarted the Mosquitto MQTT server, I had to restart HA too. I’m using a randomly generated client_id in my HA config.

So when you give HA an id, HA will re-subscribe to all MQTT topics if Mosquitto restarts? I’ll have to try that.