On Monday, February 15, 2021 at 10:26:25 PM UTC+1 [email protected] 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-development/e4d5d4ba-7605-4f1e-8469-886db6ad96c6n%40googlegroups.com.
