Interesting problem. 1. You should archive only what you observed. That is, when a datum is observed, it should be put in the database. Then you're done with it --- the value should not persist in the database.
That means your strategy 1a is best --- you put in a value for temperature when it was observed. Otherwise, it's null. You didn't say what software setup you have, but I can see a couple of options. One would be include a field for sea-temperature (call is ' seaTemperature') in your otherwise weather-oriented database schema. The archive interval would be 5 minutes or so, and the archive record, and database, would be mostly filled with weather data. Most values of seaTemperature would be null, but an occasional row would have a non-null value. In this case, seaTemperature would come from a WeeWX service. Another option is a weewx instance dedicated to sea temperature. No weather data. Its "LOOP" packets would arrive only rarely, once every few hours, so most of the time this instance would be blocking on its driver, waiting for that rare packet. Its archive interval would be pretty long too, maybe 3 to 6 hours. The resultant database would have very few entries, but most would be non-null. In this case, you'd write a driver for seaTemperature. Either approach would work. 2. Use aggregate type 'last'. It will return the last non-null value. For example, <p>The last measured sea temperature is $day.seaTemperature.last at $day.seaTemperature.lasttime</p> You don't want to use $latest.seaTemperature because that would give you seaTemperature in the last record of the database, which is likely to be null. -tk On Sun, May 10, 2020 at 2:33 AM Pila <[email protected]> wrote: > I have added one measurement (sea temperature) to WeeWx, which I get > probably only 3 times a day. How to handle such scarce data source? As > there are multiple variables which should be balanced here, I would > appreciate pointers. Small amount of data points makes for annoyingly slow > testing. > > Theoretical maximum is 6 measurements from 7:00 to 17:00 but the frequency > depends on the location. Temperature will vary mostly 1 deg C between > measurements, rarely 2 degs. The number of measurements may vary. I get new > data when it is available and my system knows know this is a new > measurement. Currently, measurements are made at 8:00, 14:00 and 15:00. I > have two questions. > > 1) I would like normal day/week/month graphs with all points connected. > Data from my weather station is saved once in 5 minutes. I use example set > by pond.py to read data as extraTemp1. I see 3 ways to supply the data to > pond.py. > > a) Save the data and have it available for only one reading. E.g. save it > at 8:13, it is read by WeeWx at 8:15 and removed from pond.txt at 8:18. > Until new data arrives, nothing is to be read by WeeWx into this field. I > just turned this mode on to test it again. > > b) I could have one reading available for one hour (or some other > duration). 8:00 reading is being received by my system at 8:18. I can leave > it available at pond.txt for reading 60 minutes and remove it at 9:18. No > data is available for reading until new data is read > > c) Let the data be available until replaced with the new data. This I > tried last day and it makes for a very jagged and wrong plot. It keeps the > last temp from yesterday (the highest) overnight and it drops suddenly at > 8:00 the next morning to the lowest temperature. > > Logically, I should collect data using a) and have it plotted with line > connected. I tried it briefly with line_gap_fraction = 0 to connect my > scarce data points but I still had breaks. > > 2) on the index page where the current values are, I should always see the > last standing value. Longest interval with no data is between 15:00 and > 8:00 the next day. This is related to above methods a) and b). In the > skin's index.html.tmpl I tried replacing $current.extraTemp1 with > $latest.extraTemp1 but I was getting N/A. > > I limit yscale to something like 15,25,1 to see the trends better. > > Maybe I was to quick in testing a) and something did not refresh or > regenerate. Since multiple features need to be balanced, I may have failed > to see the desired result using method a) which I am retesting again. > > -- > You received this message because you are subscribed to the Google Groups > "weewx-user" 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-user/a0cb5a23-f0dd-494f-99cf-6f0a69bdaddc%40googlegroups.com > <https://groups.google.com/d/msgid/weewx-user/a0cb5a23-f0dd-494f-99cf-6f0a69bdaddc%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "weewx-user" 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-user/CAPq0zEAa9RrLMc3NisAwn76-5Zw4FtMRcZ6x%2Bfr%3DjJtM0bCC7A%40mail.gmail.com.
