As far as I understood, it really only replaces the sitemap functionality which is allowing to layout items declaratively. habPanel works on html widgets, including js and css directly, which naturally can not be used for native apps for example. habPanel will always stay on its own grounds, but the widget distribution should be improved and unified.
Hi Guys.
I’m new to OH2 and have spent the last 6 weeks reading and trying to figure out how to setup OH2. Via several of the great guys on here, I have managed to finally get a light switch setup and working through the Basic UI. I am retired and if I had the coding knowledge of all this stuff I would gladly jump in and help. I have read a lot of the help files and watched videos on YouTube but it seems there are just one or two pieces of information missing to get you to the end result. I know there are a lot of sensors and modules that can be connected to OH2 but the fine details of getting them connected are missing.
I was wondering if there could be a help section where a sensor was taken from the “box” to all the steps getting it connected to OH2. When first I started using OH, the program would scan my local network and find all the devices on my network including my ESP8266 modules computers, TV and more. Now with version 2.4, the only thing it found was my network printer.
I have tried to set up hass.io and found it way too complex for me to understand all the hoops you have to jump through just to get it up and running. With OH2 almost everything I needed was loaded on the SD card and set up within an hour or two.
I may be out of my league posting this but I just thought it might be good to hear ideas from the other end of the user group (noobs) to help your design decisions for the future. So far I am happy with just using the Basic UI screens for viewing what I have set up so far, one switch (haha) but I think you guys have/are creating a great home interface. From reading the posts above, I can say that I have no idea of the coding you have to go through to keep this program working. I just know what I have seen so far it works!
Thank you
John Frankforther
5 Likes
Nope.
I think that’s a great idea. I always hope to make a YouTube demonstration of setting up a basic home automation setup, taken from installing openHAB on a RPi all the way to making a ZWave sensor work with a rule etc. Having the time to do so on the otherhand is a problem.
Releasing openHAB 3 with a set of premade tutorials? Now that’s something that’ll get new member’s attention.
2 Likes
I think what namraccr want to say here is, that if you have a good UI and a nice pictured documentation, there is no need to be that explicit. And both, the UI part and the documentation part are currently worked on.
1 Like
Though there is a HABPanel viewer app for android in beta I believe.
But it is definitely a code heavy approach to do just about anything that doesn’t come with HABPanel out of the box. It’s amazing what some can do with it but it is also beyond reach for a lot of users.
There are lots of ways to help that do not require coding and which are equally valuable to the community. Helping others on this forum is one, plus it’s a great way to learn more yourself. Contributing to the docs is another way.
This is what the Beginner’s Tutorial is supposed to do. Unfortunately it was never actually finished. Also, to a large extent, the real sticking points for users will be specific to the technology they are using. For example, the types of problems and way to use Zwave is significantly different from KNX.
Those fine details should be covered in the binding documentation.
This is a known problem and there is an issue open. The Network binding’s discovery feature is currently broken. This is why scanning for devices in the Inbox is not showing anything for you right now. But keep in mind, all you can do with the Network binding is detect whether a device is on the network or not. You can’t control your ESP8266 through the Network binding.
@bartus has a good set of videos and the start of a new beginner’s tutorial openHAB Basics Tutorial - (Part 1/n) - Introduction. I’m hoping this turns into official docs at some point.
When you make something full proof, the universe makes better fools.
Thanks for the great feedback.
I have started watching the BK Hobby series a while back as that is how I got the system up and running to start with. Unfortunately, there is where the details end, as I don’t have the type of sensors that are being set up in the videos. Since I have 4 of the ESP8266 boards using the Tasmota software, I have set up 1 switch and 3 temp/humidity sensors to play with. They work great on their own, I just needed to figure out how to interface them into OH. I also understand there are hundreds of sensors out there that can be connected to OH so each one would need to have someone post instructions on how to do that. As I am progressing through my setup I have run across information that I have posted to the community. How about adding a section to the community called Sensors - HOW TO? or something like that and only allow entries for How To’s so it doesn’t get plugged up with questions or requests. Maybe, just maybe when someone gets a particular sensor set up and working ask them to post the instructions there.
For me, I get lost in the screens where you have to enter data for the MQTT connections. I used HomeBuilder to build all my rooms, switches, sensors etc. Much better than hand coding all that myself. Several guys have helped me to figure out that I was putting the wrong data in the Thing setup screen and in the Item entries causing errors in the Log file. Once that was cleared up, no more errors and everything is working.
Maybe I can walk through my switch setup using the Tasmota software, Paper UI, the Items file, the Sitemap file and document what I did to make it work. I could also walk through using HomeBuilder to show how that works in building the Sitemap and Item files.
One step at a time.
Thank you
John Frankforther
1 Like
When you make something full proof, the universe makes better fools.
My favorite quote when software support was my job:
development is the struggle between making something idiot proof and nature inventing “better” idiots
I ment that in a positive way. As in, yes we need to make things dummy/idiot proof yet we should never assume this will resolve all problems.
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
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:
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:
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
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
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
Why just say nope? It seems to be a good suggestion to me. That is a very narrow outlook.
2 Likes
@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
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
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
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.
@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.
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.
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