Community
OpenEnergyMonitor

Community

emonSD with standard Raspberry Pi (non emonPi) setups

Tags: #<Tag:0x00007fc9af075bb8> #<Tag:0x00007fc9af075aa0> #<Tag:0x00007fc9af0758e8> #<Tag:0x00007fc9af0757f8>

Continuing the discussion from Emoncms with existing Pi running Apache2:

There have been some concerns over the compatibility / suitability of the emonSD pre-built image for use on other (non emonPi / emonBase) specific systems. I would like to work through these issues and come to an agreement on a common starting point for new users.

Yes, here’s image build guide. Same link as posted above. The guide follows the Emoncms RasPi setup steps as documented in the Emoncms repo also also adds the emonPi LCD control script + emonPi / emonBase update service. The is nothing in the pre-built image that is inherently emonPi specific accept the LCD control script (which kills itself on startup if no LCD is detected.). The same pre-built emonSD works just the same on an emonBase (Raspberry Pi + RFM69Pi), this is what all emonBase units sold via the shop are shipped with.

I totally understand this. I too, use the Pi with the pre-built image for other tasks such as an extensive nodeRED and openHAB setup, LightwaveRF and a media backup with an external drive connected. Being based on standard Raspbian Jessie I believe the image is very flexible and provides a good starting point for any new user wishing to use Emoncms as a RasPi. Please let me know what else you would like to run on the Pi and the issues you have found with the pre-built image and I will do my best to work through and make improvements.

A bit of history: to maximise compatibility and flexibiity at the request of @Paul and @Bill.Thomson the Dec beta image was fully-rebuilt using Jessie minimal as opposed to Minibian lightweight Jessie, (old forum thread). This was tough decision as the time since the Dec image was almost at the point of release. However I’m glad you persuaded me to make the change. The pre-built image is now better for everyone and in-line and fully up-to-date with standard Jessie image. Thanks guys, I very much appreciate your continued feedback and support :slight_smile:

Apologies if I came across as pushing an agenda, I just want new users to have the best experience, with minimal amount of setup pain and offer the best support. Building the latest image release and all the associated components (including the new User Guide) has been my full-time agenda since November 2015. My hopes for the new image (now it’s released) is that is draws together our cumulative developments over the past 11 months and brings new users inline with latest developments with a clear update and support track (stable Emoncms branch). Up until last week we were still shipping 17June15 image with Emoncms v8!

I’m quite aware of the work involved and many pitfalls of a DIY built. But if a user wants to go down the DIY build, that’s great (I’m sure insights gained will feedback to benefit developments). However if a user is now aware of taking the necessary precautions of running Emoncms from an SD card e.g (low write optimisations etc.) I would be concerned that in 6 or 12 months time data loss may occur due to a corrupted SD card which is not a great experience of the platform. As @borpin experienced

In light of this discussion would you be happy for me to add a note to the Raspberry Pi readme recommending users either use the emonSD pre-build card or move the file system to an external HDD if they wish to install directly onto a Pi without any low-write optimisations?

I admit a read-only root partition does make setup of some applications more involved, but ultimately once issues are resolved results in a more long term stable and reliable system.

Could we come to an agreement that the emonSD can be considered a recommended common starting point for a new user? I’m happy to consider making suggested changes to the image if you have any recommendations? Maybe a toggle (at users peril!) to turn off the read-only partition?

At the end of the day I understand that every user’s requirements are different and there is not one-size-fits all, this is the great thing about open-source that we all enjoy :smiley: .

The first, and possibly major stumbling block is the OS itself. Many users would not want to use Jessie Lite, especially when they are using the pi for other functionality too. With the current cost of SD cards, there should be no reason why space should be an issue, cramming cut down versions into a 4Gb card is really not healthy. (I see that you’re now shipping 8Gb cards with the emonpi :slight_smile:)
IMO it would be far better to use a standard Jessie OS, which would provide the flexibility to accomodate all users.

Yes I think that is an option worth pursuing.

Would it be better to wait until we’ve explored options in this thread first.

Paul

Sorry missed that - followed the other link :frowning:

And here is the rub. You are still assuming folk want to start from the prebuilt image rather than the other way round. My last fresh image was built using ua-netinst partly because it would build directly onto an HDD. I constantly tinker with stuff so would never want an RO OS and use a pure SD card setup. I also do not think you want to get involved with supporting anything else running on the Pi unless it has a direct impact on your core functionality.

I think the effort should be put into ensuring there are a good set of instructions available for those who wish to use an existing setup with the assumption that these users are a bit more savvy.

I think this is a good idea as that state will not change however we take this forward. Might be worth adding a link to the script to do just that.

I see no issue with that, Perhaps a common doc laying out the difference between the approaches (prebuilt v roll your own) as well will help (links in with the above warning).

The other aspect though, is things within Emoncms that are EmonPi specific (such as the reboot button) that should perhaps be built as a configurable item.

1 Like

Emonhub is probably another discrepancy as there are two versions. When this issue has been raised previously we were assured that @TrystanLea would endeavour to work with @pb66 to ensure a single version.
I don’t know how much has been done behind the scenes to achieve this, or if any decision has been reached?

Paul

1 Like