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.

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.

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. 

sounds very good to me,

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

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.

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

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):

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 

 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

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?

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 .

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]