MQTT change now nothing works even after returning to defaults

dodegkr · 2020-07-18T12:57:37.727Z

pi@emonpi:~ $ cd /opt/openenergymonitor/emonhub
pi@emonpi:/opt/openenergymonitor/emonhub $ git checkout master
Branch 'master' set up to track remote branch 'master' from 'origin'.
Switched to a new branch 'master'
pi@emonpi:/opt/openenergymonitor/emonhub $ git pull origin master
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Total 5 (delta 4), reused 4 (delta 4), pack-reused 1
Unpacking objects: 100% (5/5), done.
From https://github.com/openenergymonitor/emonhub
 * branch            master     -> FETCH_HEAD
   1da8085..89aabdc  master     -> origin/master
Updating 1da8085..89aabdc
Fast-forward
 src/interfacers/EmonHubJeeInterfacer.py | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
pi@emonpi:/opt/openenergymonitor/emonhub $ sudo service emonhub restart

Sadly same problem with the error

WARNING MainThread Device communication error - check settings

Edit - formatted text. BT, Moderator

bwduncan · 2020-07-20T11:02:59.698Z

Just a stab in the dark here, but if the RFM12 has been flashed, is it now using a higher baud?

borpin · 2020-07-20T12:19:25.346Z

dodegkr:

its an rpi3b+. with an rfm12

dodegkr:

2020-07-17 16:38:54,290 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 9600 bits/s
2020-07-17 16:38:56,293 WARNING MainThread Device communication error - check settings

bwduncan:

Just a stab in the dark here, but if the RFM12 has been flashed, is it now using a higher baud?

I think it is hardware rather than firmware.

To see if you can connect to the RFM card, stop emonhub and connect to the serial port directly

sudo systemctl stop emonhub.service

miniterm --rtscts /dev/ttyAMA0 9600

you should see something like… (wait 20s)

--- Miniterm on /dev/ttyAMA0  9600,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
 10 223 9 0 0 0 0 0 0 60 94 48 117 48 117 48 117 48 117 48 117 48 117 0 0 0 0
 10 24 2 0 0 0 0 0 0 127 94 48 117 48 117 48 117 48 117 48 117 48 117 0 0 0 0

If you don’t, my guess is the card has died (does happen). Did you re-flash using the menu from emoncms?

restart emonhub with

sudo systemctl start emonhub.service

pb66 · 2020-07-20T12:48:27.663Z

If the rfm2pi has been successfully reflashed with the latest firmware it will now be using a baud of 38400 (regardless of being rfm12 or rfm69) so emonhub.conf will need to be changed.

dodegkr · 2020-07-20T13:08:42.693Z

borpin:

miniterm --rtscts /dev/ttyAMA0 9600

Yes I re flashed from the admin menu, it seems to not respond.

pi@emonpi:~ $ sudo systemctl stop emonhub.service
pi@emonpi:~ $ miniterm --rtscts /dev/ttyAMA0 9600
— Miniterm on /dev/ttyAMA0 9600,8,N,1 —
— Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H —

pi@emonpi:~ $ miniterm --rtscts /dev/ttyAMA0 38400
— Miniterm on /dev/ttyAMA0 38400,8,N,1 —
— Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H —

This is likely to be me not understanding but is flashing with success possible even if its a dead card ?
It is from 2013, all my devices are 868Mhz is it possible to buy 868 stuff from the store still?

borpin · 2020-07-20T13:15:15.277Z

pb66:

If the rfm2pi has been successfully reflashed with the latest firmware it will now be using a baud of 38400 (regardless of being rfm12 or rfm69)

Useful to know - thanks Paul.

dodegkr:

This is likely to be me not understanding but is flashing with success possible even if its a dead card?

No unlikely to be successful. When you update just the emonhub from the UI, is there anything in the logs?

[edit]
source for the update script https://github.com/openenergymonitor/EmonScripts/blob/stable/update/rfm12pi.sh

Try it manually and see what output you get.

wget https://raw.githubusercontent.com/openenergymonitor/RFM2Pi/master/firmware/RFM69CW_RF_Demo_ATmega328/RFM12_Demo_ATmega328.cpp.hex -O rfm12pi.hex

avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:rfm12pi.hex

dodegkr · 2020-07-20T13:38:27.418Z

Previously on the admin page it gave

Flashing RFM12Pi


avrdude-original: Version 6.3-20171130
                  Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
                  Copyright (c) 2007-2014 Joerg Wunsch

                  System wide configuration file is "/etc/avrdude.conf"
                  User configuration file is "/root/.avrduderc"
                  User configuration file does not exist or is not a regular file, skipping

                  Using Port                    : /dev/ttyAMA0
                  Using Programmer              : arduino
                  Overriding Baud Rate          : 38400
avrdude-original: Using autoreset DTR on GPIO Pin 7
                  AVR Part                      : ATmega328P
                  Chip Erase delay              : 9000 us
                  PAGEL                         : PD7
                  BS2                           : PC2
                  RESET disposition             : dedicated
                  RETRY pulse                   : SCK
                  serial program mode           : yes
                  parallel program mode         : yes
                  Timeout                       : 200
                  StabDelay                     : 100
                  CmdexeDelay                   : 25
                  SyncLoops                     : 32
                  ByteDelay                     : 0
                  PollIndex                     : 3
                  PollValue                     : 0x53
                  Memory Detail                 :

                                           Block Poll               Page                       Polled
                    Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
                    ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
                    eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
                    flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
                    lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                    hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                    efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                    lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                    calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
                    signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

                  Programmer Type : Arduino
                  Description     : Arduino
                  Hardware Version: 3
                  Firmware Version: 4.4
                  Vtarget         : 0.3 V
                  Varef           : 0.3 V
                  Oscillator      : 28.800 kHz
                  SCK period      : 3.3 us

avrdude-original: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude-original: Device signature = 0x1e950f (probably m328p)
avrdude-original: NOTE: "flash" memory has been specified, an erase cycle will be performed
                  To disable this feature, specify the -D option.
avrdude-original: erasing chip
avrdude-original: reading input file "/opt/openenergymonitor/data/firmware/rfm12pi.hex"
avrdude-original: input file /opt/openenergymonitor/data/firmware/rfm12pi.hex auto detected as Intel Hex
avrdude-original: writing flash (8982 bytes):

Writing | ################################################## | 100% 3.08s

avrdude-original: 8982 bytes of flash written
avrdude-original: verifying flash memory against /opt/openenergymonitor/data/firmware/rfm12pi.hex:
avrdude-original: load data flash data from input file /opt/openenergymonitor/data/firmware/rfm12pi.hex:
avrdude-original: input file /opt/openenergymonitor/data/firmware/rfm12pi.hex auto detected as Intel Hex
avrdude-original: input file /opt/openenergymonitor/data/firmware/rfm12pi.hex contains 8982 bytes
avrdude-original: reading on-chip flash data:

Reading | ################################################## | 100% 2.79s

avrdude-original: verifying ...
avrdude-original: 8982 bytes of flash verified
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe

avrdude-original done.  Thank you.

strace: |autoreset: Broken pipe
Flashing RFM12Pi done

Having now tried again from ssh it errors, it also now errors in the admin page

pi@emonpi:~ $ avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:rfm12pi.hex

avrdude-original: Using autoreset DTR on GPIO Pin 7
avrdude-original: stk500_getsync() attempt 1 of 10: not in sync: resp=0x20
avrdude-original: stk500_getsync() attempt 2 of 10: not in sync: resp=0xfc
avrdude-original: stk500_getsync() attempt 3 of 10: not in sync: resp=0x20
avrdude-original: stk500_getsync() attempt 4 of 10: not in sync: resp=0xfc
avrdude-original: stk500_getsync() attempt 5 of 10: not in sync: resp=0x20
avrdude-original: stk500_getsync() attempt 6 of 10: not in sync: resp=0xfc
avrdude-original: stk500_getsync() attempt 7 of 10: not in sync: resp=0x20
avrdude-original: stk500_getsync() attempt 8 of 10: not in sync: resp=0xfc
avrdude-original: stk500_getsync() attempt 9 of 10: not in sync: resp=0x20
avrdude-original: stk500_getsync() attempt 10 of 10: not in sync: resp=0xfc

avrdude-original done.  Thank you.

So perhaps it is hardware, I will clean it and if not hope 868Mhz still works on the new ones

borpin · 2020-07-20T13:44:06.331Z

Try a hard power cycle (not just a reboot - remove power).

Robert.Wall · 2020-07-20T13:57:43.592Z

bwduncan:

but if the RFM12 has been flashed, is it now using a higher baud?

More to the point, is it really a RFM12B that’s trying to use the RFM69 code? Or vice versa? It’s worth checking. Pictures of the RFM modules are in Learn→Electricity Monitoring→Networking→Which radio module→Identifying different Radio Modules

The sketch will lock solid if it is, but it will still be programmable.

dodegkr · 2020-07-20T13:58:17.539Z

Power removed from the pi and reapplied

Same thing.

avrdude-original: Using autoreset DTR on GPIO Pin 7
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

avrdude-original done. Thank you.

strace: |autoreset: Broken pip

Robert.Wall · 2020-07-20T14:04:30.048Z

dodegkr:

I will clean it and if not hope 868Mhz still works on the new ones

A 433 MHz module will work at 868 MHz, but the range will be seriously limited, and if transmitting, you risk damage to the module if you turn the power up (because the output stage and antenna are not matched).

If you are replacing, it’s worth checking with the shop to see if they’ll either supply it without the radio module, or swap it for you.

borpin · 2020-07-20T14:06:50.588Z

Robert.Wall:

More to the point, is it really a RFM12B that’s trying to use the RFM69 code?

That link is what is in GitHub for updating an RFM12Pi according to the update script (as posted).

Robert.Wall · 2020-07-20T14:20:54.296Z

The point is, what is the radio module itself? I understand in the early days, for the emonBase using Martin Harizanov’s “RFM12B Raspberry Pi expansion”, RFM12Bs were used, then replaced by the RFM69CW. And then the “RFM12B Raspberry Pi expansion” itself was replaced by the"RFM69Pi RaspberryPi RF expansion".
As far as I know, the emonPi has only ever had the RFM69CW.

borpin · 2020-07-20T14:38:11.732Z

Robert.Wall:

The point is, what is the radio module itself

I thought the 12/69 in the name refers to the RFM chip. @TrystanLea @glyn.hudson

The GitHub repository notes aren’t definitive RFM2Pi/firmware/RFM69CW_RF_Demo_ATmega328 at master · openenergymonitor/RFM2Pi · GitHub but it does look like that is the right hex for the RFM12.

image932×341 20.6 KB

Robert.Wall · 2020-07-20T14:57:54.887Z

borpin:

I thought the 12/69 in the name refers to the RFM chip

It ought to, but it doesn’t with total unambiguity.

RFM12B-Pi600×550 68.2 KB

Very definitely a Martin Harizanov’s RFM12Pi “RFM12B Raspberry Pi expansion” with very definitely a RFM69CW.

I’m not saying this is the problem in this case, it looks like not, but it’s something to be aware of and check.

dodegkr · 2020-07-20T15:06:57.358Z

Here is my board.

AFA08D83-F243-4218-B588-4F16CC621E394032×3024 1.3 MB

27808D34-D103-47E1-BF41-11448E1DA3653024×4032 1.67 MB

Robert.Wall · 2020-07-20T15:45:10.107Z

Definitely a RFM12B. And unless you specifically uploaded the RFM12B version of the software, it will have defaulted to the RFM69 software and the sketch will lock up and not communicate.

This should not affect how the Pi itself runs, but of course if the radio isn’t working, you’ll have no input to emonHub, and nothing into anywhere else downstream.

The firmware that Trystan linked to (post 51) MQTT change now nothing works even after returning to defaults - #51 by TrystanLea is definitely for the RFM12B and communicates at 9600 baud (you’ll need that setting in emonhub.conf).

But that is not the same as what Brian posted here (post 63) MQTT change now nothing works even after returning to defaults - #63 by borpin
I have that file on my emonPi, and the C source contains this:

 #define RF69_COMPAT 1 // define this to use the RF69 driver i.s.o. RF12

If the .hex was compiled from that, and this link

borpin:

The GitHub repository notes aren’t definitive RFM2Pi/firmware/RFM69CW_RF_Demo_ATmega328 at master · openenergymonitor/RFM2Pi · GitHub but it does look like that is the right hex for the RFM12.

has that same line in the source, IT WON’T WORK because it will be using RFM69CW commands to a RFM12B radio.

You must make sure you get the RFM12B compiled version RFM12_Demo_ATmega328.cpp.hex

Notwithstanding that, you should still be able to program the Atmel '328P.

The first problem will be communicating with the Atmel '328P in programming mode. That’s not happening, according to
avrdude-original: stk500_recv(): programmer is not responding.
When you’ve solved that, the second problem will be getting the correct sketch, or changing that line and recompiling, and uploading it to the '328P.

Sorry I’m not a Pi expert, so I can’t help with the how-to.

[Edit]
Have you changed the clock speed of your Pi? Remove the following lines from /boot/config.txt :

arm_freq=1200
arm_freq_min=600

and replace with

[pi3]
arm_freq=1200
arm_freq_min=600

[pi2]
arm_freq=900
arm_freq_min=600

[all]

borpin · 2020-07-20T20:51:42.846Z

Robert.Wall:

has that same line in the source, IT WON’T WORK because it will be using RFM69CW commands to a RFM12B radio.

@TrystanLea, If Robert is correct, the emoncms update will break every installation with this board as that is the firmware in the update script.

Robert.Wall:

You must make sure you get the RFM12B compiled version RFM12_Demo_ATmega328.cpp.hex

Hang on @Robert.Wall, that is the one I linked to for the wget!

https://github.com/openenergymonitor/RFM2Pi/blob/master/firmware/RFM69CW_RF_Demo_ATmega328/RFM12_Demo_ATmega328.cpp.hex

Robert.Wall · 2020-07-20T21:07:02.872Z

I downloaded and compiled the source, and neither the RFM12B nor RFM69CW versions matched any of the file sizes offered by Github. So I haven’t a clue what’s going on.

All I do know is if you haven’t got the latest hardware (as I haven’t), you can’t blindly follow the instructions because of things like the ones I mentioned.

borpin:

Hang on @Robert.Wall, that is the one I linked to for the wget !

Yes, but you wrote that before we knew for certain that Dave had a RFM12B radio.
I suspect he’s by default loaded the '69 software. It doesn’t explain why he can’t communicate with the Atmel '328P though, unless arm_freq=1200 has crippled it.

borpin · 2020-07-20T21:43:47.051Z

Robert.Wall:

I downloaded and compiled the source, and neither the RFM12B nor RFM69CW versions matched any of the file sizes offered by Github

But unless you use identical versions of the other libraries and/or core they won’t, will they?

Robert.Wall:

unless arm_freq=1200 has crippled it.

I don’t think that makes any difference - it’s just a UART that is being used - that refers to the SOC.

Robert.Wall:

Yes, but you wrote that before we knew for certain that Dave had a RFM12B radio.

Based on his earlier post I was 99.9% confident