For sometime now a gripe of mine has been the way emonTH sends 0 values on startup after a battery change, from the outside looking in, how can a device possibly report it’s battery value is 0v (for example).
I have since discovered this is the factory test where at boot time it transmits 10 0 values to test the rfm. Fair enough, we’re pleased it is being tested, but at what cost? Having all my data zeroed during a battery change means my data is compromised unless I go in and remove all the inaccurate data.
Recently playing with an emonpi, I have now discovered it does the same. I have node 5 in use else where and each time I power up my test/dev emonpi it transmits a load of zero’s causing issues for my node 5 as other emonBases catch that payload. I have now temporarily changed the group to 200 on the emonpi to avoid this issue, but this now means I do not receive any of my group 210 devices which would have been useful for testing/developing on the emonpi.
It would be good if we could NOT factory test every device everytime it is powered up after leaving the factory. 2 simple solution spring to mind.
make the test transmission a command that is issued during the factory test (or any other time one wants a test transmission)
if it MUST be fully automatic on first power up at the factory, make a flag in the eeprom that is set after the test transmission to prevent future test transmissions, this can be further enhanced by making a command that can reset that eeprom flag so that the test transmission will work when desirable, a factory reset if you like.
I really would prefer it if my emon devices only ever transmitted “0” if that was an actual reading, having code that sends zero’s for any other reason test, error or just confusion undermines the value of any and all genuine “0” readings as “0” no longer means “0”.
As does every emonTx - except that sends a count-down 10, 9, … 0, in rapid succession, in the first value of the r.f. packet, IIRC.
I can’t remember when it first appeared, but it’s been in the ‘stock’ sketches for quite a while. [Edit: since the emonTx V3.2 in February, 2015]
It’s ironic that we went to great lengths, in the days when the emonTx used the high-pass filter to remove the bias offset, to not transmit the false values generated as the filter settled, only to replace them with the factory test false values (albeit there’s only one transmission, not five or six over the first minute or so).
I thought it might but all my emontx’s use custom FW and I wasn’t going to search the sketch repos to find out. It really isn’t acceptable IMO to send 0 values that can compromise good data feeds, or worse, it could trigger an alarm or reactive action.
I understand the need, but here has to be a better way!
The easy way is, take a leaf out of your book: transmit the factory test on a different group. That just requires the shop to have a receiver dedicated to this purpose, set to that group.
That is so easy, I think that should be put forward as a serious suggestion!!!
Although, I guess there’s always a chance someone could be using that test group, but that could be easily avoided by documenting it as such so users avoid it.
All it requires, for sketches using my rfmTx Lib, is one line changed in the sketch:
Here’s the call to transmit:
bool rfm_send(const byte *data, const byte size, const byte group, const byte node, const byte rf_power, const int threshold, const byte timeout)
Transmits the data
data - byte stream to be transmitted
size - length of the data
group - transmission group: 210 for OEM
node - the unique ID of this node (1 - 30)
rf_power - +13 dBm -- RFM12B equivalent: 0x99 | 0x88 (-10dBm) appears to be the max before the AC power supply fails @ 230 V mains. Min value is 0x80 (-18 dBm)
threshold - the RSSI level below which the radio channel is considered clear (suggested value: -97)
timeout - the maximum time in milliseconds that the function will wait for the channel to become clear,
after which it transmits regardless. Suggested value: 10
returns: true if no timeout occurred, otherwise false.
TBH now I think of it, just transmitting an odd number of 0’s or int’s 0-255 would solve it for me as emonhub would spit out the payload as it expects an even number.
I don’t favour that - it a trap for the unwary at some point in the future. If somebody uses that group, at least it will be a bit more obvious, especially if there’s a #define TESTGROUP 199 – or whichever group we choose.
No I wasn’t advocating it, just saying it didn’t have to be a disruptive test packet when the decision was made, just a single byte countdown would have avoided this issue, it’s the padding out to mimic a full payload that has caused the test payload to be mistaken for a valid payload.
[edit] although I have to add I would happily (or reluctantly) accept any of these suggestions over false zero readings!
At 17:44, I restarted the emonTH. OOPS - there’s a zero value, though not surprising as it’s the default sketch - well almost, it’s actually using the RFM69 Native format because that’s what my emonPi is running now.
Then I changed the sketch to move the factory test to Group 1, and restarted it a couple more times: first at 17:54, then I changed my emonGLCD debugger sketch to Group 1 and restarted the emonTH again, at 18:01. The factory test appeared on the emonGLCD, but the TH missed both factory tests.
I call that successful.
And it’s now tested with the RFM69 ‘Classic’ JeeLib format, and here it is: EmonTH_V2-(V3.2.5).zip (7.8 KB)
I’ve called it V3.2.5 and the changes are;
Factory Test is now transmitted on Group 1,
Missing declaration of showString( ) has been added.
The config file name is now prefixed with the parent name.
If you’d like to load it on your errant emonTH(s) (provided it’s/they’re a V2 - other versions available to order ), I think this will cure your problem.
And to go with it, the “default” sketch for the emonTx V3.4, which I’ve called V2.1
), I think this will cure your problem.