The issue is that emoncms has no way to clear the queue once that python script puts the mqtt message there. So you need a emoncms_input.php service to process that redis queue so rather than
emonhub > mosquitto-broker > emoncms-python-service > redis > emoncms-php-input-service > emoncms
it would make more sense to go
emonhub > redis > emoncms-php-input-service > emoncms
and use emonhub for all the MQTT subscribing (and publishing)
Note the Ethernet port has swapped sides so you will need a new EmonPi faceplate.
Interesting reading. Especially the line about the lack of stabilty at 7 nm.
Il make a note that the MQTT support might need reviewing. This kind of thing is always a potential issue with any dependency. When I get a chance I will test v1.6.2 and see if I can replicate the issues seen.
Long story short: Downloading EmonSD and using it on rpi4, will it work? Does fully updating it, allow to use emoncms and others(mosquito, redis, etc) work ok, or does need some work? Sorry to ask but after reading all the posts, i got more confused.
I think the answer is no. EmonSD Oct18 is based on raspbian stretch, a new image will be needed based on debian buster. If you have a pi4 at hand you could try the build script and let us know if it works? EmonSD build script progress update and beta release I haven’t personally tried it yet with the pi4.
We’ve got a Pi4 here in our hands! We’re currently testing building our image on Buster which is still in a beta version for another week or so.
The Pi4 is not available to purchase in more than one-offs until Sep 2019, therefore we are unable to order qtys for reselling until then. Not a big issue since the Pi3B+ is still more and capable of running Emoncms. We will do some testing to ensure when we do eventually transition to Pi4 it’s a smooth stable transition.
With a few minor changes Im glad to report that the EmonSD build script (alpha release) works on the Pi4 with Buster! 
I’ve created a specific branch of the build script for buster which can be found here:
https://github.com/openenergymonitor/EmonScripts/tree/buster
The main changes are:
Full details of the build script - including the current state of development can be found here:
EmonSD build script progress update and beta release
See installation readme here for full steps on how to use the build script on RPI4 Buster: https://github.com/openenergymonitor/EmonScripts/tree/buster/install
Yes, correct. We’ll be making a revision to the faceplate. Well noticed!
We will keep this Pi4 up and running here to test its stability, to see if there are any issues with the php mosquitto client or any other component. Obviously only a quick test so far.
Interesting article. It’s really great how their manufacturing in the UK (Wales even!). We have always manufactured all OEM hardware in the UK, and for the past few years in Wales. The factory is a 10min drive from our office which is very handy.
In general, it should be possible to detect the OS / RPi version so keeping a single script.
I’d thought about the PHP version problem before as you could move to 7.2 on Stretch.I’m sure I found a really neat way to get the version but cannot find it now 
but you could use
php -v | sed -e '/^PHP/!d' -e 's/.* \([0-9]\+\.[0-9]\+\.[0-9]\+\).*$/\1/'
Doh. Chicken and egg. Need to get the version to be installed from apt first.
Or else make it a variable to be set by the user.
Also, can you not just use the generic ‘php’ for the apt-get commands with the distribution picking up the default version?
Be good to keep a single set of scripts that auto adjusted as necessary IMHO.
Good to know it looks like it works.
I agree!
The main “apt-get install” line could use all non-version specific package names like so
sudo apt-get install -y php-gd php-opcache php-curl php-pear php-dev php-mcrypt php-common php-mbstring
They all (except mcrypt?) have virtual or dependency packages to facilitate this
php-gd
php-opcache
php-curl php-dev
php-common
php-mbstring
as does php-mysql and php. It seems only php-mcrypt doesn’t have a package for php7.3/Buster.
(all the links above are to the Stretch packages, use the release selector at the top right to view Buster versions)
Also there isn’t any need for the
sudo apt-get install -y libapache2-mod-php
as that is a dependency of php, so whether apache2 is installed or not, the libapache2-mod-php package will get installed with php.
The mariadb-client package is the default for either Buster or Stretch, since the “mysql-client” package in Stretch installs the " default-mysql-client" which is mariadb, so again both can use “mariadb-client”
So the only place the installers would differ then is in the paths for the extensions to be installed to, and once the package installer has been used to install “php” it is easy to query what has been installed and use that in the path eg
PHP_VER=$(php -v | head -n 1 | cut -d " " -f 2 | cut -f1-2 -d"." )
then
printf "extension=mosquitto.so" | sudo tee /etc/php/${PHP_VER}/mods-available/mosquitto.ini 1>&2
or
printf "extension=redis.so" | sudo tee /etc/php/${PHP_VER}/mods-available/redis.ini 1>&2
I have a 4GB Pi4 here but I haven’t tried emoncms or emonSD etc yet.
I did wonder whether to use the non version specific package names, I actually did it that way the first time but got a couple of warnings when installing the mods-available extensions. So I thought I would just stick to the way it was done before. Happy to change it to non version specific package names as it does work and the warnings are just warnings at the end of the day.
What warnings were they? At the end of the day if the modules installed are the same, the extensions should be none the wiser, so perhaps there is a subtle difference that isn’t so obvious?
I haven’t got it here now, it was warning that I had only installed the extension in php/7.3 and not php/7.2 and php/7.1 as well as I think it seems to install all those version folders if you don’t specify the php version.
I’ve created a development branch with your proposed changes @pb66 I havent tested it yet, I will get a chance on wednesday I think https://github.com/openenergymonitor/EmonScripts/compare/development?expand=1 the version seems to be required for php-opcache
That’s annoying!
Apparently mcrypt has been deprecated in PHP 7.2 and that’s why there is no php7.2-mcrypt package is available. instead apt-get selects php7.1-mcrypt. Should we review using mcrypt in emoncms? What is it used for specifically?
pi@raspberrypi:~ $ sudo apt-get install --dry-run php php-mysql php-gd php-opcache php-curl php-pear php-dev php-mcrypt php-common php-mbstring
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'php7.1-mcrypt' instead of 'php-mcrypt'
Package php-opcache is a virtual package provided by:
php7.3-opcache 7.3.4-2
php7.2-opcache 7.2.9-1+b2
php7.1-opcache 7.1.20-1+b2
You should explicitly select one to install.
E: Package 'php-opcache' has no installation candidate
In fact is opcache still used / essential?
There are variations on the package lists, this one from the LinuxInstall docs
sudo apt-get install apache2 mysql-server mysql-client php libapache2-mod-php php-mysql php-curl php-pear php-dev php-json git-core redis-server build-essential php7.2-mbstring -y
doesn’t list either the mcrypt or opcache extensions, but it does list json which doesn’t appear in the latest list.
Oddly, it uses mainly version-less package names except for the mbstring (which is available via “php-mbstring”) and mcrypt is present in the “PHP7” but absent from the “PHP7.2” package lists which is in-keeping with it being deprecated and raises a question about whether it is still needed.
Are we sure we still need all these additional packages?
I think we may already be using a different method, (not that I am sure in shape or form) as we save a separate “salt” in the user db.
When you search the repo for mcrypt, it only appears in the docs, not in the code and (very) quick look at the module functions suggests all functions start with “mcrypt”.
This issue (User salt too short · Issue #351 · emoncms/emoncms · GitHub) suggests it was used in the events module which was dropped in v8.4.
it looks like it was used for a “phpmailer” in the events module. we use swiftmailer (via PECL) in the current emoncms and afaik there is no mcrypt depependency there.