Just out of interest, how big was you oh setup?
300 lines of items (~250 items)
1500 lines of rules
200 lines of sitemaps
About 20 things
That’s why I’m pushing to get id of .thing and .item files. We will so much loose this battle if we stick to this unbelievably bad implementation (if you want to make yourself a picture, please also check the source code of Eclipse xtend and emf).
HA didn’t go this super scientific way of using a modeling framework and a domain specific language interpreter and parser. They are just using yaml files and parse to python objects. We are doing the same with the jsondb, so it’s really time to bury this legacy.
3 Likes
I see your point about the cpu load but the thing that drove him away was not .thing and .items files.
It was the overly complicated rule language. He was fine with textual configuration because that is what he is doing now.
1 Like
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? 
just kidding… wanted to introduce a bit of humor in this gloomy thread 
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 
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! 
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
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…
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