EmonPI firmware build

borpin · 12 November 2019 13:16

The logrotate should fire once an hour.

@TrystanLea I did notice that the defaults do not move all rotated files off /var/log. If another process is generating large files, they will be rotated hourly at maxsize 500 but rotated in place. Some systems keep quite a few files and do not always compress them.

Also I think a maxsize in a subsystem logrotate config will override this.

We did discuss this at length and I think the olddir should be a default so all rotated files are moved out.

TrystanLea · 12 November 2019 15:02

Did you install platformio with the following two commands?:

sudo pip install -U urllib3
sudo pip install -U platformio

Sorry Im struggling to think what might be causing the issue here.

adtyne · 12 November 2019 19:26

Ive been doing some more digging this evening, using a different build environment on my desktop machine.

PlatformIO 4.1.0
atmelavr @ 1.15.0 [Up-to-date]
toolchain-atmelavr @ 1.50400.190710 [Up-to-date]
framework-arduinoavr @ 4.1.2 [Up-to-date]

At Releases · openenergymonitor/emonpi · GitHub the pre compiled of V2.9.0 latest.hex has a file size of 50,332 bytes, but if build from the source I end up with a file size of 52,005 bytes.

Processing emonpi (platform: atmelavr; framework: arduino; board: emonpi)

Verbose mode can be enabled via -v, --verbose option
CONFIGURATION: Redirecting...
PLATFORM: Atmel AVR 1.15.0 > OpenEnergyMonitor emonPi
HARDWARE: ATMEGA328P 16MHz, 2KB RAM, 30KB Flash
PACKAGES: toolchain-atmelavr 1.50400.190710 (5.4.0), framework-arduinoavr 4.1.2

Converting src.ino
LDF: Library Dependency Finder → Library Dependency Finder (LDF) — PlatformIO latest documentation
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 11 compatible libraries
Scanning dependencies…
Dependency Graph
|-- 3.7.7
| |-- 2.3.5
|-- 1.1.0
|-- <LiquidCrystal_I2C>
| |-- 1.0
|-- #f097c00
|-- #a7ec6ac
| |-- 2.3.5
|-- 2.3.5
|-- 1.0
Building in release mode
Compiling .pio\build\emonpi\src\src.ino.cpp.o
Linking .pio\build\emonpi\firmware.elf
Checking size .pio\build\emonpi\firmware.elf
Advanced Memory Usage is available via “PlatformIO Home > Project Inspect”
DATA: [===== ] 52.7% (used 1079 bytes from 2048 bytes)
PROGRAM: [====== ] 60.2% (used 18482 bytes from 30720 bytes)
========================= [SUCCESS] Took 6.93 seconds ====================

Environment Status Duration

emonpi SUCCESS 00:00:06.931
direct-upload IGNORED
emonpi_deploy IGNORED
========================= 1 succeeded in 00:00:06.931 ======================

TrystanLea · 13 November 2019 10:10

Great, does the build on your desktop work when uploaded to the emonpi board? I saw your previous reply before last edit regarding jeelib library version making a difference?

adtyne · 13 November 2019 10:59

@TrystanLea Unfortunately not… My post before was wrong. I hadn’t noticed that the firmware had failed to upload. When I tried again and the upload worked the RF nodes dropped of my network.

adtyne · 16 November 2019 08:48

I’ve had an opportunity to do some more digging around on this and have found that the RF nodes do report data for about 60 seconds from the EmonPI firmware booting before any noise from the RF side of things stops.

Here is a capture of the serial output of the EmonPI from boot. The point in the output below where the last noise from the RF side was reported was 57 seconds.

 E i5 g210 @ 433 MHz q0 USA 0

Available commands:
  <nn> i     - set node IDs (standard node ids are 1..30)
  <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
  <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
  <n> c      - set collect mode (advanced, normally 0)
  ...,<nn> a - send data packet to node <nn>, request ack
  ...,<nn> s - send data packet to node <nn>, no ack
  ...,<n> p  - Set AC Adapter Vcal 1p = UK, 2p = USA
  v          - Show firmware version
  <n> q      - set quiet mode (1 = don't report bad packets)
 E i5 g210 @ 433 MHz q0 USA 0
OK 5 21 1 0 0 21 1 93 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 23 47 1 0 1 32 0 5 0 (-60)
OK 21 211 0 190 1 32 0 0 0 (-51)
OK 5 21 1 1 0 22 1 159 90 254 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
 ? 25 34 176 190 1 32 0 0 0 179 141 128 64 12 74 142 69 32 32 37 64 (-100)
 ? 26 34 32 32 50 64 12 4 128 16 96 32 0 32 136 32 4 160 88 247 64 (-102)
OK 20 203 0 159 1 32 0 0 0 (-66)
OK 5 23 1 1 0 24 1 133 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
 ? 0 3 32 64 10 0 2 50 64 188 25 80 0 0 2 8 32 2 0 0 0 (-100)
 ? 0 23 160 96 1 11 18 36 200 0 17 128 46 100 96 192 6 45 153 2 17 (-100)
 ? 2 17 5 0 56 192 133 64 16 64 99 64 0 0 34 7 224 5 128 57 139 (-101)
OK 5 34 1 0 0 34 1 170 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
 ? 18 105 64 37 32 20 0 0 29 160 20 51 0 32 3 64 49 50 36 0 33 (-103)
 ? 0 32 151 129 18 16 144 0 0 36 96 5 146 167 192 2 13 64 0 32 44 (-100)
 ? 2 32 8 74 33 158 2 67 40 64 8 16 18 64 27 131 178 64 8 101 146 (-100)
 ? 0 0 128 74 33 158 2 67 40 64 8 16 18 64 27 131 178 64 8 101 146 (-102)
 ? 2 1 13 0 0 158 2 67 40 64 8 16 18 64 27 131 178 64 8 101 146 (-104)
 ? 24 29 84 227 32 228 27 207 1 33 224 16 18 64 27 131 178 64 8 101 146 (-96)
 ? 0 30 129 154 144 36 0 196 38 192 4 60 30 192 20 128 68 0 40 33 19 (-102)
OK 5 37 1 0 0 37 1 108 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
 ? 12 51 32 63 26 104 32 96 0 36 64 0 60 33 132 16 128 37 106 208 10 (-98)
 ? 25 36 38 63 26 104 32 96 0 36 64 0 60 33 132 16 128 37 106 208 10 (-101)
 ? 0 160 32 0 79 192 20 92 1 230 38 0 60 33 132 16 128 37 106 208 10 (-97)
 ? 1 0 32 38 12 224 128 98 74 131 128 160 0 1 32 141 224 52 5 64 14 (-102)
OK 5 22 1 1 0 23 1 92 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
 ? 4 9 0 64 49 246 208 0 66 160 32 32 32 224 128 87 53 224 32 32 9 (-99)
 ? 0 81 32 64 49 246 208 0 66 160 32 32 32 224 128 87 53 224 32 32 9 (-103)
OK 5 29 1 0 0 29 1 181 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
 ? 0 35 65 32 64 0 0 0 34 0 0 0 64 96 8 2 128 192 16 0 144 (-102)
 ? 28 2 32 160 2 0 0 215 32 32 2 0 130 0 34 9 86 96 16 40 130 (-97)
 ? 25 69 64 0 74 67 18 241 4 32 38 218 140 184 250 36 196 20 4 224 7 (-98)
 ? 0 12 160 16 128 97 72 108 32 1 128 106 136 40 17 40 64 33 160 8 64 (-101)
 ? 6 53 0 73 178 33 128 64 34 52 2 100 105 34 23 224 2 2 0 8 81 (-100)
OK 5 27 1 1 0 28 1 187 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
 ? 22 32 2 73 178 33 128 64 34 52 2 100 105 34 23 224 2 2 0 8 81 (-99)
 ? 3 40 20 0 7 128 0 73 34 52 2 100 105 34 23 224 2 2 0 8 81 (-101)
OK 5 27 1 1 0 28 1 185 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 19 234 0 99 1 32 0 0 0 (-57)
 ? 16 208 0 0 44 34 197 0 0 6 136 17 106 8 36 0 1 5 177 192 0 (-101)
 ? 13 40 0 0 0 228 49 2 151 0 17 24 36 0 32 16 64 192 145 1 152 (-102)
OK 5 25 1 1 0 26 1 55 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
 ? 8 48 0 132 169 192 36 73 28 32 18 50 64 24 36 37 5 51 14 53 108 (-99)
OK 5 29 1 3 0 32 1 76 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 5 30 1 2 0 32 1 85 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 5 24 1 1 0 25 1 78 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 5 24 1 3 0 27 1 84 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 5 21 1 3 0 24 1 82 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 5 33 1 2 0 35 1 180 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 5 35 1 2 0 37 1 166 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 5 18 1 2 0 20 1 93 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 5 39 1 1 0 40 1 131 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 5 21 1 3 0 24 1 134 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 5 33 1 1 0 34 1 112 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 5 23 1 2 0 25 1 159 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 5 21 1 0 0 21 1 204 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 5 24 1 3 0 27 1 107 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 5 32 1 3 0 35 1 146 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
OK 5 25 1 2 0 27 1 138 90 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)

So at this stage it appears that my firmware build was more sucessful than id originally thought, however I still dont understand why the RF side stops working, as I am building at this stage from an unmodified source.

TrystanLea · 16 November 2019 09:11

Thanks for the update @adtyne. I will try and extended test next time im in the office to see if I can replicate. Im not sure what is going wrong Im afraid.

adtyne · 16 November 2019 09:14

@TrystanLea Many Thanks, I am continuing to experiment, and have temporarily commented out the RFM reset which means my RF nodes continue to return data, obviously i’m sure that the RFM reset is there for a good reason but this does seem to have narrowed things down quite significantly.

Ill add anything else I find here.

TrystanLea · 16 November 2019 09:18

Thanks @adtyne, interesting @glyn.hudson any ideas why the rf reset is causing issues here?

borpin · 16 November 2019 10:04

Is there anything else on that frequency?

adtyne · 16 November 2019 10:21

@borpin There’s quite a lot of general noise on 433Mhz in my area that I just cant avoid as I am in a complex of nearly 600 apartments, you can see a constant chatter in the log I posted for the first 60 seconds after the EmonPI firmware boots. Once the firmware does a reset of the RFM_69 module everything stops.

I’ve tried commenting out the line in src.ino that actually performs the RFM_69 module reset, and this keeps the data coming in, however I know that’s not a solution as the module will eventually hang…

borpin · 16 November 2019 12:10

Do you just use the EmonPi and not an EmonTH or EmonTX?

If you don’t, just disable the RFM, you don’t need it as the energy data is coming off the serial port to the RPi.

Not sure how but @Robert.Wall or @TrystanLea will be able to help.

Robert.Wall · 16 November 2019 12:26

It would mean modifying and reloading the sketch that runs on the Atmel ATMega 328P, that’s the part of the emonPi that does the energy measurement and handles the incoming data from other measurement nodes.

borpin · 16 November 2019 12:27

I think that is what @adtyne is doing anyway.

adtyne · 16 November 2019 12:27

@borpin Unfortunatley I’ve got 5 EmonTH (like) devices reporting back, and its those that I loose, which isn’t an option, I can live with occasional missing data, which I get using the pre-compiled 2.9.0 hex firmware. What I cant live with is the data from the RF nodes stopping after approx 60 seconds when using a self built version of what is supposedly the same source code. I haven’t started making the changes to the code that I wanted yet so genuinely don’t understand whats going on.

If I cant solve this i’ll end up buying an EmonTX to do the power monitoring, so I can make the firmware changes I want there, and leave the EmonPi using it’s default firmware so that my RF nodes keep working, but that feels like admitting defeat.

In the meantime I’ve done a build of the firmware against the very latest JeeLib, with the routine to reinitialise the RFM every 60 seconds commented out, as i’ve seen comments on other forums stating that this workaround should no longer be required. It’s been stable for 2 hours so far using this firmware and we’ll see how long it lasts.

@borpin @trystanlea Thank you very much for your input so far.

Robert.Wall · 16 November 2019 12:57

@adtyne
I don’t get what you’re trying to do. The emonTH’s normally send their data via the 433 MHz ISM band - it would appear that this is the case for you because I can see a few of the default NodeIDs appearing, or have you done things differently?

A possible hardware solution would be to change to the 868 MHz band, but that would mean some tricky desoldering to remove the RFM modules, and every device would need to be changed.

Trying to think on my feet here, it also might be worth looking into the “group” that we use. That won’t prevent the ‘chatter’ being picked up, but as I understand it, it works as a first-stage filter to screen out irrelevant traffic, so the ‘chatter’ won’t even leave the front end processor. A big advantage of that is it’s only a software change.

The emonPi front end is a 2-channel version of the emonTx, and by default the emonTx sends its data to the emonPi by radio. Again, I can’t quite see what that would achieve.

Some while ago, I contacted JeeLabs to ask for advice on what they meant in their documentation by the need to call rf12_recvDone() “frequently”, but I never received a reply. What I question is whether not calling rf12_recvDone() often enough was perceived as a need instead to do the reset.

adtyne · 16 November 2019 13:13

@Robert.Wall
First things first with the default, pre compiled firmware everything is working and i’ve never had problems with my RF nodes going offline, however I wanted to modify the EmonPI firmware to send additional power monitoring details (current, pfc) which are from what I can see calculated but not sent.

Whenever I build my own version of the firmware (including when no changes have been made to the source downloaded from github) the RF nodes stop reporting back when the RFM_69 is reinitialised after 60 seconds. I’ve proven it’s at this point the RF nodes stop working by commenting out the line in the source that performs the RF reset.

Switching my energy monitoring to an EmonTX would let me modify the TX firmware, and leave the EmonPI on it’s default firmware where the RF does not stop working.

I don’t believe that this is a noise issue in the RF domain, as although I will admit there is a lot of unrelated traffic that i’m not interested in, it’s never fallen over with the stock firmware.

Robert.Wall · 16 November 2019 13:40

OK, I see now. I misunderstood what your aims were.

@glyn.hudson has to be the one to explain that. He’s moved away from the well-proven Arduino IDE to using platformio, but my experience with that is well documented here.

Yes, realPower, apparentPower, powerFactor, Vrms & Irms are all calculated in emonLib, but only one or two of those are passed forwards to emonHub. Which depends on whether the a.c. voltage is available.

My feeling is that re-initialising the RFM every minute was a fudge to hide a deeper problem that was never resolved - my comment about JeeLabs could relate to that and in any case, a more exact definition would be useful. One thing I’ve got to point out is JeeLib doesn’t make use of the internal buffer in the RFM69CW, treating it instead as an RFM12B that had a buffer precisely one character wide, so unless the main processor can handle the data as it’s received, there will be a problem. This is something I’m interested in as it has a significant bearing on our hope of making the emonPi “continuous monitoring”.

borpin · 16 November 2019 17:59

@adtyne, I recently was having some issues with a new firmware build (I think it was PICNIC) but to try and remove variables I installed the Arduino IDE on Windows and it was very painless - It is actually available in the MS Store!

Worth using just to exclude it as a variable.

pb66 · 17 November 2019 09:30

It was indeed added as a temp fix against occasional rfm lockups. But there is something odd about that “fix” as reading the code it actually resets after the first 60s from power up and then every single main loop iteration after that because the last reset counter is never incremented so now minus 0 will always be greater than the 60000ms interval.

I found it difficult to believe this aggressive resetting wasn’t causing issues and pointed out this error on a couple of occasions, but I’ve never heard of any actual cases where it was an issue, perhaps the pre-compiled hex uses a specific combination of Libs and/or PIO compiles the code in a way that this doesn’t manifest as a problem.

@adtyne Instead of deleting the reset line, try adding a line to set last_rf_rest (note the typo) when the rfm is reset to see if that yields different results eg

if ((now - last_rf_rest) > RF_RESET_PERIOD) {
      last_rf_rest = now;
      rf12_initialize(nodeID, RF_freq, networkGroup);                             // Periodically reset RFM69CW to keep it alive :-(
    }

I don’t personally run any FW’s that have this rather crude 60s reset in as I have never had the issue with rfm’s locking out, it isn’t an issue that effected everyone so you maybe ok to just remove the reset, perhaps this too is a quirk of PIO and or the pre-compiled hex’s? We never got to the bottom of the lockups due to this “fix” being rolled out!