Yesterday the emonBase went offline. I couldn’t connect to emoncms nor could I ping or SSH to the unit.
This morning it was the same. There were no lights on the RJ45 LAN socket. Since I don’t have a console connected to the device, I had to pull the power. I took the opportunity to take off the lid. The exposed copper end of the aerial cable appeared to be touching one of the GPIO pins. So I put a bit of tape over the end.
I removed the rfm card & had a look. It’s possible that the aerial solder point on the underside of the board may have been touching a GPOI pin. Just to be sure I put some tape over the solder joint.
I put it all back together, plugged in the LAN & power & it all came back up.
When I connected to emoncms I noticed that it had actually been recording data right up to the moment I pulled the power. So it wasn’t totally dead, it was just the LAN that was down?
I’ll see how it goes for a few days now that it’s been taped up.
Interesting - I have an emonPi using the old WiFi USB dongle that loses the WiFi connection. Pulling the dongle out, waiting a moment or two and then replacing it restores the WiFi, and the Pi and emonHub/emonCMS carry on regardless throughout. It’s probably not related, but worth mentioning.
[When I replaced the Pi’s OS/emonCMS with the July 20 version, I didn’t do anything special for the WiFi dongle, which is the original shop Edimax (?) one.]
Apologies Paul but I didn’t read your reply properly until after I had removed the RFM module & connected the devices together. So I never checked the LED inside 
.
I connected the devices directly because after taping up the exposed metal parts of the RFM last weekend, it only stayed up for 12 hours then connection was lost again.
The devices are now communicating via direct connection (once I got past the issue with using /dev/serial0 instead of /dev/ttyUSB0 it was quite easy).
I seem to have lost a lot of sensor options with the new config (see the screenshots). However, this doesn’t bother me yet as I’m only using the CTs for input.
I did take a look at the interfacer files to maybe sort the lack of sensor inputs myself. But I soon gave this up because I don’t know Python (nor do I really know what I’m doing yet).
I’ll leave it running now to see if it stays up.
Can you clarify that?
Hi Robert
If you look at the screenshot, the top input is what I have now (only 3 power sensors and no temperature sensors).
The lower one that I was using when I used the RFM module had many more options.
If you look at the sketch, you’ll see that it only sends the values to the serial port if the input is in use. So I presume you don’t have CT4 or a temperature sensor connected. If you put a 3.5 mm plug (any 3.5 mm plug) into the CT4 input, connect/plug in a temperature sensor and then reset/restart the emonTx, the new inputs should appear.
This is all still very new to me, so I’m probably talking rubbish. However, when I was using the RFM connection, the input was called emontx3cm15. In emoncms this showed all of the sensors, as shown in the screen shot (whether they were in use or not).
I am now using the input called “0”. This input shows fewer sensors. As I’ve said this is not an issue at present.
However once I get Solar panels & some temperature sensors it might be.
Yes, but you are using a different method of connection between the emonTx and your emonBase. The emonTx is SENDING different information in each case. Specifically, the radio sends all the data every time so that the names can be matched at the receiving end; the serial connection (because the variable name is attached to each data item) doesn’t need to send everything, it only sends the things that are in use.
When the message was sent by radio, it was tagged with the Node ID “15” at source in the emonTx. EmonHub translated that into “emontx3cm15”. Now that you’re receiving it directly into the RPi, it’s coming in via a different route minus the NodeID. You need to edit your interfacer (via the web browser and emonHub) according to this post: EmonTX to Rpi - Direct Serial Connection - #49 by borpin
If you want to continue to call it Node 15, you must delete that node definition lower down the file in the [nodes] section.
Before you delete Node 15, look at it - that’s where the names get attached to the values that come in by radio.
To be clear, this is not editing the Python but the emonhub config file.
The Input NodeID actually doesn’t matter, it is where the input processing puts the data and you can just use your old feeds if you like.
Thanks all for your patience. As I said this is all new to me. From what I’ve read, I had no idea (until now) that the data sent via RF was any different to the data sent via direct connection.
I experimented this morning, adding a fourth CT to the emonTX and rebooted the systems. The new input did not show up . So I now know it’s not an automatic process.
Yesterday, I did actually try editing emonhub.conf to get the additional inputs to show up.
Since my serially connected emonTX now seemed to be identified as Node “0” instead of 15, I copied the entry for [[15]] and created and pasted it as [[0]], …
[[0]]
nodename = SerialTx3e
[[[rx]]]
names = MSG, Vrms, P1, P2, P3, P4, E1, E2, E3, E4, T1, T2, T3, pulse
datacodes = L,h,h,h,h,h,l,l,l,l,h,h,h,L
scales = 1,0.01,1,1,1,1,1,1,1,1,0.01,0.01,0.01,1
units = n,V,W,W,W,W,Wh,Wh,Wh,Wh,C,C,C,p
whitening = 1
This broke it completely 
.
I reverted the change & it all worked again.
As I said, I’m still learning what’s what. There’s nothing like a bit of experimenting and finding out for yourself 
.
I’ve never used a Raspberry Pi before let alone all the additional EMS software. So I have a lot to learn!
I would be interested to know what changes to make to the emonhub.conf file to pick up the additional inputs related to the serially connected emonTX. I tried simply changing the nodeoffset value to 15, but this didn’t work
I think I’m OK with linking inputs to feeds. It’s getting the additional inputs to show up that is the issue.
It was all new to me once, so I know how you feel. And I had a big advantage then - there wasn’t quite so much to learn. We’re used to helping people climb the learning curve, so don’t worry about it. This isn’t a certain other web forum that I could mention.
CT 4 should have appeared when you connected it - provided that you did it in the order you said, connect the c.t, then restart the emonTx. You don’t need to reboot the Pi for that, and I don’t think you need to restart emonhub either.
If that’s what you did and it didn’t show up, I can’t think of a good reason why not. I haven’t got an emonTx V3.4 free so I can’t set up an emonTx and emonBase with exactly the same software as you have at present, so I can’t test it.
If you’ve got a programmer, and connect that instead of the Pi, you should see “P4” and “E4” appear when CT4 is plugged in - but new inputs (voltage, current & temperature) are only recognised on a restart or power-up, so plug them in and they’ll be ignored until you restart the sketch. That’s the only test that I can think of.
I just power cycled the emonTX again and restarted the emonhub daemon & P4 & E4 have appeared!
Not sure what happened earlier, probably finger trouble. But I’m all good now.
Thanks for all the help.