In the process of moving my monitoring over from a legacy system to the above kit (with the main driver being upload of my three PV systems to pvOutput but with the additional monitoring the new kit will provide) and I’m having an issue with the transmission interval between my two emonTX units and the emonBase unit.
It varies from around 10s to over 2 minutes if I monitor the feed display. I’ve now moved the emonBase from a wired network connection into a hub next to my computer etc. to less than 15cm away from the tx units (so moving from wired ethernet to wireless) but it doesn’t seem to have made any difference at all to the frequency of updates. So my conclusion is that it isn’t down to proximity (at least) with the 433mHz signal.
Am I missing some configuration thing or is it always just as random?
The interval - if you’re using the sketch that was the default prior to last October - should be a little under 10 s. For the sketch that has been the default since then, it’s exactly 10 s. It’s definitely not random. The connection between the emonBase and your network should not have any effect - the emonTx does not receive any information from anywhere.
The immediate possibility that I can think of is both emonTx’s are transmitting their data at exactly the same time, so each is jamming the other and the resulting data as received by the emonBase is scrambled and rejected. What does the emonhub log reveal? You could try restarting them 5 seconds apart, that would - for a while at least - remove the possibility of mutual jamming.
The second possibility is there’s another transmitter on 433 MHz that’s jamming them - possibly not anything to do with you.
Does your emonBase show the RSSI for each emonTx, when the data gets through? There shouldn’t be a problem if it’s better than -80 dB, there might be a problem with the signal being too strong with only 150 mm between transmitter and receiver.
As far as I know, there hasn’t yet been a sketch published that allows you to change the reporting interval without editing and reloading the sketch.
I’m using the kit without modification in the last month so I’m assuming it’s the latest whatever.
As I mentioned, I’m relocating from an exiting (Current Cost) pvOutput upload solution so whether that kit interferes with the new stuff I haven’t got a clue. I was hoping to get the new stuff up and running before pulling the plug on the old.
I have some CurrentCost sensors in use here and each transmits on 433MHz approximately every 5 to 6 seconds (it’s presumably randomised to reduce the chance of repeated collisions). So it does have the potential to interfere with your new stuff (and vice versa). If signal strengths are similar a collision will likely result in loss of both messages but a stronger signal should successfully override a weak one.
Finally got my finger out to modify some existing Python to upload my three PV systems to PVOutput and removed the CurrentCost kit completely. That significantly reduced the packets that were being discarded by emonBase. Moving the unit closer to the tx modules and using WiFi rather than a directly wired connection from my desk also bumped the RSSI values received (now about -27) so that I’m not missing anything now.
There is still something transmitting on the frequency (RSSI of around -100dB) but I haven’t yet tracked it down and it doesn’t appear to be interfering with the tx packets.
I do have an Immersun 2 plus myimmersun bridge so it might be that and if it is, nothing can be done anyway.
