Is OpenHab Dying?

Sure, old pigtails have to be cut from time to time.

Yes, so with xtend and its horrible old rules language I can go along immediately. But the textual description of the .thing and .item files, currently offer a flexibility that would not like to miss.

Correct me if I’m wrong, but autodiscovery only works up to a certain level. For one technology better for the other not at all. From this point on, you have to work by hand.

I’m just imagining Things and hundreds of Things/Item links clicking together by hand in one interface. This is no fun!

But if you make such a statement, you surely already have an idea how it can go better. How can it look to use only the jsondb? How can then not automatically recognizable links be implemented?

Yikes… this is funny because I wrote this comment a few weeks ago

I have noticed two main concerns with openHAB.

1. Execution and start up speed

Just to be sure we are on the same side:

I do like if a system can represent its configuration in a human readable form, so yes I think providing configuration to openHAB via files is something that we must keep.

Jsondb does something seriously wrong that need to be fixed for OH3. It doesn’t differentiate between runtime and static configuration. Therefore it is currently not suitable for directly editing or even backups.

But we to get rid of all xtend, old rule files, .thing and .item files and use better replacements: Java native script engine, java rule files (possible with Java 11: https://www.baeldung.com/java-single-file-source-code), json/yaml files for .things and .items. No sitemaps. I know that OH1 people will strongly disagree, but seriously those are the only ones left at some point and everyone else is at HA if we don’t act.

2. Ease of use

Most people probably know about my ambitions in this area, so I’m not going to make any more comments here. But we do need an appealing UI for easy tasks. Just textual will not cut it. The optimal case is if what the UI produces can be exported as textual. That’s what I was heading for with my design study.

13 Likes

So, coming back to the original question, I’d like to sum it up:

No, openHAB is NOT dying!
We won’t let it die (corrected typo)!

10 Likes

Dy or die? :stuck_out_tongue: just kidding… wanted to introduce a bit of humor in this gloomy thread :slight_smile:

3 Likes

OH will not die, because…
first, it’s a great application.
Second, it has a superb community with great ideas and solutions.
Third, has many excellent developers and maintainers available.
Fourth, and in my opinion the main reason: the damned and unreasonable manufacturers will never agree on a few, already existing, standards.

7 Likes

I like writing code. So much more dynamic and flexible but good to the above is a must. Wider audience if its UI driven such as drag&drop rules etc.

FWIW - I moved from HA to OH because the community seemed more helpful :smiley:

8 Likes

I just want to commend everyone who has spoken up here for having OH’s best interests at heart. There’s some frustration, yes, but it’s clear that everyone has good intentions.

It’s great that a contentious conversation here can turn into a fruitful discussion, because people care more about expressing their opinions positively and respectfully than reacting sarcastically and defensively. Above all, it feels like people are willing to listen and consider, rather than stubbornly holding to opinions without giving reasons. As a relatively new user, this gives me a lot of confidence in OH.

I think OH would benefit from establishing user personas that enable everyone to grasp the different needs and capabilities of beginner, intermediate, advanced, and expert users. We could then define what features are available at each level and enable new OH users to start where they’re comfortable and gain confidence, rather than exposing beginners to concepts that they aren’t ready to tackle.

Note that this wouldn’t be about limiting access–if a beginner wants to jump right into expert-level techniques, there wouldn’t be anything stopping them beyond their own comprehension. It’s more about providing guidance and a path, while not inhibiting more experienced users.

Perhaps this has already been done. If not, I’d be more than happy to contribute. I’m far more adept at developing user personas than I am at developing code.

3 Likes

When I was looking at OH vs HA the main factor that swung me to OH over HA was the reliability. I go months between needing to reboot my 2.4 system and it is usually because I am adding a new z-wave device. I am actually much more comfortable with python over java which is why my OH system only has a few lines of Rules code, but my Node-RED is very extensive. I have over 100 items from my OH system that connect to my Node-RED flows. The ease of Node-RED integration, easier OpenHABian installation and high reliability was all I needed to convince me to stay.

I really like the HABPanel over all the other GUIs I have seen and while I am a little bummed that it has not progressed more, I still think the design is much better than anything else I have seen out there.

I think the future for OH is very bright and I am very thankful for everyone who has contributed to it. Good planning takes time and I think it will pay dividends in the end.

4 Likes

There is a software development pattern called Documentation-Driven Development. I think as well that the personas idea is really great.

The idea on how to tackle that would be to actually write the documentation and in the process find out what still is needed for openHAB to make it a well wrapped solution for beginners and experts.

Heterogeneous systems are actually not bad. I’m using the deconz software to decouple Zigbee from the OH core. I have rewritten the developer section a few days ago (soon to be merged) and added a new section to write new “IO Services” (those extensions that integrate into external software like HomeKit etc). We definitely should be open to other services.

But especially regarding Node-Red I’m a bit worried. openHAB is an automation system, and you are throwing that part completely away by using Node-Red. Hopefully we can win you back with easier Rule management and creation with new OH releases.

3 Likes

I can see we understand each other.

No sitemaps, that’s ok too. But here, too, an equivalent replacement must first be created. The first attempt was the Paper-UI Control.

The GUI area has been functional so far, never an outstanding strength of openHAB. But I observe movement in this very important area! :wink:

Now, in relation to the original topic:
Everyone brings what he can. I am glad that new people are finding themselves who can bring in a lot of new professional knowledge and take on responsibility. Getting something to work is not an art, but creating a sustainable architecture over time is professionalism. At the moment something like a generation change or evolution is taking place.

I have the feeling, also openHAB Urvater Kai is glad about it. It was always a mystery to me how he could bear so much responsibility for this great project, sometimes unfortunately too much.

OpenHAB has an ingenious architecture, especially the Eventbus and the modularization how to dock to the Eventbus is and remains an outstanding strength. For me, the level of inner values is the decisive factor in finding further good comrades-in-arms in the future.

Of course, marketing is very important in a somewhat superficial view. IoT is not a matter of days. Anyone who believes, just because news don’t patter down every day, that a project is dying, has learned very little from real life, or is damn young, sorry.

A lot is said here, not only superficially hinted at, in a respectful way - I think that’s how Open Source works. It is very nice to see how openly perceptions are addressed and how many positive thoughts many people have about the further development of openHAB!

Thank You!

2 Likes

I read this a lot on the forum so I guess it must be true. Personally I have no real programming experience. I managed to automate my house using this language. If I open a window, my heating turns off automatically. If I enter a room, lights go on and times are set to turn them off again. If I enter another room, timers in the first room are rescheduled to go off earlier etc. etc. In short, my house works. It cost me days, but it is all working correctly now. From time to time I hear people talking about removing the old rules language. This worries me a lot. I don’t feel like redoing all that work. If the current rules engine gets scraped, or gets slated to be scraped, I might as well start over. At that point I would definitely look into the competition. Not arguing that nothing may change, but please be careful about what features get scraped even if the replacement is better.

2 Likes

You spend days with the old rule engine. You will spend minutes to maximum hours to archive the same with newer technologies. And yes you are encouraged to look at the competition, the idea is that we are ahead of them by the time that happens :slight_smile:

3 Likes

Don’t worry, I may have expressed myself a little too unkindly. Nothing will disappear overnight! Besides, the old rules are not bad. Only if they are to become more complex, there are limits. And the syntax and its debugging are no longer up to date by today’s standards. We have found much better ways to write rules. That’s why we dare to go so far forward… :wink:

Textual:

Or by Paper-UI:

1 Like

Nice, but it is working, so please don’t break it. Furthermore, I highly doubt it would take only hours. That is an assumption that needs validation. I have 5000+ lines of rules file. I don’t think the code is very inefficient. Are you sure it would only take me hours?

Thanks, Good to hear. I look forward to tools improving, but not at the expense of a working smart home.

BTW thanks to all the people working on OH and people active on the forum. I wouldn’t have a working OH smarthome without you guys!

1 Like

I believe the limiting factor is the JVM version. Until we can move to something greater than 8 I think we are stuck with Jython which is 2.7 I believe.

You could have asked. Any one of us could have provided help in minutes.

val sunrise = new DateTime(Sunrise.state.toString)
val sunset = new DateTime(Sunset.state.toString)
if(now.isAfter(sunrise) && now.isBefore(sunset)) Light.sendCommand(OFF)

Please future readers of the forum. DON’T spend hours and hours fighting trying to solve some problem like this, particularly one that is just a matter of knowing how to do something. If you’ve shown even the slightest amount of effort we will be happy to help with the problem, and try to fix the docs if they are incomplete or confusing.

I’m not saying you made a bad decision in switching to HA. I’m also not defending the Rules DSL and saying that it doesn’t need to do stuff like this easier. What I am saying is no one should spend a couple of weeks trying to figure out something so trivial. Please ask for help. If you don’t ask for help, we don’t know where we might have holes in the docs and we can never make them better. Plus, we don’t want anyone to waste hours of their time fighting with an issue that we can provide help to solve off the tops of our heads.

My understanding is they provide a cloud service for $5 per month instead of free, but they do offer a cloud connection service like myopenhab.org.

These statements and all the follow ups are germane to the overall discussion, but let’s not re litigate the issue of text based config files here. We have another thread where pretty much all that can be said on the topic has been said. For this discussion, dealing with all the Xtend based stuff is a target for replacement to avoid some of the problems discussed so far.

I’m probably one of the few people who has anything good to say about the Rules DSL. Most of the people who complain about it are developers. If you already know how to program (doesn’t matter what the language is) the Rules DSL is pretty much a disaster. It’s like trying to carve a sculpture with your feet if you already know how to program.

But, if you don’t already know how to program, Rules DSL isn’t so bad. It deliberately removes a whole host of programming concepts that you don’t have to learn in order to be productive in writing Rules. It’s not perfect and there are many areas where they require knowledge and expectations on users that should not be expected of non-developer users (e.g. the 5 simultaneous Rule limit).

With the helper libraries, I think the JSR223 Rules have caught up in simplification so I no longer try to defend the Rules DSL. But it’s not all bad and it served it’s purpose over the years.

The old Rules DSL support will not be removed without some sort of migration approach. What that is and how it will work is TBD at the moment, but I do not see that the Rules DSL will just be dropped without some sort of migration path or continued support for the language as one among many. However, all the docs and all the new examples will shift from Rules DSL to what ever replaces it as the default. And over time the number of people with the knowledge and ability to help on the forum will become less and less until you are on your own.

Depending on how many Items you have I don’t know about that. Using my own setup as an exemplar (which I think is reasonable) I would expect an efficient Items to LOC ratio to be around 4 LOC to 1 Item (I’m actually around 3 1/3 LOC per Item). So if you have less than 1250 Items I wouldn’t say that your existing Rules DSL Rules are efficiently written. But that’s a topic for another thread.

9 Likes

I agree with this statement, but I don’t feel like it always comes across this way to new users. Not because people don’t want to be helpful, but because the encouragement for new users to search the forums is sometimes too aggressive. As was mentioned earlier, there may not be as many rtfm comments as in the HA forums, but there are still rtfm comments.

I totally get these responses. If you feel like something’s already been said elsewhere, it’s natural to think that others should also be able to find it with minimal effort. In practice, that’s not actually true in many cases. For example, there are numerous discussions of virtual items, unbound items, and dummy items, but a new user might not know they’re all the same thing. That lack of knowledge affects what they’ll find in searches.

Again, I think everyone’s trying to be helpful, but responding that people should search for themselves or pointing to another thread without giving any direction or suggestions can easily come across as rtfm. At the worst, it can convey “if you can’t figure it out for yourself, you don’t belong here.” I don’t think that is ever anyone’s intention in the OH community, but I’m certain that it’s happening at times.

Any programming language and automation system has its quirks, pros and cons. Python for example is infamous to often result in spaghetti code and hard-to-find errors. Yes a number of programmers dislike OH’s rules DSL because it works different from what they’re used to. You need to get used to the way it works to become effective in programming your automation.
Is that now better or worse than Python or Java ? I think it’s neither of this - it’s just different.
I think @lipp_markus has expressed it well here.

Such an experience can be the specific reason for a user to get frustrated and change to HA, but from an objective point of view that is not a valid, comprehensive judgement on the automation language comparison part.

OH also provides several means of getting around this (astro binding with triggers to eliminate the need to compare altogether, JSR223 to provide an alternative programming language, and last not least - as @rlkoshak stressed you just should have asked - many helpful users and example code in this community how it can be done even in OH’s “pseudo-java” language).

I understand it’s tempting to use these figures for a comparison, and to some people this might a reason to change. But again this is really premature thinking and misses the point.

In the long run, it is meaningless if your system consumes 20 or 40% as long as it’s working.
And even startup time is not relevant either because once you’ve overcome the initial hurdles to get your home automation system working (and cease restarting all the time), you’ll want to run it 24/7 and won’t need nor want to restart it except for SW upgrades (which there is not really a need for in OH most of the time).

@tsymbaliuk moved away long ago (at least the forum SW says it’s years we saw him last time) so his experience is probably based on old versions.
Up-to-date, optimized systems don’t consume that much and don’t take that long to restart.
My RPi3 takes less than 15 mins to start (with many more lines of code) and usually runs at <10% CPU. As always, mind the details, i.e. measument method, SW version etc.
(BTW @David_Graeff: parsing .things and .items takes just a few seconds, vast majority of the startup time is rules parsing)

HA has some advantages on first look but as always you have to dig a little deeper and shouldn’t extrapolate first or singular impressions. That however is what many users do, and these are usually the loudest ones, that’s one of the reasons for the impression of the thread title.
Apparent lack of progress due to ESH reintegration is another one.

Just like @rlkoshak I don’t want re-ignite the discussions we had in other threads but
PLEASE people look more carefully and draw the right conclusions:

rules DSL has its cons but it’s mostly programmers to complain because they’re used to different concepts. On the other hand, it’s not programmers we need to attract, it’s ‘ordinary’ users with little or no programming skills, and removing rules DSL will not ‘get’ us any of these.
We should add modern alternative solutions for those instead (PaperUI NG, NGRE, …).

CPU use and startup times are still pain points. Yes I dislike them, too.
But once you properly think about it, in the end, they’re not really important to the average user.

2 Likes

Most of the curt non-helpful answers like “rtfm” tend to be when the asker:

  • has shown no indication that they have spent any effort trying to search or read the manual and want us to do all the work for them
  • has not provided nearly enough information for us to do anything but guess at what is being asked let alone answer.

In both cases then yes, curt “rtfm” or “here’s a post telling you how to ask a question” is often the result. That is why I said, I should have bolded, “If you’ve shown even the slightest amount of effort…”

We don’t have time to do everyone’s homework for them. So show us you’ve at least tried to search and read the manual and we will be happy to help. Fail to do so and we will ask you to do at least that much.

Honestly, it’s not that we expect you to know how to search and actually find the answer. But you do expect that you at least tried to search before you asked. If you ask a basic question and didn’t mention that you did a search and read the docs then we can only assume you couldn’t be bothered.

That may not be fair but looking at it from the other side. When we help people who have shown a willingness to at least try to find the answer then we as helpers know that that user is going to become self reliant at some point and perhaps even turn into a contributor on the forum. However, those who can’t be bothered to search or rtfm first end up becoming huge time sinks who never become self reliant and instead a net drain on the forum overall.

To kind of put it another way, if the asker can’t be bothered to mention what they have done or tired to solve their own problem, I don’t fault the responder for not bothering to provide more of an explanation beyond a link to the answer. What I’ve found is often the next reply is either “Perfect, that link solved my problem!” or “I saw that and didn’t understand x, y, and z.” In the latter case you will find the helpers on the forum will pounce and start trying to help as much as they can.

3 Likes

I agree with this entirely, but I also think we have to be careful not to sound like we’re dismissing or marginalizing new users simply because we perceive that they haven’t made an effort.

Note that I’m talking about a specific subset of users: those who come in with very limited knowledge and experience. They’re the ones who are most likely to ask questions without fully understanding what they’re asking, and are highly likely to walk away from OH if frustration outruns progress.

One-line responses with a link to “how to ask a good question” are efficient and to-the-point from the writer’s perspective, but they’re the emotional equivalent of a parent telling you to clean your room again because it wasn’t good enough the first time. Your parent is probably right, but it doesn’t make for great conversation at dinner time.

Again, I think this is mostly done well in the OH community, but there’s always room for improvement.

I’m actually super impressed with how generous many of you are with your time and efforts in this community after so many years. It’s really easy for me to be here for less than two months and say what I’m saying, but you’re the ones who’ve been doing it. I can only hope that I’ll be able to match your commitment a few years from now.

5 Likes