Skip to content

Conversation

jlaur
Copy link
Contributor

@jlaur jlaur commented Oct 4, 2025

@jlaur
Copy link
Contributor Author

jlaur commented Oct 4, 2025

@lolodomo - I noticed that type is required here for a configured channel, not a custom channel:

    channels:
      electricity#grid-tariff:
        type: datahub-price
        config:
          chargeTypeCodes: "CD,CD R"
          start: StartOfYear

whereas it can be omitted in DSL:

    Channels:
        Number : electricity#grid-tariff [ chargeTypeCodes="CD,CD R", start="StartOfYear" ]

I don't know if this was already discussed and decided, just wanted to let you know in case not, since I'm trying this out now for the first time and seeing it with new eyes. 🙂

@lolodomo
Copy link
Contributor

lolodomo commented Oct 5, 2025

@jlaur : in your case, you don't need to set the "type" field but the "itemType" field to value "Number".

@jlaur jlaur marked this pull request as draft October 5, 2025 12:55
@jlaur jlaur force-pushed the energidataservice-yaml-doc branch from 0097b65 to f50ed88 Compare October 5, 2025 12:58
@jlaur jlaur marked this pull request as ready for review October 5, 2025 12:58
@jlaur
Copy link
Contributor Author

jlaur commented Oct 5, 2025

in your case, you don't need to set the "type" field but the "itemType" field to value "Number".

Thanks, that worked as well. I didn't think of this much before, but it seems itemDimension is not needed, it's still EnergyPrice as defined for the channel type being configured. In the DSL syntax, I just added "Number : " to make it work (I guess), but with the YAML syntax it's now obvious that specifying either channel type or item type seems redundant? Since my only interest is to provide some parameters for configuring channel electricity#grid-tariff.

@lolodomo
Copy link
Contributor

lolodomo commented Oct 12, 2025

I didn't think of this much before, but it seems itemDimension is not needed, it's still EnergyPrice as defined for the channel type being configured. In the DSL syntax, I just added "Number : " to make it work (I guess), but with the YAML syntax it's now obvious that specifying either channel type or item type seems redundant? Since my only interest is to provide some parameters for configuring channel electricity#grid-tariff.

When the channel type is specificied, the accepted item type is retrieved from the channel type.
In case we would accept to declare a channel without neither a channel type nor an item type, the channel will be created without any accepted item type. This will be accepted as the parameter is nullable but this will more than probably have an impact, maybe in UI when the user tries to link an item and maybe when handling commands for this channel ? I am not sure if the core framework and UI is really prepared to handle channels without any accepted item type.

Signed-off-by: Jacob Laursen <jacob-github@vindvejr.dk>
@jlaur jlaur force-pushed the energidataservice-yaml-doc branch from f50ed88 to e8eb720 Compare October 12, 2025 10:29
@jlaur
Copy link
Contributor Author

jlaur commented Oct 12, 2025

In case we would accept to declare a channel without neither a channel type nor an item type, the channel will be created without any accepted item type.

My thinking is that this should be derived from the channel being configured, i.e. this should be possible:

    channels:
      electricity#grid-tariff:
        config:
          chargeTypeCodes: "CD,CD R"
          start: StartOfYear

or:

    Channels:
        electricity#grid-tariff [ chargeTypeCodes="CD,CD R", start="StartOfYear" ]

I didn't test the DSL version, probably it won't parse the syntax validation.

Just a thought, and obvously not related to this PR. It just feels strange having to either provide channel type or item type when both are redundant and could (at least theoretically) be derived from the channel being configured.

Copy link
Contributor

@lolodomo lolodomo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you

@lolodomo lolodomo merged commit 32a7c33 into openhab:main Oct 12, 2025
2 checks passed
@lolodomo lolodomo added this to the 5.1 milestone Oct 12, 2025
@jlaur jlaur deleted the energidataservice-yaml-doc branch October 13, 2025 17:58
jlaur added a commit to jlaur/openhab-addons that referenced this pull request Oct 13, 2025
Regression of openhab#19435

Signed-off-by: Jacob Laursen <jacob-github@vindvejr.dk>
lsiepel pushed a commit that referenced this pull request Oct 16, 2025
Regression of #19435

Signed-off-by: Jacob Laursen <jacob-github@vindvejr.dk>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants