> 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
> 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.
Jan-Jaap van der Geer schrieb am Montag, 15. Februar 2021 um 21:01:33 UTC+1:
> On Sunday, February 14, 2021 at 8:10:44 PM UTC+1 [email protected]
> 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 "Import from UDP" to debug level. The driver
>> works now for me, the last thing on the wishlist would bei to let
>> genStartupRecords only generate one entry per archive_interval. I might do
>> that myself if I find some time.
>>
>
> I'll incorporate these changes yes :)
>
>
>> Good work! And thank you for the driver enhancements!
>>
>
> 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?
>
> 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.
>
> I have some ideas how to address that for a future version.
>
> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-development/fb2fc331-1861-4d88-95ad-890dbd6a526cn%40googlegroups.com.
