I have an EmonPi which receives data from two EmonTx units, one for the house and one for the garage. The EmonTx in the house is a few metres from the EmonPi, and the connection is very good. On a OpenCMS graph, data quality is typically 99%.
The EmonTx in the garage sometimes works normally, but frequently fails to report data for long periods - sometimes hours at a time. Switching it off and on again doesn’t solve the problem. As this EmonTx is further from the EmonPi, I’ve been putting up with the data loss because I had assumed that the data loss was caused by either the distance or by interference from something outside the house.
However, I’ve just bought an additional EmonTh which I’ve put in the garage, and the EmonTh doesn’t experience much data loss. It’s possible that the EmonTx in the garage is faulty. Is there anything I can test to help track down the intermittent problem?
EmonPi (purchased in November 2016).
House EmonTx (v3, purchased in March 2017). RSSI is -44
Garage EmonTx (v3, purchased in November 2017). RSSI is currently -69.
Both EmonTx units are powered by the original AC adaptors that they were supplied with, and are running the original firmware.
An RSSI of -69 dB certainly should give a good signal on its own, my immediate thought is there’s a much nearer transmitter on the same channel that’s transmitting at approximately the same intervals. The time between transmissions is derived from the processor’s timebase, and that’s going to be fractionally different for each, and more to the point, it’s going to be temperature dependent. So the rates will differ slightly. If the two transmissions happen to overlap - as one catches up with and overtakes the other, then it’s probable that the stronger signal will overwhelm the weaker and it’ll get lost. (If the signal strengths were equal or nearly so, then I’d expect both to show data loss at about the same times, as each blocked the other.)
You could prove that by switching off the near emonTx - if you can do that while the Garage emonTx is “failing” and it immediately recovers, that’s a good indication that this is what is happening.
Do you have a programmer? If you have, you could try changing the rate of one by a small amount - in the present sketch, it’s set to 10 s - 100 ms ( = 9.9 s), but I’ve a feeling it might not be that in your emonTx’s. The data transmission takes approx 5.7 ms. If the two always differ by more than 5.7 ms but not a multiple of that, you should only lose the occasional message (about 6 in 10,000). I’d try reducing the time by about 5 ms and see whether it improves it. If it’s worse, reduce it by the same again, because you changed the slower one! Don’t be tempted to increase the time between readings, because that will give you problems with emonCMS substituting NULL values and discarding the data.
A more radical option would be to stop using the 433 RFM transmission and use Wi-Fi with either an ESP8266 or an old Pi or Pi Zero W and connect directly to the emonTX.