Back when I originally set up my system there was a problem with the connection dropping between EmonPi and EmonTX. This was resolved with help on the old forum (here and here). I’ve not been back on the forum for months as the set up was stable (EmonPi firmware 2.5, EmonCMS vlow-write-8.5).
Over the last week, the connection has been dropping again on a very regular basis. The only difference in conditions is the temperature of the EmonPi itself. When the temperature drops below 7degC the connection is unstable (but I don’t think the signal strength is down: -80 v -78 before). It can be immediately re-established by changing the GroupID in the config editor, saving and then changing back again. The data then flows again for a variable length of time.
Coming back to the forum, and everything has changed! Lots of new releases of firmware and EmonCMS. Having spent an hour or so trying to work out how safely to upgrade via the forum and main site pages, I still have not worked out how to do so. I’m sure all the details are there somewhere, but for a casual end-user, its not easy to work out what to do.
I’ll probably order the new SD card to short cut a lot of this. However, to get to the question (at last!!), I’d appreciate the expert view on whether the updates are likely to sort this issue, given that it appears to be environmentally triggered.
Not an expert but a signal strength of -78 (rssi value ?) means your parts are far away from each other or there is something really interfering. -78 is pretty low signal strength.
The other element you mention : temperature … I don’t think a radio signal is that much affected by it (a HAM expert might shed some light on that) but maybe there is some micro crack on a board circuit that ‘opens’ when the temp goes down ?? This is more a wild guess then an affirmation though …
Yes RSSI. Solar inverter is in garage, way away from the EmonTx and through several walls. Maybe I need to work out how to use an EmonBase and a direct ethernet connection (garage is network cabled), but trying to minimise background power use.
How close to the first wall is the emonTx? Is it possible to run a short co-axial cable through the wall to an antenna on the other side?
Or is it possible to extend the CT cable, relocate (or extend) the ac adapter (if you’re using one) and move the emonTx into a more favourable position?
Thanks for the suggestion… Not easy, I’m afraid. Might just be possible with the EmonPi aerial. After 8 months of continuous connection, however, I’d still like to understand why the current issues with the link.
Sorry to hear your having issues. Very interesting to hear that after 8 months of continuous operation the emonTx has started dropping off with the only thing you can think of that’s changes is the temperature. I don’t think temperature would affect RF transmission, but then again…maybe there is a link.
I’d go along with @glyn.hudson on the temperature question.
Could it be moisture on or moisture content in one of the (many) walls? A damp wall will start to look like a conducting sheet, and reflect the signal off it rather than allowing it to pass through. 8 months ago was April, when everything was starting to dry out? I’m not saying that is the cause, but it could certainly contribute.
The other thing you could look at is lowering the data rate of the transmissions. That’s a fairly complicated procedure as you need some non-standard programming at both ends of the link, but it’s been reported as being effective in marginal conditions, which is what looks to be the case for you.
@Bill.Thomson knows more about rf than I do, maybe he’s got a suggestion?
Don’t think it is the water content of the walls: much higher at many times this year but I see the point. The temperature is rising (6.9degC tonight). I guess this next few days of milder weather will be instructive. I’m not a programmer, so that is not an option for me I’m afraid.
But why does changing the GroupID away and back again restore operation? Or was that a coincidence?
When is the GroupID read from the config file? Is it possible that the Pi is seeing a power supply disturbance that’s enough to corrupt some memory but not enough to cause a restart? Have you checked the 5 V to the Pi?
I was thrown by this symptom when it was mentioned previously, I don’t think the changing of the group id actually has anything to do with the group id itself, the same effect should be achievable by changing to 868MHz and back to 433MHz or swapping out the baseid and back, it’s the forcing of an rf12_initialise() trick that gets the rfm going on locked rfm devices. BUT it’s reported this emonPi is running a v2.5 firmware which is where Glyn introduced the “reinitialise every 60secs regardless” watchdog hack, so the effect of “reset by changing groupid” is should be happening every 60secs anyways???
My theory on this was that a partial brown out could be stalling the RFM due to loss of settings if the RFM is more susceptible. it is unlikely to be AVR memory corruption as previous tests on this have shown any one of the 3 settings can nudge the rfm back to life, so it is assumed the other 2 of the 3 settings are safely held in RAM still as all 3 are written to the RFM in one call and it always restarts the rfm.
The fact the device in question is right at the end of the RSSI range at best (-78) it would not take much for this to pass in and out of “acceptable range” I believe (from memory) -80 or -82 is the threshold and anything outside that will be “discarded”.
The fact this has been good all summer and now dropping out, could be a seasonal or minor lifestyle change, e.g. closing doors and windows due to cooler weather or running more electrics e.g. heating or fluorescent lighting. I noticed a comment at the end of one of the previous threads possibly said tongue in cheek, but could well be true.
@AndyS - Is there any way you can get the RSSI up for a test period? perhaps some less convenient positioning to get them closer or in a better line? could the Pi be taken closer to the emontx for few days?
Thanks for all the thinking going on. The usage in and around the house has not changed significantly, certainly not within the week when the dropouts started again. Heating is obviously on, but so it was when the 2.5 firmware solved the problem. External air temp does not seen to be the problem, it seems have started as the internal temp in the garage (and hence of the EmonPi) dropped. Also, the drop in connection appears at any time of day or night and may be minutes or hours after resetting the
There is no easy way to move either the EmonPi or the EmonTx without significant impact on walls or premise security, I’m afraid. I’m going to try and find some connectors so I can move the receiver on the EmonPi outside the garage wall via some coax as suggested by @Robert.Wall.
Been stable today with RSSI still -80, temp 8.6degC in garage!
Another option might be to update the emonPi firmware to v2.8.1 as that now includes the ability to see “discarded packets” so it may be possible to confirm if this is a simple range issue as any packets received with an RSSI that doesn’t meet the threshold will still be visable in the emonhub.log despite being discarded and not passed to emoncms.
It can also highlight a number of other problems eg if the packet is being corrupted or if anything at all is being received etc.
Paul, on the old forum there were a number of threads relating to lost comms and towards the end there was a list of things to make sure we’re OK before blaming the software.
From memory, make sure the Pi power supply is OK and has sufficient umph - replace it with a good one and see if the problem persiats, then make sure the rfm module is seated properly and not making contact with other Pi pins. I think there were some more things but it might be a good idea to let posters know about these things to check before you get inundated with possibly spurious issues.
Indeed these are good things to check. However in this instance the device is an emonPi which will not have the same issue with the gpio connector seating and the suggestion to change the firmware is only to give us better tools for debugging rather than suspecting it is at fault. but it is always wise to check the basics first
Apologies Paul hadn’t checked back to the original post. Just thought in view of the number of posts recently in this area it would be good to revive the advice - if only to save you debugging non existent issues in the code.
Just an update: I’ve been letting this run and have been monitoring. Until Boxing day the connection was stable, with RSSI from -74 to -83 as far as the node display in Emoncms is concerned. The garage temperature dropped below 7degC again early yesterday, and the connection has again become unstable. The RSSI for the node shown when the connection is absent can be anywhere in the range above, but I guess that is for the last successful packet received. Interestingly, a Node 0 has appeared in the node list with an RSSI of -104: there is no Node 0 hardware on my site. This did not appear at the same time as the connection failure.
I have acquired a 1m extension cable which should allow me to move the antenna on the EmonPi into protected open air under the eaves of the garage, as per suggestion of @Robert.Wall. If anyone can comment on whether the likely additional gain is going to be offset by the cable loss, that would be interesting to hear. If this cures the issues, then I’ll know it was a S/N issue. otherwise, I’ll do the firmware update or replace the SD card with the latest release.
