Community
OpenEnergyMonitor

OpenEnergyMonitor Community

Is there any way to regress to emonSD-26Oct17?

I have made mistakes regarding an attempt to upgrade my emonpi so I needed to start with a fresh install. I cannot use the emonSD-24Jul20 release. When fresh installing the 26Oct17 release it gets stuck in the initial auto update phase (still going after 12 hrs!), and all attempts to reboot or turn off fail. After disconnecting the power, the restart gets stuck on the “Pi booting up” sequence for ever. Is it possible to stop the auto updates when installing this 24Jul20 image?

Why not?

My wall mounted monitor is an elderly iPad 1 with Safari which works well with the 17 release. A brief go with the 20 release showed the iPad would not display the graphic outlet. The iPad is on ios5.1.1 and cannot be upgraded.
The 20 release does not include NodeRed and I have been using emonpi/NodeRed to control my EV charging successfully for 4 years. It took over 10 hrs of following the detailed instructions over and over again to try to install and commission NodeRed on 20 but try as I might I could not connect NodeRed input to the emoncms data. Not that this mattered as I found that I could not use the iPad anyway.
After 4 years of very successful use I was a bit silly trying for the update given the issues so I am trying to get back to my previous configuration. And before you ask - I didn’t know how different the update would be when I elected to update via the admin function in emonpi. A screen appeared telling me I could not update, but too late - the LCD was frozen on “updating do not disconnect” and my troubles started. That’s when I obtained a 32GB micro SD and attempted a clean upgrade. And now I can’t seem to find a way to regress back to 17.

I’m not sure what to suggest.

The initial update is, I think, a Raspbian process rather than an emoncms thing. You could pull the Pi out and connect a monitor and see what is going on at first boot.

NR was removed as it had changed over time and the recommendation is to run it on a separate device and not the EmonPi. As you have discovered, it is a little picky sometimes.

Re the iPad, can you install another browser?

I have been looking for iPad alternatives without success. The iPad 1 will not accept other browsers from the Apple App Store as it is too old. I have also been looking at jailbreaking it and trying for a Linux solution but without success - I did find several internet sites dedicated to trying to make these early iPads usable with Linux, but early days. The very sad thing is that until my very silly interference, the emonpi / NodeRed combination was operating extremely successfully. It seemed such an easy solution - download and re-install the 17 version, which works well with its integrated NR package and early browser support, and repeat the previous setup. Given that 17 is available for download, I was hoping that someone must have been able to figure out a method of preventing the initial auto update and consequential freezing up of the installation. If not, the download is not useable. I will try yet again today with both the original 4GB SD and a larger SD to see if this makes a difference, but I am not confident.

As Brian suggested, I think you need to connect a monitor to the Pi to see what is happening during that first boot. I presume you also checked the web interface wasn’t available and didn’t just believe the LCD display?

Indeed, “Booting…” comes from the Atmel 328P and the “emon” part of the emonPi. It’s only when the Pi is up and running that it sends serial data to the display and wipes that line to replace it with its own data.

I have tried an installation of 17 via ethernet after disconnecting my router to the internet - worked well, and enabled setup. I then enabled wifi and set it up as normal. I was surprised to find it locked up with the message “Updating do not disconnect” hours later, with the system unresponsive. I gather that eventually the auto update starts and for reasons unknown gets locked up with something its trying to update from the latest version 20?? I will try this again today but with a different MicroSD. I don’t think this is relevant but I flash the SD from a Mac using balenaEtcher v1.5.116, which always finishes with a verification.

Trying to be a bit more precise I have now undertaken the following:

1st test: using MacBook Pro OS10.14.6 and install latest 24Jul20 to prove process
Download emonSD-24Jul20
Flash onto 32GB microSD using balenaEtcher 1.5.116
Insert SD into hardware, ethernet connected and wait
Screen: Updating……….DO NOT UNPLUG
After several minutes, update finishes
Allow SSH connection selected
Download and install NodeRed
Follow every instruction religiously to complete NodeRed installation
Replace circuit boards into cover and connect all peripherals
Plug in, all normal, setup required feeds from inputs
Solar App now visible and working, seen with MacBook and Apple iPad Air
Can access emoncms log in screen with iPad1, but will not log in to show graphics.
Can access NodeRed, import NodeRed EV program, but cannot get the MQTT inputs to engage with emoncms

Conclusion: The process to install emonSD software works, but version 24Jul20 removes functionality that I have used and that has worked well during the last 4 years.

2nd test: repeat process with emonSD-26Oct17
Download emonSD-26Oct17
Flash onto 32GB microSD using balenaEtcher 1.5.116
Insert SD into hardware, ethernet connected and wait
Screen: Updating……….DO NOT UNPLUG. This is frozen. The front and reset buttons have no effect.
(In this case I waited 2 hrs. On previous occasions this has been literally overnight. This is the same issue as when I used the software update option on my original stable in-use system).
Disconnected power, and restarted.
Screen: Booting……Please wait. This is frozen. Front button not working.

Conclusion: Either something important is being requested for update but is not available, or something is now being updated which is incompatible with the software.

3rd test: repeat process with emonSD-26Oct17 but without internet access
Flash onto 32GB microSD using balenaEtcher 1.5.116
Insert SD into hardware, ethernet connected but internet disconnected
Noted front screen error – could not connect to MQTT server
Disconnect power (presumably interferes and hopefully stops installation process)
Replace circuit boards into cover and connect all peripherals
Plug in, all normal, setup required feeds from inputs
Checked log – issue:
000|WARN|phpmqtt_input.php|Not connected, retrying connection
Connect to the internet.
WARN|phpmqtt_input.php|Connecting to MQTT server: Connection Accepted.: code: 0
WARN|phpmqtt_input.php|Subscribed to topic: emon/#
Solar App now visible and working, seen with MacBook, Apple iPad Air and iPad1

Can access NodeRed, import NodeRed EV program, but cannot get the MQTT inputs to engage with emoncms. This strikes me as odd as the NodeRed program was a copy/export of the previously working program

SSH into emonpi and check MQTT as per website instruction using:
$ mosquitto_sub -v -u ‘emonpi’ -P ‘emonpimqtt2016’ -t ‘emon/#’
All required MQTT inputs are present and updating properly

Seems like the one remaining issue to be resolved, will struggle until desperate then post a seperate issue (but might be connected to this issue?)

So finally to see if I could fix the NodeRed “won’t connect” issue I decided to again try the update procedure. And again, the log stated the system was to old and would not be updated - and the emonpi is now frozen with the LCD “Raspberry Pi Booting”, and no ability to reboot, turn off, etc. Disconnecting is my only control, and on repower it is back to the frozen state “Raspberry Pi Booting”. I will again go through the rebuild without internet connection; looks like I have lost my NodeRed EV charging program.

Have you at any stage had the HDMI port on the Pi connected to a display when it was booting up to the “frozen” state?

You may need to update the MQTT configuration - I’m not sure the passwords are preserved.

Do you mean you installed NR then copied the flow into the new instance?

I wonder if the issue is the local time of the Pi. That image is so old that the restored time will be way out and if it is too far out, timesyncd will not correct it.

Once installed, go into the Pi and set the time date then connect to the internet check the time date has synced and then force an apt update & upgrade.

My emonpi is a bit old and does not have a HDMI port (or any screen port) so I have only seen the logs when able to connect - and when starting up no connection possible.

The date as set is correct (UTC - not Summer Time). The emonpi Debian GNU/Linux does not recognise “timesyncd”. You are correct - the old developed NR flow is copied into the new NR, which is fully pre-installed on this emonSD-26Oct17. I never had a MQTT connection issue with the original emonpi so this is a bit foreign to me. It appears to be the only issue with the flow.

There is a standard Raspberry Pi board (probably a 2B+, 3B+ or 4B, depending on its age) within your EmonPi and all of those Raspberry Pi boards have a HDMI port. That port isn’t brought out to outside of the case in the EmonPi though, so you might have to take the Pi out of the case to access the HDMI port.

When Brian and I suggest plugging a screen in, we’re talking about into that Raspberry Pi HDMI Port.

You need to pull the Pi out.

At what point? Before you connect to the internet?

Because you will have set it up. Go into the MQTT configuration item in NR and check the password is there.

It never connects first time. You do not need to connect to the internet as the MQTT broker is on that machine.

I have tried to follow all the instructions on emonPi, NodeRed and MQTT - Blog | OpenEnergyMonitor
and it fails on 2 counts:

**[email protected](rw)**:**~**$ node-red-pi --max-old-space-size=128
Welcome to Node-RED
===================
12 Mar 09:37:35 - [info] Node-RED version: v0.15.3
12 Mar 09:37:35 - [info] Node.js version: v0.10.29
12 Mar 09:37:35 - [info] Linux 4.9.35-v7+ arm LE
12 Mar 09:37:36 - [info] Loading palette nodes
12 Mar 09:37:42 - [warn] ------------------------------------------------------
12 Mar 09:37:42 - [warn] [sensehat] Error: Can't find Sense HAT python libraries. Run sudo apt-get install sense-hat
12 Mar 09:37:42 - [warn] ------------------------------------------------------
12 Mar 09:37:42 - [info] Settings file : /home/pi/.node-red/settings.js
12 Mar 09:37:42 - [info] User directory : /home/pi/.node-red
12 Mar 09:37:42 - [info] Flows file : /home/pi/.node-red/flows_emonpi.json
12 Mar 09:37:42 - [warn] Communication server error: Error: listen EADDRINUSE
12 Mar 09:37:42 - [error] Unable to listen on http://127.0.0.1:1880/
12 Mar 09:37:42 - [error] Error: port in use

I have tried the suggested
sudo apt-get install sense-hat
and this fails to connect with a number of IP addresses.
I know it needs to connect with 127.0.0.1:1880/ but does not seem to do so. I have tried this in the MQTT NR node, as well as 127.0.0.1:1883, to no avail. (At least when I try these the NR MQTT node at least goes to a yellow state “connecting” as opposed to just the red “disconnected” I get with localhost which I used successfully in the past with my original flow). If I have to use the user/password settings, what do I use? I have tried various combinations without success - I never used them at all in the previous system.

I would expect NR to be running at boot time - no need to start it (probably why it fails).

Open Node-Red, double click on the MQTT in/out node, click on the pencil icon against the server

image

and check the credentials for your server (different to mine).

Then deploy. If you get a green dot under it, it is connected.

The server credentials I used on my last EmnSD-26Oct17 NodeRed inputs successfully were:
Server: localhost:1883

I think I’ve exhausted my supply of suggestions.

The current advice is to use NR on a separate system/Pi to emoncms. The 2017 image will become more problematic as that version of Linux is (or near) End of Life so not supported.

Sorry I can’t help further.

Thank you - I appreciate your inputs in trying to assist.