Hello Till, On Thursday, May 7, 2020 at 4:48:41 PM UTC-4, Till Maas wrote: > > Hi Greg, > > On Wed, May 06, 2020 at 01:01:24PM -0400, Greg Troxel wrote: > > Till Maas <[email protected] <javascript:>> writes: > > > > > So a PC supports probably several Master Bricks, each master Brick > > > several Outdoor Weather Bricklets (they contain the wireless receiver) > > > or other sensors and each Outdoor Weather Bricklet supports 255 > wireless > > > sensors and 255 wireless weather stations. The weather stations > provide > > > wind speed, direction, gust, humidity, temperature and rain values. > The > > > wireless sensors temperate and humidity. > > > > I think the big question from the weewx viewpoint is "what is a weather > > station". > > yes. If I understand correctly after also looking at Matthews link: > > A weewx weather station consists of one driver and possibly multiple > services. It supports multiple temperature/humidity sensors but only one > rain/wind sensor. > > > > Since I only have one weather station at the moment, I need to support > > > only one. But since the hardware supports more, I wonder how to do > this > > > with weewx. It seems that the database schema does not have an ID for > > > different weather stations. So I guess each weewx instance/config file > > > is meant to accommodate only one weewx station. I guess this logical > > > weewx station could still consist of one Tinkerforge weather station > and > > > multiple extra sensors because of fields like > > > "extraHumid1".."extraHumid8" in the schema. Are there some best > > > practices how to map those values in a driver from different sensors? > > > > I'm not sure about best practice - it really depends on what those > > sensors are measuring and what they mean. > > > > Let me ask you what you are trying to do with "multiple weather > > stations" in the tinkerforge sense. Do you want to report them as > > separate logical things? Average them? > > I don't know. I don't have a use case for myself, therefore I was > wondering if it makes sense to support more than one of them. Since > there is no way to store most of it's data in weewx (rain & wind), it > does not seem to make sense. Not sure, if someone might care about wind > speed/direction in different height or points in an area. >
Right. In any case, WeeWX only supports rain and wind from one station <https://www.tinkerforge.com/en/shop/outdoor-weather-station-ws-6147.html>. However, as temperature and humidity and a few other data elements can vary quite a bit at a single location, WeeWX supports multiple sensors in those cases. For WeeWX, what could make sense is to initially write the driver to support the weather station's built-in sensors. There seems to be a well-defined Python API for the Outdoor Weather Bricklet at https://www.tinkerforge.com/en/doc/Software/Bricklets/OutdoorWeather_Bricklet_Python.html. Then, supporting the HumidityV2 Bricklet <https://www.tinkerforge.com/en/doc/Software/Bricklets/HumidityV2_Bricklet_Python.html> would provide both temperature and humidity. The configuration in weewx.conf could be added in a way to support many temperature and humidity Bricklets. For example: [TinkerForge] driver = user.tinkerforge host = localhost port = 4223 bricklets = OutdoorWeather, IndoorTempHumidity, AtticTempHumidity, GreenhouseTempHumidity [[OutdoorWeather]] uid = XYZ # assuming each weather station has a unique UID bricklet = OutdoorWeather ... [[IndoorTempHumidity]] uid = ABC bricklet = HumidityV2 humidity = inHumidity temperature = inTemp [[AtticTempHumidity]] uid = DEF bricklet = HumidityV2 humidity = extraHumid1 temperature = extraTemp1 [[GreenhouseTempHumidity]] uid = GHI bricklet = HumidityV2 humidity = extraHumid2 temperature = extraTemp2 The above is one theoretical way to map Bricklets within a driver configuration. Other Bricklet sensors could also be mapped the same way provided they can be mapped to an associated existing WeeWX data element. If you want to support Bricklet sensors that are not weather related, that's entirely possible but requires extending the database or using a second database for those data elements. In theory, it should be possible to bridge the brickd daemon with WeeWX using MQTT - https://www.tinkerforge.com/en/doc/Software/API_Bindings_MQTT.html#api-bindings-mqtt and then use the WeewX MQTT subscribe driver to load the data via MQTT. However, brickd doesn't support MQTT natively so it requires running the tinkerforge_mqtt script as a daemon to relay the data from brickd to the MQTT broker. > > Why does it matter that tinkerforge calls things that also do rain/wind > > "weather station" while they call things that only do > > temperature/humidify "sensor"? In what fundamental sense are they > > really different? > > Since weewx supports several temperature/humidity sensors, it seems it > makes sense to support several of those Tinkerforge sensors in one > driver instance but only one Tinkerforge weather station. > Exactly. Hope this helps, -Bill -- 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/c49fec1b-fd1e-4b4f-91de-d118af40b388%40googlegroups.com.
