Roadmap to Happiness - What is missing in the core framework

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. “” 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:


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: 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.


Was a bit hard to find.


I’d have never found it… thanks

1 Like