@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 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/64ec8cc1-c662-46fd-aba0-7bd0ab1c7c01n%40googlegroups.com.
