Directions for openHAB 3

Development
#46

Very true. But here we have the situation that we can observe the most common beginner questions. And if we can avoid 90% of them --> So much relief for the supporters. And people can finally think about cool solutions with openHAB and not how to cope with and workaround its limitations.

If we are facing the truth: openHAB cannot even be used as a simple drop-in hue bridge replacement.

  • No UI controllable timers/alarms/scheduled-tasks (however we end up calling those),
  • no scenes,
  • no unified visual concept (old-sitemaps vs widget-based in habpanel),
  • no easy rules (if motion detected, switch that).

That’s sad. Such a simple use-case (some light actors, some sensors and a way to glue them together) should also be simple to setup.

My vision that I’m working on with my projects is to get to that state with OH.

  • MQTT being the first piece (next to Hue, MQTT is the big thing among IoT devices and DIY devices). So that you can add your Things with a button click.
  • A nice setup&maintenance UI to manage your things and items. No text files involved. And to click and place your rules, install rule templates and so on.
  • The part that I will not tackle, because of lack of time, is the control UI part. I hope that the widget distribution for habPanel can be improved and that Yannick can present a nice UI for controlling openHAB and managing sitemaps and so on.

Because some people here have the imagination of a meatball: No that doesn’t mean other features of OH are removed. Just the above use-case will be easy to reach.

It is also quite sad, that there is no OH visions document that sets those things in stone somehow.

Cheers, David

5 Likes
#47

This thread is about a future version of openHAB and the main concept being discussed here is basically how to make the software easier to set up and use for people who are just starting out. (folks like you @johntech ) Your feedback gives valuable insight to the developers of the software about the common pitfalls encountered by a beginner. Thank you for posting your thoughts on the challenges of setting up your system

There are indeed hundreds, if not thousands of sensors that work with openHAB. The software is designed to be hardware ‘agnostic’ meaning it will work with almost any hardware. (although some things will require creativity) In it’s current state however, openHAB will still require you to do some research on how your individual devices interact with the software. Because there are so many sensors and different hardware that you can use, posting instructions for each one would be a very big job. The good news is that the forum has examples of lots of other people’s experiences doing the same thing and by searching the forum, you can find the help you need.

The forum has a section about hardware in general where you can post questions about individual sensors. It can be found here:
https://community.openhab.org/c/hardware
There is also a tutorials and examples section where folks write up step by step instructions for various devices and software. It can be found here:
https://community.openhab.org/c/tutorials-examples
As an example, here is a thread where I asked folks to post thier experiences with motion sensors


In that thread, I reviewed several popular brands of zigbee and zwave protocol motion sensors and information about how to set them up is included for each one
Good luck and welcome to the community!

1 Like
#48

Thanks Andrew! The main reason for using the ESP8266 modules is that I can have multiple sensors connected to it. I can have switches, temp/humidity sensors and even motion sensors all at the same time. Given the diversity of those modules, I still need to find a way to connect it to OH so it will work. I will have to check out your discussion on Motion Sensors. The grandkids are always leaving the lights on in different rooms of our home and I have to go around turning them off. It would be nice to add a motion sensor and relay to control that.
I am a retired electronic tech so using the ESP modules is a cheaper alternative to the high dollar sensor that only does one thing. Chances are that those modules are controlled by the same ESP chip with proprietary software loaded on them. I will continue to support OH as much as I can.

Thank you

John Frankforther

2 Likes
#49

Please forgive me as I think I have over stepped my boundaries with comments in this forum. I am not a developer, as this is a developer forum. I wasn’t asking for specific help with the ESP boards just a possibility for future options.

Thank you

John Frankforther

#50

Why just say nope? It seems to be a good suggestion to me. That is a very narrow outlook.

2 Likes
#51

@johntech I don’t think you have any reason to apologize. This forum is for everyone, not just developers. We welcome (respectful) feedback from newcomers, even when it’s not possible to execute all the ideas.

It might be a good idea to open a new thread if you’re taking the discussion away from the original topic, but I think you would find people here would love to give you feedback and help with your project. I actually am working on something similar using Particle boards and MQTT.

Check out this thread for some best practices on interacting with this community.

Please don’t judge this entire community on one comment. Most of all, welcome!

9 Likes
#52

There has already a Tutorials and Solutions category where postings like this would go. Sorry if patrolling the category and deleting posts that don’t fit I can’t see how we can limit it.

If you search the firm for Tasmota you will find more than one tutorial telling you how to use it with OH. For example, Using Sonoff Power Switches with Tasmota firmware and openHAB2 MQTT2 binding

Also, there are literally tens of thousands of supported devices, and that’s just counting the commercially available ones. There is a near infinity of devices if you count DIY ones like an ESP8266. You want a separate end to end tutorial for them all? That’s just not feasible.

What is feasible is what we have. General purpose documentation that covers the common stuff, specific documentation in the binding docs, and tutorials on the forum that various users have volunteered to post.

In my experience we can avoid 90% of of them but then 90% of those get replaced with new beginner questions. That’s kind of what I meant by the quote. We still have a net gain of 10% so it is well worth doing. But especially for a system as open ended and complex as OH, we will never get it down to 100% intuitive and easy to figure out by the new users.

I totally agree. Don’t think I’m arguing against the proposed improvements. It’s just that I don’t see them as being a complete solution because a complete solution to avoiding beginner’s questions because that is impossible.

True, but when you are taking on DIY sensors and electronics you are in many ways stepping outside the scope of OH, at least in terms of what support you can expect from this forum. We are not generally DIY electronics experts (though there are many on this forum) and there is a near infinity of ways to build and connect them. To just list the popular ones I’ve seen mentioned on this forum:

  • MySensors
  • Tasmota using MQTT
  • ESPEasy using MQTT
  • Tasmota using HTTP (I can’t remember if ESPEasy has HTTP)
  • Serial connection to Arduino
  • custom written firmware
  • Raspberry Pi (or other SBC) with Python scripts

That’s seven different ways to connect a single DHT22’s reading to OH, and the last two could actually expand to dozens depending on how the developers decide to have OH communicate with it. That’s just the commonly used ones. Which one should we build the end to end tutorial around?

Can there be end to end tutorials, of course. The Beginner’s Tutorial is supposed to be that and there are several others posted to the Tutorials and Solutions category. Can we ever cover an end to end tutorial for every possible combination of sensors and actuators? No. We can’t even built a complete list of supported devices. The list is constantly growing. It would never be complete.

1 Like
#53

Areas for improvement that I see are related to item (device/control) description (functionality) and locations (areas/rooms) which would make rule development and reuse much easier. Currently, OH has very little idea of what an item does (current types are not descriptive enough). As well, OH has no concept of areas and an item’s location.

For instance, it should be easy to tell OH to turn off all the lights in the basement. The logic behind the rule is simple and could work regardless of the underlying lighting system if OH has the basic concepts of what is a light and what is the basement.

Or, how about turning on outside lights at sunset and turning them off at sunrise. In OH this requires a lot of understanding to add the lights, setup Astro and add the right items, and then connecting that logic in a rule. That was my first OH project and I was probably 3-4 hours from starting at the PaperUI to actually having a working rule.

I really think we need better item ontology and the concept of locations/rooms/areas.

3 Likes
#54

Have you looked at HABot and the corresponding semantic tagging? HABot Walkthrough (1/n): Introduction and Installation This is a first step to directly address this topic.

#55

@rlkoshak, yes I have looked at HABot in detail. I haven’t used it yet.

I would argue this should be a core part of OH with formal guidelines on how to accomplish this. Right now we have a variety of approaches to item tagging (using item Tags or Metadata) and they don’t necessarily use the same semantics.

#56

I believe incorporating support is on the list of features for the replacement to PaperUI that will be part of OH 3. And there already are guidelines for how to apply the ontology to Items. I think the semantic tags go in tags and the synonyms go in metadata. The current .items file syntax is really not sufficient to support this, but the config files are also going to be addressed for OH 3.

Normalizing on tags will require coordination across multiple bindings and consequently development teams. I don’t know if the core can/should say “thou shalt” or whether the bindings will have to decide on their own to normalize, or if normalization is even possible. I don’t know all that goes into the choices in tags and how much of that is driven by the service (e.g. Alexa, Google Assistant, Hue Emulation) that it integrates with.

#57

What I’m hoping for is that the semantics would be a natural part of defining your items, so you would get HABot functionality without much hassle. This should IMHO be one of the goals of a new administration UI.

Edit: not only HABot of course, but also Alexa, Google, Siri and others since ideally we would agree on a set of tags based on what each platform offers and requires. Then, again ideally, no matter what “assistant” you use, a similar query would resolve to the same items.

3 Likes
#58

WOW,
I am not sure how I missed this here.
There is even an Architecture Council.

So I ve many points for OH3 and I agree the UX is really bad. This needs to be Priority 1:
Make OH easy to use.

2 Likes
#59

There is an open bug report where I have discussed with other users to use item metadata for some hue emulation internals. While we are on it, I think I should also look into what the semantic tagging framework provides for us to maybe auto expose certain items.

I agree.

1 Like
#60

Certainly Items can be more clearly defined. A light switch (for a basic on/off light) is simply that - a light switch. That can easily be expanded to other types of lighting (dimming, color). OH wouldn’t need to know what the underlying bridge is (just as it doesn’t know for current items). But if OH knew it was a light it could turn off all lights.

Currently, we are using “Dimmer” to represent a volume control. Presumably that was done for UI reasons but it makes no sense at all.

Expanding the list of predefined item Types, done properly, would greatly improve usability.

#61

I don’t see why this couldn’t mostly be solved with an expanded list of item Types. Why would we have a user pick a “Dimmer” item type and then have them Tag it as “Volume”?

1 Like
#62

You’re gonna have to tag it’s location anyway, so what are we really saving? Personally, I’d rather see Dimmer renamed to something more generic like “Level” than see a proliferation of Item types which ultimately just end up being different names for the exact same functionality. I don’t know if there are other current Item types that are not sufficiently generic also, Dimmer is the only one that comes to mind.

But I’m not going to code it so my opinion doesn’t count for much.

There is a very real benefit to users, particularly new users, by limiting the types of Items that they have to choose from. If you define a Dimmer and a Volume, what is a new user going to think when they want to represent the level of their oil tank? They won’t see an OilLevel type and assume we don’t support it.

1 Like
#63

Because then you would have dozens of item types, possibly in a (object-oriented) hierarchy, and it would be a mess if not introduced properly to users. Hierarchies usually are hard to grasp - a limited set of ‘primitive types’ however, along with a ‘kind’ which gives more information about their nature is a good compromise.

#64

That doesn’t make sense to me, to say we shouldn’t have more item types, because someone has to tag an item location?

There easily could be a generic level type, but if there wasn’t the number type would cover that.

A greater selection of item types if done properly, doesn’t add complexity, it reduces it.

That’s partly what the Homie MQTT specification does.

#65

Well, as with anything in an opensource project. If you feel strongly about it, open the issue or even better submit the PR.

1 Like