Till Maas <[email protected]> writes: > A weewx weather station consists of one driver and possibly multiple > services. It supports multiple temperature/humidity sensors but only one > rain/wind sensor.
I don't think that's quite right. "weather station" there means "pile of stuff that weewx gets data from". The driver/service distinction is an arbitrary software thing and I think we shouldn't give it too much architectural weight. As for multiple temperature and only one rain, I don't think that's true either. There is a database with a schema, and *by default* there are single columns for rain, wind, inTemp, outTemp, and so on. There are also extraTemp1 and so on by default. The reason the schema has the above defaults is as I understand it partly becuse wview did it this way, but I think it's really because a typical high-end weather station (e.g. Davis) supports extra temp sensors. If you simply extend your database to have extraRain1, extraRain2, and have whatever driver/service get that data and put it in the database, you should be able to do this. There's nothing magic about rain vs temp - it's that historically having extra temp sensors was normal and having extra rain sensors was not. So you could have an extraRain1 graph also in your skin. I added inDewpoint to my database, because I wanted to record and graph that. Granted that's extra vs a second of the same kind of sensor, but weewx doesn't care. The real issue is managing the data logically in terms of having lots of sensors and deciding what the right output is. >> 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. I think without a plan you can't explain what is sensible. Your notion of wind at varying heights is a good idea. Of course, most people don't manage to even have the first wind sensor at 10m like they should. Overall, I think that we are arriving at a world of more flexible sensor configuration and it's time to take a step back and look at the current schema and perhaps make changing the schema to add sensor columns more of a normal thing rather than a scary thing. >> 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. I think they aren't really different; you were just misled by extraTemp1 being prepopulated in the standard schema, becuase others before you wanted that, while nobody before has talked about on the list wanting multiple rain sensors. Pivoting weewx's db to have unit numbers for sensors, or location codes, is a huge amount of work and disruption and I don't see that happening. Right now we have extraTemp1 which is kind of a denormalized table that might instead look like time | sensor number | temp or time | sensor type | sensor number | sensor value but I think the standard view is that the db columns represent fields in packets from Davis and similar stations, which itself have that kind of denormalized schema. Overall I'd encourage code to be written so that there can be both a driver and a service, making most of it a library essentially, and to be able to handle multiple bricks, with some internal interface that looks like the second example above, and then a way to map that to weewx database fields. -- 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/rmiv9l67euf.fsf%40s1.lexort.com.
