The current state of the driver seems to meet what I'd expect. Thanks again
to everyone.
Jan-Jaap van der Geer schrieb am Dienstag, 16. Februar 2021 um 21:33:38
UTC+1:
> On Tuesday, February 16, 2021 at 4:56:49 PM UTC+1 michael.k...@gmx.at
> wrote:
>
>> @Jan-Jaap: a friend of mine made a
On Tuesday, February 16, 2021 at 4:56:49 PM UTC+1 michael.k...@gmx.at wrote:
> @Jan-Jaap: a friend of mine made a couple of things mentioned above and
> filed a pull request.
>
Nice! I saw it earlier. I'll take a more thorough look later on. :)
Cheers,
Jan-Jaap
--
You received this message
On Tuesday, February 16, 2021 at 5:52:06 AM UTC+1 michael.k...@gmx.at wrote:
> > Hm, why would that not work? I just tried that but it worked for me. (I
> suppose you don't mean x but the actual number, right?)
>
> I didn't have this value in my config at all
>
Hm, that shouldn't matter. As
@Jan-Jaap: a friend of mine made a couple of things mentioned above and
filed a pull request.
michael.k...@gmx.at schrieb am Dienstag, 16. Februar 2021 um 05:52:06 UTC+1:
> > Hm, why would that not work? I just tried that but it worked for me. (I
> suppose you don't mean x but the actual
> Hm, why would that not work? I just tried that but it worked for me. (I
suppose you don't mean x but the actual number, right?)
I didn't have this value in my config at all
> If weewx does the accumulation you also get a windGustDir
That's a good point.
By now, you are using the mapping,
On Monday, February 15, 2021 at 10:26:25 PM UTC+1 michael.k...@gmx.at wrote:
> > You're welcome. Did you find out why the REST part didn't work
> initially? From your earlier explanation, I don't really see why it
> wouldn't work for you?
> It was devices = ST-000x
>
Hm, why would that
> You're welcome. Did you find out why the REST part didn't work
initially? From your earlier explanation, I don't really see why it
wouldn't work for you?
It was devices = ST-000x
> A bit surprised you didn't take up an issue that I had expected you'd
mention: The skin you use seems to
> You're welcome. Did you find out why the REST part didn't work
initially? From your earlier explanation, I don't really see why it
wouldn't work for you?
It was devices = ST-000x
> A bit surprised you didn't take up an issue that I had expected you'd
mention: The skin you use seems to
On Sunday, February 14, 2021 at 8:10:44 PM UTC+1 michael.k...@gmx.at wrote:
> seems to work!
>
Great news! Thanks for letting me know! :)
> I made two local changes:
>
1.) I removed the
>
> @property
> def archive_interval(self):
> return 60
> And changed the logging of
Hi Jan-Jaap,
seems to work! I made two local changes: 1.) I removed the
@property
def archive_interval(self):
return 60
And changed the logging of "Import from UDP" to debug level. The driver
works now for me, the last thing on the wishlist would bei to let
genStartupRecords
The skin is Nick's bootstrap skin, he and me are currently working on it to
show live data (did you notice the 3s updates at the wind gauges) more
Info: https://groups.google.com/g/weewx-user/c/3BCDn6lNEPw/m/nXAosYWEAwAJ
here ist the current bleeding edge
version:
On Friday, 12 February 2021 at 07:23:23 UTC+1 michael.k...@gmx.at wrote:
> I'm confident I'll get along with this. Looking forward to get this
> "production ready":
> https://www.kainzbauer.net/weather/Rif-Tempest/live.html
Nice site. Is that skin or whatever it is publicly available?
How
On Friday, 12 February 2021 at 07:19:56 UTC+1 Jan-Jaap van der Geer wrote:
> Well, if you have one Tempest, or one Air or one Skye or one set of Sky &
> Air, it should Just Work (tm). However if you have multiple units or
> unknown units then you would need to do things to the sensor map.
>
I'm confident I'll get along with this. Looking forward to get this
"production ready": https://www.kainzbauer.net/weather/Rif-Tempest/live.html
Jan-Jaap van der Geer schrieb am Freitag, 12. Februar 2021 um 07:19:56
UTC+1:
> On Friday, 12 February 2021 at 07:01:44 UTC+1 michael.k...@gmx.at
On Friday, 12 February 2021 at 07:01:44 UTC+1 michael.k...@gmx.at wrote:
> I'll give i a try the next few days. API-Token was already configured, it
> was probably something with the sensor map I indeed have in my config.
Well, if it is your sensor map I think the only consequence would be
I'll give i a try the next few days. API-Token was already configured, it
was probably something with the sensor map I indeed have in my config. How
is "For most configurations the driver will figure it out itself" to be
understood?
Jan-Jaap van der Geer schrieb am Freitag, 12. Februar 2021 um
On Tuesday, February 9, 2021 at 7:29:55 AM UTC+1 michael.k...@gmx.at wrote:
> In brief my observations with your driver:
>
>- udp-packets are being picked up (and published with mqtt in my case,
>because I've installed the extension)
>- missing database values are NOT being
On Wednesday, February 10, 2021 at 6:39:42 AM UTC+1 gjr80 wrote:
> That's the good thing about WeeWX, everyone can contribute. If you believe
> the documentation can be improved propose an amendment, preferably via a
> pull request, though I expect for something simple Tom would consider a
>
That's the good thing about WeeWX, everyone can contribute. If you believe
the documentation can be improved propose an amendment, preferably via a
pull request, though I expect for something simple Tom would consider a
request with suggested text in a post.
Gary
On Wednesday, 10 February
Correct. The start of an interval depends on the current timestamp. The
start of the interval right now may well be different to the start of the
interval if it were five seconds later. Consider all time since epoch
timestamp=0 split into intervals archive_interval seconds long. Then the
start
On Tuesday, February 9, 2021 at 2:03:52 PM UTC+1 michael.k...@gmx.at wrote:
> Thank you :)
>
> so when I said:
>
> "For backfilling missing data would use an approach like: If there is data
> available in weatherflow REST service, an if it is available on a time base
> which is more frequent
On Tuesday, February 9, 2021 at 1:48:18 PM UTC+1 gjr80 wrote:
> Very simply, when your driver is emitting loop packets your time
> resolution is the time between loop packet timestamps, once your driver is
> emitting archive records your time resolution decreases and is the time
> between
Sounds fine, though what function you use to obtain archive record field
values from the REST records depends on the observation; most will be
‘average’ but if rain is involved I expect it would be ‘sum’ not ‘average’,
also if any status fields are involved they might be ‘last’ rather than
On Tuesday, February 9, 2021 at 10:56:34 AM UTC+1 gjr80 wrote:
> That being said there is no requirement for that to be so, hence why you
> see words like ‘if’ and not ‘must’.
>
The 'if' concerns the if we're implementing the genArchiveRecords(), so
that's a clear yes. Other than that it says
Thank you :)
so when I said:
"For backfilling missing data would use an approach like: If there is data
available in weatherflow REST service, an if it is available on a time base
which is more frequent than archive_interval, I would try to backfill like
this: for every top of an weewx
Very simply, when your driver is emitting loop packets your time resolution
is the time between loop packet timestamps, once your driver is emitting
archive records your time resolution decreases and is the time between
archive record timestamps. Similar but slightly different with actual
OK, let's work through it. The hardware stored data at one minute
intervals, so between 11:05:00am to 11:10:00am the hardware will have five
stored records, the driver then creates a single archive record covering
11:05:00am to 11:10:00am, the observation that has the max value at
11:07:00am
For the loop packets this is what I already thought to know.
What I wanted to know if my weew archive interval is 5 mins, and the
hardware stored at 1min:
Lets assume the archive_interval 11:05:00am to 11:10:00am is to be
backfilled. The driver gets the stored archive values from the hardware,
If your one loop packet was the only loop packet received by WeeWX in that
archive interval then the archive record that WeeWX would synthesise from
that solitary loop packet would be the same as that loop packet. If as you
said that loop packet was stored by hardware and if the driver's
> If you mean does WeeWX determine if any incoming archive record has (for
example) a new daily max for some field and then save that data, then yes
that is what StdArchive does.
So if a hardware sends a loop packet with all the readings in a
one-minute-interval, and stores these exact
On Tuesday, 9 February 2021 at 19:43:50 UTC+10 michael.k...@gmx.at wrote:
> Thanks Gary.
> So if the driver "wants" to control the archive interval, it is overriden?
> For my personal reality, 1 Minute is too short.
>
Simply put, if WeeWX is using hardware record generation and the driver
On Tuesday, 9 February 2021 at 19:40:43 UTC+10 Jan-Jaap van der Geer wrote:
> On Tuesday, 9 February 2021 at 10:23:40 UTC+1 gjr80 wrote:
>
>> To clarify, the archive interval coming from the driver or weewx.conf is
>> quite acceptable.
>>
>> If a driver has the ability to emit archive records
Thanks Gary.
So if the driver "wants" to control the archive interval, it is overriden?
For my personal reality, 1 Minute is too short.
> If one or more archive records are provided WeeWX accepts and uses them
How does this work in detail? does weewx take care of min/max if there are
more
On Tuesday, 9 February 2021 at 10:23:40 UTC+1 gjr80 wrote:
> To clarify, the archive interval coming from the driver or weewx.conf is
> quite acceptable.
>
> If a driver has the ability to emit archive records then it MAY also
> control the archive period (by the same token it may not).
To clarify, the archive interval coming from the driver or weewx.conf is
quite acceptable.
If a driver has the ability to emit archive records then it MAY also
control the archive period (by the same token it may not). Consequently, if
you are using driver emitted archive records (ie hardware
Hi Jan-Jaap.
In brief my observations with your driver:
- udp-packets are being picked up (and published with mqtt in my case,
because I've installed the extension)
- missing database values are NOT being backfilled
- current archive records from loop data are NOT being generated
On Sunday, February 7, 2021 at 12:31:33 AM UTC+1 michael.k...@gmx.at wrote:
> I've just installed your driver. Whats the status now? Right now it
> neither seems to backfill data nor store current data from UDP into the
> database.
>
Yes, I've recently noticed that UDP data is not getting
Hi Jan-Jaap,
I've just installed your driver. Whats the status now? Right now it neither
seems to backfill data nor store current data from UDP into the database.
Other Question:
@property
def archive_interval(self):
return 60
What purpose does this have and why is it hardcoded
On Thursday, January 21, 2021 at 6:53:11 PM UTC+1 vince...@gmail.com wrote:
> On Wednesday, January 20, 2021 at 11:10:35 PM UTC-8 Jan-Jaap van der Geer
> wrote:
>
>> > * if you're asking if there's some kind of hybrid UDP 'and/or' REST
>> weewx driver...
>>
> I'm not asking that, but the latter
On Wednesday, January 20, 2021 at 11:10:35 PM UTC-8 Jan-Jaap van der Geer
wrote:
> > * if you're asking if there's some kind of hybrid UDP 'and/or' REST
> weewx driver...
>
I'm not asking that, but the latter is what I'm trying to create. Well,
> it's working though very much a WIP. However I
Interesting. I haven't noticed this, but I probably have not that much
traffic on the frequencies that WF is using... I'll investigate this. How
does weewx cope with reporting out-of-order times for its LOOP data?
On Wednesday, 20 January 2021 at 23:49:47 UTC+1 Tom Keffer wrote:
> Here's the
On Thursday, 21 January 2021, 01:30:19 CET, Vince Skahan wrote:
> If 'what' is down ? The weewx box ? The WF servers ? The network
in-between ? The Hub ?
The weewx-box. That's under my control and I suppose I won't manage to have
anywhere near the up time any of the others. And it
On Wednesday, January 20, 2021 at 2:13:40 PM UTC-8 Jan-Jaap van der Geer
wrote:
> I didn't much like that the UDP-based driver doesn't fetch data if it's
> down.
The problem for me is that you cannot fetch historical data, for example if
> the system has been down for a period. But
Here's the discussion:
https://community.weatherflow.com/t/backdated-udp-obs-st-messages/7873
Maybe they've made some changes since then and my comments are no longer
relevant. I don't know.
On Wed, Jan 20, 2021 at 2:13 PM 'Jan-Jaap van der Geer' via
weewx-development wrote:
>
> Yes, that's
Yes, that's the idea. Use REST for archive data and UDP for the LOOP data.
OK, so I understand that this is not a supported scenario. I'll have to
decide if I want to bother doing something with that or not. The wind
vector graph looks rather different for 1 minute and 5 minute intervals :)
I'm confused by what you're doing.
So, you are using UDP data for the LOOP data, but the REST data for the
archive data? I suppose that could work, but you're going to have to decide
whether to honor the 1 minute archive interval of the REST data, or the 5
minutes you hope for.
If you really
I'm new to python and new to weewx drivers, but I've had a weewx
installation for several years. I recently acquired a WeatherFlow Tempest
and I created a new weewx installation with the based on
the https://github.com/captain-coredump/weatherflow-udp driver. I later
switched to the Tom Keffer
47 matches
Mail list logo
