Archived Forum

Been looking into this more, and found out that the readings the emonTx's give out over the UART header also make it to the emonBase over RF.

I ran the $ minicom -D /dev/ttyAMA0 -b 38400 command I found on http://openenergymonitor.org/emon/modules/emonpi#ssh

In looking through the forums here, I learned that other people are having problems with the latest (?) version of emonhub.

Does the emonBase auto-update when connected to the internet?

How can I update the emonBase as mentioned here: http://openenergymonitor.org/emon/modules/emonpi#update ?

I can't seem to access my emonBase from my browser by just entering it's LAN IP address, just by using SSH.

I don't believe the emonBase does update automatically, but hopefully Paul (pb66) will be able to answer the emonHub questions.

One point about your assembly requires a warning: The RFM69CW radio modules must not be operated at full power without an antenna (that warning is in the data sheet), so it would be advisable to have some sort of antenna, if only a long wire, to reduce the power reflected back into and therefore dissipated in the output stage of the transmitter.

Thanks for the warning about not using any antenna, I will add a wire to it.

Another thing I just found by reading the emonPi/emonBase setup guide: "The emonBase will need to be shut down by logging in via SSH and entering $ sudo halt."

"CAUTION
Unplugging power from the emonPi without properly shutting down can result in a corrupted SD card."

Until now we've just unplugged it without doing this. How do power outages affect the SD card?

(we have it send data to emoncms.org, not keep it locally on the SD card)

I believe that there's no journaling etc in the OS that is used, so if there's a write in progress as the power dies, the card might be corrupted. Others here know the details better than I do.

Can you provide some emonhub.log?

you can open the whole existing log with

cat /var/log/emonhub/emonhub.log

as a static file or you can see and active version if you use

tail -f /var/log/emonhub/emonhub.log

to see the last 10 entries and any new ones as they are added.

The log level will probally have shipped as "WARNING" so the logs may not be very informative until you set "loglevel = DEBUG" in emonhub.conf. To edit the conf you will need to switch the OS to "write" mode and then open the conf file in a text editor using

rpi-rw

sudo nano /etc/emonhub/emonhub.conf

Once edited you can save the file with ctrl-x => y => enter.

You may find once you have found your way around or set the loglevel it is easier to reboot to get a completely fresh log (the gets reset every reboot on a read only OS) or at least restart emonhub using

sudo service emonhub restart 

to capture the starting up phase as this will show if there are any initialisation issues.

The methods above should work on all systems regardless of era or version, but there are other ways too, using emonhub commands eg emonhub -c to open the configuration for editing or later versions have a webpage in emoncms.

Without knowing what your image comprises of it's a little tricky to be specific, but I expect if you purchased it within the last year the odds are it's the "emon-pi" variant of emonhub, emoncms (possibly v8.5) is installed  and the OS is configured as Read-only with a writable partition. 

Generally speaking it is considered bad practice to "just pull the plug" on any OS but most OEM images (certainly all last year) are configured as read-only BUT many are then given a writable partition to enable some stuff to be persisted. Although much more resiliant than a non read only OS the writable partition is a weakness as it couls cause failure and a failure takes down the whole card not just the partition.

However I have been running fully Read-only images for several years and deliberately stress test them by never shutting them down gracefully. They have survived many power cuts and "plug pulling" without any issues of any kind. These images however are not the OEM images, they are very simple, but extremely reliable emonhub v1.2 and a fully read-only OS with no writable partition or other OEM software such as emonCMS running.

Most of the "emonhub" issues you will have read about will be the "emon-pi" variant. The genuine emonhub code has not needed any bugfixes for well over a year. The auto baud detection is a little iffy but that can be easily over ridden as is recommended (it is only needed if you do not know the devices baud).

emonhub doesn't automatically update itself but if you do use the emoncms update function in later images it will also update emonhub.

I think it's unlikely any thing has "updated" unless someone has instigated it, if you can provide some emonhub.log we can go from there, if the log doesn't include the start up can you confirm the version? it is included in the first couple of messages following emonhub being started. 

Paul

We bought it sometime in April 2015.

I have been trying to install a (somewhat) newer on the SD card using the info here http://openenergymonitor.org/emon/guide but so far my PC bluescreened twice while trying to write the image file to the SD card using Win32DiskImager.

This PC is running Win7, I'm currently trying to write to the SD card on a Win XP laptop.

Hasn't crashed (yet) but all this probably means I can't use the old version to get a logfile.

Oh! that doesn't sound good at all! I have no recollection of any "blue screens" being previously reported.

If you have partially over-written the sdcard or corrupted it then there is no going back. But if I were you I would try the card in the Pi again and if it boots then do not attempt any further overwrites until you sort the win32imager out. If you have another card, test with that until you are able to successfully write each time, if you are using a usb sdcard reader you could also use the Pi to write your image to the 2nd card rather than a PC if all else fails (and the first sdcard is intact).

I wouldn't bother with a later image they are becoming more suited to the home IoT enthusiast rather than a robust professional solution. If we are unable to access the old image and debug / fix, then I would strongly recommend a custom "rock solid" image. I can help you with that if you wish.

Paul

It works!

I thought I posted this an hour and a half ago, but I guess I didn't click "save" on the forum post correctly.

This PC has been derpy sometimes. I also noticed after the first bluescreen that there was 74GB out of 76GB used on the HDD, so that might be problem when working with a ~4GB image file.

The PC has a multi-card reader on the front, the laptop has just an SD card reader.

I did get Win32DiskImager to succesfully write the image file to the SD card. Then I put it in the emonBase, powered it up, connected it to LAN, and navigated to http://emonpi/, registered an account and entered the write api key from my emoncms.org account.

We've just installed it at the client we intended to install it at a couple days ago, and it's been updating the graphs on emoncms.org since then.

(new grocery store in old building, we intend to find out how much smaller the building's main fuses can be. You pay less monthly for having smaller values)

The old image that suddenly didn't work anymore is now gone too cause it's overwritten, so we can't find the actual cause of the problem.

I should write up a post about our logger, which is what we call it. Curious what others would think about our solution for measuring 3 phase voltages with a single emonTx V3.4.

--- your image  -- if you purchased it within the last year the odds are it's the "emon-pi" variant of emonhub, emoncms (possibly v8.5) --

The image I installed now IS V8.5, meaning our original image predates that. I looked up the invoice, we ordered it on April 13th, 2015.

Regardless, thank you both for trying to help, Robert and Paul!