emonSD-03May16 Release

Stopped at 1GB again …

weird as I just pulled it from my server via wget at 11M/s without any problem.

Ok, this should definitely be fixed now. I’ve created a separate files.openenergymonitor.org sub-domain which is set to bypass Cloudflare. This will download direct via http to our server. This will be the most reliable and fastest method.

Please confirm it works for you. Thanks for you patience.

YES! That worked. Much faster too. Also tried via the UK Mirror 1 link and all OK.

Thanks Glyn. Glad I could help test.
Cheers.

1 Like

:grinning: Excellent! Cloudflare is great but there are a few little things to be aware of.

UK Mirror 1 was probably very slow. That’s a little baby server we run in the lab for dev.

Tried it again from my office. Stopped again at 1.0 GB… Was able to resume the transfer.

Were you using the updated link coming from the files sub domain as opposed to /files folder?

New Link (updated above): http://files.openenergymonitor.org/emonSD-03May16.img.zip

If that’s the link at the top of the page immediately to the right of the word RELEASE, yes, that’s the one I used.

The image file is available via the USA Mirror. FTP and HTTP transfers are supported.

Click the link for an HTTP download

The FTP server is: ftp.oemusamirror.com
User name is: [email protected]
Password not needed, i.e. it may be left blank

Note: For an FTP transfer, enter the user name as shown above, i.e. the entire string.

Another mirror on a Canadian server

no need for logins, just click the link

1 Like

Eric,

I added your link to the others at the top of the thread.

1 Like

Thanks for the mirror links :thumbsup:

This may not be the right place, but today I did a manual update remotely and my emontx stopped working.

I got home thinking it was a hard reset required but no. I then wrote this new image to the SD card and started from scratch. Still no emontx. After reading the update logs I figured out how to fall back the RFM firmware manually (on a hunch) and went from latest (/home/pi/emonpi/firmware/compiled/latest.hex) to V2.5 in the archive directory. Restarted emonhub and the emontx is back.

My emontx is an off the shelf unit, non-updated from Sept/Oct last year.

I should note that during this kerfuffle the emonpi and emonth nodes were absolutely fine.

Update: Found your change for V2.6 here Glyn: There's a way to reset the rf module? · Issue #92 · jeelabs/jeelib · GitHub - I guess something’s gone wrong for my config. Anything I can do to help, including SSH access to test f/w ?

Thanks a lot for letting me know. This is interesting, it’s the first report of its type. What would be very useful to know is what firmware version your emonTx is running. Do you have a USB to UART cable or an ftdi cable you could use to read the serial output from the emonTx at startup? It will return it’s version version at startup @ baud 9600. Could you post the full serial output. Have you made any other customisation to the system.

If not, your approximate time of purchase (order number) might give us a clue.

Order #10026, 2nd October 2015.

I have a USB to UART thing but I can’t find it right now, hence I haven’t updated the firmware. It’s here somewhere… I think it might be 1.6 f/w

I would try going back to V2.6 on the emonpi/RFM but I think it’s done that a few times already by itself and it was working as the emonTH was being seen fine. The other symptom was that power cycling the emonTX resulted in one update, CT1 showing “10” and all the other inputs zero and no further updates.

Update; The emonTX is “off the shelf”. I have done nothing to it.

Ah ok, it it was bought recently (Oct15) then there should be no need to update emonTx firmware. Is the node ID 8?

It’s intriguing that the emonTH kept working when the emonTx stopped, since they both use the same RFM69CW module.

V2.6 has been totally stable for me, I have about 5 emonTH’s at home on a single emonPi but not an emonTx. I will setup a test in the lab tomorrow. I will have to do some further investigation and get back to you.

The node ID is 10 and appears as emontx1 in emonhub. After much faffing I am just about back.I can give you direct SSH if you want to try things, none of the monitoring is critical per se - except when I am using it to drive the MQTT relay of course :slight_smile:

I will look at this separately but I also had a restore issue and had to manually run the restore. Unrelated.

Also, to note, they are all physically co-located in the under-stairs cupboard - not a distance or RF issue.

Glyn - There was another case where reverting back to v2.5 firmware was needed to restore emonTx traffic after an update to v2.6 on an emonPi.
Re: Loss of feeds to EmonPi from EmonTx after update to 2.6

Plus we are still battling against the same issue on the RFM69Pi stops updating/freezes despite following your lead and recompiling the rfm2pi firmware with the updated JeeLib so it maybe you are just experiencing a “good spell” it certainly isn’t fixing it for all unfortunately.

2 Likes