Specify data_binding on a per tile basis

[nifoc]

Is your feature request related to a problem? Please describe.

As far as I'm aware, the skin currently always uses the same data_binding. In practice this means that it can only display data stored in the default (wx_binding) database.

Some plugins (e.g. weewx-aqi)store their data in a separate database, which - as far as I know - can currently not be queried/displayed.

Describe the solution you'd like

Introduce a data_binding attribute (like in the weewx default skin.conf) that can be used to specify the "source" of a specific field.

This should work with stat and diagram tiles (I personally don't use the table and I imagine it would be harder to make it work with that tile type, too).

Describe alternatives you've considered

N/A

Additional context

weewx DataBindings docs weewx Data Bases docs weewx DataBinding programming interface weewx Multiple bindings docs

[Daveiano]

Yeah, I also stumbled upon this when working on the weewx-DWD integration. This extension also creates a new database for the forecast data. But besides the example for weewx-DWD:

[ImageGenerator]
    ...
    [[day_images]]
        ...
        [[[forecast]]]
            data_binding = dwd_binding
            line_gap_fraction = 0.04
            time_length = 950400
            x_label_format = %d.%m.
            [[[[outTemp]]]]
            [[[[dewpoint]]]]

I could not find any information about this in the weewx documentation. Is this somewhere documented that you can set this per graph or something? I am wondering what the ''default support' for setting the data_binding in weewx is.

This will definitely be included in the next 2.3.0 release.

[nifoc]

Is this somewhere documented that you can set this per graph or something?

Good question. I saw this mentioned in quite a few plugins, so I assumed that it is something that's documented ... but it doesn't look like it is?

Searching for data_binding in the weewx source code reveals this (optional) parameter in quite a few places (and comments): https://github.com/weewx/weewx/search?q=data_binding I'm not sure of the skin uses any of these classes (directly).

Apparently you can also specify the binding directly in the template by doing something like this:

$current($data_binding='foo_binding').outTemp

Source

Also mentioned in multiple places here.

[Daveiano]

First, Thanks for investigating this!

Is this somewhere documented that you can set this per graph or something?

Good question. I saw this mentioned in quite a few plugins, so I assumed that it is something that's documented ... but it doesn't look like it is?

Searching for data_binding in the weewx source code reveals this (optional) parameter in quite a few places (and comments): https://github.com/weewx/weewx/search?q=data_binding I'm not sure of the skin uses any of these classes (directly).

As far as I see, the most relevant logic for our use case is in https://github.com/weewx/weewx/blob/80160d81402e9549a93806473855144e00f9f022/bin/weewx/imagegenerator.py#L91 (imagegenerator.py). But since the skin does not use the imagegenerator (because the graphs are rendered via javascript), the class is not used by the skin. From a quick investigation it looks like weewx uses the data_binding defined in [StdReport] as the default, you can then override this for every generated image.

But since weewx-wdc also supports setting the observations for the stat and tables tiles, besides the graphs, I think this should be configured globally per observation(?). Something like this:

...
[DisplayOptions]
    ...
    [[obs_bindings]]
        custom_obs_1=extension_1_binding
        custom_obs_2=extension_2_binding
    ...

With this, custom_obs_1 and custom_obs_2 could be used in table_tile_observations, stat_tile_observations and diagram_tile_observations. This should cover every use case?

Apparently you can also specify the binding directly in the template by doing something like this:

$current($data_binding='foo_binding').outTemp

Oh yes, I was aware of the direct usage in templates.

[Daveiano]

After writing the last comment, I noticed this does not work out for every use case: For example, the forecast extensions (I used weewx-forecast and weewx-DWD) also provide a new data_binding. But these extensions do not necessarily add new observations, they simply reuse existing ones (a forecast includes outTemp, windSpeed, barometer and so on).

So using an obs like outTemp from two different databases would not be possible with this. Instead it should be like:

...
[DisplayOptions]
    ...
    [[obs_bindings]]
        [[[custom_obs_1]]]
            data_binding = extension_1_binding # eg wx_binding
            observation = obs_key # eg. outTemp
        [[[custom_obs_2]]]
            data_binding = extension_2_binding
            observation = another_obs_key
    ...

[Daveiano]

This will definitely be included in the next 2.3.0 release.

Well, I need to correct myself. This will hit in v3, since this is part of a bigger refactoring of the general diagrams configuration. See #73

[Daveiano]

@nifoc It would be really helpful for testing if you could provide me with your default database along with your weewx-aqi database.

Personally, I do not use any extension that uses its own data binding besides the forecast extensions. But with these it isn't easy to test because values are always in the future, I guess (I already implemented custom data_bindings in https://github.com/Daveiano/weewx-wdc/tree/71-specify-data_binding-on-a-per-tile-basis and its basically working but its giving me a strange error on the month-%Y-%m and year-%Y pages so I wanted to double check if this is from the forecast extensions data structure or something else).

Do you use any other ease-to-set-up extensions with a own data binding? I found that the purple-air sensors for weewx-aqi are quite expensive (If you consider I just want them for testing :D)

[nifoc]

Sent the AQI database via email :)

Fairly certain you won't need the default DB just to test another data_binding since (as far as I understand) there no real "dependency" between the AQI and the default DB.

Do you use any other ease-to-set-up extensions with a own data binding?

I don't, sorry! But I think you should be able to (for example) just specify a different default DB as new, different data source. Something like this (in addition to the normal wx_binding):

[DataBindings]

    [[wxtest_binding]]
        database = archivetest_sqlite
        table_name = archive
        manager = weewx.manager.DaySummaryManager
        schema = schemas.wview_extended.schema

[Databases]

    [[archivetest_sqlite]]
        database_name = weewxtest.sdb
        database_type = SQLite

And just use an existing weewxtest.sdb to read some dummy data from a different data source.

[Daveiano]

Thank you very much!

Great idea with the second "test database"! I simply ran my local installation with the Simulator (mode: generator) driver to get some test data :)

This is looking good now, will drop in 3.0.0 like I said :)