Archived Forum

Hello Andy. We've been working on the upgrade/migration to v9 procedure for the June 2015 image: emonSD-17-06-15.img.zip which is the version running the low-write branch of emoncms. http://openenergymonitor.org/emon/node/11843.

Its been a while since I have used the image you're running. However, if I remember correctly, that image supported all feed engines including PHPFINA, PHPFIWA and PHPTIMESERIES. How many feeds do you have that use any of those engines? They are listed in the feeds list under the engine field.

I would recommend to start with, making a backup of your MySQL database and the feed engine data files. Then it may be best to start with the latest image we are building here: http://openenergymonitor.org/emon/node/11799, then move the data across.

If you are currently using a hard drive and wish to keep it that way, you may not need to do any data conversion. Let me know what feed engines you're using first, and we can go from there.

Hi Trystan,

Thanks for your reply - I have 23 PHPFIWA feeds and 2 PHPFINA feeds. I'd probably prefer to stick with a hard drive because the existing setup has been rock solid, and I'm also running a small instance of Cacti on the same Pi. On the other hand the prebuilt image is appealing as the path of least resistance ;)

Cheers and Happy New Year,

Andy

An alternative (plan B!) would be to backup your data as per Trystan's post, and start afresh using this guide to install emoncms on your SD card.
Once installed on the SD card, there is now a script to move your OS to the HDD.
Then import your data - again as per Trystan's link.

Should take about an hour to complete.

Paul

Yes good idea Paul

Thanks for the replies - just to let you know that I succeeded in migrating from 8.4 to 9.3.

Performed a clean install of Jessie onto a new RPi 2 and installed emonCMS as per the book. I did the feed engine and DB migration manually because I had already taken a backup from the old install before I saw Trystan's nice new script. I also chose to start with clean emonHub and emonCMS config files.

It was mostly painless, there were a couple of things I noticed along the way:

- Needed to use raspi-config to turn off serial console login (equivalent of modifying inittab in Wheezy). Don't think this is mentioned in the build docs.

- After import of the DB the emonCMS timezone settings were null. Easily spotted after looking at the emonHub logs.

- The multi-graphs made it across fine (contrary to what I'd read before) although they did need re-saving to draw reliably.

- Realtime widgets had lost their feed association, although easily remade.

Other than that, all seems to be working. The only thing left to do is the migration to HDD. Thanks again!

Andy

One unexpected thing which is immediately obvious running 9.3 is how much regular packet loss I seem to be getting. Without the new 'Skip Missing Data' flag set in the visualisation, the graphs look like the attached.

Looking at the emonHub debug logs in noisy mode, there are plenty of discarded packets. I guess 868 is pretty crowded round here, something else to look at when I get time!

Andy

Good to hear you upgraded everything without too much trouble. Glad you seized the opportunity to install a fresh "Jessie" OS (the full version I hope).

The "releasing the serial port" is included in the guide in the "install emonhub" section. Editing inittab is no longer required with Jessie so just editing cmdline.txt is all that's required.

Regards the missing datapoints, there are several possibilities, the foremost are "bitslip" on emonTx's or "RFM not waking fast enough" in emonTH's or "RF collisions" in either. If you can attach a chunk of emonhub.log it shouldn't be too difficult to fathom it out from the "discarded packets" what's happening.

The discarded packets are a much better indication of dropped packets than the fixed interval feeds in emoncms, if, for example a 10 second interval is actually 10.5 seconds then 5% of packets will appear to been dropped even when every packet is successfully received.

Paul

Hi Paul,

Yes I used the full-fat version of Jessie :)

Regarding releasing the serial port, I was under the impression that configuration in cmdline.txt affects whether console data is output to the serial port during boot, whereas the inittab config (as it was in Wheezy) enabled console login via the serial port. Certainly just editing cmdline.txt did not have the desired effect until I then disabled serial access via raspi-config. Still, I was doing several things concurrently so without building it again from scratch I can't be certain.

I've attached a 2 minute chunk of debug level logs. There is a definite periodicity to many of the missing datapoints so an interaction of sampling intervals would make sense.

Cheers for your help,

Andy

Actually most if not all of the discarded packets in that log are weak ( -90+ rssi) and unlikely to be "lost" packets. I havent looked that closly but the few node 10 packets I checked were over 11 secs apart so you should see at least 10 percent of datapoints recorded as null if using a 10 second fixed interval.

The changes to cmdline.txt are only seen at boot time so changing it will have no effect until it's rebooted. Jessie is able to take that boot time info and configure the serial console or not using a deamon rather than needing the inittab file. If you were to check the raspi-config source code the only change for Jessie to the serial console part is they added an "if exists" to the part that changes the inittab file.

Paul  

Yes having spent some time actually looking at the logs I can see that this is more of a sampling artifact. The periodicity of this can be seen in the attached graph from node 10. Can anything be done to tighten up the timings of the nodes, or indeed does it even matter?  

Cheers,

Andy