TasmoHAB is a great extension to the Openhab system! Thank you for your efforts!
While OpenHAB is excellent in integrating very diverse devices from different suppliers and all kind of standards under one hood, it is not that good if it comes to configuring your personal smart home according to your needs. I strongly believe that the big break through of smart homes is not that much blocked by incompatibility of the hardware but by finding a comfortable functional configuration fitting the needs of the residents. TasmoHAB is helping on the second, simplifying the configuration.
These are my proposals for further improvements to be discussed:
Simplified setup of TasmoHAB
For most users of OpenHAB, the setup of TasmoHAB may be too complicated.
Maybe an integration of TasmoHAB into the OpenHAB-UI would be my dream vision.
A tutorial could be a first step.
Zigbee2MQTT-HAB
A similar solution like TasmoHAB could be built for Zigbee devices managed by Zigbee2MQTT.
The situation from the OpenHAB viewpoint is the same: Support starts with MQTT, anything before MQTT is out of scope. Zigbee2MQTT-HAB could read the the Z2M-configuration and generate related things in OpenHAB based on the same Ninja-template concept as used by TasmoHAB.
ASSTA
I am using many Zigbee wall-switches (Aqara) which shall control OpenHAB switch items, many of them Tasmota-relays. Today, I need to setup dedicated rules assigning incoming Zigbee triggers to item switch commands. My vision is a more graphical UI where I can assign the item to be switched to any of my Aqara wall-switches. I call the tool “ASSTA” for ASSignment TAble. The output of the ASSTA tools are automatically generated OpenHAB rules (again using the Ninja-template engine).
In addition, ASSTA may generate XLS-files to be loaded into my Niimbot label sticker printer.
What do you think of these ideas?
I may start to implement Zigbee2MQTT-HAB in python. Should this be a separated tool or better be integrated as another functional module to today’s TasmoHAB?
Seems to me a more generic wholistic approach would be better for inclusion into openHAB core and MainUI. While Tasmota is popular, it’s still only a minority of OH users who use it.
TasmoHAB is also written in Python so anything that it would support in OH proper would have to be converted to Java.
Finally, it seems to be config file focused, not managed configs.
I think a better overall approach would be to create a binding with auto-discovery of Tasmota devices (assuming that’s not already possible). We already have “create equipment from thing” to generate the Items for a given Thing. There might be improvements that could be made there and then all bindings can benefit, not just Tasmota.
So I would separate the Things from the Items.
Again, this sounds like a good binding or an extension to the MQTT binding.
Seems like an extension of Scenes.
If you use Python it will forever be a separate tool.
If it only works with text config files it will be always incomplete and many users of OH, particularly newer and less technical users who only work in MainUI and use 100% managed configs.
Thanks rlkoshak, for your prompt and valuable feedback!
You are right, Tasmota may not be mainstream at the side of OpenHab. Are there any statistics available about running OpneHAB instances and their hardware layout?
ZigBee wall-switches (e.g., Aqara) should be quiet common, aren’t they?
Let me summarize your feedback:
Java instead of Python to stay in line with the OpenHAB code base for potential integration.
No but based on forum traffic I have a feeling for what people are using. Even when just looking at ESP devices I get the feeling that it’s fairly evenly split between Tasmota, ESPEasy, and other firmwares.
I’m not sure. Zigbee in general is very popular. It’s hard to judge their relative popularity between the native Zigbee binding and zigbee2mqtt.
But my point is if you want to make changes to OH core (e.g. how Items are created from Things/Channels), the changes need to be technology agnostic.
If there is a change that is specific to a technology (e.g. autodiscovery of Tasmota devices), that change needs to be centralized in a binding.
Not prefer, but you gotta at least support managed configs or else you’ve pretty much only provided a tool that makes it easier for expert users who, frankly, are the users who need the least amount of help in this regard.
That message is clear, no doubts. Giving my full respect, may I ask for the reason?
A better understanding of how OpenHAB is used by the community may be an excellent input for further developing OpenHAB in the right direction. I would call that “customer oriented”. If we don’t know, there is a risk that all developers are doing happy engineering to some degree.
Usage feedback based on the forum activity may be an indicator (better than nothing) but I guess, those people who are present in the forum are not necessarily typical users of OpenHAB.
Don’t get me wrong, this should not sound disrespectful, I just want to have it openly discussed and clarified.
Collecting usage feedback doesn’t necessarily mean that OpenHAB shall spy out its users.
Good point! That means, we might like to collect user data but we are restricted by boundary conditions.
Your initial statement sounded to me like it would be the own decision by the OpenHAB team.
The core concept of OpenHAB (things, items, rules, …) is great as it enables the universal usability for any kind of technology or standard. At the same time, it is bothersome and error prone to edit these data structures manually over and over again when you have multiple instances of the same device (copy-paste-find&replace).
TasmoHAB is estabishing a higher abstraction level which enables automatic generation of the OpenHAB data structures.
Are there any other examples where things, items, rules are automatically generated and not manually programmed by users (regardless of managed configs or config files)?
One of the things that attract users to openHAB is that it’s possible to set up a completely cloudless environment without such tracking. Even the presence of the option of gathering telemetry turns many of our users away. The legal complexities of GDPR also poses onerous requirements on a project such as ours effectively putting this sort of thing out of reach even if we wanted to do it.
There are many existing tools available to ease this burden on the end users.
The standard approach is:
Navigate to Settings → Things → + → Binding → Scan for devices. Any discovered devices will appear in a list. You can zero or more and approve them. You’ve just created the Things.
Navigate to Settings → Things → One of the new Things → Channels. Select “Add Equipment to Model”. Fill out the information and click “Add to Model”. You’ve just created all the Items linked to that Thing and situated it into the Semantic Model. Because it’s in the Semantic Model, it’s also automatically represented in the Locations, Equipment, and Properties tab of the MainUI Overview Page.
Rules tend to be very bespoke but there is the concept of Rule Templates: Rule Templates - openHAB Community. These can be installed from Settings → Automation. Once installed, when you go to Settings → Rules → + you can choose from the installed templates and fill out properties to configure the rule created from the template. JS Scripting also supports npm and jRuby supports gems for third party libraries.
By far, the preferred method for Things is to automatically discover them. No copy/paste/edit. No chance for syntax errors. The devices show up and are approved. Couldn’t be less work.
Manually situating Items into the semantic model is challenging when done individually. And because everyone’s semantic model is bespoke (it’s a model of the physical layout of the you house after all) so it’s challenging to automate that from an external tool. Some configuration is required and, as far as I can surmise, the minimum set of configuration parameters are those that are presented when you click “Add Equipment to Model”.
All of this is presented in the Getting Started Tutorial.
Where is gets tedious is if you have a bunch of similar Things which you want to create a lot of the same Items for. If it’s a modest amount (6 or less let’s say) the above steps are probably going to be the least amount of work over all. Above that there is the “Add Items from Textual Configuration” or the REST API.
All of the above only addresses managed configs but these are built into OH and they are the “standard” way to configure OH.
I’d love to see improvements to this but you can already see there is no copy/paste/edit involved.
For text based configs there are a slew of tutorials on this forum with scripts that muck with the REST API and create excel spreadsheets and stuff like that or create config files based on the Things defined. As far as I’ve explored though these don’t really solve any problems. They mainly just convert the same old configuration requirements from one format to another, making some things more convenient and other things less convenient. I’m not convinced what’s proposed here is any different from these other attempts.
Create your items in code / scripting, e.g. JSScripting and JRuby have full support for creating Things, defining Channels, Items, etc. The advantage of this is the sky is the limit when it comes to flexibility, because you can directly use programming constructs like loops, inheritance, etc to build your things/items. The downside is it’s more complex to get started and there’s no “standard” way of doing it.
IIRC, it was Tasmota that completely dropped the Home Assistant standard support. Though maybe that was ESPEasy.
I know one of them required recompiling the firmware from scratch to get HA support for awhile and then dropped it completely. So 1 may not be an option any more.
