Emoncms spam-creating new Devices and Inputs continuously

Emoncms
1

I’m not sure what’s causing this - but my installation (and I’ve just wiped and re-imaged the SD card) is continually creating new Devices and Inputs with simply a number as the Node ID.

This happened both on my existing install (11.7.4) and the fresh SD card with 11.4.1.

Any idea how to debug this?

image
image3198×1788 313 KB

An example of one of the input objects created:

image
image2662×1686 198 KB

My install is 1x EmonPi2 with 12CT and 4x EmonTx5 in various locations (some are probably out of range, I’m still just setting things up).

Is it possible the further away nodes are resulting in the EmonPi receiving corrupted packets and causing the device creation with autoconf?

Thanks!

2

Think I solved it - it was one of two things;

  • One of the nodes had a bad FW flash on it (unlikely)
  • More than one node had the default NodeID set (they were all 27)

Re-flashed all EmonTx nodes with the latest FW and updated their CT and NodeID configs to make them distinct seems to have solved it.

3

Ooh… That’s BAD. Every NodeID must be unique.

The other thing you could do is disable auto configuration in your emonhub.conf file. This has historically caused a lot of trouble, though this seems to have been solved now. Near the top of emonhub.conf, change to set

autoconf = 0
4

Screenshot 2025-12-23 at 16.51.04
Screenshot 2025-12-23 at 16.51.042860×924 332 KB

Screenshot 2025-12-23 at 16.50.47
Screenshot 2025-12-23 at 16.50.472900×1216 388 KB

Screenshot 2025-12-23 at 16.46.41
Screenshot 2025-12-23 at 16.46.413190×1568 347 KB

So, this is still ongoing - even with all nodes re-flashed and configured with distinct nodeIDs, for some reason the EmonPi still keeps trying to create new devices and inputs (possibly my oil-tank monitor on 443MHz interfering?).

In any case, I enabled the new “Disable Input Creation” feature on the Inputs page, and autoconf has been set to 0 since earlier in the year, the phantom Devices and Inputs keep getting created.

A new symptom since the new “Disable Input Creation” feature was enabled is that now it appears every time the EmonPi tries to create a new Device and its assocaited inputs - it can’t (which is good), but emoncms_mqtt.php crashes with the following:

Service Restarted

2025-12-23 10:23:49.246|WARN|emoncms_mqtt.php|Starting MQTT Input script
2025-12-23 10:23:49.349|WARN|emoncms_mqtt.php|Not connected, retrying connection
2025-12-23 10:23:49.360|WARN|emoncms_mqtt.php|Connecting to MQTT server: Connection Accepted.: code: 0
2025-12-23 10:26:16.-68|WARN|emoncms_mqtt.php|Starting MQTT Input script
2025-12-23 10:26:17.035|WARN|emoncms_mqtt.php|Not connected, retrying connection
2025-12-23 10:26:17.046|WARN|emoncms_mqtt.php|Connecting to MQTT server: Connection Accepted.: code: 0

Service crashes as it can’t create inputs (which is expected)

2025-12-23 11:53:22.-366|WARN|emoncms_mqtt.php|error creating input
2025-12-23 11:53:22.-364|WARN|emoncms_mqtt.php|MQTT has disconnected - cleanly

It seems there is a bug in the mqtt.php service that it doesn’t interop with this new feature.

Attached screenshots of Inputs screen, error and services.

5

Sorry, I can’t help with this.

@TrystanLea ?

6

HI, can you confirm your setup, please? You say you have reflashed the TXs - are these communicating via RF then?

(sorry missed this)

What is sending data via MQTT?

Have you had a look at the MQTT data via another tool?

I’ve take off the solved tag.

There have been other reports of bugs in this @TrystanLea

7

I’m also reproducing this issue but having difficulty working out what’s causing it, @borpin do you remember what the other threads were that reported this issue?

8

I’ll try. One is here (slightly different) Emoncms_mqtt randomly stops when Disable further input creation is enabled - Emoncms - OpenEnergyMonitor Community

[edit]
Can’t find any others but I’m sure there was at least one. Perhaps I am an AI and I’m hallucinating!

9

Thanks @borpin managed to figure it out, this is now fixed in the latest master and stable branches.

@emonuser please try updating to fix this issue.

10

Finally updated yesterday, has been stable since - so thank you Trys, I think that’s solved it!