Whatever I said that gave you that impression, it wasn't my intention. It's entirely possible to create an attractive UI with openHAB's HABpanel (
see examples here). Mapping a widget's elements in HABpanel is no more onerous than in Home Remote. Both lack complex abstractions so you'll be mapping each individual element of an alarm panel or thermostat or lock.
I use the term 'mapping' but another term is 'binding'. For example, you must bind a slider control to, say, a light's brightness parameter. You bind a toggle control to a light's powerstate parameter. To represent a thermostat, you might need to use more than a half-dozen controls and bind each one to a parameter (setpoint temperature, ambient temperature, HVAC operating mode, current HVAC state, humidity, fan mode, fan status, etc).
FWIW, there's no need to do mapping/binding in Home Assistant. It supports complex abstractions of common household devices (thermostats, alarm panels, locks, etc). For example, it detects your Ecobee thermostat and creates a named 'entity' (like climate.ecobee). If your thermostat cannot be automatically detected, you would define it manually, specifying the thermostat's type, its desired entity name, etc. Done. The UI will now automatically render your thermostat entity using a stock
thermostat card. If you don't like its appearance or placement you can swap the card for another (perhaps a custom card made by a contributing user), reposition it, move it to a new tab in the UI, etc. No need to re-bind/re-map any UI controls/widgets.
Once you've installed Home Assistant, the level of effort to create the UI is considerably less than THR. However, in the interests of honesty and transparency, the installation of Home Assistant is a chore compared to THR. Remember, with Home Assistant you're installing and configuring a full-blown home automation system whereas THR is a UI builder.
This brings me to the topic of deployment. With THR, you use its designer software to create a UI targeted for a specific device's screen-size and operating system. The result is a file that you place on the target device that is running THR's renderer app.
I had created one version of a UI for my Android phone and another for my wife's iPhone. Any changes to the UI required modifying both flavors (Android/iOS) and sending (myself and) my wife a new version of the file (as an email attachment). This is not an uncommon deployment technique (for this kind of application). Nevertheless I didn't find it to be very convenient, especially during the initial phase of the UI when it is subject to frequent nips and tucks.
openHAB and Home Assistant render their UIs using web technologies so the target device only needs a (modern) browser. Deployment is only a matter of updating the UI and it, of course, becomes immediately available to all devices.
A UI created with THR is designed for a specific screen-size (i.e. screen resolution). The UI produced by OH and HA is designed to resize itself to fit the device's available screen-size. To be precise, based on my experiences many months ago, HABpanel didn't resize its UIs all that well (this may have been improved by now). It over-expanded widgets when there was more screen real-estate available. If you compensated by shrinking the original design, it would look too small when viewed on a smaller screen. So it was sort of resolution-specific. In contrast, Home Assistant does a more eye-pleasing job adapting its cards to the available space. For my purposes, I prefer Home Assistant's adaptability but I can understand why someone might want to create a UI optimized for a very specific screen-size.
Current drawbacks in HA's UI are:
- It cannot be based on the logged-in user (there's sort of a workaround for it)
- You can't have more than one active UI design (yet another kludge is available).
Perhaps a future version will address these issues.
I really can't say very much about Allonis because what can one really say by seeing only one or two examples? Unless you have access to many other examples, all I can see is what is shown on their web-site, which isn't very much at all. Maybe I'm not looking in the right place? What they do show is, to be honest, rather simple and easily replicated in THR, OH, or HA (and probably all the others you mentioned, except I've never tried them).
I think it's also important to mentioned the issue of price. We are comparing products that vary from zero to hundreds of dollars. We should be lowering our expectations (for feature set and product support) when looking at a
free product and raising them when considering a product costing a
quarter to a half grand.