Roadmap to Happiness - What is missing in the core framework

One suggestion, which came up in another thread I’d started related to some weirdness with sending commands via a rule – I think the ESH metadata defining channels needs to be updated to have the concept of a primary type and supported types, and the framework should send commands of supported types through to the binding directly. The “as()” conversions should be deprecated, and the system needs to log appropriately when a command of the wrong type is sent to a binding.

Right now you’ve got conversions running in the framework from some types to some other types which may or may not be appropriate to the binding, and a situation where a conversion not happening causing a type mismatch doesn’t trigger anything in the logs – the event just vanishes.

My use case was a little more specific, but to be more generic about it, an example would be a channel representing a dimmer state. Right now a dimmer state may take a PercentType, and if you send an OnOffType, the system down in OnOffType will convert that to a PercentType(100). The binding therefore has no idea the user sent ON, just that they sent 100. The binding may want ON to mean something else, so you end up having two channels that can take ON – one that is interpreted as ON and can do something binding specific (restore to prior state, for example) and one that receives 100, and the user needs to know the difference (which isn’t obvious, because both will take either command type) The inverse is even weirder, because the as implementation in PercentType is different for OnOffType vs OpenClosedType, for example. (Only 100 is OPEN, but anything non-zero is ON).

What I’d really like to see – both from the standpoint of a binding author and a binding consumer – is the ability to tell the framework “this channel is a PercentType, and if you ask my state, that’s what you’re getting, but I’ll accept an OnOffType”. Then I can do a binding-specific interpretation of the other types rather than hoping the type conversions and logic in the defined item type matches my behavior, rather than having to define multiple channels that do almost-but-not-quite the same thing.

Hm. If I understand you correctly, you want to bind a channel to a switch item and a dimmer item. And in the binding you will receive either a PercentType or an OnOffType command (whereas you currently only receive a PercentType)?

I think the Issue David is referring to is

Hm. If I understand you correctly, you want to bind a channel to a switch item and a dimmer item. And in the binding you will receive either a PercentType or an OnOffType command (whereas you currently only receive a PercentType)?

Well, that’d be an example of it. What I more specifically want to do is be able to register a channel to receive more than one type, rather than having the ESH framework do ad-hoc type conversions that may or may not match what I expect to see. (Like I said, the behavior of the code in PercentType is inconsistent, as just one example).

In the other thread where I mentioned it, I suggested the channel metadata could be extended so you could give an item-type and a item-type-supported entry, as one possibility.

Basically like this:

<channel-type id="dimmer-switch">
	<item-type>PercentType</item-type>
	<item-type-supported>OnOffType</item-type>
	<label>Dimmer</label>
             ...
</channel-type>

Basically tell the framework “this is a PercentType channel, but if you call handleCommand for this channel and pass me an OnOffType, I’ll know what to do with it”. And then not run the as() conversion on OnOffType to generate a PercentType(100). Then in the code, I could do an instanceof check and OnOffType.ON could be a “turn on to last level”, rather than “turn on to 100”.

That’s just one example. Skimming bindings, there’s gobs of examples where a single real-world behaviors are split among channels. Now, an argument could be made that a conceptual purity is maintained by having a “On/Off” channel and a “dimmer level” channel, except that purity is blurred once some item types can be converted to others via fairly arbitrary rules, so I’m not sure how realistic of an argument that is. If that kind of purity was desired, than On/Off should toggle something on/off, and a dimmer PercentType should set the level if the device is on, not turn it on if its not, and certainly not infer anything from an ON state. So to turn a light on to a given level, you’d send dimmerLevel.sendCommand(50%) followed by dimmerPower.sendCommand(ON) or something. I don’t think people would like that, though, so I get why there’s a conversion so dimmerLevel.sendCommand(ON) works.

What tripped me up with it, before I read through the ESH code, was two things – first, there’s no logging if a type-conversion does’t exist. So sendCommand(ON) to a PercentType, or a DecimalType works (they’ll get 100 or 1 respectively) but sendCommand(ON) to a StringType silently fails. And secondly, there’s no consistent documentation, if any really, about what type conversions happen, what the conversion behaviors are, and what the implications of them are (like needing to double up dimmer channels).

I’m still trying to make heads or tails of the ESH code – it looks to me like that actually is supported to some limited extent already in CommunicationManager, but the default ThingTypeProvider for thing types, which reads from the ESH-INF just doesn’t support it. ChannelType only holds a String for itemType, and via some mechanism that seems to work its way down into CommunicationManager. But basically, the system should let you register multiple supported types in the thing definition, and toAcceptedType should skip conversion to any of the supported types for a channel, handleEvent() should also log all three debug lines in it as WARN, so when a channel doesn’t support any of the types the provided event can be converted to, it actually gets logged in a useful way for users.

I would rather have a list of item-types, all equally possible. The linked item decides what type to send.

Make a PR to allow this :slight_smile:

1 Like

Honestly, if I knew enough about ESH to feel comfortable making the change, I would. But I’m not even remotely comfortable that I understand the nuances of what its doing in this code, and I don’t really have a ton of time to dig into it at the moment.

The reason I think the two (the item-type and item-type-supported) need to be different is that caller code may want to know the type they’re going to get when the state is retrieved. Ie, you can updateState or sendCommand with any of the types, but the state will always be the item-type. That also helps with backwards compatibility because any code talking to any channel that previously was interacting with a given channel would continue to get the type they were expecting.

Isn’t this already supported?

https://www.eclipse.org/smarthome/documentation/concepts/items.html#a-note-on-items-which-accept-multiple-state-data-types

There are a number of Items which accept multiple state data types, for example DimmerItem , which accepts OnOffType and PercentType , RollershutterItem , which accepts PercentType and UpDownType , or ColorItem , which accepts HSBType , OnOffType and PercentType

I’m not familiar with the implementation of updateState or sendCommand but it seems to me the problem is with those commands.

2 Likes

It is, I use it in the WemoLightHandler

1 Like

Kind of – the issue is that, like the State conversions, the supported combinations are baked in as far as I can tell. That means frequently trying to map logical behaviors to name that don’t really match them (and thus are confusing to end users), and those types don’t seem to be extendable in metadata, just in code.

I did some more research. It looks like a binding does get the OnOffType but has to decide how to implement it. Hence some implement it as 100%. and there is nothing forced. If a binding doesn’t implement OnOff, it won’t be handled.
I agree that if arguments passed to like sendCommand, that can’t be handled, should give some warning and not be silent.

Not sure what you mean with that?

There’s a bit of conflict there - IF commands get passed as-is to bindings (without conversion), there is no way to know if one of the bindings might handle it correctly, and a warning is unwarranted.

Isn’t that already a problem. handleCommand in ThingHandler just passes any command and if the binding doesn’t handle it nobody will tell. Maybe it should return a boolean to confirm it handled the command?

1 Like

While working on converting the HASP project to openHAB, I noticed there were a couple missing pieces of functionality that prevented me from making the configuration more “flexible” rather than having to hard-code configuration settings into .rules files. (configuration I’m talking about).

  1. Sitemap Selection element mapping list should allow input from map or other input file
  2. Sitemap Text item should allow textbox input directly into item (with validation)

For #1, I’d envision the “mappings” configuration option having a filename input (i.e. “ThermostatMode.map” instead of the actual “1=HEAT, 2=COOL,…” mapping. That would make the mapping a lot more dynamic and easier to maintain. As an example, I have a Selection element that contains 30+ values (LED effects), and I have about 10 of them. So, every time I change the LED effects list, I have to do it in 10 different places. If I had a filename mapping, I’d be able to change it in one place and have it pulled in to every Selection element.

For #2, this is pretty self-explanatory - there is just no way to interact with Text items other than through rules or variables within those rules. For things like menu config items on the HASP, or other custom-defined text items, it would be amazing to have a text box on the UI, that could be used to enter the value directly into the item.

Of course, there should probably be some validation rules on the text inputs (max length, restricted characters, etc.), but that could also be a configurable option (for example, a RegEx transform on the input item that would format/validate the input into its proper form (e.g. GPS coordinates for map element, URL for image/Chromecast stream, etc…)

These are pretty basic improvements, but I think would have a huge impact on user experience with openHAB.

Sitemaps are an OH 1 technology and there is no real OH 2 replacement yet. I guess that is because of Habmin and other Widget based replacements. Sitemaps are more or less in maintenance mode only, I haven’t seen any new features lately.

Isn’t there a new concept discussed in the smarthome repo?

I think I have seen such an issue.

I guess I understand that, but Sitemaps are still a core component of openHAB’s configuration (until we get rid of the Basic/Classic UIs, or build them through other means, that is), and I may be wrong, but at least I don’t remember seeing the “Selection” element until a few recent releases (I had been using mapped “Switch” elements until I realized we had a Selection element available), so it seems like there are still features being added to it, maybe not at the pace of the new UIs.

I’m all about Habpanel, for its ease of design/layout and ability to create our own widgets, but I would like to think there’s always a place for the Basic UI (and therefore Sitemaps) on small screens which don’t do so well with Habpanel UIs. But, in its current state, Sitemaps are lacking some basic abilities to make them dynamic (I’m sure my 2 ideas above don’t cover everything that could be done to improve them, either).

As great as Habpanel is, it also doesn’t appear to offer the same basic functionality. I see that the selection widget has an option to list items via “server-provided list”, but I don’t see that allowing me to provide those items from a dynamic configuration file. Even worse, when I configure the selection widget list locally, that just becomes yet another place for me to keep track of and change when the item list changes. I also don’t see a widget that allows text input directly to a text item. I’ll try creating one myself, just to see if it’s possible, but I’m not sure how, if at all, I could solve issue #1.

Bottom line, it would be great to have these pieces of UX/UI functionality, so I’m adding them to the “wishlist” :wink:

link?

I guess I always assumed that HABPanel WAS the OH 2 replacement.

I am intrigued, would love a link if you can find it again. I have seen some activity on the Android App repo about getting it to work with HABPanel. When that happens it might be just the push I need to abandon sitemaps for good.

Selection has been around since OH 1.x (1.7 based on personal memory). It is discussed in the old OH 1.x Wiki: https://github.com/openhab/openhab1-addons/wiki/Explanation-of-Sitemaps#element-selection. IIRC it was broken for while so maybe that was why you needed to use Mappings with Switches.

One of the biggest problems with updates to the sitemap functionality is it touches soooo much code across at least three repos that it really becomes unreasonable to add anything to it. Were I to recommend an area to focus, it would be to address your concerns with HABPanel or working on something more dynamic to replace sitemaps instead of propping up sitemaps. They were a workhorse and great in their day, but IMHO they are not maintainable. It’s simply too difficult to add new features to it.

2 Likes

Was a bit hard to find.

2 Likes

I’d have never found it… thanks

1 Like