I have set up a minimal test with an emonpi (configured through web api) and one emonTx that measures a single CT clip-on sensor (automatically showed up in the ‘input’ list of the emonpi’s web interface). Eventually we need to process measurements of 4+ emonTx nodes, so now I’m trying to add a second emonTx. This one, however, does not show up automatically in the input list. I have tried to set the first jumper on the emonTx board to ‘on’, to no avail. I am probably misunderstanding something basic in the setup process, hence these questions:
How can I get the second emonTx to show up properly?
I’ve read that, when I go beyond 4 emonTx, I need to adjust the image itself. So, until 4 nodes, I can manage with the DIP switches?
Have you got the correct DIP switch, and have you restarted the emonTx after you changed the switch?
Only Switch 1 changes the Node ID, the second sets 120 V for our N.American friends. Both switches are only read by the sketch when it starts at power-up or reset.
Unfortunately, that also means that you can only have a choice of 2 nodeID’s with the switch, to get more than that, you will either need to edit and reload the sketch, or use the on-line configuration immediately the sketch starts. For both of these, you need the programmer & serial interface cable and of course a computer. And you’ll need to set up the Arduino IDE.
OK, so I know for emontx3,4,5,… I will have to dive into the Arduino IDE. However, for the second one, I’d like to see it working at least once. I located the DIP switch D8 for the second emontx, set that to ‘ON’. The first emontx I left in its default state, so I assume it is still on off/off.
I can see in emonhub.conf, loaded on the emonpi, that the first one is named ‘emontx3’, on nodeid 8. So as far I understand the documentation, the second emontx should pop up at emontx4, on nodeid 7, when clicking the first dip switch to ON?
I do see some misalignment in the emonhub.conf file (the spaces in emontx3’s block do not correspond to the one with the space in emontx4’s block, they’re off by 1). Not sure if that’s significant.
:edit:
i forgot, I flipped the switch when the emonTx was disconnected from the power block
I suspect that last comment was actually significant: I had to re-align the default .conf file so emontx4 matched emontx3. Now it gets picked up by emoncms!
I did not think the leading spaces in the file were significant, in my copy there are 6, 7 & 8 spaces in front of ‘names’, ‘datacode’, etc. I will check.
Hmm, I guess I was put on the wrong track due to the fact that that particular second emonTx does not send data as frequently as the first one I connected.
The first one sends data every 10 seconds, and I can see those updates in emonPi. The second one seems to start sending very slowly, only getting out a message every couple of minutes (I see, right now, the last message is 8mins old. As I’m writing, it got a new update, but that seems to be a rare one as well, as no update is coming in for another minute and counting). I tried connecting a third emonTx, set up with jumper 1 to ON, which seems to send more frequently than the second one (every 10-20 secs, apparently).
Could it be that there’s something physically wrong with the second emonTx? Or is there interference at play, due to the two emonTx’s being close to each other? Would an Arduino flash on the second one be a solution?
The real question is, is the “second” emonTx not sending the data every 10 s, or is the data not being received and decoded correctly?
The easiest way to check would be to power down the “first” emonTx (and all other devices that use this 433 MHz band) and see what effect this has. That would probably answer this:
Do you mean reload the sketch? It’s unlikely that a different sketch was loaded in the factory, though you can do so if you wish. But it will be better to change the minimum number of things at a time, otherwise confusion will ensue.
What do you mean by “jumper”? Do you mean the DIP switch, or JP2? Neither should affect the reporting rate.
Well, apparently screwing in the antenna was pretty much a necessity to get reliable traffic. Pure luck made it so that one machine was oriented in the right position to get traffic, while the others could not for obvious reasons. I successfully updated the emonTx’s ID over serial, and used the first DIP switch to indicate id 7 and 8 (indeed, mis-named it as a jumper).
I’ll leave my shame in this thread, so other people might not forget to screw their antennas in :). Thanks for your time, Robert!
You must always do that. You are lucky that you did not damage the RFM69CW - the data sheet warns that a correctly matched antenna is necessary when the transmitter is operated at full power, otherwise the module may be damaged.
Then I consider myself lucky, the emonTxs still seem to work. If it is that crucial that the antenna is present, perhaps it is important to add a big warning in the documentation pages (for example + Add Additional emonTx - Guide | OpenEnergyMonitor). I based myself on that information, and I can imagine other electronics novices will do the same before resorting to looking at the board data sheets?
Maybe it’s my fault for being an engineer with at least a little knowledge of radio - I wouldn’t expect a transmitter inside a metal box with no antenna to work as well as one with an antenna on the outside of the metal box.
If you want the details, without the antenna, most of the power that would have been launched into the ether has nowhere to go and instead cooks the transmitter, destroying it.
