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 long as you have one tempest, it should just
find out about that...
What does this report? :
PYTHONPATH=./bin python3 ./bin/user/weatherflowudp.py --token=<insert your
token here> --create-sensor-map
> If weewx does the accumulation you also get a windGustDir
>
> That's a good point.
>
> By now, you are using the mapping, if specified, for both I guess?
>
Yes, that is correct.
> I'm thinking of having some kind of suffix ('.udp' and '.rest' for
> example)
> [[sensor_map]]
> #this is the sensor mapping used for UDP and REST
> ...
> windSpeed = wind_avg.ST-000xxxxx.rapid_wind
> windDir = wind_direction.ST-000xxxxx.rapid_wind
> windGust = wind_gust.ST-000xxxxx.obs_st
> ...
> [[[REST]]] #if configured, use this mapping when getting data from
> REST, values are inherited from above
> windSpeed = wind_avg.ST-000xxxxx.obs_st #overwrites above
> mapping
> windDir = wind_direction.ST-000xxxxx.obs_st #overwrites above
> mapping
>
> Or like this?
>
Not sure I like that. I would rather have one map that can be generated by
the software if omitted. The above model makes that a bit more complicated
IMHO.
I still have one thought: let's assume your WIFI has an outage. In this
> case, a friend told me, the station is holding back all the data. When the
> WIFI is back, it burst all the missing UDP values, the timestamps are all
> there. How to deal with that? Weewx is still online, because, in my example
> it's on a wired device. What does the driver do with that data?
>
I don't think that's a driver question. The question is more: What does
weewx do then? The driver supplies a timestamp so in theory the driver
should just pick up the UDP values (I don't know if they'd come in the
correct order. Tom Keffer has indicated that they sometimes come out of
order, and this may well be such a case. I don't know. I also don't know if
weewx would cope with that (maybe not since Tom was not at all happy about
it?)
> And then a similar case: a power outage: the power comes back, WIFI comes
> back, the station burst all the values. Weewx comes back just right after
> that, tries to fetch missing data, which not yet is available via REST.
> Weewx starts up, doesn't get any values from REST, it never tries to get
> them again.
>
There really is no other way I suppose. How is the driver supposed to know
that it should wait and how long? If you're concerned about this maybe you
should add a pause before weewx starts, that might solve this scenario.
In both cases I know what I would do, because I save my weewx database
> every hour a day. overwriting the backup after 24 hours, but keep the 0:00
> copy for a month before overwriting. So I would go back to a database
> backup before the outage and start weewx when all values are available via
> REST.
>
That's another solution, but it's a bit more hassle I suppose...
Cheers,
Jan-Jaap
--
You received this message because you are subscribed to the Google Groups
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-development/dff17ed5-54bd-4495-8d64-160b82a4b0d7n%40googlegroups.com.
