emonBase frequently unusable

I have the emonBase with 10 emonTH.
I use it together with node-red to control the heating system for my house.
I have 8 heating circuits which for which I use node-red to control them.

Every 1 to 2 months I have to reflash the whole system.
Last night I made a configuration change in the emonhub.
After a restart of the raspberry pi it’s just bricked.
No http connection possible. No ssh connection possible.

Really annoying to reflash the whole system. Install all packages and updates.
Lost all my emonTH data. Lost configuration data.

A day before I tried to do a backup in the emoncms but no luck => segmentation fault.
Whatever that means.

Am I the only one who has such problems?

I’m seriously consider to build my own emonBase with a simple Arduino to receive the signals from emonTH and do the rest on a more stable system than the emonBase.

Hello @heebtob sorry to hear that, are you reflashing to the same SD card? what other applications are you installing? I wonder if the additional packages you are installing are causing additional write wear to the SD card reducing the lifespan?

I suspect this is an SD card issue especially if you are saving values to disk from node-red. I’ve had an SD card in a Pi in such circumstances fail within 6 months.

I suggest a new SD card for the EmonBase and run node-red on a separate Pi.

If you do want to stick to a single Pi, you need to offload the system to a HDD or SSD device (plenty on the RPi docs and forum on how to do that). You can then easily build the emonbase with the emonscripts.

What version emonSD are you running? The emonSD have been optimised for long term SD card lifespan: emonSD pre built SD card Download & Change Log · openenergymonitor/emonpi Wiki · GitHub

It’s also possible to create full backups to easily and quickly restore using Emoncms backup module pre-installed on emonSD.

Strictly speaking that is true if just running EmonCMS on it. As soon as a user uses the system for other things as well, those other systems can well impact the longevity of the SD Card.

1 Like

Thanks for the comments.
I now understand the heart of the problem.

In my case node-red is not optional. It’s the heart of the system.
However emonBase/emonhub/emoncms is only there to receive and store emonTH data.

Personally I’m done with the raspberry pi. I bought a Udoo bolt V3 as a solid base for a new system.
Ubuntu as OS, node-read as the central controller and an mqtt server to store the data. Also a backup is planned to periodically save all data to a NAS and a UPS to safely shutting down the system if there’s a longer power outage.

I also bought an Adafruit Feather 32u4 Radio (RFM69HCW). I’m planning to add an Ethernet shield to that to be independent. The new Adafruit should receive the 433 MHz emonTH data and directly send them to an mqtt server on the Udoo. Then node-red will process the data from the mqtt server.

I realized that this isn’t quite as easy as I thought. I thought that writing a new firmware to receive the emonTH data is everything I need to do. The problem is that the emonTH uses a little bit special library for the RF processing called Jeelib. I would like to use a more common library like RadioHead. I don’t care about compatibility with older hardware. I just have the newest emonTH’s. So I also need to write a new firmware for the emonTH itself and update all emonTH arduino’s.
I don’t know how to update them because they don’t have a USB port.

Could I get some tips how to do that?
Do I need to solder some USB Ports to the board?

I appreciate your help and feedback about my ideas. :wink:

So the Pi, as you discovered, is not really the ideal tool, if it is writing regularly to the SD Card.

If you don’t want to use EmonCMS to store the data, you could simply have the EmonHub installed on the Pi with the EmonBase card - It will then receive the RFM data from the TH and pass it onto your MQTT broker.

I have the RFM board on an OrangePi doing just this. All that is installed is the emonhub python script and the systemd service to run it.

As you have the RFM board and EmonTH, it seems a waste to butcher it. It is extremely reliable if setup correctly.

Use the right tool for the job - you wouldn’t use a glass bottle to hammer in a nail. It isn’t the bottle or the Pi’s fault if it fails to do what you ask of it.

Personally, I use Pi’s for bits and pieces, but my main systems run on multiple VMs on an HP Micro Server.

I’ve been running an emonBase rPi for about 3 years and had 1 major SD card failure - but I did have a couple of python scripts writing other data to file as well. It has 2x emonTH’s, 2x emonTx, a modbus connection to PV inverter and a Mk2 diverter for hot water.

A few months ago I looked to add a water level sensor, using an additional RFM69 transmitter but found it impossible to integrate it into the existing JeeLabs platform, and confirmed by @Robert.Wall in [this post]
(Custom sensor nodes - #12 by Robert.Wall).
So I ended up using a pair of Adafruit feather 32u4 RFM69HCW boards with the LowPowerLabs library. A simple Arduino script picks up the data and another python script (originally on rPi but now on my desktop) sends the data to the MQTT server on the emonBase. This data is also picked up in Node-red for other uses.
So far it’s been working well.

Just use the right tool for the right purpose is a good advice. :slight_smile:

I replaced the emonBase with a very small PC (Udoo Bolt) which runs ubuntu with docker containers.

The problem was that the Udoo doesn’t have an RFM Module to receive the EmonTH data. I had to build some kind of relay from RFM to MQTT. And then I went down the rabbit hole. :stuck_out_tongue:

I bought an Adafruit Feather M0 with an RFM69HCW and an ethernet module. The next problem was that the EmonTH uses some weird library from JeeLib. I prefered RadioHead which Adafruit suggested. But they won’t talk to each other. So I had to rewrite the firmware of the EmonTH. I found the source code somewhere on github. First I just wanted to get the RFM working but later I realized how easy it was to use some more cool features like AES encryption. The power consumption was also challenging because I had to get rid of the JeeLib code which did that stuff magically. I had to learn how the sleep modes work on the ATmega328P. Work through the ATMEL datasheet. That brought me back memories of my engineering studies. Cool stuff but not an every day task for me.

Beside the MQTT Server I use Node-Red and ElasticSearch with Grafana. Everything with docker containers. Node-Red controls the heating valves in my home based on temperature data sent from 12 EmonTH modules. With ElasticSearch and Grafana I can create some fancy looking dashboards to visualize everything.

Rewriting the frmware of the EmonTH was really a challenging thing to do but in the end I succeeded.
:muscle: :partying_face:

The system is now running for about 2 months without any problems. So I would call it a success. :slight_smile:

1 Like