EmonTx stops sending data - no led activity until reboot

Hi there, first post.

Just bought an emonTx V3, sending data (4xSCT13 and AC-AC sensor) to my Pi3 with RFM69Pi, using pre-loaded SD card. Planning to monitor EV charging and going to buy/build an openevse charger as soon as I can fix issues (my goal is solar PV diversion for EV charging).

So, after initial emoncms setup and emontx wiring everything worked fine in the beginning. After a few days I had to reboot the emonTx since it stopeed sending data. Then again the following day. And again. Swapped the AC-AC with another one, and again same failure. Added an usb power supply and after a few more days still frozen.

As soon as I replug the power adapter I get data logged on emoncms. Rebooting the raspberry doesn’t solve issues.

What should I try next? I have access to a battery holder and a usb to serial programmer too. Unsure if it’s a malfunctioning unit or something I’m doing wrong.

Thank you for your help

Giovanni

There have been a couple of similar reports. The suggestion by @Robert.Wall is to add a 5V USB supply. Note the comment on the jumper.

Thanks for the report @paganig as @borpin mentioned we are currently investigating this issue.

If you are happy to compile and upload firmware it would be interesting to hear if the following addition of a watchdog to the firmware fixes the issue for you https://github.com/openenergymonitor/EmonTxV3CM/tree/watchdog

While it doesnt fix the underlying issue which we are still trying to get to the bottom of, it should mean the EmonTx recovers, you will be able to see the number of times the EmonTx resets if you record the ‘Msg’ message count to a feed.

@paganig we’ve now released a new version of the EmonTx firmware that includes the watchdog feature. If you are able to upload it to your EmonTx to test that would be great. If you can record the Msg count input alongside mains voltage that would be great. It would be really useful if you can report the number of times the Msg count resets over time and the voltage at these times so that we can better understand whats causing this issue.

The other perhaps more likely cause of this issue is related to the firmware for the radio module on the EmonTx, if you are aware of any RF events that might be interfeering with the EmonTx, e.g other 433MHz devices in the home, that correlate with the crashes please let us know.

Thank you all for your suggestions.
Removed jumper, after one week It stopped working again, at 3am, so no other 433mhz devices active (garage door opener is the closest 433mhz remote). Github links returns a 404 error, I’ll try to update in the next days

Source code is here: GitHub - openenergymonitor/EmonTxV3CM: EmonTxV3 Continuous Monitoring Firmware (Default shipped EmonTxV3 firmware)

The watchdog timer is in release 1.3: GitHub - openenergymonitor/EmonTxV3CM at 1.3.0

There is a later release Releases · openenergymonitor/EmonTxV3CM · GitHub

I think I might be having the same problem - my new emonTX 3.4 stopped working at 9pm last night, 6 days after it was setup. It’s powered using the AC-AC adaptor from the shop, and is monitoring one CT clamp and DS18B20 all from the OEM shop. When I checked the emonTX this morning and connected via USB/UART cable, it woke up and started transmitting straight away. The emonTX is currently running v1.2 which doesn’t flash the LED every 10 seconds, so harder to tell when it’s working or not working. I’ll try loading the new 1.4 code and monitor.

I’ve now updated my emonTX to use continuous monitoring v1.4 and will monitor the status.
I had hoped I could just upload the v1.4 firmware.hex file that @borpin flagged in post #7, and after eventually getting this uploaded using avrdude on Windows 10, it showed version number 1.20 !
So I downloaded and compiled using Arduino IDE, uploaded to the emonTX via USB/UART and this time it showed as v1.4.0. Fingers crossed.

I have raised the versioning as an Issue.

Hi
Same problem here
Did you solve updating emontx ?
Never had problem for about 6 8 month, now just started :disappointed_relieved:
Thx

Emonpi updated to 10.1.13 but image of 2017. I need to reboot emontx to solve. Reboot emonpi not solve

No new 433 gadget installed in my house recently

Could it be related to big change apported in emonpi ? May be after 10.1 ?

Hi
Now just passed exactly a week and on the same hour 6.00 am empontx stop is offline… no more data sent no more red light.
I have all 4 sensor attached
Hope this help to solve
Emonpi works

Hi Lord_valex,
Since I updated to the continuous sampling sketch, my emonTX has not locked up. However it’s only been 2 weeks, so it’s still early days.

Thx I will try when I will recive necessary equipment from the shop
Please let me know your news

I am actively trying to trace the cause of the problem. It seems to be connected with the radio transmitter, but what the exact mechanism is that causes the sketch to either reset or to lock up has not yet been found.

2 Likes

I have substituted the code in the file “rfm.ino” from the 3-phase sketch, instead of using JeeLib. Reporting once per second, it has now run for about 3½ days - equivalent to about a month of normal use - with no issues. I have not, however, found the true source of the problem.

Those of you suffering lock-ups may wish to try this.

Instructions to replace JeeLib.

Caution: The following instructions will remove some of the functions of the JeeLib library - in particular, the part that prevents the transmitter from sending its payload whilst the radio channel is in use. Therefore, it is possible that an emonTx so modified will ‘jam’ any other node, causing the data from both to be corrupted and lost. It is only safe to do this change if the emonTx is the only sensor node in use.

1.  If you have customised your emonTx sketch, ensure you have a copy.

2.  Download “rfm.ino” which is part of the emonTx 3-phase sketch. GitHub - openenergymonitor/emontx-3phase: emonTx 'approximate' 3-phase firmware

3.  Put “rfm.ino” in the same directory as your emonTx sketch.

4.  Open the Arduino IDE and navigate to that directory. You should see a tab for each file in the main window.

5.  In your emonTx sketch, make the following changes (you may wish to comment out rather than delete)

delete #include <JeeLib.h>
add:

#include <Wire.h>
#include <SPI.h>
#include <util/crc16.h>
#include <OneWire.h>

add above void setup() (change the 2nd line below to #define RF12_868MHZ if appropriate):

#define RFM69CW
#define RF12_433MHZ
#define RFMSELPIN 10
#define RFMIRQPIN 2
#define RFPWR 0x99

delete rf12_initialize(nodeID, RF_freq, networkGroup);
and replace that with:
rfm_init();

delete rf12_sendNow(0, &tmp, sizeof tmp);
and replace that with:
rfm_send((byte *)&emontx, sizeof(emontx), networkGroup, nodeID);
(or rfm_send((byte *)&tmp, sizeof(tmp), networkGroup, nodeID); if the original line had tmp instead of emontx)
(two instances)

delete rf12_sendWait(2);

if present, delete

  else
    rf12_recvDone();

6.  Compile and upload to your emonTx.

1 Like

An update:

I stopped the test using the transmit-only code after 6 days and 525000 data transmissions at 1 s intervals, representing almost 2 months at the normal rate. No lockups and no resets occurred.

1 Like

This was because the platformio was using an incorrect tag.

Fixed in the Master release - might be worth updating as there have been some changes.