I’m trying to work out why my new emontx keeps crashing. It’ll work for a day or couple of days then stop sending updates. Alas I can’t see any logs being sent to the emonpi from it unless I’m missing something?
Absolutely nothing unusual is going on when it dies - the last update currently was 22 hours ago, so about 6pm… maybe slightly increased power usage when I got home from work? Only a power cycle seems to fix it… there are no lights showing (the blue light goes out a few seconds after power cycling and doesn’t appear to come back on).
I don’t think the emonTx has a blue light anywhere?
And to answer the question, the emonTx only sends data to the emonPi (via the GSM radio), it does not store any data, nor send any other information.
Both @TrystanLea and I tested the new library extensively before it was released (I’m guessing that you bought your emonTx after 18th October just gone), but the sketch I used isn’t the one that’s factory-loaded in the emonTx.
3 c.t’s, a recently purchased emonTx feeding to an emonpi in another room (which has been running without issue for years, but I needed 3 inputs so switched to this configuration).
The AC adapter was supplied with the emonpi… it’s an IdealPower model DB-06-09. It says its output is ‘9VAC Max. 6VA’
Since adding the USB supply the emontx has so far been stable.
I note the AC voltage around here is all over the place (15v variation in a few minutes sometimes) but I wouldn’t expect that to be an issue assuming the emontx is just deriving 5vdc from it… I’d never have even noticed if I hadn’t started graphing it
That might turn out to be significant. The a.c. adapter actually goes directly to the 3.3 V supply, but in order to minimise the amount it disturbs the waveform that is being measured, there’s a very delicate balancing act between getting enough power to operate the emonTx and not drawing so much current that the wave shape is distorted too much.
Even powering with the AC adapter now the emontx is crashing every few days. It seems to be getting worse… I’ve given up at this point… will have to try to go back to just the emonpi, which doesn’t have enough inputs but is reliable.
I’ve been running extensive test but I’ve so far been unable to pin down the cause, other than it is happening during the process of transmitting the data.
I’ve also been testing a slightly modified version of the demo sketch (that comes bundled with the emonLibCM library) but using the “transmit-only” code lifted from the 3-phase sketch in place of the complete JeeLib - and that appears to be rock solid. As I write, it’s sent 173331 messages without resetting or locking up - just before the holiday it reached 525190 messages until I got fed up of waiting for it to fail, so I recommend you try that approach.
My tests with the power supply failed to make it lock up - every time, it recovered gracefully with only the message count and energy accumulators reset to zero as evidence.
No, nor won’t be from me, I’m afraid. However, you’ll be pleased to learn that it’s run for the equivalent of over 400 days in normal usage without failing, I’m now testing it with a slightly improved “rfm.ino” and that so far had sent nearly 250,000 messages without a problem.
Unfortunately this doesn’t apply as described. You can’t define RF12_433MHZ as empty because of the line byte RF_freq = RF12_433MHZ; which needs a value. All the other RF12_ values need defining too as they’re read in various places in config.ino. However this breaks rfm.ino which treats them as flags.
I’ve compiled it by hacking out lines until I could get it to compile, but no idea if it still actually works. A pull request would have been many times easier to deal with… but whatever…