Hello,
I have finally found the problem.
Seemingly the image generator is not case sensitive with the signal names.
The input signal was named 'rain_RG11'.
The unit group system IS case sensitive because in my plugin I linked
weewx.units.obs_group_dict['Rain_RG11'] = 'group_rain'
And so I got a
Hello,
I checked my image generation settings again and I also tried to check the
imagegenerator.py file but I did not find any reason why the conversion to
"mm" is not applied or at least the native database unit "cm" is not
applies.
I would be glad, if someone can give me a hint where this
Hello to all,
I got another question. The import of additional rain works fine now.
So if a add the following tag to my template:
$day.Rain_RG11.sum
I get the correct value in my preselected unit. (Database is metric and my
default unit for group_rain is "mm")
I'm also generating two graphs
On Tuesday, 28 May 2019 06:52:22 UTC+10, engolling wrote:
>
> So I started off with the noob variant...
> https://github.com/menachers/WeatherDuino/tree/master/WeeWx_Plugin
>
That looks like it will work, but be aware that if the record you are
augmenting is in anything other than US customary
Hi Gary,
sometimes I can't see the forest because of all of those trees anymore... :)
Thank you for your great answer again.
So I started off with the noob variant...
https://github.com/menachers/WeatherDuino/tree/master/WeeWx_Plugin
I will change it to the sophisticated procedure you proposed.
The number one rule when augmenting archive records or loop packets with
data is that you must check the unit system used in the record or packet
(ie check the usUnits field) you are adding data to and make sure that any
data you do add is in the same units as used by that unit system. If you
Hello Andrew,
indeed it actually is only augmenting.
But in case the archive data is gained from a DMPAFT packet it seems to be
converted complete after augmenting. If the archive data is gained from a
LOOP packet it converted before.
So the following things would probably solve the issue:
-
Hallo,
think I tracked the issue down.
First it starts with record generation software.
So each time a archive dataset is retreivedn form the hardware logger my
data is augmented and then it runs apparently through the unit converter,
converting it to metric units (in case of my augmented data
Hello,
of course I can give more details :-)
So as you know I'm augmenting some extra data to my archive records which I
get from emulated davis loop packaged.
My file whichs contains always the latest data looks like this:
Hi,
Perhaps you could give us some more details as to how the extra temperature
data is being obtained/provided/added to WeeWX, happy to see code/data
formats etc - code usually gives an unambiguous picture, descriptions are
often open to interpretation. I am having a little difficulty
Hello,
me again :).
Thank you for your last answer Thomas. Works fine.
Now I have a new "thing" I do not understand.
As discussed above I'm augmenting different data - also rain data to the
archive records as described in the customization guide.
I also augment temperature signals and
Yes. That's certainly possible.
-tk
On Tue, May 7, 2019 at 1:35 PM engolling wrote:
> Hello together,
>
> it's me again with hopefully a last question...
> As you know I'm augmenting some extra data from my service to the WeeWx
> archive records. But if archive records are loaded of the
Hello together,
it's me again with hopefully a last question...
As you know I'm augmenting some extra data from my service to the WeeWx
archive records. But if archive records are loaded of the stations logger
this data (which is in the future) is also augmented.
Is it possible to read the
Good that you have tracked down the issue. Running hardware record
generation on a Davis station has it advantages, though maybe not so
advantageous on emulated hardware.
Regards plotting rain data from two sensors. The current WeeWX plot engine
will certainly allow you to plot two obs in a
Hi Gary,
again thanks for your extended reply.
Meanwhile I added a lot of debugging code in the vantage driver and the
WeatherDuino code and was able to find out the reason what happened.
Their is a buffer on the flash chip which is written before storing the
data in the flash page. And this
Sorry for being a little tardy in replying but I wanted to sit down and
work my way through the Davis protocol. It seems everything is being
followed, I do not know if the lack of a final acknowledgement is critical
or not but what I would say is that the Davis driver works with real Davis
Hi Gary,
I tried to debug the system and therefore I built a "serial sniffer" in
form of an Arduino Mega passing through the data between serial0 and
serial1 and printing all messages out on serial2.
I used HTERM to display it and I will provide some screenshots for a better
visibility.
Here
The vantage driver is somewhat complex. How the vantage driver operates
depends on whether hardware or software record generation is in use. If
software record generation is in use then the vantage driver obtains loop
packets from the console (using the LOOP command) and the loop packets are
Hi Gary,
I checked the emulation of the WeatherDuino in the code and from my point
of view it seems to be implemented as in the protocol description.
Nevertheless it might differ in any behaviour which is not exactly defined
in the description.
It's very hard for me to understand the python
It seems that the WeatherDuino emulation of the Davis logger may still have
some issues. It's possible that the WeeWX vantage driver has some issues
but the driver is mature and has been in use for many years communicating
with actual Davis hardware without issue. One thing I have noticed with
Hi Gary,
I disabled my data service and the errors still were there. See the logfile
in attachment.
So I assumed that there is a problem with the vantage driver in combination
with my hardware.
So I changed in weewx.conf to
# If possible, new archive records are downloaded from the station
On Tuesday, 19 March 2019 07:57:06 UTC+10, engolling wrote:
>
> Hi Gary,
> thanks for your patience.
>
> This is not normal operation. Because something it triggering an archive
>> record to be saved every few seconds the NEW_ARCHIVE_RECORD event is also
>> triggered which causes your service to
One more thing - I do not own a original davis station - I'm using a
WeatherDuino, emulating a davis station for import of "standard" data.
https://www.meteocercal.info/forum/index.php
My plan is to get some extra data out of my hardware wich can not be
transmitted via the LOOP packets e.g. the
Hi Gary,
thanks for your patience.
This is not normal operation. Because something it triggering an archive
> record to be saved every few seconds the NEW_ARCHIVE_RECORD event is also
> triggered which causes your service to fire as well. The issue here is not
> your service but whatever is
On Monday, 18 March 2019 08:36:24 UTC+10, engolling wrote:
>
> Hi Gary,
>
> maybe I have found my problem after looking at my code and your advices
> again.
> Because it seems that I have bound my additional signals to the archive
> record and not to the LOOP packet
>
There is nothing wrong
Hi Gary,
maybe I have found my problem after looking at my code and your advices
again.
Because it seems that I have bound my additional signals to the archive
record and not to the LOOP packet
class WeeWxService(StdService):
def __init__(self, engine, config_dict):
Hi Gary,
maybe I have found my problem after looking at my code and your advices
again.
Because it seems that I have bound my additional signals to the archive
record and not to the LOOP packet
class WeeWxService(StdService):
def __init__(self, engine, config_dict):
Am Sonntag, 17. März 2019 02:32:13 UTC+1 schrieb gjr80:
>
> OK, your archive schema appears fine, that rules out one variable. WeeWX
> services are loaded at WeeWX startup and are retained as long as WeeWX
> continues to run so any properties you add are retained. Have a go at
> simplifying
OK, your archive schema appears fine, that rules out one variable. WeeWX
services are loaded at WeeWX startup and are retained as long as WeeWX
continues to run so any properties you add are retained. Have a go at
simplifying your service then I suggest you run WeeWX directly
Hello Gary,
thanks fot your efforts. You are right with your description how my code
should work.
Let's say my main problem is that I know how I construct software in
principle, but my python knowledgde is not very good, so in order to safe
the last cumulative rain value my only
Hi,
I had a look through your code and I think you have made things overly
complex for yourself. As I understand your setup you have a file,
/home/pi/WeatherDuino/WeeWx_Exp.txt, that contains your WeatherDuino data,
there are three rows of semicolon separated data, the rows being
Hi Gary,
thanks for your very interesting reply. I tried to augment my extra data to
the NEW_LOOP_PACKET, whichs works in priciple for all my data except the
rain delta.
As I mentioned it seems that the rain delta values are getting sorted out
somehow.
You can find the code here:
Short update:
I have found out that my plugin is executed via data_services each time a
loop package is generated and this is approximatly every 3 seconds.
An archive dataset is written every 60 seconds, leading to chance of 1/20
that the raindelta is saved correctly - thats too less :-D
So I
Hello,
I tried to implement a driver providing the rainfall in intervall but until
now it does not work as expected.
I'am able to handle the correct data to WeeWx with this command:
syslog.syslog(syslog.LOG_DEBUG, "WeatherDuino: " +
str(names[n+1]) + ": " +
weewx requires rain during archive interval for storing in the database
archive records. A driver may have to convert whatever it receives (eg
running total) so as to obtain the value for the interval. Daily is
accumulated by weewx from the archive interval values and weekly and
monthly are
35 matches
Mail list logo
