Raspberry Pi 4

indeed, hence the “big question”!

MQTT in general doesn’t seem well supported for PHP, IMO MQTT in emoncms is way more trouble than it’s worth. The Python MQTT (paho) will always be bang up to date for Mosquito as they are both by Eclipse, no reliance on 3rd parties. I think either MQTT in emoncms should be dropped and develop emonhub further to be the MQTT front end for emoncms OR just write a Python service to replace the PHP service, but the latter means you have 2 Python services doing the same thing. I have toyed with the idea of a redis interfacer for emonhub so that it can write directly to emoncms input queue’s somehow, using emonhub you could have as many MQTT interfacers set up as you liked, so subscribing to some obscure IoT devices MQTT topics would easy, rather than forcing all devices to publish to emoncms’s chosen base topic.

1 Like

Perhaps a new thread? I do not understand the inner workings of the message/data handling between emonhub and emoncms. I do suspect that a python script to provide an interface (in and out) between emoncms and an MQTT broker is going to be required. Whether that is via emonhub or not I could not say.

However, for now, I suspect ‘Buster’ will have to remain unsupported.

[edit]
Any reason not to pass a JSON string via Redis?

I’m making a lot of use of MQTT as part of the demandshaper module so I would be keen for a PHP solution to this and Im not convinced we should throw it out more generally. Il make a note to investigate with PHP7.3 . Has anyone tested the latest Mosquitto-PHP with 7.3? looks like 7 might now be supported? GitHub - mgdm/Mosquitto-PHP: A wrapper for the Eclipse Mosquitto™ MQTT client library for PHP.

Looks like there has been a small amount of movement in April; first for 2 years. I was sure I’d read some issues about it and 7.3 but perhaps I am wrong.

Comment about the RPi 4 itself and their manufacturing strategy: https://eandt.theiet.org/content/articles/2019/06/raspberry-pi-4-unveiled-interview-with-founder-eben-upton

2 Likes

There were issues with Mosquitto 1.6.2

Emon MQTT data incomplete

Feed from one input stops updating, others feeds continue to work

Mosquitto V1.6.2 MQTT issues

due to the older images using the Mosquitto repos rather than Debian’s, we are currently using 1.4.10, Buster uses 1.5.7, i seem to recall that when the raspbian repo was at 1.5.? users (Brian?) were rolling back to the 1.4.10 due to some other errors, where between 1.4.10 and 1.6.2 things fall over i don’t know.

Yeah, initial php7 support came in at the end of 2016, little has happened since then, only 2 commits since the end of 2017!

A couple of those links above do use 7.3, but the issues were with the Mosquitto version not so much the PHP version AFAIK.

The extension hasn’t been updated since March 2017 on PECL, php 7.3 didn’t release until 2018 so if it is compatible it’s more chance than anything.

I wasn’t suggesting dropping MQTT support, just changing the way it’s done. You maybe flogging a dead horse with support for MQTT in PHP, even if PHP7.3 does work with Mosquitto 1.5.7, what happens when we reach Mosquitto 1.6.2 (already known to be an issue)? or php7.4, scheduled to be released on November 21, 2019?

Yes I’m with you on that. MQTT publishing already uses Redis (IIRC). Why not do the same both ways via a python script and use JSON as the message format? Just a thought.

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.

1 Like

Interesting reading. Especially the line about the lack of stabilty at 7 nm.

1 Like

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! :slight_smile:

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

1 Like

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 :frowning: 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.

1 Like

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.

2 Likes