Emon TXs not updating after Emonpi update

Hardware emonPi
1

This is a similar issue to that posted by @amaad but the details are a little different hence the new topic:

Here is the old topic:

I have been using an entirely shop bought oem system (with no modifications other than a firmware/software update in Sept) since June with one Emonpi and two TXs. I am strictly a user with no programming skills as yet. A few teething problems aside (all resolved by me so not likely to have been any fault of the equipment) the set-up has been running fine but the TXs have been dropping out (both at the same time) at variable intervals. I have assumed this to be some interference or clash and since a simple reboot always restored the inputs I was not too concerned.

I updated the Emonpi (via the UI “update now” button) last night. Since then there are no inputs from the TXs (all registering n/a). Being a simple soul I have tried a combination of reboots/resets etc both from the UI and locally without success. Although the Emonpi inputs and feeds were still all working CT2 has dropped out subsequently and can not be revived with a reboot.

The Emonpi is registering the input on the LCD but in Emoncms this is registering as n/a. This is a CT from the output of a wind turbine and the drop out coincided with a temporary cessation of generation as the wind dropped but that may just be a coincidence.

In answer to @glyn.hudson 's questions from the previous thread:

  • The SD is the supplied 03May16 version.
  • The Emonpi was updated in Sept without issue.
  • The version following last nights update is low write 9.7.7 2016.10.29
  • The emonpi has two CTs connected and four temperature inputs.
  • The TXs are as supplied (separate nodes). One has four CTs connected and two temperature inputs and the other has three CTs connected. They are around 6’ from the Emonpi at different heights.
  • The TXs appear to be broadcasting normally - leds flashing as usual.
  • Emonpi rssi is displayed as 0 in Emoncms.
  • Following reboots etc one or both TXs seemed to register very briefly on a couple of occasions.
  • I can provide any information available via the UI (emonhub log , update log, screenshots etc) but don’t have direct terminal access at this time. Appreciate this and my ignorance make it a bit more difficult to get some help.
  • Is there an issue with the latest Emnopi/Emoncms versions or do I have a set-up specific problem?
2

Oh dear, sorry to hear. I have several emonPi running the latest update (FW: V1.7) and have been unable to recreate the issue. The emonPi’s after the update are sill receiving data from RF nodes.

Is anyone else able to test by running emonPi update? @Jon :blush:

When an emonTx drops offline is the red LED on the emonTx unit still flashing? Do the emoTx units now both drop off together?

3

Yes the leds continue to flash as normal and after reset they also flash rapidly on start-up and then settle to the normal interval flash. Note that the two TX leds are actually different colours - one red, one green.
They have failed to reconnect at all following Emonpi reboots except on the couple of occasions already mentioned when one or both have reconnected very briefly before dropping out again. I only conclude this because the Emoncms “updated” time changed. By the time I viewed the inputs following reboot they had dropped out again.
I have just noticed that although the Emonpi CT2 is still showing n/a the value for this CT is being added to the power1pluspower2 input?

4

Glyn - did you mean firmware 2.7??

I’m running the emonSD-07Nov16 BETA image (if it matters). My current firmware is version 2.5. I’ll do an update tonight or tomorrow morning and let you know what happens.

5

This is normal correct behaviour, the multiple flashes at startup indicate that an AC voltage wave sample has been successfully detected.

This is nothing to worry about, this is due to different manufacturing batches. One of our suppliers made a mistake with the LED colour.

Do you mean the system time of the emonPi? You can see this by looking at the emonhub log in Setup > emonHub in local Emoncms. This this should be UTC. Alternatively you could connect via ssh and view the time of the system with the $ date commend. It’s important that the emonPi is connected to the interent to get NTP UTC time.

Please could you supply emonhub, emoncms and emonpiupdate logs. They can be downloaded from Emoncms interface.

This is very strange, please could you illustrate with a screen shot of the Emoncms Inputs and Feeds pages.

Yes, I mean firmware V2.7. Thanks so much, you just need to hit emonpi update and let it do it;s thing.

6

All seems to work A-OK with the current emonPi Update.

1 Like
7

Houston says it’s a go? :grin:

2 Likes
8

No - sorry I mean the time since last update. System time is normal. Ethernet connection to router is working ok.

Please find attached. Two update logs - second after I tried another update (foolishly thinking the first may somehow have been corrupted).

Wider awake this morning I see that power2 is now showing as a new input. Don’t know when this appeared as I was a bit pre-occupied with the other stuff. I imagine I can just set this up as a new feed and delete the old one. Bit of an irritation with split data but I still view all this as “extended” commissioning!
Screenshots attached. There are some virtual feeds but I guess these are not relevant to the current problems.

emoncms.txt (810 Bytes)
emonpiupdate1.txt (2.8 KB)
emonpiupdate.txt (10.1 KB)
emonhub.txt (196.3 KB)

Feeds.JPG1432×394 28.5 KB
Feeds1.JPG1401×658 101 KB

Feeds2.JPG1402×593 88.2 KB

Feeds3.JPG1404×601 73.5 KB

Inputs.JPG1416×392 24.5 KB

Inputs1.JPG1407×618 66 KB

Inputs2.JPG1387×636 71.6 KB

Inputs3.JPG1420×605 63 KB

Apologies if this is all looking a bit long winded but you did ask for them! Anything else and I will try to oblige.
A couple of possibly irrelevant points about the environment. This is an off-grid set-up and quite isolated from possible interference sources - no mobile reception up here for example. There is a Davis weather station broadcasting in the vicinity but this has always been present and it’s operation has not been changed. The hardware is all housed in the same building as the off-grid hardware and is subject to temperature fluctuations of around 5c-30c over the year. Currently temperature locally is lowest since Emon install at around 8c.

9

@Jon thanks for testing.

@jingy thanks for all the info.

All look fine looking at the screenshots and graphs. on the emonPi receiver. Could you setup an input process to log the RSSI for each emonTx to Feeds in Emoncms. So next time the emonTx comes online we get capture the RSSI (signal strength) values.

If you manually reset the emonTx’s to they come back online?

Since I can’t recreate the issue I’m starting to think that maybe we had a bad batch of RF modules on the emonTx’s :confused:. I don’t want to jump to conclusions without further testing.

I think a good way to proceed with be for us to send you a set of new emonTx units that you can install instead of the current units for testing. How many emonTx units do you have in total? Do you have two emonTx’s per network? We will set different node ID’s.

10

@glyn.hudson - The rollback from v2.6 to v2.5 was proven to resolve the “No RF” problems seen by some, but not all users. v2.7 reinstates those v2.5 to v2.6 changes without any confirmed fault or fix, as far as I can tell.

Since the fault occurred at the time of updating and was perfectly ok prior to that for some months, would it not prove useful to try a rollback on the firmware? Even if replacing all 4 emonTx’s does overcome this issue by chance it tells us nothing about why this has happened when updating. For example the min RSSI threshold in emonlib has been tightened so if the emonTx signals where at the lower end of the range they may well just be excluded purely by the lib update and replacements may or may not pass that threshold or work for a while or even sporadically.

Could we also consider reinstating the “non-quiet” function in the emonPi FW? That way the emonhub.logs in the emoncms webpage could possibly shed significantly more light on this type of issue,

And maybe (on a future revision) the led on the emonPi could be made visible, either with just a well positioned hole in the end plate or replacing the SMT led with one that could over hang the board edge and protrude through a hole in the end plate ? The combo of no led and quiet function make it quite tricky to debug RF on an emonPi.

@jingy - Would you be willing and able to get ssh access to the command line to install a different firmware hex, with some guidance if needed?

12

Quick version:

Replacement emonTx units should not be required. I have identified an issue with the emonPi update (V2.7),

I have pushed a new update (V2.8) which should fix the issue. Run emonPi update to pull in and apply the latest firmware (V2.8).

Very sorry for the hassle. Please let me know how you get on.

The long version:

Well remembered. I am aware of the issue with V2.6, therefore V2.7 is based on V2.5, V2.7 has the same ‘RF keep alive’ as V2.5.

https://github.com/openenergymonitor/emonpi/blob/master/firmware/src/src.ino#L250

HOWEVER, V2.7 was compiled with the latest JeeLib while the last known RF stable firmware (V2.5) was compiled with JeeLib from 10th Sep 2015. I had tested V2.7 prior to release with all the emonPi’s and RF nodes that we have here in the lab and it worked fine. The only difference I can think is that the RF nodes here in the lab are mostly transmitting 0’s since they are not conected to anyting or just temperature values. The issue only seems to effect emonTx units which are monitoring multiple circuites i.e they will have large(er) RF packets.

For the latest firmware I have just pushed (V2.8) I reverted back to JeeLib from 10th Sep 2015. This fixed the issue, I was given remote access to an emonPi with a few emonTx’s connected monitoring multiple circuits which had stoped working using V2.7 started working again with V2.8 :slight_smile: . Compiling the code using platformIO was super useful in the case since the library commit version can be specified in platformio.ini, this will ensure anyone who compiles the firmware will have exactly the same version.

https://github.com/openenergymonitor/emonpi/blob/master/firmware/platformio.ini#L37

As to why, the latest version of jeelib has got an issue with longer RFM packets, this is still a mystery. I will need to debug further.
emontx/2141?u=glyn.hudson&source_topic_id=2233

Interesting, when did this change take place. I can’t see any recent changes to RSSI threshold in emonhub commits.

My plan was to get hold of the emonTx myself for testing back in the lab. I was worried we could have a sub-optimal batch of RF modules. Maybe this will not be needed now.

Yes, this is a possibility. What would require adding to the code for this? Do you have a working test?

Mm this would be quite tricky. It would probably be easier just to remove the end-plate(s) of the emonPi to view the LED. Actually new versions of the enclosure in the future will have mounting holes for DIN rail mount therefore we might be able to see the LED through these holes :slight_smile:

13

Glyn
This morning I have run Emonpi Update as requested and both TXs (there are only two, I have always had a couple of “ghost” nodes showing) came back on line immediately. I have set up feeds for both TX rssi for future reference. Both are recording -30 or thereabouts currently - which I believe is fine?
I guess I should just monitor this and see how it goes for a while then report back.
Still don’t know why the Emonpi CT2 input disappeared and then came back as another input - maybe to do with all the rebooting, updating activity?
Not bothered by all the “hassle” - just pleased that it might be sorted and has drawn attention to an issue which needed addressing. Good reminder for me that I should set-up and familiarise myself with ssh access to help with any future issues.
Many thanks to yourself and the others for prompt help.

1 Like
14

Great!

Yes, that’s good.

15

PR submitted