Standardising OpenEnergyMonitor wireless node ID's

Hello everyone,

Up until now we haven't defined any standard for RFM12B node ID's. I think, this is something we should do since given a node ID it would be nice to know if it was an energy monitoring node, base station or temperature monitoring node. This would help with identification of inputs in emoncms.

The JeeLib RFM12B library supports 0-31 node ID's per network with 1-30 used for normal operation. ID 0 is reserved for OOK use and ID 31 can be used to communicate with nodes on any network group.

I've been looking through our code examples on github and the default node ID's so far are:

10 - emonTx
15 - emonBase (NanodeRF/RiPi) )
18 - low power temperature node
20 - emonGLCD

Update: see my post below

I propose to in the future we will try and stick to the following standard:

ID Node Type 
1-14 energy monitoring sensor nodes
15-17 base station & logging nodes
18-25 remote temperature monitoring nodes
26-27  Control nodes (yet to be developed!)
28-30 --Un-assigned --
31 Master base station - communicate with nodes on any network group

This standard won't be enforced, there is nothing stopping you choosing your own node ID's. In the future we might consider some sort of automatic or suggested setup of input processes and logging in emoncms based on the node ID. Something like "data from node 10 detected, this is probably an energy monitoring node would you like to create Kwh/d and histogram input processes?" or "data from node 19 detected, this is probably a remote temperature sensing node, would you like to x by 0.01 , log to a feed and create a daily average feed?"

Any thoughts on this scheme? 

Robert Wall's picture

Re: Standardising OpenEnergyMonitor wireless node ID's

You should definitely assign some undefined space, if only so that everyone knows that area could be anything. It will hopefully prevent an action replay at some point in the future.

ukmoose's picture

Re: Standardising OpenEnergyMonitor wireless node ID's

This gets my vote.

 I assume you are classing the emonglcd as a temperature monitoring node?

If so is it worth changing the emonglcd id to 18 as a default i.e. the first of the temperature node id's

 

Could you also standardise on the nomenclature?

The RFM12Pi scripts defines it as a BaseID rather than NodeID  which I think confuses people.

glyn.hudson's picture

Re: Standardising OpenEnergyMonitor wireless node ID's

Good idea regarding un-assigned space, I've modified to post to give some free space. I've intentionally only assigned a few control nodes as openenergymonitor is primarily an open-source monitoring system. There are other open-source home automation/control system our there which will probably do a better job of control. 

The reason we called it baseID is that that ID is the ID of the base station i.e the raspberry Pi. Thinking more about it, maybe 'RFM12Pi node ID' would be a better term. I'll look into changing it. 

nbown's picture

Re: Standardising OpenEnergyMonitor wireless node ID's

sounds very good to me,

Is a there any ground in standardizing the payload data sets?

Series530's picture

Re: Standardising OpenEnergyMonitor wireless node ID's

Gets my vote too.

as to the payload sets , surely it all depends upon the application? I can appreciate that some applications may have common data but others will have different data or variations of a theme. I'm not aware  of a method whereby a transmitted payload can be picked at by the recipient receiver.... It being accept the whole payload or nothing. I wouldn't want a bloated payload being transmitted just to provide a wrapper to conform.

Robert Wall's picture

Re: Standardising OpenEnergyMonitor wireless node ID's

It seems that Node ID is the "correct" name as that's the one used by JeeLabs, the maintainers.

glyn.hudson's picture

Re: Standardising OpenEnergyMonitor wireless node ID's

Trystan and I have been giving some more thought to the node ID allocations, we foresee the need for more remote temperature nodes and less energy monitoring nodes. Working around the current (rather random) node IDs we have been using for the various base station makes assignment rather awkward. It would be possible to change the current  node ID's, but this would cause a fair bit of issues during a transition period. 

As a reminder the current allocations are:

10 - emonTx
15 - emonBase (NanodeRF/RiPi) )
18 - low power temperature node
20 - emonGLCD (as far as the base station is concerned this is a transmitting temperature node)

I propose to in the future we will try and stick to the following standard (2nd version):

ID Node Type 
0 Special allocation in JeeLib RFM12 driver - reserved for OOK use

1-4

Control nodes 
5-10 Energy monitoring nodes
11-14 --Un-assigned --
15-16 Base Station & logging nodes
17-30 Environmental sensing nodes (temperature humidity etc.)
31 Special allocation in JeeLib RFM12 driver - Node31 can communicate with nodes on any network group

This standard won't be set in stone, you can still set any node ID you fancy if you want! In the future emoncms might suggest imput processing setup based on node ID but this won't be enforced 

Petrik's picture

Re: Standardising OpenEnergyMonitor wireless node ID's

 

 

 

 Already have the following so please make adequately long reservations for eaxh device type.. Right now looks like there is not space enough for logging nodes for basics already in system over here (in cold Nordics):

3 x emontx (one for 3 phase mains, one for heatpump+electric central heating+warm water, one for heatpump and 1-wire network and air to air heatpump fan rpm)

2 x funky sensor (primarly for temperature and voltage). I may add one funky per each add on heating element per room which would add this to 5 or 6.

1 x emonglcd with also ambient temp, planning to change this to to ambient + humidity with DHT22.

1 x nanode for outputting to emoncms.org

Waiting for build

1 x emontx shield as solar controller and datalogger

1 x raspberry to act as local server

 

 

jb79's picture

Re: Standardising OpenEnergyMonitor wireless node ID's

Some questions about the ID Allocations:

1.) What are Control nodes? Do they exist at the moment or are they under development now?

2.) What IDs should be used for one/more emonGLCD(s) with no temperature sensor?

3.) At the moment my EmonTx is at ID11. What happens if I set it to ID10? Do I have to recreate all settings in EmonCMS new or does the system change the settings to ID10 without any reconfiguration work for me?

glyn.hudson's picture

Re: Standardising OpenEnergyMonitor wireless node ID's

Hi jb79:

1.) No, they don't yet unless you build something like a solar PV power diversion controller yourself, lots of discussion on forums 

2.) Doesn't matter since it won't be transmitting. 

3.) Ye, if you running multinode sketch on your emonBase new inputs will be created in emoncms. You will need to re-map these to your feeds .

glyn.hudson's picture

Re: Standardising OpenEnergyMonitor wireless node ID's

Robert Wall has kindly written a documentation section on how data is packaged and transmitted between nodes. The recommenced node ID allocation table above has been included in this. Going forward will be standardizing on these node ID's

[Edit] ...with help from ukmoose [RW]

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.