EmonHub autoconf and nodelistonly settings

[TrystanLea]

autoconf = 1

[hub]
    ### loglevel must be one of DEBUG, INFO, WARNING, ERROR, and CRITICAL
    loglevel = DEBUG
    autoconf = 1

Back in November 2022 I added a feature called autoconf to emonHub. I mentioned it briefly at the time in the EmonTx4 documentation thread here:

@TrystanLea

There is now a new section in the ‘Adding an emonTx4 to an existing install’ covering adding the required emonhub node decoder Adding an emonTx4 to an existing installation — OpenEnergyMonitor 0.0.1 documentation . There is also a new option mentioned called autoconf which can be enabled at the top of the emonhub config file. This automatically configures nodes based on a list of available node decoders. I will be adding more detail on that in the emonhub documentation section.

But it was a busy time getting the emonTx4 to release point and this was one of many parallel pieces of work and so I never did a more detailed post about this feature or more importantly updated the documentation. So here is a more lengthy introduction and a point to review and see how this feature might be improved going forward.

The intention behind this feature was to:

1. Move away from the pre-set list of emonhub node decoders that restricted the nodeid’s that radio nodes could use. That approach worked well when you had one or two of e.g and emonTx4 running the standard firmware but less well if you wanted to connect more than the allocated id’s or had a different radio packet. It also made for a very long and hard to read emonhub.conf where all possible node configuration were listed.

2. Make it possible to ship the emonhub.conf configuration file without any node decoders listed and for node decoders to get allocated automatically based on the radio packet data received. Removing the nodeid restriction and making for a cleaner emonhub.conf with only the nodes in use that need to be configured listed.

In testing here this feature worked really well, nodes were automatically configured and popped up without additional user configuration on the emoncms inputs page.

However it has not been plain sailing for all and in environments with more radio activity? a lot of non valid nodes have been auto configured by this mechanism, leading to long lists of nodes in the emonhub.conf nodes section and plenty of associated nodes and inputs in emoncms.

How does autoconf work?

1. Autoconf works by first matching the packet length of the received radio packet with a list of known node decoders (this list can be found here: emonhub/conf/available.conf at master · openenergymonitor/emonhub · GitHub)

2. If there are multiple node decoders that match the packet length it will do a second check based on the nodeid of the received node. E.g it is expected that the emonTx4 is transmitted on node 17 or 18 and so if the received node has nodeid 17 or 18 whilst also matching the packet length it will allocate the emonTx4 node decoder in this instance.

Limitations

It seems that in @grod55’s case there is some other non OpenEnergyMonitor device sending data with a 52 byte packet length but with the nodeid byte clearly not a nodeid as it kept changing, resulting in the allocation of a very large number of node configurations and associated emoncms inputs!

Disabling autoconf alone does not resolve the issue as these non OEM nodes can still pass through emonHub via the mechanism that just forwards the raw byte data without the node configuration.

Hence the addition this week of another setting:

nodelistonly = 1

Set in the runtimesettings of the relevant interfacer, here the EmonHubRFM69LPLInterfacer:

    [[SPI]]
        Type = EmonHubRFM69LPLInterfacer
        [[[init_settings]]]
            nodeid = 5
            networkID = 210
            resetPin = 24
            selPin = 16
        [[[runtimesettings]]]
            pubchannels = ToEmonCMS,
            nodelistonly = 1

This setting can be used to disable this pass through mode essentially discarding node data that is not already configured.

autoconf does currently override nodelistonly. If autoconf =1 and nodelistonly =1 then new nodes can still be created if they match the node definitions.

To completely disable both pass through and new node configuration with autoconf both settings need to be set to 0 e.g: autoconf = 0 and nodelistonly = 0.

Global vs interfacer specific?

At the moment autoconf is a global setting set in the [hub] section and nodelistonly is a interfacer specific setting set in the [[[runtimesettings]]] section fo that interfacer. I am considering making both interfacer specific for consistency… this seems like the more logical location I think.