What is “Emoncms Node Name*” here? There’s absolutely no mention of it in the words, the note under the text box seems to indicate it’s a user-configurable string, I presume data can be entered there as it’s marked with an asterisk as is the APIkey and the instruction is to enter that, but whether you can enter and save the name, or whether it’s just a display, I can’t tell for certain:
I think we have some crossed wires somewhere. My comments about id’ing the device relate to the serial connections between multiple emonTx’s and and a single emonpi/base. There is no issue with one tx attached to one esp as there is only one tx, the esp adds an id from there onwards.
Using a PiZero, emonbase or emonpi one to one with emontx is also ok, but when you connect 3 emonTx’s with no nodeid in the payload and identical adapters without serial numbers or ids then there is no telling which is which, hence you must add a nodeid or use adapters that cannot be mistakenly mixed up, ie serial no or ids, or different models.
I beg to disagree. If I am connected via a Terminal programme to the UART and start the EmonTX, it gives me the ability to enter the ‘options’ menu!
Brian,
It follows on from
Then I wrote - and here again is the sentence in full:
and then you say I’m wrong because you have a terminal connected.
And I’m not disagreeing - while a programmer or equivalent is available. Users who purchase OEM gear are neither encouraged nor advised to purchase a programmer (except by us), and by no means do all users have a programmer, nor indeed the knowledge, aptitude or desire to set up the system to use one, so to that subset of users, no options are available.
I have a programmer! 
I have one unit setup in esp already, so I will try the node name and see.
I don’t even know whether you set up the ESP with a programmer or over the air using its WiFi address. And I don’t know whether to be glad or sad that I don’t know that. 
As you do have a programmer, you might like to look at downloading the sketch in your emonTx’s and adding the line to delay the start. (Post no.15). As I wrote in that, it’s only designed to avoid clashes when all three are powered up at the same instant.
It has a GUI webpage for that. you posted it earlier “emoncms node name” is what your setting, it looks like “0” is the default, which is interesting because some years ago it was decided node “0” was not to be used in emoncms as it can cause issues with tests for populated node ids ie if node id would test True for 1 and above or any text names but return false if the node id is set to int(0) a string “0” would be ok.
OK, I know I’m a card-carrying cynic, but it looks like the right hand had forgotten what the right hand did a while before?
Node zero is special in JeeLib RFM69 Native mode too. I’m not sure why without crawling through all the documentation again, but if my memory serves, it’s exactly as you say, zero = no node = don’t do anything. So if Node zero might be wrong now, it’s a recipe for trouble before too long. And as for ‘\0’ and “0”, that’s guaranteed confusion.
Plus, IIRC and emoncms hasn’t changed since. When you post data via the input api and omit a node id, emoncms assigns a zero node id. So if node 0 is a legitimate node and you are doing some experimenting and omit the node id from a test url, bang goes the integrity of your valued data.
I think that’s still true.
Hmm. Even if Node zero is valid, it seems it shouldn’t be. If/when we adopt the RFM69 Native format, that argument for using every available NodeID diminishes, as “node ID (RF69 supports 1…60)” and “61 is for send-only nodes, 62 is reserved, 63 is receive-all” [quoted from JeeLabs].
I can’t recall the exact reason node 0 is reserved in JeeLib right now but I do recall the discussion at the time (re emoncms node 0) was to avoid using node 0, fullstop. That way we avoid issues with JeeLib and with false negative tests whilst keeping node 0 open on emoncms to be able to see data posted without a node id, which can be useful when tinkering! So why a default of 0 is used in emonesp I have no idea!
Two reasons I can think of: It just happened without being thought about, or “It seemed a good idea at the time.”
Maybe the distinction between zero and NULL came into play - or not?
I guess I need to ask Gwil to send me an ESP, so that I can get to the root of all this.
In the original JeeLabs “RF12 broadcasts and ACKs” from 10 June, 2011, he writes about Node 0:
[in the header byte] “There are three bits : C = CTL, D = DST, and A = ACK, and there is a 5-bit node ID. Node ID 0 and 31 are special, so there can be 30 different nodes in the same net group.”
and in the documentation for the rf12.h header file: “ID 0 is reserved for OOK use.”
(I should have remembered that.)