OpenEnergyMonitor Community

V11 2nd emontx node 16 lost

Hi I recently upgraded to the version 11. I noticed that not all data from my 2 emontx units was being logged. I rebooted the emonpi and now I have lost the input from the new unit altogether.

where do I go from here to get things back?

The problem is almost certainly the emonhub configuration file, emonhub.conf. Ideally, you need to retrieve your old one and replace the node definitions in the new - which change over time - with the old. Failing that, I need to know the versions of software in each emonTx, or a copy of the error that appears in the emonhub log from each emonTx usually has enough information for an educated guess. You can get at both these files via your web browser and Setup → Emonhub.


This is the info from the SETUP/EMONHUB/ edit config option

I do I backup every Friday so have last Friday available.

Where do I get the version data for the 2 EMONTX

This is extract from the emonhub log file. Data stopped at about 08:11
emonhub.log.txt (47.3 KB)


Is it that is not receiving the data, or your local emonCMS? If it’s the local version, there’s nothing of use to me in the log, so can you change lines 11 & 12 of the config file to:

### loglevel must be one of DEBUG, INFO, WARNING, ERROR, and CRITICAL
loglevel = DEBUG

(I don’t know why your line 11 has been changed to what it is - it’s totally unhelpful)
and then post another snippet showing the error messages from the log.
(I deleted the config file from your post as it showed your APIkey - it’s not a good idea to reveal that.)
You can change line 12 back after we’ve sorted this, if you wish. Leave line 11 with the options though, for next time.

Was that the backup of your emonhub.conf or the present version?


I’d changed nothing (to scared to). All I did was follow the instructions to update to the new version 11 a couple of days ago. I had to reboot the emonpi this morning because I noticed that data from the second emontx was very intermittent. It was after the reboot that things went fully awry.

I haven’t even checked the on-line as it’s been the local bit I’m concerned about

DEBUG set at about 15:32 stripped down log

emonhub (1)2.log.TXT (303.9 KB)


Somehow it got changed - I’m wondering whether an update went bad and caused it?

The log shows that Node 8 (an emonTx) is being received normally and the data is being sent to emonCMS. But there’s no hint of anything from another emonCMS, only the data from Node 5 (the emonPi itself). So it’s looking as if a second emonTx is not being received at all by the emonPi.

But I can see a Node 16 in the early part of the first log file, which I’d expect to be a new emonTx running the ‘CM’ software. It disappears after 8:11. Whether it’s failed, crashed or just out of range I cannot tell. What I can tell from the DEBUG setting is it’s not being received, without that, I couldn’t tell whether it wasn’t being received or not being decoded correctly. I think the fault is not in your emonPi and not in your emonCMS, but the emonTx itself.


This is the graph of the node16. this the red line which is very intermittent. It stopped as you say at 08:11…

I’ll try and take it of the wall and move it closer to the pi. If that doesn’t work I’ll get onto the shop for a warranty replacement as it was only purchased in October.


What is between that emonTx and the emonPi - in terms of distance, masonry, walls with foil-backed insulation, … things like that. If it is on the wall, is the antenna (of both) clear of the wall and metalwork. I can see in the log the signal strength from Node 8, it is very good, (-28) but in the absence of a log showing the Node 16 values (and assuming you didn’t log the RSSI in emonCMS) I don’t know whether the signal before 8:11 was good or marginal. I have trouble when the signal strength falls below the -70s.


I moved the unit, jiggled the antenna a bit and things and data was received. I’ve put it back in place and data is still being received all be it intermittently. The antenna are 3 metres apart, between 2 brick walls and both units sit next to a fuse board.

emonhub (2).log.txt (563.9 KB)

Is there any other way of getting the data from the node16 unit to the pi


The brick walls can’t be helping. Are they dry internal walls, or might they be external and possibly damp due to precipitation? If damp, that will make things significantly worse.

Can you log the RSSI (on the local emonCMS), so that we can see the strength of the signal being received?

Also, is it possible to arrange a ground plane? This is the easiest way to improve signal strength. There was a big discussion a little while ago - Improving RF signal strength emonTH emonTX
Pictures: Extending the Coaxial RG-174 cable from inverter 2.4Ghz Antenna | Archived Forum

You can have the ground plane at either or both ends of the link, though the emonPi is seeing a massive signal from Node 8, so a ground plane for the emonPi might actually create problems for that emonTx (something to be aware of).

Is it possible to get the antenna the other side of the first wall? It’s likely that an extension cable through the wall will be less lossy than the radio path (@Bill.Thomson is likely to know the numbers off the top of his head).

Or, do you have a decent WiFi signal where Node 16 is? If so, you could connect the serial (programmer) port to (say) an PiZeroW and send the data straight into your LAN. Or if not there, near enough to have the PiZeroW where there’s a good WiFi signal and close enough to the emonTx for the serial link to work satisfactorily.

Unfortunately, the Pi has only one serial port, and that’s in use already, so you can’t connect directly. But at only 3 m and if there’s a reasonably direct cable route, a serial connection between the emonTx and a serial to USB adapter plugged into the emonPi might also be feasible (especially if you use a lower baud rate).


Thank you very much. A lot of this goes well beyond my pay grade (retired accountant).

Re the improving strength. “But… replacing the CAT 5 antenna with a 82mm length of 2.5mm solid copper (13A mains cable), I now get the following results, with both transmitter & receiver in exactly same positions;” would I just plug the copper wire into the antenna socket??

I do happen to have a free Raspberry Pi Zero 2 W. I can get power to it and it would be very close to mesh router. Sorry to ask the silly question what do I need to connect to what.

Thanks John

Basically, yes - but check the frequency you’re using. A horrible thought - you are using our standard 433 MHz? Unless your original set-up is quite old, (pre-2015) it is probably 433 MHz. Your new emonTx is certainly 433 MHz unless you specially ordered it. And I know your emonPi is working at 433 MHz - but the radio might just be 868 MHz. Mixed frequencies are bad news, and would explain a very poor signal.

82 mm is for 868 MHz, for 433 MHz, you need a length of double that - 165 mm.

@borpin will tell you, and what software you need (Thanks in advance, Brian).

I have not really read the entire thread, but in effect you connect the PiZero to the EmonTX and run emonhub on the PiZero which then sends the data to your main EmonCMS instance. You can just use an EmonSD, the fact that it is actually running emoncms is irrelevant and it does help in configuring the emonhub.

Search for pizero or serial emontx and you should find the right threads.

@borpin I’ll leave the PiZero for now because @Robert.Wall I’ve move the emonpi and lowered the antenna on the emontx. Getting rssi of between -42 and - 46.I have also put on an aerial that is about 180mm long as the shorter 115mm antenna didn’t seem to work at all.

Related question (I hope) Is there any reason why the transmission still drops out now and again, even on the original emontx (-28 rssi)



Now that you have a good signal (I presume), then it’s possible that the two emonTx’s are jamming each other - because they both transmit on the same frequency. It’s perfectly legal (each transmitter is allowed to transmit no more than 1% of the time) and expected, and it need not be the other emonTx - it could be anything nearby operating on or close to the frequency.

Any form of corruption to the signal is likely to spoil the data, so it’s rejected; and that at least prevents stupid values appearing.

@Robert.Wall Robert sorry to be a pain. Is there someway/program I can use to see what else is being received. I use Alexa to loads of equipment and switches.

Other than the emonHub log, there is nothing built-in. What you’re looking for there is like this, but with a question mark instead of “OK”
2022-01-12 15:10:52,267 DEBUG RFM2Pi 413921 NEW FRAME : OK 5 49 0 40 0 89 0 123 94 ...
but it’s unlikely that what follows will allow you to determine what the data is or where it came from.

There might be other radio solutions that can monitor the band, those would detect all transmissions, and might be able to identify them. I would have assumed, and I’m almost certain this is the case, that Alexa uses the WiFi frequency, which is a long way away from the ISM band. What you’re more likely for find as interfering sources are burglar alarms, car alarms, garage door openers, doorbells, etc. If you can get an eyeball on such things, look for the magic number “433” (MHz). If it’s got that, it’s a possible culprit.