The code is still there in the sketch - nodes 8 & 7. If you have another Node 7, then there’s a conflict and two devices will be appearing in the same slot. Is that what’s happening? What NodeID does it tell you at startup on the serial monitor?
I will check when I get home in a bit. Maybe I should have put the DIP switch back before I uploaded the sketch, not sure that would make a difference. Does one override the other? e.g. is the sketch NodeID the master or the DIP switch?
Can I check the node number without pluging into a PC? Thorugh emonCMS maybe? Just trying to avoid unplugging everything from the garage each time!
The sketch checks the DIP switch every time you power the emonTX on (when using the standard sketch).
Only if emoncms (or more precisely, emonhub) is receiving it! Have you looked in the log - that should show if two nodes are transmitting using the same ID, because the timing won’t be a regular 10 s (but maybe 8s & 2 s)
and when you hit the reset button.
When I look at the ‘Input’ screen in emoncms (setup>Inputs), the emonPi is every 2’s and the emonTx every 8’s. Is that what you meant?
I have looked at the log via setup>emonhub but can’t see any obvious ‘timings’…??
No - the input screen is updated asynchronously, so it tells you how old the last input was when the screen updated.
What you need to do is check the timings of the emonTx’s in the log. You’re hoping to see two, sending at regular 10 s intervals. But my hypothesis, which we’re trying to test, is they’re both using the same Node ID. If they are, then you’d expect to see one Node 8 sending at 10 s intervals, the second Node 8 sending a different set of values but otherwise indistinguishable also at 10 s intervals, but the two will drift in time relative to one another, so the interval between 1st and 2nd, plus the interval between 2nd and 1st, will add up to 10 s.
If both are transmitting, you should see both in the log, even though the data might be rejected. If that’s what is happening, the next step will be to sort that out.
This is the first line in the log for an emonTx:
2017-09-14 19:21:54,608 DEBUG RFM2Pi 135 NEW FRAME : OK 11 4 0 0 0 0 0 0 0 82 93 248 117 148 117 148 117 148 117 148 117 148 117 1 0 0 0 (-75)
Received at 19:21:54.608 from Node 11. There are 22 more lines following as the message is processed.
If there’s definitely only one emonTx showing up in the log, then we’ll have to look carefully at the sketch you downloaded.
I have the emonTx sat on my desk now. I put the DIP switch back to off, set the NodeID to 7 in the src sketch and re uploaded it as a double check. No CT’s or AC-AC connected but the aerial is connected and batteries in it. The red LED illuminates on reset but is not flashing every 10 secs or so.
If I click Tools>Serial Monitor this is what I get;
⸮!⸮⸮֨⸮⸮<Z⸮⸮⸮⸮R⸮⸮tԠ⸮⸮q⸮I⸮!-⸮<0⸮
,⸮Q=^⸮⸮n~⸮⸮⸮⸮⸮i⸮~
I am guessing this is not right at all…
From the log I can see I can see emonPi (node 5):
2017-09-14 20:19:53,198 DEBUG RFM2Pi 225 NEW FRAME : OK 5 92 0 1 0 93 0 45 96 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
And emonTX3 (node 8);
2017-09-14 20:22:47,280 DEBUG RFM2Pi 277 NEW FRAME : OK 8 143 1 255 255 0 0 0 0 74 102 184 11 184 11 184 11 184 11 184 11 184 11 1 0 0 0 (-30)
But no extra emonTx. I do see this every so often in the log;
2017-09-14 20:23:57,002 DEBUG RFM2Pi Discarding RX frame ‘unreliable content’? 0 0 0 0 0 0 0 0 0 251 101 184 11 184 11 184 11 184 11 184 11 (-103)
That’s correct for battery operation.
My first thought here is the Baud rate is wrong. It’s sending at 115200. Is your monitor set the same?
That’s most likely interference or something on the same channel at some distance away.
To receive Node 7 in emoncms, you should have a block exactly the same as the block at line 58 in the sketch, but obviously Node ID [[7]]
With an RSSI of -103, it looks (at least in part) like it may be more of a weak signal vice an interference issue.
It’s certainly in the long grass.
I changed the Baud rate to 115200 and get this;
V3.4 Discrete Sampling V2.90
OpenEnergyMonitor.org
No EEPROM config
RFM69CW Node: 7 Freq: 433Mhz Group: 210
POST…wait 10s
‘+++’ then [Enter] for RF config mode
CT 1 Cal 90.90
CT 2 Cal 90.90
CT 3 Cal 90.90
CT 4 Cal 16.67
RMS Voltage on AC-AC is: ~1V
AC-AC NOT detected - Apparent Pwr measure enabled
Assuming VRMS: 230V
Assuming power from batt / 5V USB - power save enabled
NO CT’s detected
No temperature sensor
CT1 CT2 CT3 CT4 VRMS/BATT PULSE
ct1:18393,ct2:0,ct3:0,ct4:0,vrms:503,pulse:0
ct1:3626,ct2:0,ct3:0,ct4:0,vrms:509,pulse:0
ct1:714,ct2:0,ct3:0,ct4:0,vrms:507,pulse:0
ct1:140,ct2:0,ct3:0,ct4:0,vrms:508,pulse:0
ct1:27,ct2:0,ct3:0,ct4:0,vrms:504,pulse:0
ct1:5,ct2:0,ct3:0,ct4:0,vrms:500,pulse:0
ct1:1,ct2:0,ct3:0,ct4:0,vrms:504,pulse:0
ct1:0,ct2:0,ct3:0,ct4:0,vrms:510,pulse:0
ct1:0,ct2:0,ct3:0,ct4:0,vrms:512,pulse:0
Just remember that if you changed the sketch nodeID, you’ve change the values the DIP switch on/off will use.
Here’s the two lines of code from the sketch that manage the nodeID (from src.ino on github):
byte nodeID = 8; // emonTx RFM12B node ID
if (digitalRead(DIP_switch1)==LOW) nodeID--; // IF DIP switch 1 is switched on then subtract 1 from nodeID
That is what allows the DIP switch to change the nodeID from 8 to 7. If the DIP switch is off, nodeID is 8.
If you have changed that first line from byte nodeID = 8;
to byte nodeID = 7;
, then turning the DIP switch to ON will cause your nodeID to switch from 7 to 6.
It isn’t what your problem is currently, but just putting it here in case you’re having issues with a weird nodeID 6 device appearing some time in the future
That looks correct and indicates you’ve got nodeID set to 7. Is it showing up in emonCMS now?
The CT1 values falling away is normal - it’s the pre-loaded filter decaying to zero because the input is shorted to ground.
You should have a Node 7 definition in your emonhub.conf file already. It is exactly the same as Node 8 and the Node 8 one at line 58 in the sketch. If this emonTx hasn’t appeared, that is the next thing to check - though it will appear in the log whether or not the config is present and correct.
Node 6 would appear, but only the powers and voltage would be interpreted correctly.
I reinstalled the unit in the garage, powered using AC-AC. Red Led flashing every 10 sec or so.
Still does not appear in the log or on emoncms. Tried resetting the emonTx and the emonPi but no change.
Let’s recap, because I’m losing the plot:
You bought two emonTx’s from the shop. Let’s call them the working one (the one that is Node 8) and the non-working one. Did you try both before doing anything else with them?
Then you loaded the 3-phase sketch - into one or both, and if one, which?
Then there was a change of plan. Which sketch do you have in the working emonTx?
Let’s just kill one postulate. Loading a part-sketch shouldn’t cause physical damage, so I don’t think
has anything to do with the problem.
There’s only one possible way that I can think that you can damage the hardware, and that’s to run the RFM69CW at full power without an antenna. If that’s happened, the output stage may well have been damaged, which would explain why it’s (apparently) not transmitting. But even that’s not likely, because the power level is set well down - 6dB below maximum to the same as the RFM12B - in the 3-phase sketch.
You and me both, really appreciate all the help so far!
I bought 2 x emonTx and 1 x emonPi from the shop. All were working fine in the garage as installed, on a phase each. At first I could only see one emonTx (Node 8) and not the other, so I moved DIP switch 1 to the on position and could then see it in emoncms etc.
Some strange results (5VRMS etc., Zero load on one of the phases) but all working ok so I was unsure if they needed the 3 phase sketch. I have since found there was a wiring issue, one of the phases wasn’t being used by any of the circuits, hence no load and weird voltage reading.
I decided adding the 3 phase sketch would give me more measuring options using 2 x emonTx in the garage, one using the standard sketch and the other using the 3 phase sketch, with the emonPi inside the house measuring an additional 2 circuits. EmonTx (Node 8) has remained as purchased, no modifications. EmonTx (Node 7) was the one I installed a part complete 3 phase sketch onto (by mistake really…) and since then has not been visible on emoncms since.
EmonTx(Node 7) now has the original sketch uploaded back on it from here;
I put DIP switch 1 back to off and changed the Node Id to 7 in the sketch and uploaded it. This appears to be working fine, emonTx(Node 7) red LED is flashing every 10 seconds, powered via AC-AC adaptor but not transmitting of some reason.
Is it possible the hardware has been damaged by uninstalling/re installing so many times in the garage? I presume they are fairly robust unless you hoof them across the driveway (I have thought about it but not done that as yet…)
If you saw the treatment the units I’ve got here get, you wouldn’t even consider that! No, unless you’ve been really heavy-handed, I doubt that simply moving one about would cause damage.
I’m beginning to think that the problem is the RFM69CW. The normal failure mode is it doesn’t respond at all, therefore the sketch hangs with the LED on and doesn’t get through initialisation. I think I’d try touching all the soldered joints on the module with a hot iron, just in case one is iffy. And check the aerial socket too. If that doesn’t work, I think you need to contact the shop.
But I’m intrigued by what you mean by
though I can’t see how that could cause any damage. Mine had plenty of half-complete sketch to contend with while I was developing it.
Is there a way to test the aerial socket?
I will check the joints and put the iron over them just to be sure.
It was the full 3 phase sketch but unmodified from the initial version, so I hadn’t set any of the parameters. My internet has been playing up for about a week so the machine was hanging, when it woke back up I had obviously clicked upload somehow by mistake on the IDE. After that it had no red LED so I assumed something had gone wrong and uploaded back to factory sketch.
Write that off as a red herring. The default sketch would “work”, just not correctly. At worst, with the wrong radio specified, it would hang.
I have just ordered another emonTx so I can at least get the whole system up and running.
If I can fix the other one then I can use this to monitor individual house circuits which would be useful.
So, is there a way to test aerial socket?