I have a conceptual question to ask. I have a feeling I’m missing something obvious, so hopefully someone can get me back on track. 
In the Energy Data Service binding I have a channel publishing the price of electricity tax. However, there are actually two different rates - there’s also “reduced electricity tax”. The binding cannot know which one applies.
Initially I thought I would simply add another channel for reduced electricity tax and let the user figure out which one to use, and perhaps set up a proxy item for automatically switching between the two at the right time (i.e. at the beginning of the year and then again when exceeding 4000 kWh consumed within a year).
However, there are also some internal calculation thing actions in the binding that can take all prices into consideration. So if the binding is not told which rate applies, those calculations would either be incorrect, or the thing actions would need to be told which prices to include for each method and each call. This seems a bit cumbersome.
So I’m thinking it would be better if the binding is aware which of the two rates currently applies, i.e. normal tax or reduced tax (boolean/switch: Reduced rate, defaulting to false). This could then be exposed in the existing electricity tax channel and could also be taken into consideration for all the thing actions. The reduced rate could still be exposed as an advanced channel for full flexibility, but that’s something additional.
Now the question: How to tell the binding which rate applies? It could be thing configuration or channel configuration, but I think this won’t work, since the configuration cannot changed by a rule (I’m having file-based configuration in mind also)? It’s a requirement to be able to automate the switching between rate. When having an integrated power meter, this would be very simple.
So a writable Switch channel might be the solution then? However, this would be more cumbersome for users not wanting or having the possibility to automate it, but simply wants to enable reduced rate manually. In this case configuration would be preferable rather than having to create a persisted item for configuring this.
Perhaps I could combine the two, so that a channel could be used to override configuration.
But it all seems quite work-around’ish. So back to my question: Am I missing an obvious concept allowing user configuration and automation of this configuration (i.e. accessible by rule engines) at the same time?