Can anybody tell me what's happened here?

Due to the help of a few people in a previous thread, I got my initial OEM setup working a few days ago. I’d been getting happily obsessed with watching the graphs etc, and was ready to introduce the system to my solar inverter. But, upon checking today, I noticed the following :

My initial thought was that something had upset the RFM69Pi board or similar. Or that EmonHub had simply stopped functioning. I checked the board visually, and actually restarted the EmonHub service, to no improvement.

Then I ran up Minicom to see if values were still streaming in… And they are, but there’re a whole lot of nonsense…

Remember - just a few days ago they looked much better :

Anybody got any ideas? Has my EmonTx just lost its marbles? Should I reset it? Is this typical of some kind of failure?

Ok, little update (not sure why this only occurred to me after posting the above). I realised that the EmonTX’s light had stopped flashing. So I did pull the power and reapply it. Then it did its boot-up sequence and started flashing. So it looks like maybe something upset it, and it just gave up for a bit.

Now looking in Minicom I do see at least some “OK” rows :

However even after quite a bit of time, I spotted that it was still saying 2.1 days since the last update. Finally restarting EmonHub service did clear this and bring in a recent last updated (8 seconds).

Can anyone throw some light here on :

a) what may have happened to upset EmonTX?
b) are all the other rows interference from other 433 devices?
c) is this something ‘commonplace’ simply requiring a restart of the EmonTX? If so, that doesn’t feel particularly great!

Cheers, and apologies for replying my own post. But sometimes I think asking for help makes you re-examine the problem and sometimes even partially solve it oneself… and this seems to be what happened here.

Hm, but now the plot thickens further :

13 mins since last update?!

But when I check minicom there do appear to be valid entries :

I’m lost now!

Again, doing a sudo emonhub restart has brought them back up to date. But it’s weird that this worked for 3+ days absolutely fine, then now has had (what appears to be) an EmonTX lockup problem and also now seems flakey generally on the EmonHub side.

What are you seeing in the emoncms.log and emonhub.log?

What are you using for a power supply to the emonTx? If the mains voltage dropped sufficiently, that could well cause the emonTx to fail. If you have a 5 V d.c. USB supply, try powering te emonTx with that.

Has anyone nearby got another transmitter on the same frequency? This would explain the low level (-90 dBm) ‘rubbish’ that you’re seeing. (It might have started up recently, or it could well have been there for some time and you didn’t see it.)

I’ll have a poke through those. I ought to have done that really before posting. Mea culpa!

Thanks!

I have a bunch of temperature and humidity sensors on 433 also. What I’m a little puzzled by is that I don’t think I’ve moved those, and yet they are now being picked up by the RFM69Pi. Bit odd.

On the powering… Is it generally recommended to “dual power” the EmonTX? I.e. one 5v stable DC source and one 9v AC for voltage monitoring? I currently only have the 9v AC<>AC one. I wonder if that is perhaps not the most stable way of powering it.

Ta.

It’s radio; odd is normal :slight_smile:
It might be any slight movement of the antenna, or movement of something unconnected but nearby, or just a change in the weather.

If you just have CT’s connected to the emonTx then using an AC supply to power it should be fine. If you have more than one temperature sensor connected to it, then you need a DC USB supply as well. I can’t find that section in the docs right now - it seems to be well hidden.

(I looked in Adding to an existing install — OpenEnergyMonitor 0.0.1 documentation System Overview — OpenEnergyMonitor 0.0.1 documentation)

Ah found it, it’s buried in emonTx3 User Guide — OpenEnergyMonitor 0.0.1 documentation

That’s not exactly true. The a.c. adapter won’t go down to the absolute minimum supply voltage given a set of worst-case components. That’s why I asked. (If you want to know, I designed it for the emonTx with the RFM12B module, and the design was transferred to the RFM69CW without regard to the higher transmit current that the latter demands.)
If the problem persists, I recommend trying with a separate 5 V power supply, and use the a.c. purely as the voltage monitoring input.

Then the wiki should reflect that, not state what it does.