Right now I’m struggling with mosquitto. I have a permanent error in my emomcns admin panel, which repeats again and again:
LAST ENTRIES ON THE LOG FILE
2018-05-29 21:57:29.002|ERROR|phpmqtt_input.php|exception 'Mosquitto\Exception' with message 'The client is not currently connected.' in /var/www/emoncms/scripts/phpmqtt_input.php:129
Stack trace:
#0 /var/www/emoncms/scripts/phpmqtt_input.php(129): Mosquitto\Client->subscribe('emon/#', 2)
#1 {main}
2018-05-29 21:57:29.002|WARN|phpmqtt_input.php|Not connected, retrying connection
2018-05-29 21:57:35.001|ERROR|phpmqtt_input.php|exception 'Mosquitto\Exception' with message 'The client is not currently connected.' in /var/www/emoncms/scripts/phpmqtt_input.php:129
Stack trace:
#0 /var/www/emoncms/scripts/phpmqtt_input.php(129): Mosquitto\Client->subscribe('emon/#', 2)
#1 {main}
2018-05-29 21:57:35.002|WARN|phpmqtt_input.php|Not connected, retrying connection
Also, my emoncms administration cannot identify the MQTT version:
MQTT
Version
Host
localhost:1883 (127.0.0.1)
If I run mosquitto_sub -v -u 'user' -P 'password' -t 'test/topic'
I get the error:
Error: Connection refused
And yes, of course the “user/password” combination was added.
Here’s the weird part. If I run: sudo systemctl status mosquitto
I get (besides the active, /etc/init.d/mosquitto, etc stuff)
May 29 22:27:50 raspi3 systemd[1]: Starting LSB: mosquitto MQTT v3.1 mes
After some googling I found out that I could run sudo mosquitto -v
If I do this, I can subscrive with mosquitto_sub and the errors in emoncms.log do not pop up anymore. Furthermore, the teminal gets flushed with lots of information:
1527634341: mosquitto version 1.5 starting
1527634341: Using default config.
1527634341: Opening ipv4 listen socket on port 1883.
1527634341: Opening ipv6 listen socket on port 1883.
1527634343: New connection from ::1 on port 1883.
1527634343: New client connected from ::1 as mosq/?OrgbR9Lc5Y1lZ9Kj= (c1, k5, u'emoncms').
1527634343: No will message specified.
1527634343: Sending CONNACK to mosq/?OrgbR9Lc5Y1lZ9Kj= (0, 0)
1527634343: Received SUBSCRIBE from mosq/?OrgbR9Lc5Y1lZ9Kj=
1527634343: emon/# (QoS 2)
1527634343: mosq/?OrgbR9Lc5Y1lZ9Kj= 2 emon/#
1527634343: Sending SUBACK to mosq/?OrgbR9Lc5Y1lZ9Kj=
1527634348: Received PINGREQ from mosq/?OrgbR9Lc5Y1lZ9Kj=
1527634348: Sending PINGRESP to mosq/?OrgbR9Lc5Y1lZ9Kj=
1527634353: Received PINGREQ from mosq/?OrgbR9Lc5Y1lZ9Kj=
1527634353: Sending PINGRESP to mosq/?OrgbR9Lc5Y1lZ9Kj=
1527634358: Received PINGREQ from mosq/?OrgbR9Lc5Y1lZ9Kj=
Noticed the first line?
1527634341: mosquitto version 1.5 starting
So am I running 2 versions? Where does this second instance comes from and which configuration is it using?
Not completely sure about the other bits, but the exception is caused because this version of the script tries to subscribe when there is no connection to the broker. Often you get a couple of these until the connected callback is fired. Is your logging set to INFO?
It looks like that is an issue for which a fix has just been merged
The 2 different “version” numbers you see are for different things, the “1.5” is the version of the Mosquitto software that provides the MQTT broker/server and “3.1” is the MQTT protocol version being used by that software and broker, usually 3.1 or 3.1.1.
the -v option is just “verbose logging”, when you run that command you are restarting Mosquitto with a new logging level and because it is via the commandline (not a daemon) you see the output in the console.
So no you are not running 2 versions, you are starting the same one twice in slightly different ways. Why that would change the response you get to the mosquitto_sub command I do not know. Is the command string you use EXACTLY the same?
Thank you for your reply.
The version issue is fixed, thank you. That pull does fix it.
As for the command, yes that’s what I’m using (of course with adapted username/password)
I even tried to activate anonymous access, then omitting the user/pass parts and still I get “Error: connection refused”.
After I start mosquitto from the command line, I can access either with user/password or anonymous…
Looks like there is something wrong with the user/password. If you cannot get the mosquitto_sub command to generate data. However, I am bemused, as the Inputs to EmonCMS use those credentials (unless you changed them in settings.php).
I’ll point you to this post - check the password file. You may need to recreate the password as suggested.
One of the things I did was to move /var/log to tmpfs. This caused the log folder to be removed and it was not being recreated automatically at boot (apache, mysql, redis, etc, all are but mosquitto isn’t).
Of course, immediately after I fixed the issue I found this
So I’m guessing I missed some step or the pull which is supposed to fix this with logrotate isn’t actually working
If those checks don’t show anything up can you post the full output of the Mosquitto service status and also the service log using
sudo journalctl -u mosquitto
plus this command
ls -la /etc/Mosquitto
so we can see the file ownership and permissions etc.
Assuming the password is the same, it looks a lot like the old Mosquitto starting issues that led to delays being added to rc.local, have you run the emonpiupdater since creating the image? Can you show us the contents of /etc/rc.local?
There is also the version of Mosquitto you have installed to consider, as far as I know, 1.5 hasn’t been tested with the OEM stuff yet. The emonSD image only had 1.4.10 installed and even now Glyn is trialing a emonSD that is upgraded from jessie to Stretch (not a fresh install) that also uses 1.4.10. Versions 1.4.14 and 1.4.15 have made appearances on the forum, but not necessarily on an emonSD image. I think @borpin has tried 1.4.15 and is now running 1.4.14 on a DietPi image, so you are straying off the beaten path a little with 1.5.
[edit] I have just seen your post and you have found the log issue, I will post this anyway as the linked threads explain the issues you may face depending on how or more importantly when you create the Mosquitto log file. The delays in rc.local are essential.
