2

First, if you just have 1 garage door opener, why are you generating a random client id every time? using a fixed clientID would be the right thing to do here. The only time a random clientID makes any sense is when you are using a transient client e.g. a webpage using MQTT over Websockets. Second, you appear to be double looping your reconnect function. ...


2

From all the available information in the question, the 2 simplest options. There are no messages being published on the topic subscribed to. There is an ACL in place on the broker and the user is not authorised to see messages on the topic subscribed to. Add -d to the command line to see if the connection and the subscription actually complete ...


2

I also faced the same issue in Ubuntu 18.04. For me, stopping and starting the service worked. Instead of: sudo service mosquitto restart I used sudo service mosquitto stop sudo service mosquitto start And I was able to see the effect of changes made in the local config. Running the status command sudo service mosquitto status gives the following ...


1

Bah I figured it out. I need to put single quotes around the topic so that $SYS isn't interpreted as a variable. So like this: mosquitto_sub -h myserver.myserver.myserver -p 9500 -t '$SYS/broker/clients/connected' -u "my-user" -P "my-password" --capath /etc/ssl/certs/


1

When running Mosquitto Broker as a service on Windows, it will always look for a config file in the MOSQUITTO_DIR path. If you do not have a config file there, it will fail. Usually the installer creates this for you, I suggest you to check if the configuration file is present.


1

I had to attach the policy to the certificate and set the port to 8883 because the protocol is MQTT and not MQTT over Websockets.


1

First, it's bad practice to start topics with a leading / (while allowed in the spec it ends up causing problems later when you starting using things like shared subscriptions). As John S hinted in his answer, this is not something you really want the broker to be doing, you should be doing this yourself with a separate client. Assuming you are running the ...


1

You might be overthinking it. You can just create an MQTT client service that runs on the RasPi separate from the mosquitto server that subscribes to the topic that you want to transform, then publishes to the new topic upon receiving the original one. It's perfectly fine to have an MQTT client running on the same machine as the MQTT server. So the MQTT ...


1

First, it is really bad practice to start topics with leading /. It adds a null entry to the start of the topic tree and causes problems with things like shared subscriptions (we will get to that next). Second, I think you have miss understood how shared subscriptions work. Topics that start with $share/ (note the lack of leading /) are used to set up shared ...


1

I don't get the unsubscribe error, but I do get the same effect of only the first mapping taking effect. Without digging into the code I'm going to assume that the bridge is stopping at the first matching pattern, which in this case is # which matches everything. This makes sense, especially when we remember that loopback bridging to the same broker is ...


1

First, you can definitively make you web server subscribe to MQTT, it's just the business of setting up a thread and providing the callbacks. Using the paho mqtt module for this, it's just a matter of using the Client class and calling loop_start() to launch the thread. However, depending of your needs, it may not be the best solution to make your webserver ...


Only top voted, non community-wiki answers of a minimum length are eligible