As an anti-proliferation measure, how about combining these (and likely offset) into one profile, where each of factor / offset / units parameters is optional.
1 Like
I think its quite opposite. With smaller profiles which do one thing you can assemble behavior you need. For example you can have two profiles average and debounce. Depending on order you place them you will have different results. For example:
- handler > debounce (60s) > avarage (10) - gives you avarage from 10 values received every 60 seconds
- handler > avarage (10) > debounce (60s) - gives you avarage value of last 10 values every 60 seconds
I know official profiles tend to do ie. range + inverse operation but I don’t have to. If you go with chained profile approach, which I proved is doable, then you can simply do range profile separately from inverse. Later one can be used standalone with miss wired contacts or to do trivial switches (!occupied → free).
1 Like
I hope people considering new profiles also take into account their two-way nature e.g. massaging state from channel to Item and massaging command from Item to channel.
It gets a bit complicated for those bindings that can issue commands or listen to states, maybe a profile needs a command path and a state path.
This becomes more important if chaining.
1 Like
This is right. Currently most profile assumption is that operations are same (or reversed in some ways). I could imagine myself situation we wish to filter incoming updates (from handler) but not outgoing (item) values or vice versa.
Technically speaking it is doable as configuration mechanism is not contained by anthing. It’s a matter of making such profiles. In fact I think that with a bit of luck it is possible to make an “adaptive” ConfigDescriptionProvider which will make whole process within UI a iterative process. We can keep adding new config parameters to description as profiles are appended letting UI draw a nice form with it. 
So… a bit later I actually come across a need to run code I drafted. Now I have more field experience to share. Turns out that trick with dynamic configuration will not fly. This is due to fact that OH core does not support nested configurations (key-value under key-value). Then there is also an issue of tricking UI which didn’t fly since profile configuration is semi static and UI does not inquiry for config of particular link. It always asks about profile-type:xyz configuration. Yet, this might be improved in OH 3.2 which I didn’t check yet.
Non nonetheless I was able to workaround issue by flattening maps. I wanted to avoid use of JSON which would complicate processing of link config. In the end using the XML config format I refered in other topic I ended up with something like that:
<links>
<link item="TInstallations_PV_DC_Power">
<channel>modbus:data:sunnyboy_power:dcms_watt:number</channel>
<config>
<profile>connectorio:profiles</profile>
<quantity.profile>connectorio:quantity</quantity.profile>
<quantity.unit>W</quantity.unit>
<sma-filter.profile>connectorio:sma-filter</sma-filter.profile>
</config>
</link>
</links>
Using text files it would look probably like below. In real life it will not fly due to dots in the keys, but that’s least of my concerns right now. 
Number:Power TInstallations_PV_DC_Power {
channel="modbus:data:sunnyboy_power:dcms_watt:number" [
profile="connectorio:profiles",
quantity.profile="connectorio:quantity",
quantity.unit="W",
sma-filter.profile="connectorio:sma-filter"
]
}
I worked on standalone linking mechanism (externalized from item definitions). This allows to make a semi static model across multiple installations and do all heavy lifting in things and links. Above example has two profiles associated - one turns decimals into quantity and other filters out 0x8000 values reported by SMA inverters when its dark.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.