> 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, if specified, for both I guess?
> 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?
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?
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.
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.
Jan-Jaap van der Geer schrieb am Dienstag, 16. Februar 2021 um 00:03:34
UTC+1:
> 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-000xxxxx
>>
>
> 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?)
>
> > A bit surprised you didn't take up an issue that I had expected you'd
>> mention: The skin you use seems to actively use the wind packages that come
>> much more often in the UDP messages, but which I have removed,
>> > at least when it comes to the default sensor maps. And if you want to
>> use these nonetheless, by using an explicit sensor map, you will get
>> problems when using the REST interface as these are not really compatible
>> as it is.
>> > I thought we didn't loose too much functionality by doing that in the
>> driver, but I now understand that there actually is a use case for that
>> stuff as well.
>>
>> Well, here is why:
>>
>> [[sensor_map]]
>> outTemp = air_temperature.ST-000xxxxx.obs_st
>> outHumidity = relative_humidity.ST-000xxxxx.obs_st
>> pressure = station_pressure.ST-000xxxxx.obs_st
>> lightning_strike_count =
>> lightning_strike_count.ST-000xxxxx.obs_st
>> lightning_distance =
>> lightning_strike_avg_distance.ST-000xxxxx .obs_st
>> supplyVoltage = battery.ST-000xxxxx.obs_st
>> windSpeed = wind_avg.ST-000xxxxx.obs_st
>> windDir = wind_direction.ST-000xxxxx.obs_st
>> currentWindSpeed = wind_speed.ST-000xxxxx.rapid_wind
>> currentWindDir = wind_direction.ST-000xxxxx.rapid_wind
>> windGust = wind_gust.ST-000xxxxx.obs_st
>> luminosity = illuminance.ST-000xxxxx.obs_st
>> UV = uv.ST-000xxxxx.obs_st
>> rain = rain_accumulated.ST-000xxxxx.obs_st
>> radiation = solar_radiation.ST-000xxxxx.obs_st
>>
>> I map the rapid_wind data to nonexistent (database) keys
>> ("currentWindSpeed", "currentWindDir"). These values get into the loop and
>> are published to the mqtt server to feed the live gauges and only the live
>> gauges of the skin I use. You can see what happens, if you debug the
>> javascript of my skin and take a closer look to the "jPayload"-variable on
>> "site.js". Every three seconds there will be a packet containing
>> "currentWindSpeed" and "currentWindDir", updating the "Wind", "Winböen"
>> (gust) and "Windrichtung" (direction) - gauges. Yes, all three of them,
>> even without having "windGust" in the package. If the currentWindSpeed is
>> higher than the gust-gauges value, the new gust value is currentWindSpeed.
>> It's reset with the once-a-minute package cointaining "windGust_mps", which
>> is mapped to windGust in the above stanza.
>> The other values are stored in the database and they also feed the live
>> charts. There is no problem at all, I use all values in their special way,
>> I am fully compatible. There is absolutely no benefit in storing rapid_wind
>> data when the device calculates the avg values on a one-minute-base, and my
>> interval is on a 5-minute-base.
>>
>
> Ah, smart! I understand.
>
> I'm thinking of having some kind of suffix ('.udp' and '.rest' for
> example) which could then be used to differentiate between the two maps.
>
> There might be a tiny benefit by letting weewx accumulate the rapid_wind
> instead of using the accumulation of the Tempest. If weewx does the
> accumulation you also get a windGustDir, which you won't get by letting
> Tempest do the accumulation. Not sure if there's much value in that
> datapoint, but it is a difference...
>
> 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/57d6a02e-3b80-41b6-aedb-a8479ebd4221n%40googlegroups.com.
