Archived Forum

The preliminary image I posted up here now needs upgrading with the kWh data bug fix and the feedwriter symlink rather than manual edit:

http://openenergymonitor.org/emon/node/11009#comment-34766

Not quite sure how to follow this thread without posting so thanks. Love your work.

Trystan - In the list above I saw a reference to "my electric bug fixes".  I am curious if the "00:00 UTC to 00:00 local time" issue was fixed for the SD Card Image?  This is when the My Electric app doesn't work properly starting at 00:00 UTC and then starts working properly after 00:00 local time (for me that is 00:00 CDT or 05:00 UTC). 

In the current version of emoncms.org (v9) it has the same issue.  The My Electric page shows an odd bar graph and USE TODAY states the ALL TIME kWh usage. 

         Before 00:00 UTC

         After 00:00 UTC (lasts until 00:00 local time)

EDIT - removed old image and added current images from today.

Thanks Jon, I still need to look at the myelectric bugs, I keep thinking I find a fix and then something else pops up, not sure yet about the latest ones. I will update on progress.

Great news, thank you in advance :)

openHAB and node-red together with emonCMS in a single image, that would be really a great pleasure :)

please report about the progress, and the availabilty of the image.

My only comments would be that the base image is getting quite large now, do you actually need NodeRed + openHAB for everything to work correctly now?

@Jon, I think I have fixed the issue between midnight UTC and midnight local time. I've pushed up the fix to both the master and v9.0 branch of the apps module. Can anyone running this on a different timezone confirm that I havent broken anything in the process?

Hi 

When i try to update my emonpi i get this error

pi@emonpi /var/www/emoncms $ cd /var/www/emoncms && git pull && git checkout 9.0Already up-to-date.
error: Your local changes to the following files would be overwritten by checkout:
        Modules/dashboard/Views/js/widgets/dial/dial_render.js
Please, commit your changes or stash them before you can switch branches.
Aborting

anyone no how to fix?

Thanks Steve

fix with 

git reset --hard

all upgrade and working now

We are currently working on building and testing a SD card image with the following features: 

• Based on minibian lightweight Jessie (12-11-15) 
• 4GB min card size download (shipping on 8GB expanded SD card)
• Emoncms V9
• Read-only root FS (see discussion thread) with MOTD to display a login notifying users how to switch to RW
• NodeRED, LightWave RF MQTT OOK control and openHAB installed with skeleton OEM config 

I would be interested tp hear if anyone has some thoughts or comments on the proposed feature set. 

Glyn,

For my three hapence worth I'd have things like OOK control and openhab as options on the install.

I think the SD card image should contain the basics of a functioning system with those additional non specific features like MQTT  and NodeRed. Lightwave OOK is very specific as is openhab.

Not sure how this could be acheived, maybe through something like the raspbian 1st time setup.

Hi Glyn

Not sure if this is a bit off topic but is there any way to include a function the resize the SD card  with in emoncms as I think me a most other people with have to upgrade their card at some point in the future as the OS/MySQL patches and emoncms grows

Steve

If it is of any help I have a guide here that explains how I setup my Pi images to be readonly: http://blog.mjwconsult.co.uk/embedded-read-only-root-on-raspberry-pi-and-odroid/

If I need a writeable disk I run the script /opt/bin/mount-rw in /etc/local before exit 0:

/opt/bin/mount-rwdata &

making sure that I have a definition in /etc/fstab for /mnt/rwdata.  Eg:

/dev/sda1 /mnt/rwdata ext4 noatime 0 0

There are also a number of init scripts etc. to make apps readonly (usually putting PID etc in /tmp) under: https://github.com/mattwire/embedded_debian/tree/master/apps

I also use monit to supervise running processes and there are scripts for those processes there too.

Hope that is of use.

Matthew

Thanks Matthew 

I have a read of that 

Steve

Based on minibian lightweight Jessie (12-11-15) 

The raspberrypi.org folks now have a "lite" version of Jessie.

www.raspberrypi.org/downloads/raspbian

The lite version of Jessie = minibian I believe 

The lite version of Jessie = minibian I believe 

Doesn't look like it.

Unzipped, the Raspbian Jessie Lite .img file is 1,424,384 kB on disk and Minibian unzips to a .img of 813,056 kB on disk. Looks like Minibian is a better deal when it comes to saving disk space.

If you install the raspbian netinstall version from here https://github.com/debian-pi/raspbian-ua-netinst you start with a 64MB image which installs to around 200MB and is about as minimal as you can get.

Hi Glyn

I think Bill is right about the images 

Sorry, you're right Bill. Minibian is more minimal than Raspbian minimal. However I believe both start from a similar code base (Jessie). Raspbian minimal must have some extra modules. We are keen to stick as close to Raspbian as possible. Minibian is pretty minimal to start with but still on the main Raspbian Jessie Kernel and code base. 

I have recently been testing an image built from scratch on Minibian with a read file system implemented in the same way as on the previous image. As before a few tweaks are needed to make things work with a read-only file system. 

As per the image build guide and install script as in the previous image the following directories are mounted as tmpfs:

pi@emonpi:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       3.1G  1.2G  1.8G  39% /
devtmpfs        483M     0  483M   0%   /dev
tmpfs           487M     0  487M   0%    /dev/shm
tmpfs           487M  6.5M  481M   2%  /run
tmpfs           5.0M     0  5.0M   0%      /run/lock
tmpfs           487M     0  487M   0%     /sys/fs/cgroup
tmpfs           1.0M  8.0K 1016K   1%   /var/lib/dhcp
tmpfs            30M  880K   30M   3%   /var/log
tmpfs            30M  4.0K   30M   1%    /tmp
/dev/mmcblk0p1   61M   20M   42M  32% /boot
/dev/mmcblk0p3  484M   32M  427M   7% /home/pi/data

Paul's R/O NTP time fix is implemented and /etc/resolv.conf.dhclient-new and /etc/resolv.conf are symlinked to writable version in /home/pi/data and a modified version of /sbin/dhclient-script is used.

All is working well: DHCP leases and DNS resolving. However taking a look in the daemon.log there are a few errors relating to a read-only FS. The question is are these errors important? If so should the entire /var folder be mounted as tmpfs? We already mount /var/log and /var/lib/dhcp as RO. I have head of an issue a customer reported after running update & upgrade where /var/lib/dhcp5 was created and needed to be also mounted as tmpfs before a reliable dhcp lease could be negotiated. 

pi@emonpi:~$ sudo cat /var/log/daemon.log | grep only
Dec  1 22:17:17 emonpi systemd-tmpfiles[166]: chmod(/var) failed: Read-only file system
Dec  1 22:17:17 emonpi systemd-tmpfiles[166]: chmod(/var/cache) failed: Read-only file system
Dec  1 22:17:17 emonpi systemd-tmpfiles[166]: chmod(/var/cache/man) failed: Read-only file system
Dec  1 22:17:17 emonpi systemd-tmpfiles[166]: chmod(/var/lib) failed: Read-only file system
Dec  1 22:17:17 emonpi systemd-tmpfiles[166]: chmod(/var/lib/systemd) failed: Read-only file system
Dec  1 22:17:17 emonpi systemd-tmpfiles[166]: chmod(/var/lib/systemd/coredump) failed: Read-only file system
Dec  1 22:17:17 emonpi systemd-tmpfiles[166]: chmod(/var/lib/container) failed: Read-only file system
Dec  1 22:17:17 emonpi systemd-tmpfiles[166]: chmod(/var/spool) failed: Read-only file system
Dec  1 22:17:17 emonpi networking[171]: rm: cannot remove '/etc/resolv.conf.dhclient-new': Read-only file system
Dec  1 22:17:17 emonpi networking[171]: rm: cannot remove '/etc/resolv.conf.dhclient-new': Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: unlink(/var/cache/man/es/index.db): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: utimensat(/var/cache/man/es): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: unlink(/var/cache/man/de/index.db): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: utimensat(/var/cache/man/de): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: unlink(/var/cache/man/fr/index.db): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: utimensat(/var/cache/man/fr): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: unlink(/var/cache/man/pt/index.db): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: utimensat(/var/cache/man/pt): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: rmdir(/var/cache/man/fr.ISO8859-1/cat8): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: unlink(/var/cache/man/fr.ISO8859-1/index.db): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: rmdir(/var/cache/man/fr.ISO8859-1/cat7): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: unlink(/var/cache/man/fr.ISO8859-1/CACHEDIR.TAG): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: utimensat(/var/cache/man/fr.ISO8859-1): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: rmdir(/var/cache/man/vi/cat1): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: unlink(/var/cache/man/vi/index.db): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: rmdir(/var/cache/man/vi/cat7): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: unlink(/var/cache/man/vi/CACHEDIR.TAG): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: utimensat(/var/cache/man/vi): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: rmdir(/var/cache/man/fr.UTF-8/cat8): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: unlink(/var/cache/man/fr.UTF-8/index.db): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: rmdir(/var/cache/man/fr.UTF-8/cat7): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: unlink(/var/cache/man/fr.UTF-8/CACHEDIR.TAG): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: utimensat(/var/cache/man/fr.UTF-8): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: unlink(/var/cache/man/cs/index.db): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: utimensat(/var/cache/man/cs): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: unlink(/var/cache/man/ru/index.db): Read-only file system
Dec  2 10:10:43 emonpi systemd-tmpfiles[4037]: utimensat(/var/cache/man/ru): Read-only file system
Dec  2 10:17:01 emonpi systemd[1]: Stopping LSB: Save the current clock & ntp drift on read-only filesystem...
Dec  2 10:17:01 emonpi systemd[1]: Starting LSB: Save the current clock & ntp drift on read-only filesystem...
Dec  2 10:17:01 emonpi systemd[1]: Started LSB: Save the current clock & ntp drift on read-only filesystem.

Hi Glyn,

Have you thought about creating the SD card R/O image with the same tools used to create a Live CD?

Since an SD card R/O filesystem, and a Live CD filesystem both operate in read-only mode, perhaps some insight could be gained on how to build an SD image that operates sans the R/O errors listed above.

Thanks for all your hard work on this part of the project.

I think it will be useful for many people like myself. I would like to see the inclusion of the suggested addons such as MQTT, NodeRed, Lightwave OOK and openhab. I have found in the past that these are difficult to build onto the base EMONCMS system and to have working correctly. I think the majority of people would like to be using these sort of extra modules to control the power in their homes as just knowing the consumption is very useful, but seems like the first step.

I can understand from a CPU and RAM point of view that people may not want these additional modules, but if they aren't configured I can't see that they would be putting much if any load on the system. From a storage point of view, the extra space is really nothing considering the cost of microSD cards today.

How is the development going?

Today I use Emoncms NOT ONLY for "power control". I send to it any kind of "numeric data" that Emoncms can log and give me a feedbak or stattistics.

I have two RaspPi, and Emoncms is logging data from them, like: CPU temperature, memory and CPU use, wifi signal, disc space. Emoncms give me the opportunity to predict a possible problem, or just analyse when something happened.

I don't beleive that Emoncms should have any special Openhab addon. I can see Emoncms data into my Openhab using Openhab addos (this is Openhab function). I can see data via MQTT and Dashboards via HTTP.

Maybe, only to ADD in Emoncms a way to see specific graphics and Apps without all the html content, to add them into any other tool or website. These graphics could add a Emoncms logo into it (wathermark). I believe that this is not so hard to do.