Updating system libraries used by emoncms

Does anyone know why we are still using mosquitto-alpha?

The last alpha version was 0.2.2 released 20 Mar 2014, Since then the mosquitto extension for PHP has passed to beta (v0.3.0 Sept 2015) and updated again to 0.4.0 13 March 2017.

I noted the linked emoncms guide for installing mosquitto has been revised for PHP7 to include the required symlinking, however, looking at the extension changelog, PHP 7.0 wasn’t officially supported until the last beta version (0.4.0 Mar 17) so I’m guessing “Stretch” users at the very least should be on the beta version?


Not helped by the GitHub documentation telling you to use the Alpha!


Having just read through it again, I also notice that the MQTT enable/install guide assumes an existing Mosquitto server (or similar?) is installed, installing Mosquitto itself doesn’t seem to be documented, except for in the emonSD build guide within the emonPi repo perhaps.

However that guide is specific to “Jessie” not “Stretch” and it not only specifies the 3yr old mosquitto-alpha extension, but also, in contrast, to install the cutting edge mosquitto package direct from the Mosquitto repos rather than using the Debian repo packages.

As discussed in another thread

1 Like

Never noticed that. I do remember hunting for instructions on how to install Mosquitto once. It would make sense to bring the server install under the MQTT doc and make it more general.

Comes back to the old discussion that instructions to complete the same task are in several different places for different install routes and those instructions are often slightly different (when they should be the same).

Well lets ask the question! - Mosquitto-alpha · Issue #84 · mgdm/Mosquitto-PHP · GitHub



Ok! So having looked into this to answer my own question, it would seem Stretch users installing the Mosquitto extension for PHP since March 2017 using the command pecl install mosquitto-alpha will actually have version 0.4.0. You guys should be able to confirm that is the case as it should be listed in the last section on the admin page of emoncms or by using pecl list-upgrades.

By specifying -alpha it defines the acceptable release level deemed acceptable as “alpha”, ie any stable, beta or alpha releases are allowed, the default unless overridden in this way is “stable”. Since there has not yet been a release tagged as “stable” we have to use a -alpha or -beta suffix otherwise the install will fail, stating there is no stable release available.

So whilst there may arguably be some benefit in using mosquitto-beta to avoid potentially buggy “alpha” releases, I don’t think any change is needed except to be mindful that we may not all be running the same version when debugging and to possibly include checking for upgrades once in a while rather than just blindly sticking with whatever was the release at the time of initial install, just in case it goes to a “stable” release.

Hi @pb66, Thanks for clearing this up. Your explanation is really good. Running pecl list-upgrades on the latest emonSD returns the following. It seems 0.3 is currently installed locally. Should I update to test 0.4? How is best way to do this?

pecl list-upgrades
Channel pear.php.net: No upgrades available
Channel pear.swiftmailer.org: No upgrades available
pecl.php.net Available Upgrades (stable):
Channel      Package   Local          Remote         Size
pecl.php.net dio       0.0.6 (beta)   0.1.0 (beta)   37kB
pecl.php.net Mosquitto 0.3.0 (beta)   0.4.0 (beta)   24kB
pecl.php.net redis     2.2.5 (stable) 3.1.6 (stable) 196kB

Have you tried sudo pecl install Mosquitto-alpha
or even sudo pecl install Mosquitto-0.4.0 to be more specific.


1 Like

or just sudo pecl upgrade mosquitto

Should that be sudo pecl upgrade Mosquitto?
…or does it accept lower case too.


Are you referencing the capital “M”? If so no, the name is converted to all lower case so even sudo pecl upgrade mOSQUITTO should work.

1 Like

Nice, this did the trick I’m now running 0.4 :+1: . I’ll report back any issues

On a separate topic I see there are updates available for dio and redis. We can start a new topic to discuss these if you think they are worth updating. What version are you running? Have you successfully been running a newer version?

In fact all this discussion regarding Mosquitto update should be moved to a different topic since it’s not direclty related to Stretch.

pecl.php.net Available Upgrades (stable):
Channel      Package Local          Remote         Size
pecl.php.net dio     0.0.6 (beta)   0.1.0 (beta)   37kB
pecl.php.net redis   2.2.5 (stable) 3.1.6 (stable) 196kB
1 Like

I’m currently running;

dio v0.1.0 (@pb66 suggests that this is no longer needed)
redis v3.1.1

…on Stretch


1 Like

Is everybody in agreement that we remove the dio module from the installation guide?


I can confirm that this is the version installed.

1 Like

Yeah, by the time I had written the post, the proceeding thread had disappeared leaving it making no sense, I was out of time and had to go out so I just deleted it until things settled.

No not at all, I would have edited it to make sense, but if I do that now it will leave these posts hanging so I will just copy the content here so it is searchable text not an image (also so I can edit my typo on the version I was running for some months, v3.1.4 not v3.1.6, that is what I have now upgraded to).

So what I posted was…

Regards the redis extension, we have discussed that in some depth elsewhere, but using the install guide will fetch the latest version, only the emonSD image needs further discussion as there are 3 install methods used on that image and it has historically been fixed at v2.2.8.

I have been using redis v3.1.4 for several months without an issue and now upgraded to 3.1.6 without any obvious issues yet, however I am using php7 on Stretch not am emonSD image so it needs testing for php5.

As for the dio module… Why is it still in the guide??? I have brought this up before, more than once. We have not used the dio module since the emoncms “rfm2pi” module and the php script for the rfm2pi, before oemgateway and emonhub, it maybe 4 years since it has been used and as the serial port is used exclusively by emonhub (when installed) installing the dio module only adds the possibility of a user running a non-standard php script that interferes with the serial port and emonhub. I stopped including it in any of my SD card images or personal install scripts/guides way before the emonpi was launched.

While we are at it…

Can we please start installing the extensions using the provided mechanism rather than manually creating multiple text files?

all the OEM guides say to add 2 links for each extension/module in the apache2/conf.d and cli/conf.d folders under either etc/php5 or etc/php/7.0 depending on which version of php you are using. eg

sudo sh -c 'echo "extension=redis.so" > /etc/php/7.0/apache2/conf.d/20-redis.ini'
sudo sh -c 'echo "extension=redis.so" > /etc/php/7.0/cli/conf.d/20-redis.ini'

This is not in keeping with the intended methods, there should be only one text file written to the mods-available directory eg

echo 'extension=redis.so' > /etc/php/7.0/mods-available/redis.ini

and then the extension can be enabled with phpenmod redis or disabled with phpdismod redis eg

[email protected]:~$ sudo phpenmod redis
[email protected]:~$ ls -la /etc/php/7.0/*/conf.d/*redis.ini
lrwxrwxrwx 1 root root 37 Oct 27 12:54 /etc/php/7.0/apache2/conf.d/20-redis.ini -> /etc/php/7.0/mods-available/redis.ini
lrwxrwxrwx 1 root root 37 Oct 27 12:54 /etc/php/7.0/cli/conf.d/20-redis.ini -> /etc/php/7.0/mods-available/redis.ini


[email protected]:~$ sudo phpdismod redis
[email protected]:~$ ls -la /etc/php/7.0/*/conf.d/*redis.ini
ls: cannot access '/etc/php/7.0/*/conf.d/*redis.ini': No such file or directory

So instead of (for example)

for php5

sudo sh -c 'echo "extension=redis.so" > /etc/php5/apache2/conf.d/20-redis.ini'
sudo sh -c 'echo "extension=redis.so" > /etc/php5/cli/conf.d/20-redis.ini'

or for php 7.0

sudo sh -c 'echo "extension=redis.so" > /etc/php/7.0/apache2/conf.d/20-redis.ini'
sudo sh -c 'echo "extension=redis.so" > /etc/php/7.0/cli/conf.d/20-redis.ini'

we would have

for php5

sudo sh -c 'echo "extension=redis.so" > /etc/php5/mods-available/redis.ini'
sudo php5enmod redis

or for php 7.0

sudo sh -c 'echo "extension=redis.so" > /etc/php/7.0/mods-available/redis.ini'
sudo phpenmod redis

or better still, since using echo for this purpose is frowned upon in many circles (since it behaves differently in various shell’s) and initiating another shell within a shell is messy (sudo sh -c) we should probably be using

for php5

printf "extension=redis.so" | sudo tee /etc/php5/mods-available/redis.ini 1>&2
sudo php5enmod redis

or for php 7.0

printf "extension=redis.so" | sudo tee /etc/php/7.0/mods-available/redis.ini 1>&2
sudo phpenmod redis

I have been using these methods for a long time now without any issue.


Should we still be mentioning php5 when the current installation guide is for Stretch, which specifies php7.0?
Users should be building systems from current standards, not archives.

Paul, please feel free to update the current build guide.


I’d go further than this and suggest a script that took out the guesswork, checked for PHP versions and created the right links.

Am I right in thinking that this is also better a better method if you are using a stack that is not Apache? i.e. works for all stacks?

Could also have a small script for the MQTT libraries as well.

I’d suggest, it may well be easier to maintain a script, than keeping the install guides correct. This may well get more of a chore as the Stretch v Jessie questions arise as folk start to migrate.

All I’d ask is that the script’s commands run at the same level the script is run at. I tend to use DietPi which has a root login as default so scripts with a liberal sprinkling of ‘sudo’ are a pest!

Summarizing the suggested changes so far (so they don’t get forgotten/overlooked!)

  1. Remove dio installation from build guide
  2. Change the way in which redis is referenced
  3. Change the way in which Mosquitto is referenced
  4. Consider the development of a install script
  5. Consider changing the way in which Mosquitto is specified - discussed, and agreed that Mosquitto-alpha should continue to be specified in the build guide.