No. NodeID just tells you where it came from. (SImilarly ‘Group’ - it’s software and doesn’t prevent interference and clashes in the r.f. spectrum.) Everything of ours uses exactly the same frequency. You’d need a lot of details about the interfering source(s) to even try to move to a different frequency within the approved band.
Is it the door opener, only happens when you open/close the garage door? You haven’t said otherwise, so I’ve been thinking it happens all the time.
I don’t think it is the garage door opener as there has been no data for over 25 hours and I have used the garage door opener a few times today.
Is there a way to remove the listing from the local emonCMS? It does not show up in emoncms.org and I would like to remove it and then see if it comes back at any point in time. NOTE: I just removed it via the gear icon - will see if it comes back
This still leaves me with the issue of Node 17 reporting sporadically.
Would reflashing the firmware be a place to start?
This suggests a duff unit IMHO.
You can always remove unused/false Nodes from the Inputs page - just delete them. But that won’t stop it/them reappearing as soon as a interfering data gets past emonHub - which is where the problem lies. It’s a new problem created by the self-configure “feature”, hence my call to Trystan to be able to permanently disable it.
This means it has not completed the set-up routine - definitely re-upload the sketch.
I wanted confirmation of the default sketch. I think it’s going to be emontx4/firmware/EmonTxV4 at main · openenergymonitor/emontx4 · GitHub but I haven’t seen it written down anywhere.
I reloaded the firmware (same as is running on the other two emonTX4s - which is emontxv4-1-5-7-Irms-RF.hex - from Glyn). The red indicator light stayed on solid for about a minute after loading. I checked the serial settings and the local emonCMS and everything stayed configured correctly.
Still getting sporadic entries. Below are the RSSI values from all 3 emonTX4s as an example.
@glyn.hudson I am beginning to believe that this emonTXv4 is defective. How do I arrange for a replacement?
That’s not right.
Can you access the on-line calibration for the errant emonTx (Node 17) and reset it to the default values? If the reporting interval or anything else has been accidentally changed and saved to EEPROM, this will have survived reloading the sketch. The numbers above don’t fit this scenario, but it’s the last thing I can think of.
https://docs.openenergymonitor.org/emontx4/configuration.html#directly-via-serial
If there’s still so many missing values, I’d tend to agree with you that you have a faulty one - email The Shop at [email protected] and include a link back to this thread.
Hi Robert,
I will check this out when I return in a few days (it is the Thanksgiving holiday here in the USA). I did check the Indicator light before I left the house and it was back on solid red.
Will update you when I get back.
Thank you for your assistance.
In reading thru the doc, it looks like r is the only command I need to use to restore to default - correct?
I will do a list first to see what the Emon is currently set to so I have something to compare.
Thx
Available commands:
Yes, the ‘r’ command immediately wipes the EEPROM, then it restarts the processor. Having an empty EEPROM, it reads and starts with the default values in the sketch.
Hi Robert,
unfortunately doing the restore/reset function did not fix the problem.
I was able to do the reset and received the resetting message. Then I was able to update the CT settings and received confirmation that the changes were saved.
In looking at the logged data, I only received 16 out of 134, whereas the other 2 nodes reported 134 each for the same time slots.
Looks like I have a defective emonTX4.
Contacting the shop now.
thanks,
Gordon
To be honest, I had not expected it to do anything - but it was worth a try.
