This detail is definitely not lost on me, and is the biggest sticking point. My impression, which is based on very limited knowledge, so it could be very wrong, but it would seem there is tight coupling between the limited types and the UI elements, which are all not easy to extend.
If I owned this architecture, which I don’t… but if I did, I’d be inclined to create a generalized complex type in the core and leave it at that. Then I’d require that any binding developer who creates complex types needs to create at lease basic example UI widgets which implement their type, and package it with the binding so that bindings work out of the box. I don’t see anything wrong with creating one-off types that are binding specific, but I also don’t see any reason that needs to end up in the core and end up being a drag on core development. There just needs to be enough control to keep custom stuff from getting out of control … you shoot yourself in the foot if you allow 100 bindings to come up with 100 different implementations of a power switch … but it’s advantageous to let someone like Honeywell create a binding for their thermostat and maybe even a branded UI widget to go with it… for example. But that’s just my opinion.
The type abstractions I see in openHAB tell me that someone was going for “strong typing”. There are advantages to strongly typed constructs, and given that java is a strongly typed language, it’s a common perspective that feels very natural to java developers … it’s usually an attempt to simplify or “idiot proof”. “I select a switch and I can’t go wrong because that strongly enforces switch semantics… I don’t have to think, I don’t have to configure, it just works”. But when you strongly type things the inflexibility leads to more strongly typed things because something with suitably different semantics requires a whole new type rather than just tweaking a config parameter… so the downside is your productivity is destroyed by all the time you spend on type maintenance. Taken together, that usually leads to a static and anemic list of strongly typed things that people have to struggle to fit to what they’re trying to do.
Honestly, there’s nothing that won’t fit in a string type. I can base64 encode binary values, I can XML encode whole objects, I can represent integers as ASCII or binary. The only time it really matters is at the presentation layer, and there we’re talking about type of presentation semantics.
I might create a ContiniouslyVariable.class. You could configure it with actual min and max values, so that might be min="-40" max="+20" units=“db”. You could have step=“0.5”, you could have transferFunction=“linear” | “log(10)” | “<transfer_function_formula>”. Then you would bind a UI element that can bind to a ContiniouslyVariable type, like a knob, slider, etc. You should be able to bind a text field and see the value go up and down as you turn the dial. Bind some radio buttons and you could switch it dynamically between values and percent. Then things like Volume and Dimmer become just labels at that point. Create a List type and a Boolean type and you’ve probably covered the majority of use cases.
