Yes. Both units are emonTxv4s
Just because emonhub is not receiving the data, doesn’t mean the TX is posting sporadically.
First question - are both TX4s green LED flashing at ~10s intervals?
Second, are they flashing at the same time? If so try and make it so they flash at different times.
Third, are they in close proximity to each other and/or the emonBase?
Most likely issue is that there is RF clash (yes I know in theory the new code should help that).
Best solution would be to connect one by USB and the other by RF (or both by USB). Alternatively, get a Wi-Fi module for one of them.
@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.
@TrystanLea
Which sketch is @grod55 likely to have had in his emonTx4s?
@glyn.hudson can you answer Robert’s question on the sketch version? This is the new emonTX4 that I just received from you.
Robert, et al, I am going to add a 3rd emonTX4 to see if it has similar issues or not.
Not sensible, bearing in mind the other thread Null Data and Wireless where @grod55 said he wanted to move from Wi-Fi to ISM band.
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)
I converted Nodes 18 and 19 from wifi - both of which are working fine. The new ISM emonTX4 is Node 17 and is the one giving me problems.
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
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:
- l list the settings
- r restore sketch defaults
- s save settings to EEPROM
- v show firmware version
- z zero energy values
- x exit, lock and continue