ID change, without reset or new batteries!

[skyewright]

Hi,

This morning RFXCOM was having particular difficulty with signals from my WMR928 rain gauge (RGR126, known here as rain2).

I decided that a change of antenae position might help, though all other sensors were pretty happy with the old position, and the WMR928 console has been receiving fine.

So, I shut down the NSLU2, moved everything and restarted. When I got back down from the loft and checked through the browser interface I found that RFXCOM had not had a signal from rain2 - but thought it had found a 'new' RGR126 - see image in next post.


So, I removed the 'old' rain2 from the list and reused the name for the 'new' sensor.
The log now shows old and new rain2 sensors - but the rain total on the 'new' sensor is 38320, as opposed to the 400 of the 'old' sensor.

The WMR928 console doesn't think anything strange has happened and still has 'total rain of 40mm.

Any idea what's been going on?

[skyewright]

Here's the sensor image missing from the last post!

[admin]

Hi,
data logging is based on sensor IDs. In RFXCOM mode you can decide what sensor to get what ID. As the sensors don't have fixed identifiers (just a randowm number until getting a reset again) I don't think there is another way of doing this.

The total rainfall is recodered in the sensor. When you interchange the IDs of two rain sensors, recorded total rain will also change. So this looks ok to me.

To get rid of the unwanted change in total rain, you should mark this entry as deleted:
20080320132056 rain2 .....

Meteohub then ignores the raise in total rain :-)

[skyewright]

Hi,
data logging is based on sensor IDs. In RFXCOM mode you can decide what sensor to get what ID. As the sensors don't have fixed identifiers (just a randowm number until getting a reset again) I don't think there is another way of doing this.

But that's the point I was trying to make. The sensor had not been reset, it and all the other sensors were running normally the whole time. All I had done was turn off the NSLU2, move the antenae, then restart.

The total rainfall is recodered in the sensor.

And the WMR928 console which is reading form the same sensor does not think that the total rainfall has changed - it still reports 40mm (which equates to the 400 of the 'old' rain2)

To get rid of the unwanted change in total rain, you should mark this entry as deleted:
20080320132056 rain2 .....

Meteohub then ignores the raise in total rain :-)

I don't understand.
Won't that still leave a big jump from
20080320114847 rain2 010 0 400
to whatever is the first record on the 're-totalled' rain2, e.g.
20080320132143 rain2 0 0 38320

At present, Meteohub seems to be ignoring the leap anyway, as day1_rain2_total_mm and month1_rain2_total_mm are showing the same figure as from before the 'leap'. It will be interesting to see what they show when it next rains!

Is there (or should there perhaps be) a sanity check on large jumps in values (I think that WD might call it a spike filter).

[skyewright]

And now a couple of hours later 'another' (prehaps the original?) RGR126 has appeared!

I've now name this other RGR126 as rain1 (which is what I had originally intended to use anyway).
It will be interesting to see how the two versions of the same sensor get on!

I suspect this may be one for RFXCOM to consider...

[skyewright]

It will be interesting to see how the two versions of the same sensor get on!

'rain1' is the 'old' (real) sensor that the console is seeing.
I'm mainly getting 'rain2', with the occasional 'rain1'!

Code: Select all

20080320172655 rain2 0 0 38320
20080320172742 rain2 0 0 38320
20080320172846 rain1 0 0 410
20080320172916 rain2 0 0 38320
20080320173050 rain2 0 0 38320

These lines are all for the same physical sensor!
Notice that rain1 has now had an extra mm of rain, but rain2 hasn't

I suspect this may be one for RFXCOM to consider...

I'll be sending them an e-mail as soon as I get the chance!

[admin]

in regard to deleting raw rain data:
1) Meteohub realizes that there is a jump caused by the deleted marked data and levels this to zero in its computations
2) when there is a too big jump between the rain total of two sensor readings close in time, then Meteohub assumes a sensor change or some other effects and ignores the jump.

why a \"shutdown of meteohub, moving it around a bit and powering it up again\" does make a change in mapping sensors to IDs is unclear to me. I would like to say that cannot be, but experience tells me to be more careful ;-) no explanation for this and not consistent with my experience.

If you are out of luck, both sensors could have become the same random number from their inner logic when putting the batteries in, but that would result in changing values for the same sensor id in the log.

[skyewright]

in regard to deleting raw rain data:
1) Meteohub realizes that there is a jump caused by the deleted marked data and levels this to zero in its computations
2) when there is a too big jump between the rain total of two sensor readings close in time, then Meteohub assumes a sensor change or some other effects and ignores the jump.

2) is behaviour I sort of expected. Good design, :)
1) is very smart. Nice idea. I hadn't realised you were using 'mark as deleted' behavoiur

why a "shutdown of meteohub, moving it around a bit and powering it up again" does make a change in mapping sensors to IDs is unclear to me. I would like to say that cannot be, but experience tells me to be more careful ;-) no explanation for this and not consistent with my experience.

In nearly 20 years as a developer I've learned to expect the unexpected too! Funny things computers... :S

If you are out of luck, both sensors could have become the same random number from their inner logic when putting the batteries in, but that would result in changing values for the same sensor id in the log.

Quite the reverse here - one sensor has somehow gained two ids and some signals are being asigned to one id, some to the other!

I'm now communicating with Bert at RFXCOM. He's asked for an RFreceiver recording, for which I'll need to disconnect meteohub at some point. If I've understood your manual correctly 'listening' to port 5557 might give him pretty much the same thing - but 'live'?

I believe I've set up my router to give access via 5555-8 if you wanted to take a look yourself (you have my IP from earlier e-mail).

[skyewright]

Rfxcom were able to listen to port 5558 to observe the RFXCOM output directly using their RFreceiver application - much handier than having to disconnect the NSLU2 and re-connect the RFXCOM to an XP machine. :)

RFXCOM's first suggestion is that the extra rain gauge is from a neighbour's OS weather station, but none of my neighbours have weather stations of any sort, and this being NW Scotland even my very nearest neighbour is well over 100m away, and the next twice that distance.

This morning a second WMR928 anemometer has put in a brief appearance too (Sensors shows an unassigned STR918 last received over 4 hours ago).

Strange...

[skyewright]

RFXCOM's first suggestion is that the extra rain gauge is from a neighbour's OS weather station, but none of my neighbours have weather stations of any sort, and this being NW Scotland even my very nearest neighbour is well over 100m away, and the next twice that distance.

I've discovered that a neighbour 900m away who I though had a different Wx actually has a WMR928. At the moment it looks as though the RFXCOM is picking up his rain gauge as if it were at the bottom of my garden - but (most of the time) not picking up the one that really is at the bottom of my garden[1]!

Ironically he's not getting good reception on his own console, so he's going to move his gauge anyway. As an experiment he's going to move if so that his stone built house gets in the way of line of sight to me. It will be interesting to see if the extra rain sensor then disappears (and maybe mine will improve?).

This morning a second WMR928 anemometer (which may also be his) has popped up 3 or 4 times now with hours between readings - I've given it an ID so that I can log its appearances!

[admin]

so you can log data for your neighbor and tell him when he should think about changing the batteries :-)

If your rfxcom sees you rain gauge and the one from the neighbor and tends to give it the same id, then you should reset your gauge to give it a new not conflicting address.

[skyewright]

so you can log data for your neighbor and tell him when he should think about changing the batteries :-)

Interesting idea. ;-)
He was quite gobsmacked when I said that I thought I was picking up one of his sensors 900m away. The only other sensor of his I'm getting is the anemometer, and that only occasional (30 log records since midnight), but even so it's quite a testament to the sensitivity of the RFXCOM receiver!

If your rfxcom sees you rain gauge and the one from the neighbor and tends to give it the same id, then you should reset your gauge to give it a new not conflicting address.

That's not a problem. The id's are different. That confusion came about because after I re-booted with the antenna in the new better position it was the other guy's 928 gauge that got picked up. My own 928 gauge didn't start being received again till a lot later and is still infrequent at times (it varies).
Sometime next week I hope to be able to try something new, that might help with that (I'll mention it here if it helps). :)