If you’re using JeeLib, that’s entirely possible. If you’d updated to my rfm69nTxLib, that checks that the band appears to be free before transmitting, and LPL will retransmit if it doesn’t get an acknowledgement.
I’m fairly certain @grod55 will be using LPL as they are emonTx4s (am I right? - I can’t tell from the log).
@borpin
What about the 61-byte data packets that emonHub is seeing?
They are being rejected by emonHub because they don’t fit the 40-byte Node definition, hence the NULL values being recorded.
But there are good packets being received in between.
So where are the bad ones coming from? I see these possibilities:
The emonTx sketch is going haywire.
The transmit half of the LPL library is going haywire.
The receive half of the LPL library is going haywire.
emonHub is going haywire.
There’s another transmitter on the channel, sending valid but not the expected data packets.
Ok. I added a 3rd emonTX4 and it is reporting fine. I am beginning to think that Node 17 is bad. Node 18 continues to report good, as does the new Node 19.
Wondering if I should reload the firmware on Node 17 - thoughts?
Before I added the 3rd node, I noticed that I have a new “device” showing up in my list of inputs. I have no idea what “73” is and it has not reported data over the past 23 hours. I am wondering if this is an interferer (signal strength is showing as -92) and it lists 61 inputs plus rssi. I’ve attached a print of the inputs. I do not see any reference to “73” in emonHub - so not sure what to make of this. Emoncms - input view.pdf (133.5 KB)
61 inputs (do you mean ‘bytes’) corresponds to the rejected messages i saw in your emonHub log.
Clearly an interfering signal from somewhere - do you have anything else that uses 433 MHz - alarm, garage door opener, doorbell? How far away is a neighbour who might have something like this?
@TrystanLea More trouble from your ‘auto-configure’ - it needs to be capable of being permanently disabled.
I have also noticed that the red indicator light on Nodes 18 and 19 flashes at regular intervals, but the red indicator light for Node 17 is on solid - not flashing at all. I swapped cables and that did not make any difference.
Then unplugging the cable and plugging it back in gets it to report, and then the light goes out and flashes at non-regular intervals.
I saw the 61 inputs listed on the input page of the local emonCMS (ie when you click on the header it usually shows P1, P2, P3, etc. - when I click on the header for this “device” it lists 1 thru 61 and then rssi at the end).
I have a garage door opener less than 20 feet away - would changing the node ID from 17 to something else (eg 20) change the channel away from any interferer?
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
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.
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?
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.
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.