Archived Forum

The limit is set by JeeLib - 5 bits are available for the nodeID. You'll find details of the format of the message used to send the data by radio over at the JeeLabs website.

Thanks Rob for your quick reply.

I have had a quick look at the jeelib documentation and couldn't find the answer but i haven't spent very much time with that.

Anyway after a quick conversation between somebody in the office with Trystan the reason for having the limit is due to noise that (i can't understand how) was making emonCMS create thousands of nodes, so this was a good way of solving the problem. I know this explanation is missing a scientific explanation but i wasn't the one in the phona, sorry!!

The important thing about this is that $max_node_id_limit can be increased in EmonCMS but according to Rob's answer nodeIDs for radio nodes must be kept in the 32 limit (to comply with JeeLib specification.

Cheers

   Carlos

As I understand it, the problem inside emonCMS is that the software expects a node number attached to the incoming message, if that's missing, then emonCMS creates a new node on receipt of each new message, hence hundreds of new nodes each with one data point.

If you're not using radio and JeeLib, it may be possible to exceed the 32-node limit, Paul (pb66) will put you right on that.

Hi Rob,

Yes i had noticed that if you don't add node to the request a new nodeId is created automatically which i find not to be a very clever thing to do. If a node hasn't got a nodeId it is pointless that it sends inputs as all of them will be seen by emonCMS as they come from different nodes.

In our case we are not using RF but it would be silly not to take it into account as you never know if we will need it. What we are thinking is increasing $max_node_id_limit reserving the first 32 for RF nodes while higher nodeIds would be assigned to tcp nodes. 

  carlos

The "5 bit" node Id used by jeelib is the source of the 32 (0-31) limit, but it has been widely adopted as THE limit as it was the natural choice when a control was implemented. 

The issue causing many inputs to be created by not defining a node id is a relatively recent bug as emoncms previously assigned a node id of 0 to undefined nodes but that is no longer the case.

It would be a great idea to differentiate between the maximum number of nodes permitted and the accepted "labelling" range but I'm not sure the "RF reserved 0-31" is the best way for the wider adoption. it is widening the window perhaps unnecessarily. If you only have 1 rf device and one tcp device you do not need "$max_node_id_limit = 33;" when "$max_node_id_limit = 2:" is less open to errors. Plus if you have more than one rf network how would that effect the numbering? and what about other source types what would their band of node ids be? Perhaps a type or source prefix to the node id could work.

the next version of emonhub has "node offset" to enable multiple rfm networks, basically each interfacer will have the ability to add an "offset" to each node id eg the 2nd rfm network can also use 0-31 (as imposed by jeelib) but the interfacer adds 32 to each node id so emoncms see's nodes 32-63.

Personally I would also like to see the "node id" being more informative and less likely to clash by being a more complex UUID or sourceid+nodeid combo, this line of thinking works well with the direction mqtt may lead the development but is less accommodating for auto assignment though.

But certainly on a local install you can set the "$max_node_id_limit =" setting to a number > 32 and this has direct ties to jeelib. 

Paul

Thanks again Paul for another very informative answer.

We don't want to limit the number of nodes in anyway as we still don't know how many there will be. We will start with a very little number of them but don't know what after. Also we don't know if they will be rf or tcp. Many questions not answered for our "Register Module" that will assign nodes id. In order to make it reusable we need to have all this ideas clear so that we don't limit the future use of the module.

Thank you very much all for yout input

   carlos