A 2nd EmonTH does not show up in the inputs list

Robert.Wall · 2025-01-11T19:19:40.705Z

Welcome, Jon, to the OEM forum.

jon.in.swansea:

I then set dip switches on the 2nd emonTH2 and put batteries in and the green glowed for a few seconds as expected.

Did you set the switches to a different combination for this second emonTH2? What are the switch settings for each? I take it you’ve been looking here: EmonTH v2 Install — OpenEnergyMonitor 0.0.1 documentation

In emonCMS, go to Setup → EmonHub and click on Edit Config.
Scroll down the list until you come to the emonTH settings - the first one should look like this:

[[19]]
   nodename = emonth1
   [[[rx]]]
      names = temperature, external temperature, humidity, battery
      datacode = h
      scales = 0.1,0.1,0.1,0.1
      units = C,C,%,V

There should be 8 (named ‘emonth1’ to ‘emonth8’ with IDs [[19]] - [[26]] ) Check that you have one for each emonTH’s Node ID as read from the switch settings.

(If you change the switch settings, take a battery out for a few moments - the switches are only ever read once at startup.)

jon.in.swansea:

I don’t find any mention of a procedure for getting the EmonBase to refresh it’s list.

You cannot. It’s automatic as soon as the message comes in via the radio. And until it does, and it’s valid and the Node ID in the message matches an entry in the config file, it won’t be processed and you won’t see it on the Inputs page. Also note - it only transmits every 58 s or so - so if you miss it, you’ve got a minute to wait for the next.

jon.in.swansea · 2025-01-12T08:45:39.000Z

Thanks for the comments. I set the 2nd EmonTH2 with the dip switch closest to the battery to the right.

I went into the Edit Config and here is what I found (note I an earlier set a different name for the node - perhaps
that was a mistake). What I see is somewhat different than what you sent in terms of the datacodes.

## See config user guide: [https://github.com/openenergymonitor/emonhub](https://github.com/openenergymonitor/emonhub)
## If autoconf is enabled above, node configuration will automatically
## populate based on templates listed in available.conf

[nodes]
[[23]]
nodename = emonth2_23
[[[rx]]]
names = temperature, external temperature, humidity, battery, pulsecount
datacodes = h, h, h, h, L
scales = 0.1, 0.1, 0.1, 0.1, 1.0
units = C, C, %, V, p

There are no additional EmonTH entries in the Edit Config listing.

Here is a section of the log - there is an entry regarding the RFM69 module.

2025-01-12 08:28:41,913 INFO MainThread Running as user: pi
2025-01-12 08:28:41,914 INFO MainThread Logging level set to DEBUG
2025-01-12 08:28:41,914 INFO MainThread Creating EmonHubOEMInterfacer 'EmonPi2'
2025-01-12 08:28:41,914 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 115200 bits/s
2025-01-12 08:28:41,915 INFO MainThread Creating EmonHubOEMInterfacer 'USB0'
2025-01-12 08:28:41,916 ERROR MainThread Could not open serial port: /dev/ttyUSB0 @ 115200 bits/s (retry every 10s)
2025-01-12 08:28:41,917 INFO MainThread Creating EmonHubRFM69LPLInterfacer 'SPI'
2025-01-12 08:28:41,922 INFO MainThread Creating RFM69 LowPowerLabs interfacer
2025-01-12 08:28:41,922 INFO MainThread RFM69 node_id = 5
2025-01-12 08:28:41,923 INFO MainThread RFM69 network_id = 210
2025-01-12 08:28:41,923 INFO MainThread RFM69 interruptPin = 22
2025-01-12 08:28:41,923 INFO MainThread RFM69 resetPin = 24
2025-01-12 08:28:41,923 INFO MainThread RFM69 selPin = 16
2025-01-12 08:28:41,923 INFO MainThread Starting radio setup
2025-01-12 08:28:42,623 ERROR MainThread Could not connect to RFM69 module
2025-01-12 08:28:42,624 DEBUG MainThread Setting SPI pubchannels: ['ToEmonCMS']

I have rebooted the pi. Log shows same message about RFM69. I tried changing the battery in
the Emonth2. The EmonBase was added to an Pi4 and it is running from an SD card that I got from OpenEnergyMonitor.

-Jon Hand

[Edited for presentation - Moderator (RW)]

Robert.Wall · 2025-01-12T14:56:39.547Z

jon.in.swansea:

There are no additional EmonTH entries in the Edit Config listing.

There’s your problem. It will only ever decode the data from Node 23. You need to copy the section for Node 23 and rename it to correspond with the switch settings on your second emonTH2, and change nodename = emonth2_23 to something sensible - it’s purely to help you identify which is which.

And again for the third emonTH2.

I didn’t need datacodes = ... because all my values are short signed integers. As you have a mix of short signed h and long unsigned L, you need to specify each one.

If you’re receiving data from the first emonTH, the error message about the RFM69 can safely be ignored. I don’t have a SPI RFM69 module so I don’t know exactly what to expect, however it looks as if two interfacers are trying to connect - one for the ‘old’ serial interface and one for the ‘new’ SPI interface. And the one that can’t see the RFM69 is giving the error, the other has connected.

I edited your post to make it a bit more readable. When posting code or output, please put 3 ‘backticks’ (normally found at the top left of the keyboard) on a line of their own before the code, and 3 more backticks also on a line of their own after the code:

```
code
```

If it is something like php you can add a language identifier after the first 3 backticks: ```php or even ```text if you don’t want any language markup applied.

jon.in.swansea · 2025-01-12T18:59:22.000Z

Thanks for the response. And for the note about including code. It was ages ago that I used OEM kit and I am trying to get back into the swing of things…

I had thought that it would self-populate the Edit Config listing if the radio detected more devices. I will add entries for the additonal EmonTH.

However, as I am getting no data in the feed for the first EmonTH it could be that the EmonBase SPI RFM69 warning is correct and the unit is faulty? Should I contact OpenEnergyMonitor directly about that?

Robert.Wall · 2025-01-12T20:27:35.816Z

jon.in.swansea:

I had thought that it would self-populate the Edit Config listing

Not that I’m aware of, and certainly not reliably. There is something Trystan tried to develop called “autoconf”. I’ve never found any significant documentation describing what it’s supposed to do or how it’s supposed to do it. All I know is this comment copied from the file here: emonHub Configuration File — OpenEnergyMonitor 0.0.1 documentation Another fact is this ‘feature’ has caused a lot of trouble for a lot of users, and my recommendation is to not even think of enabling autoconf.

jon.in.swansea:

I am getting no data in the feed for the first EmonTH

Was it not receiving the first emonTH when you started? Do you still have data appearing on the Inputs page? - if not, have you inadvertently changed something in the top part of the config file?

If you have new data appearing on the Inputs page, have you set up any processing there? The minimum you need is “Log to Feed”. It’s only when you have this - or one of the other process steps that send data to a Feed, will the values reach the feed and be recorded (a Feed is in fact the database). There’s more here: Emoncms Core Concepts — OpenEnergyMonitor 0.0.1 documentation Don’t read past that section, go to here: emonCMS: Getting started emonPi/Base — OpenEnergyMonitor 0.0.1 documentation

N.B. When you create a Feed for data from the emonTHs, you must set the Feed Interval - the rightmost drop-down list “Selec” - to 60 s (or greater, never less, or you will have NULL values in the database which will cause problems later).

image1731×448 142 KB

Give it 5 - 10 minutes to collect some values, and you can then try a Graph. If you see anything when you’ve selected the emonTH and the temperature feed and a suitable period (1 hour?) the feed is working.

rupert · 2025-01-12T22:04:57.877Z

@jon.in.swansea

I don’t know if this helps as I don’t have an emonTH … but

Background

1) There are two main radio protocols used. They are not compatible.
a) The older one is called Jeelib Classic format.

b) The newer one is called LPL (Low Power Labs) radio format.

2) There are two radio modules for the emonBase.
a)The older RFM69 Pi module has a RFM69 radio module and an atmega 328 controller. It talks to the Pi via the Pi AMA0 serial port. The atmega 328 controller can be programmed to receive either LPL or Jeelibs protocol. The atmega 328 firmware can be changed from the Admin > Update page.

b) The newer RFM69SPI module just uses the RFM69 radio module, and talks to the Pi via the Pi SPI port. The decoding of the radio format is done in the Pi. The SPI decoder in emonHub is only for the LPL protocol

So -
What sort of radio receiver is being used on the emonBase:

an RFM69SPI 433Mhz Transceiver - the current version - see
RFM69SPI 433Mhz Transceiver - Shop | OpenEnergyMonitor
New: emonBase with RFM69 SPI (Direct) — OpenEnergyMonitor 0.0.1 documentation
or
an RFM69 Pi (ATmega328) Transceiver - the previous version - see
emonBase with RFM69Pi (ATmega328) — OpenEnergyMonitor 0.0.1 documentation
How old are the emonTh2s and do they contain the original firmware? Older ones will have shipped with the Jeelib Classic format, while newer ones will have shipped with the LPL format. I am guessing that the changeover was about February 2023. The radio format of the emonTh2 can be changed by changing the firmware in the unit - see
Firmware — OpenEnergyMonitor 0.0.1 documentation

All three emonTh2s and the emonBase need to use the same radio format to be compatible. If you are using an RFM69SPI 433Mhz Transceiver, all units must use the LPL format.

For more details see

emonBase can't connect to RFM69 module Hardware

I had posted this earlier as “can’t open serial port”, but I have since confirmed that I can connect to the serial port by plugging in a zigbee dongle just to test. The log file shows a successful connection. However, I cannot connect to the RFM59 module. Suspecting that the module might be defective, I swapped the module from a working emonBase and emonHub still shows as unable to connect. In searching other posts, I saw a reference to changing the baud rate, so I tried 38400 and still no luck…

Hope this helps. Apologies in advance for any mistakes!

grod55 · 2025-01-13T00:12:38.744Z

jon.in.swansea:

2025-01-12 08:28:41,922 INFO MainThread RFM69 node_id = 5
2025-01-12 08:28:41,923 INFO MainThread RFM69 network_id = 210
2025-01-12 08:28:41,923 INFO MainThread RFM69 interruptPin = 22
2025-01-12 08:28:41,923 INFO MainThread RFM69 resetPin = 24
2025-01-12 08:28:41,923 INFO MainThread RFM69 selPin = 16

@jon.in.swansea
if you are connecting the emonTH to an emonBase, the RFM69 resetPin = 24 must be set to RFM69 resetPin = 26. This was the solution to same issue I had in post emonbase-cant-connect-to-rfm69-module]

Robert.Wall · 2025-01-13T12:27:14.461Z

jon.in.swansea:

One emonTH2 was powered up when I started the pi and first went into the emoncms. I saw it in the inputs tab.

@rupert @grod55
How do you both explain how Jon got data from the first emonTH?

jon.in.swansea · 2025-01-13T12:42:09.000Z

Just an update - it turns out I have yet to get actual data from the emonTH. I am going to start with a fresh
install of the OS on my Pi4 with the emonbase and see what happens…

Robert.Wall · 2025-01-13T13:14:10.889Z

So you never actually saw data on the Inputs page?

grod55 · 2025-01-13T14:22:02.023Z

Hi Jon,

Are you installing the fresh OS on your emonBase and looking for inputs on it? This is the scenario that I have with 5 emonTHs connecting to it.

When I did the fresh install (downloaded the latest SD card image) and ran the updates the emonBase would not recognize the emonTHs until I changed the entry in emonHub for the reset pin to be 26. @TrystanLea pointed this out as it was not documented previously.

grod55 · 2025-01-13T14:24:56.194Z

jon.in.swansea:

install of the OS on my Pi4 with the emonbase and see what happens…

One other question. You mention Pi4 with emonBase, I assume you are using a Raspberry Pi4 with the emonBase OS installed on it - correct?

rupert · 2025-01-13T14:56:30.364Z

@Robert.Wall
I was thinking that perhaps Jon had a mix of new and old emonTHs, some using the LPL format and some using the Jeelib format. A single receiver would not resolve both formats. Like you, I was assuming that one emonTH was working.

I had forgotten about the RFM69 resetPin = 26 issue; If it was set to pin 24 then I don’t think any emonTHs would be received?.

It seems that there is some confusion between RFM69 resetPin = 26 and
https://docs.openenergymonitor.org/emonbase/rfm69-spi.html#overview
which says

[interfacers]
    [[SPI]]
        Type = EmonHubRFM69LPLInterfacer
        [[[init_settings]]]
            nodeid = 5
            networkID = 210
            selPin = 26
        [[[runtimesettings]]]
            pubchannels = ToEmonCMS,

and
https://github.com/openenergymonitor/emonhub/blob/master/conf/emonpi2.default.emonhub.conf#L46
which says

[[SPI]]
        Type = EmonHubRFM69LPLInterfacer
        [[[init_settings]]]
            nodeid = 5
            networkID = 210
            resetPin = 24     # remove line if hardware is emonBase RFM69 SPI
            selPin = 16       # remove line or change to selPin = 26 if hardware is emonBase RFM69 SPI
        [[[runtimesettings]]]
            pubchannels = ToEmonCMS,

?

Robert.Wall · 2025-01-13T15:09:59.337Z

We don’t know what Jon has in the top part of his emonhub.conf, so it’s all been guesswork, not helped by what now appears to be an inaccurate initial post.

jon.in.swansea · 2025-01-13T16:44:20.601Z

I never saw any change in the values on the input page.

Robert.Wall · 2025-01-13T16:45:44.103Z

jon.in.swansea:

I saw it in the inputs tab.

It would not have got there without an input coming in by radio.

jon.in.swansea · 2025-01-13T16:53:01.949Z

Yes, I had an existing RPi4, I added an emonBase unit to it and used an SD card I got from OEM. I also have three of the V2 of emonTH.

I did the usual sudo apt-get update & install. I had read through some of the documentation (I had experience a decade ago with OEM and coming back has resulted in some messages to the community. The web interface opened as I remembered it.

The community has been most helpful. The reset pin =26 certainly I would not have known about. I have edited the configuration to include that and also took the suggestions about editing in three entries for the emonTH.

Before I do a nuke and pave on the device would it be useful for me to upload the log file and the hub configuration file?

jon.in.swansea · 2025-01-13T17:01:41.591Z

Ah, I just noticed the comment about removing the resetPin line. I will try that…

BRAVO - I did a hub restart and now I see in the inputs list all three of the emonTH.

Perhaps the documentation on emonbase and on the SD card download and setup might be updated to include a hint about the selPin = 26?

rupert · 2025-01-13T21:44:23.137Z

@jon.in.swansea
That’s good.

So I take it that you’re now getting sensible temperature readings from the three emonTHs on the input page?

If you want to save the data, you’ll have to create some feeds - see Logging data locally in
https://docs.openenergymonitor.org/emoncms/intro-rpi.html

jon.in.swansea · 2025-01-13T22:15:25.945Z

The input page is working as well as are the feeds. Graphing nicely now the local data. And now that it is up and running I have ordered a 4th emonTH as well as a pulse metre to complete the setup.