zedoude / wfrog

Automatically exported from code.google.com/p/wfrog
GNU General Public License v3.0
0 stars 0 forks source link

WH1080 rain per hour always zero #89

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Normal usage
2.
3.

What is the expected output? What do you see instead?
Numbers other than zero while raining. Now the graph is always flat and  number 
value zero, no matter what.

What version of the product are you using? On what operating system?
wfrog 0.8.1, pywws-11.05_r380, ubuntu 10.04, WH1080

Please provide any additional information below.
I use mm as units

Original issue reported on code.google.com by karst...@gmail.com on 18 Jun 2011 at 7:45

GoogleCodeExporter commented 9 years ago
I confirm this issue (wfrog 0.8.2 pywws-12.02_r487, WH1080)

Original comment by udo.rat...@googlemail.com on 29 Mar 2012 at 9:03

Attachments:

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Update:
Freshly installed everything from scratch and latest versions but no change:
Ubuntu 10.04.4 LTS
pywws-12.05_r521
wfrog 0.8.2

Original comment by karst...@gmail.com on 17 Jul 2012 at 11:39

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Confirmed here...

Original comment by timothee...@gmail.com on 14 Oct 2012 at 9:11

GoogleCodeExporter commented 9 years ago
Confirmed here too
Debian Squeeze
wfrog 0.8.2-1 from .dev
pywws-12.10_r547

Original comment by cianda...@gmail.com on 4 Nov 2012 at 9:56

Attachments:

GoogleCodeExporter commented 9 years ago
Confirmed also from my side.
RaspBerry PI
Debian Wheezy.
wfrog 0.8.2-1
pywws-12.10_r547
Weather Station : WH-1090.
Which workaround can be done ?

Original comment by gaetan.g...@gmail.com on 1 Feb 2013 at 10:52

GoogleCodeExporter commented 9 years ago
I can confirm this bug is still present.

                if data['rain'] is not None:
                        e = generate_event('rain')
                        e.total = (136*(data['rain']))/100
                        e.rate = 0
                        send_event(e)

rain rate is actually set to 0 in the wh1080.py station driver. 

Original comment by paal.and...@gmail.com on 4 May 2013 at 7:05

GoogleCodeExporter commented 9 years ago
I've implemented a simple backward difference estimation for the wh1080 driver. 
I haven't tested it extensively, but it does show something.

Original comment by karljoha...@gmail.com on 11 Aug 2013 at 1:16

Attachments:

GoogleCodeExporter commented 9 years ago
The patch in my previous post will give very spiky graphs, because of the low 
granularity of the rain sensor of the WH1080. I'm experimenting with averaging 
over a longer period (20 minutes at the moment) and will provide a patch if it 
shows better results.

Original comment by karljoha...@gmail.com on 18 Aug 2013 at 2:33

GoogleCodeExporter commented 9 years ago
We just had a rain fall and this new patch, taking the average over 20 minutes, 
gives a much smoother result with moderate rain rates. It can easily be changed 
to take the average over an hour instead if that is wanted.

Original comment by karljoha...@gmail.com on 18 Aug 2013 at 5:51

Attachments:

GoogleCodeExporter commented 9 years ago

First of all, IMO this is not an issue or a bug. AFIK in this case the hardware 
is not providing this information and therefore it is correct that wfrog does 
not record this data. And as for trying to calculate it, real rain rate is an 
information that can only be calculated by the weather station hardware by 
doing the inverse of the time taken for a bucket to fill and rotate. The 
precision of the measure will depend on the precision of the rain bucket. 
Notice that you need to know the precise time in which the rotation happens to 
be able to calculate it and this is not the case since weather stations usually 
send data on a fixed period.  The measure that your patch calculates is the 
average rain rate over a period. Notice that the spikes probably happen when 
the period is too small compared with the period of data retrieval and 
therefore the error becomes much higher.

Having said that, I wouldn't mind including the patch in the trunk code if it 
was optional (deactivated by default) and it was clearly explained that you are 
using average rain rate to fill up the rain rate. I would also like to hear the 
opinion of the official driver maintainer (duinzicht).

Original comment by jordi.pu...@gmail.com on 19 Aug 2013 at 6:53