EmonBase, EmonTX no inputs found

I have a Pi3 into which I installed the RFM69Pi and flashed the latest EmonBase onto an SD card. I have the EmonTXv3. I live in the US. I have two CTs installed (to more coming) and a temp sensor. I am powering it via the AC-AC adapter.

Emoncms Version low-write 9.8.24 | 2017.11.27
Modules Administration | App v1.0.0 | Backup v1.0.0 | EmonHub Config v1.0.0 | Dashboard v1.1.1 | EventProcesses | Feed | Graph v1.0.0 | Input | postprocess | CoreProcess | Schedule | setup | Time | User | Visualisation | WiFi v1.0.0
Buffer 0 feed points pending write
Writer Daemon is running with sleep 60s

The EmonTx gives a Solid Red, then flashing Red, then periodically flashes Red. I believe this should be the desired behavior.

The EmonBase boots up and I can login to the webpage. The webpage reports that there are no Inputs. When I goto the Administration Page. The log shows:

Stack trace:
#0 /var/www/emoncms/scripts/phpmqtt_input.php(112): Mosquitto\Client->loop()
#1 {main}
2017-12-06 04:23:42.569|ERROR|phpmqtt_input.php|exception 'Mosquitto\Exception' with message 'The client is not currently connected.' in /var/www/emoncms/scripts/phpmqtt_input.php:112
Stack trace:
#0 /var/www/emoncms/scripts/phpmqtt_input.php(112): Mosquitto\Client->loop()
#1 {main}
2017-12-06 04:23:42.570|ERROR|phpmqtt_input.php|exception 'Mosquitto\Exception' with message 'The client is not currently connected.' in /var/www/emoncms/scripts/phpmqtt_input.php:112
Stack trace:
#0 /var/www/emoncms/scripts/phpmqtt_input.php(112): Mosquitto\Client->loop()
#1 {main}
2017-12-06 04:23:42.572|ERROR|phpmqtt_input.php|exception 'Mosquitto\Exception' with message 'The client is not currently connected.' in /var/www/emoncms/scripts/phpmqtt_input.php:112
Stack trace:
#0 /var/www/emoncms/scripts/phpmqtt_input.php(112): Mosquitto\Client->loop()
#1 {main}
2017-12-06 04:26:17.661|ERROR|phpmqtt_input.php|exception 'Mosquitto\Exception' with message 'The client is not currently connected.' in /var/www/emoncms/scripts/phpmqtt_input.php:112
Stack trace:
#0 /var/www/emoncms/scripts/phpmqtt_input.php(112): Mosquitto\Client->loop()
#1 {main}
2017-12-06 04:26:17.662|WARN|phpmqtt_input.php|Not connected, retrying connection
2017-12-06 04:26:32.090|ERROR|phpmqtt_input.php|exception 'Mosquitto\Exception' with message 'The client is not currently connected.' in /var/www/emoncms/scripts/phpmqtt_input.php:112
Stack trace:
#0 /var/www/emoncms/scripts/phpmqtt_input.php(112): Mosquitto\Client->loop()
#1 {main}
2017-12-06 04:26:32.109|WARN|phpmqtt_input.php|Not connected, retrying connection

What am I missing? What do I need to do to get them to talk? What do I need to do to get Inputs?

Have you tried rebooting the emonBase since adding the emonTX?

There is a long standing issue with the mqtt input to emoncms not correctly creating newly added devices, but normally you would see just an RSSI input created not “no inputs”.

Try restarting the mqtt_input service (before rebooting if you haven’t already done so) with

sudo service mqtt_input restart

The log looks worse than it is, that is AFAICT just a couple of reconnections, having said that I’m sure the info is useful, only recently have those additional lines been reported. Until a few days ago that same log would have read just

2017-12-06 04:26:17.662|WARN|phpmqtt_input.php|Not connected, retrying connection
2017-12-06 04:26:32.109|WARN|phpmqtt_input.php|Not connected, retrying connection

Can you post some emonhub.log?

Thank you for your reply. I know I must be missing something obvious.
Things look a bit different than they did a few days ago. I assume there was an automatic update? The interface looks different and it reports a successful connection. But I still see nothing on Setup > Inputs.
When I first started working with it, the log did look like what you posted.
Here is the log file from the emonhub tab.

2017-12-09 23:17:38,731 INFO     MainThread EmonHub emonHub emon-pi variant v2.0.0
2017-12-09 23:17:38,732 INFO     MainThread Opening hub...
2017-12-09 23:17:38,733 INFO     MainThread Logging level set to DEBUG
2017-12-09 23:17:38,733 INFO     MainThread Creating EmonHubJeeInterfacer 'RFM2Pi' 
2017-12-09 23:17:38,736 DEBUG    MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2017-12-09 23:17:40,739 WARNING  MainThread Device communication error - check settings
2017-12-09 23:17:40,740 INFO     MainThread Setting RFM2Pi frequency: 433 (4b)
2017-12-09 23:17:41,741 INFO     MainThread Setting RFM2Pi group: 210 (210g)
2017-12-09 23:17:42,743 INFO     MainThread Setting RFM2Pi quiet: 0 (0q)
2017-12-09 23:17:43,746 INFO     MainThread Setting RFM2Pi baseid: 5 (5i)
2017-12-09 23:17:44,747 INFO     MainThread Setting RFM2Pi calibration: 230V (1p)
2017-12-09 23:17:45,749 DEBUG    MainThread Setting RFM2Pi subchannels: ['ToRFM12']
2017-12-09 23:17:45,750 DEBUG    MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']
2017-12-09 23:17:45,751 INFO     MainThread Creating EmonHubMqttInterfacer 'MQTT' 
2017-12-09 23:17:45,752 INFO     MainThread MQTT Init mqtt_host=127.0.0.1 mqtt_port=1883 mqtt_user=emonpi
2017-12-09 23:17:45,754 INFO     MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg' 
2017-12-09 23:17:45,854 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:17:45,855 INFO     MQTT       Could not connect...
2017-12-09 23:17:46,957 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:17:46,959 INFO     MQTT       Could not connect...
2017-12-09 23:17:48,061 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:17:48,062 INFO     MQTT       Could not connect...
2017-12-09 23:17:49,163 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:17:49,164 INFO     MQTT       Could not connect...
2017-12-09 23:17:50,266 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:17:50,268 INFO     MQTT       Could not connect...
2017-12-09 23:17:51,370 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:17:51,371 INFO     MQTT       Could not connect...
2017-12-09 23:17:52,473 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:17:52,474 INFO     MQTT       Could not connect...
2017-12-09 23:17:53,576 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:17:53,578 INFO     MQTT       Could not connect...
2017-12-09 23:20:02,678 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:02,781 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:02,884 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:02,986 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:03,088 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:03,191 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:03,293 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:03,395 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:03,497 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:03,599 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:03,701 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:03,804 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:03,906 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:04,008 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:04,111 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:04,213 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:04,315 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:04,417 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:04,519 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:04,621 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:04,725 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:04,827 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:04,929 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:05,031 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:05,133 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:05,235 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:05,338 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:05,440 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:05,542 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:05,645 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:05,747 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:05,850 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:05,952 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:06,054 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:06,156 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:06,258 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:06,360 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:06,462 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:06,564 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:06,666 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:06,768 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:06,870 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:06,972 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:07,074 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:07,176 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:07,279 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:07,381 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:07,483 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:07,585 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:07,687 INFO     MQTT       Connecting to MQTT Server
2017-12-09 23:20:07,689 INFO     MQTT       connection status: Connection successful
2017-12-09 23:20:07,690 DEBUG    MQTT       CONACK => Return code: 0
2017-12-09 23:20:07,792 INFO     MQTT       on_subscribe

Hello @rearden, It looks like your log is missing incoming data from the emontx, your log should look something like this:

2017-12-10 08:17:14,057 DEBUG    RFM2Pi     50869 NEW FRAME : OK 24 137 0 0 0 77 3 28 0 1 0 0 0 (-52)
2017-12-10 08:17:14,060 DEBUG    RFM2Pi     50869 Timestamp : 1512893834.06
2017-12-10 08:17:14,060 DEBUG    RFM2Pi     50869 From Node : 24
2017-12-10 08:17:14,061 DEBUG    RFM2Pi     50869    Values : [13.700000000000001, 0, 84.5, 2.8000000000000003, 1]
2017-12-10 08:17:14,061 DEBUG    RFM2Pi     50869      RSSI : -52
2017-12-10 08:17:14,062 DEBUG    RFM2Pi     50869 Sent to channel(start)' : ToEmonCMS
2017-12-10 08:17:14,062 DEBUG    RFM2Pi     50869 Sent to channel(end)' : ToEmonCMS
2017-12-10 08:17:14,134 DEBUG    MQTT       Publishing: emon/emonth6/temperature 13.7
2017-12-10 08:17:14,135 DEBUG    MQTT       Publishing: emon/emonth6/external temperature 0
2017-12-10 08:17:14,137 DEBUG    MQTT       Publishing: emon/emonth6/humidity 84.5
2017-12-10 08:17:14,138 DEBUG    MQTT       Publishing: emon/emonth6/battery 2.8
2017-12-10 08:17:14,139 DEBUG    MQTT       Publishing: emon/emonth6/pulsecount 1
2017-12-10 08:17:14,141 INFO     MQTT       Publishing: emon/emonth6/rssi -52
2017-12-10 08:17:14,142 INFO     MQTT       Publishing: emonhub/rx/24/values 13.7,0,84.5,2.8,1
2017-12-10 08:17:14,143 INFO     MQTT       Publishing: emonhub/rx/24/rssi -52
2017-12-10 08:17:15,069 DEBUG    RFM2Pi     50870 NEW FRAME : OK 26 120 0 113 0 107 1 25 0 1 0 0 0 (-54)
2017-12-10 08:17:15,072 DEBUG    RFM2Pi     50870 Timestamp : 1512893835.07
2017-12-10 08:17:15,072 DEBUG    RFM2Pi     50870 From Node : 26
2017-12-10 08:17:15,073 DEBUG    RFM2Pi     50870    Values : [12, 11.3, 36.300000000000004, 2.5, 1]
2017-12-10 08:17:15,073 DEBUG    RFM2Pi     50870      RSSI : -54
2017-12-10 08:17:15,074 DEBUG    RFM2Pi     50870 Sent to channel(start)' : ToEmonCMS
2017-12-10 08:17:15,074 DEBUG    RFM2Pi     50870 Sent to channel(end)' : ToEmonCMS
2017-12-10 08:17:15,088 INFO     emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y
2017-12-10 08:17:15,155 DEBUG    MQTT       Publishing: emon/emonth8/temperature 12
2017-12-10 08:17:15,157 DEBUG    MQTT       Publishing: emon/emonth8/external temperature 11.3
2017-12-10 08:17:15,158 DEBUG    MQTT       Publishing: emon/emonth8/humidity 36.3
2017-12-10 08:17:15,159 DEBUG    MQTT       Publishing: emon/emonth8/battery 2.5
2017-12-10 08:17:15,161 DEBUG    MQTT       Publishing: emon/emonth8/pulsecount 1
2017-12-10 08:17:15,162 INFO     MQTT       Publishing: emon/emonth8/rssi -54
2017-12-10 08:17:15,163 INFO     MQTT       Publishing: emonhub/rx/26/values 12,11.3,36.3,2.5,1
2017-12-10 08:17:15,165 INFO     MQTT       Publishing: emonhub/rx/26/rssi -54

Is there any chance your emontx is on a different group or frequency? Is it within range?

Can you confirm if the emonTx is running default node and group settings or have you changed them? As @TrystanLea says there should be some sign of activity from the emonTx in emonhug.log if it’s in range.

Can you also check the RFM69Pi is seated correctly and firmly on the end 10 pins of the GPIO and the underside of the RFM69Pi board is not resting on the unused GPIO pins below it. When you restart the emonBase there should be a 1sec led flash, can you confirm that is also happening.

After that the RFM69Pi should flash (not as bright or long as the initial flash, so easily missed) each time a packet is recieved, so the emonTx and the RFM69Pi’s LED should be flashing around the same time, approximately every 10secs. Can you confirm the LED status on both devices please.

As a test to check if the RFM69Pi is in communication with emonhub you could try changing a [[RFM2Pi]] [[[runtimesetting]]] in the emonhub config eg set quiet=true whilst watching the emonhub.log, once the setting is saved emonhub should send a command

<date+time> INFO MainThread Setting RFM2Pi quiet: 1 (1q)

and the RFM2Pi should reply with something like

<date+time> DEBUG RFM2Pi device settings updated: [RF12demo.14] B i5 g210 @ 433 MHz 1q

likewise when you change it back to quiet=false should reply

<date+time> DEBUG RFM2Pi device settings updated: [RF12demo.14] B i5 g210 @ 433 MHz

I am thinking that the radio on the Pi is not behaving. I reseated the radio on the last GPIO pins. I placed a thin strip of plastic between the rest of the GPIO pins and the board. I did not notice a flash on boot up and did not see any flashes when the emonTX flashes. I turned the lights off so I could detect the flashes better. I changed the config as follows, the quite flag and the voltage flag:

Blockquote
[[RFM2Pi]]
Type = EmonHubJeeInterfacer
[[[init_settings]]]
com_port = /dev/ttyAMA0
com_baud = 38400 # 9600 for old RFM12Pi
[[[runtimesettings]]]
pubchannels = ToEmonCMS,
subchannels = ToRFM12,

    group = 210
    frequency = 433
    baseid = 5                              # emonPi / emonBase nodeID
    calibration = 110V                      # (UK/EU: 230V, US: 110V)
    quiet = false                            # Disable quite mode (default enabled) to enable RF packet debugging, show packets which fail crc
    # interval =  0                         # Interval to transmit time to emonGLCD (seconds)

and the emonhub log responded with:

BlockquoteMainThread Setting RFM2Pi calibration: 110V (2p)

That’s odd, all the RFM69Pi needs to flash at boot is Vcc and Gnd which it takes from the GPIO. When you say “boot up” are you rebooting via the command line or power cycling. Can you confirm no LED flash when powering up?

Unfortunately this result is inconclusive. voltage setting is not used on the emonBase and is not recognized by the RFM69Pi. The “response” you’ve posted is actually the “change voltage” command being sent by emonhub TO the RFM69Pi, there is no response (shown). You have not shown the “set quiet mode command” and that is the one we would hope the RFM69Pi would then respond to.

If there is no LED activity ever, that could mean either

  • the Pi is faulty and not supplying the required voltage (how are you powering the emonBase?)
  • the RFM69Pi is physically faulty, or
  • there is no firmware installed to the RFM69Pi

From the command line can you try stopping emonhub for a moment to use avrdude to see if you get a response?

sudo service emonhub stop
sudo avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400
sudo service emonhub start

Do you have access to and confidence using, a multi-meter to check voltage at the GPIO and on the RFM69Pi board?

When I boot up. I shutdown the pi via software, then unplug and replugged it in while I watched it. I tried that sequence again with the lights off and did not notice any lights around the radio board.
The Pi and the EmonTx are within a half a meter of each other.

Here is the result when I put in the commands:

pi@emonpi(ro):~$ sudo service emonhub stop
pi@emonpi(ro):~$ sudo avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400

avrdude-original: Version 6.1, compiled on Jul  7 2015 at 10:29:47
                  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
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

I toggled the quiet flag several times and I am not getting a response in the emonHub log.

I am not an expert with a multi-meter but am quite familiar with one. Where do I need to check for voltage on the boards?

I am powering the EmonBase with the 2.5a power supply which came with the Pi.

Here are two picture of the Pi with radio installed so you can see if I installed the radio incorrectly. The emonTx is in the background of one of the pictures, so they are quite close for testing purposes.

And the second picture:

Hi @rearden,

It sound like you have a faulty RFM69Pi hardware since you cannot see the LED on the unit light up at statup and also I can see from your emonhub.log that the RFM69Pi is not acknowledging the commands e.g. at statup each command sent to the RFM69Pi should be acknowledged with a response in the log file:

RFM2Pi acknowledged command: > 0q

Full emonhub log file at statup from a working RFM69Pi:

2017-10-26 17:06:25,931 INFO     MainThread EmonHub emonHub emon-pi variant v2.0.0
2017-10-26 17:06:25,932 INFO     MainThread Opening hub...
2017-10-26 17:06:25,932 INFO     MainThread Logging level set to DEBUG
2017-10-26 17:06:25,933 INFO     MainThread Creating EmonHubJeeInterfacer 'RFM2Pi' 
2017-10-26 17:06:25,935 DEBUG    MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2017-10-26 17:06:27,940 INFO     MainThread RFM2Pi device firmware version: [RF12demo.13]
2017-10-26 17:06:27,940 INFO     MainThread RFM2Pi device current settings:  E i5 g210 @ 433 MHz
2017-10-26 17:06:27,941 INFO     MainThread Setting RFM2Pi quiet: 0 (0q)
2017-10-26 17:06:28,943 INFO     MainThread Setting RFM2Pi calibration: 230V (1p)
2017-10-26 17:06:29,945 DEBUG    MainThread Setting RFM2Pi subchannels: ['ToRFM12']
2017-10-26 17:06:29,945 DEBUG    MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']
2017-10-26 17:06:29,947 INFO     MainThread Creating EmonHubMqttInterfacer 'MQTT' 
2017-10-26 17:06:29,948 DEBUG    RFM2Pi     acknowledged command: > 0q

I will be in contact on your shop support ticket to arrange a replacement. When the replacement arrives please could you follow up on this thread to confirm this issue has been fixed. Very sorry for the hassle.

Thank you for helping me, I hope to get it running soon!
rearden

In that first picture the rfm69pi looks awfully close to that heatsink, is there any chance they could touch and cause a short?

To check the voltage, there are 2 rows of 5 contacts between the RFM69Pi and the RPi GPIO. On the inside row (nearest to us in pic1 and furthest from us in pic2) the Vcc pin is at the top (furthest left 1st pic) and the ground is the 5th pin down (5th pin from the left end in pic1), There should be 3.3v DC across those 2 pins.

The reset pin is also in that same row, next to the ground pin (4th from the left pic1), this pin if at 0v will hold the chip in a reset. So between the vcc pin and this reset pin there MUST NOT be 3.3v (or anything close to that).

The solution was to replace the RFM69Pi. It is now working well. Thanks!

1 Like