Desktop Client Connection Options

The Desktop Client provides two ways of connecting to the weather station:

• The Database Backend
• The Web Backend

Both options provide almost identical functionality so you can choose whatever is most suitable.

Functional differences between the two backends

The current functional differences between the Web and Database backends are:

• The Data Gaps report only shows marked permanent gaps when using the Web Backend. When using the Database backend it shows both Marked and Unmarked gaps.
• If the weather station has a camera setup the image shown on the main window may not have full metadata available and its properties dialog will only be partially populated. To view the full metadata for the image, find the image in the Images window

There are plans to fix the second difference at some point, probably as part of issue #41.

Database Backend

This backend connects directly to the weather database on your LAN. This of course won't work over the internet unless you expose your database server to the internet (probably a bad idea). So this option really only works when you're at home. When away from home (at work, traveling) you'll need to use the Web backend. Random members of the public likewise will need to use the web backend.

Performance-wise this is the fastest option but at times it can feel slower than the Web backend. This is because, unlike the Web backend, the database backend is synchronous. This means the user interface can lock-up briefly while queries run. There are plans to fix this at some point.

Web Backend

Using this connection method the Desktop Client can run anywhere in the world. The one requirement is that you have the Web interface setup and publicly accessible. This method doesn't require that you setup the WebSocket server (with raw TCP connections enabled) but it is very strongly recommended and will likely become a requirement at some point in the future.

When using this method running a report or plotting a chart over a particular timespan for the first time can be quite slow as the app has to go off to the internet to fetch data for the requested timespan. Running a report that looks at the stations entire dataset (such as Monthly Averages) can result in quite a lengthy download if the station has been running for a long time.

The upside is the app caches data fairly aggressively and tries to minimise the number of requests it makes to the server. This means that subsequent report runs, data exports, charts, etc, tend to be almost as fast as when using the Database backend.

Data Gaps & Caching

The Web Backend downloads data in one month blocks into a local cache database. So if you plot a chart for a single day last month it will result in all data for last month being downloaded into the cache if it isn't already there.

When data for a month is downloaded that data is scanned for any gaps between two records that are at least twice the stations sample interval. This indicates that one or more rows of data are missing for some reason. If a detected gap is marked as permanent then it is ignored. If a detected gap is not marked as permanent then:

• The month is marked as incomplete in the cache
• If its the first detected gap in the months data a marker is set to indicate data for the month is contiguous up to that point
• If it is the last detected gap in the months data a marker is set to indicate all data from that point to the end of the month is contiguous.

When an operation is performed that needs data for a particular timespan (eg, plotting a chart). The timespan is split into months and the cache status for each month is checked in the cache database:

• The first month in a timespan covering two or more months must have contiguous data from the start of the timespan to the end of the month
• The last month in a timespan covering two or more months must have contiguous data from the start of the month to end of the timespan
• All other months must not be marked as incomplete

Any months that do not meet these requirements will be re-downloaded unless that month is not the last month in the timespan and it has already been re-downloaded in the last 24 hours.

This means that months in the stations data set containing gaps will never be cached by the Desktop Client for more than 24 hours unless those gaps are specifically marked in the database as permanent. Any gaps marked as permanent are ignored by the desktop client and if all gaps in a given month are marked then the month will be considered complete and permanently cacheable even though its missing data.

The Data Gaps report can show gaps, both marked and unmarked, when connected via the Database Backend. You can mark unmarked gaps as permanent (and give them a label if you like) using the admin tool.

Archived Stations

Archived stations are an exception to all of this. Archived stations are effectively read-only; data-loggers should refuse to log data for archived stations and WeatherPush will refuse to stream data for Archived stations. As the dataset for an Archived station is read-only any gaps present can not be filled and so are permanent.

So if a station is Archived the Desktop Client will consider all detected gaps to be permanent and all data it downloads will be cached permanently.