Something caused my emonPI to lock up tonight. The LCD display had frozen, no response to pressing the button and no response to the network.
So I had to power cycle it.
It appears to have come back to life, but I can see one issue.
On cycling through the LCD display, Power1 & Power2 both indicate “—”. However, both of these feeds are reading and logging values which appear to be correct.
Both CTs along with the Voltage Adapter are shown as detected on the LCD Display during the startup.
Would this be a hardware or software issue I’m looking at?
In the event that the unit has a fault, are replacement EmonPI units still available?
At the moment I’m making a backup of what’s there and I do have a backup which was made last week.
Just to add to those. It’s only the Power1 & Power2 values on the LCD which seem to be the problem. All the other data shown on the LCD such as wifi status, vrms, appear to be fine.
The SD Card is less than a year old, it was replaced back in January this year when the system was showing some corrupted data in the feeds. The emonPI was four years old in August.
I could flash an image onto a spare card to see how that affects the values on the LCD Display.
The emonPI had several reboots last night and the hardware powered off completely to ensure a full reset. The only thing I see is that the Power1 & Power2 values are still indicating “—”
so, I might leave it till the weekend if it’s still functioning and only the local LCD display values are affected. Is it possible that the power value indications are unrelated to the lockup and that these values on the LCD have been faulty for some time? I don’t visit the electrical cupboard very often to press that button.
But I wouldn’t mind understanding what corruption/failure has taken place to stop only the power values indicated on the display. Should I be looking at any particular log file?
In my mind also, is that the system has grown from only two CTs and a couple of EmonTH’s. To have 245 Inputs, 270 feeds, 10 dashboards and collect/shares feeds and inputs with Home Assistant. It is four years old so I have thought that since the home relies on it so much, I should perhaps consider upgrading to the new version which I see splits off the power monitoring from the database/webserver which means I’m really only looking at a Raspberry PI being the culprit of a Total Failure of the system which to me seems easier to repair.
Seems to be only two values on the LCD. Looking at the values from the feeds they seem to be reading correctly for the house usage and solar generation today.
Model :- Raspberry Pi 3 Model B+ Rev 1.3 - 1GB (Sony UK)
Serial num. :- 71604C19
CPU Temperature :- 55.84°C
GPU Temperature :- N/A (to show GPU temp execute this command from the console “sudo usermod -G video www-data” )
emonpiRelease :- emonSD-10Nov22
File-system :- read-write
Client Information
Client Information
HTTP
Browser :- Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
Language :- en-GB,en-US;q=0.9,en;q=0.8
Window
Size :- 2069 x 1104
Screen
Resolution :- 2560 x 1440
If you think you are pushing it too much, the key bit to watch is this. As long as load average is less than one, the CPU is idling at times. Also need to watch memory usage.
The one thing I have seen is that if reading too many MQTT topics, the system can miss some data. Better to send multiple inputs as a single JSON data structure on a single MQTT topic. If you get the structure right, it just replaces existing inputs so you don’t need to redo all the input processing.
HA runs on its own hardware, another PI in a nice metal case hidden away in the IT cupboard:-) The emonPI I like to leave standard which makes supporting it and getting support far easier.
If I can’t make the changes to its configuration via the web interface I’m usually very reluctant to make changes to the Linux operating system as that takes it away from the standard install which may cause me issues in the future.
The problem I have is that in a previous life part of my duties was as the administrator of the OSISoft PI Server for a Power Station. So that was collecting roughly 45000 tags every say 1 second. So I tend to treat the emonPI as if it can do the same thing and forget that adding several hundred tags could kill it:-) I do occasionally check to see how the PI is performing, and that’s partially a reason I’d like to upgrade to a separate Database/webserver from the Power Measurement.
I’m used to creating batches of thousands of tags and not blinking an eye:-)
But hey, comparing it with an industrial data logging system with a database that supports a hundred client requests for data and tens of thousands of tags, I’m always impressed by what the emonPI can do for its price:-)
But hey, today’s puzzle is these two LCD indications:-)
Modbus over TCP/IP, Modbus Serial, OPC, and a couple of proprietary interfaces on a Siemens and Wonderware-based DCS. In the same way, we grouped the Modbus tags to collect around 100 consecutive addresses at a time, and the OPC were in groups of 800.
You create the tags as a list in a Spreadsheet with all their attributes and then import them into the system. I think the biggest single import of tag configuration I ever did was adding just over 14,000 binary and 3,500 floating Point tags when some new Gas Turbines were added, and they all just started reading.
Interesting, I do see that an MQTT software interface is available for that DCS as well now:-) But everything seemed to be heading OPC, or we would insist on Modbus over TCP/IP as 2nd option.
On another note, yesterday I made the decision to upgrade the EmonPI to the newer system with separate EmonTX V4 and emonCMS Base Station. There is so much in the house now that relies on it, and that PI has run now for 4 years I suddenly realised how exposed the house is to what would be a single point of failure.
I think that with the new system, it is easier to replace the base station, and should the emonTX V4 fail, then I don’t have the issue of the other nodes losing data. So that’s going to be installed through the week sometime. I think I’ll run the two in parallel till I see all the feeds updating correctly.
But still, I’ll bottom out the problem with the EmonPI once it’s released from service and hold it as a backup should I ever need it. So I need to understand how the LCD gets its values.
I know it won’t help much, but…
At startup, the very first message on the LCD comes from the ATMega 328P, because this starts up a lot faster than the Pi. Thereafter, the Pi takes over except when you’ve asked for current and power factor to aid calibration (c command), which come direct from the front end again.
Beyond this, I can’t help you, because I don’t know my way around inside emonHub & emonCMS.
That will be why then The EmonPi does have an emonhub ModbusTCP interfacer, but it is a little rudimentary.
If you are worried about reliability, an emonTX with a Wi-Fi module hooked into emoncms running on an LXC under PVE on an old laptop is about as robust as it gets (IMHO).
