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.
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.
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!
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.
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
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…
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!
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.
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_markushas 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.
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.
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.
Speaking as someone with pretty basic coding skills, I’ve asked numerous questions and never been told to RTFM or search the forums… safe to say that without the forums I would have found writing rules very difficult or even impossible. With the forums it’s been pretty straightforward.
I’ll weigh in a little on the rules DSL, at the risk of repeating things that people may have said elsewhere.
The Xtend language has some significant limitations, particularly things like the function syntax if you want to factor anything out, and when trying to generalise groups of items.
Having said that, to my mind the JSR223 has many of the same ugliness problems. The bottom line is that we’re using a language that wasn’t intended to be used in the way we’re using it - xtend was originally for making extensions to the Eclipse platform. Javascript was for browser automation (and not a particularly good language at that either), it’s become so prevalent that people are pressing it into service as a general purpose language, and it’s not really suited to it.
I think it’s easy to point out that Xtend is ugly, but compared to what? If compared to Javascript, then not really so ugly - the JSR223 has it’s own peculiarities and syntactical ugliness (I found the same when using AngularJS with Javascript - they had to seriously torture the language to get it doing what they wanted).
If someone was to say we could use Ruby or some other strongly typed language, and it would have all the data types and Openhab classes natively available, then I’d be quite excited. But it’s also probably not realistic - taking any general purpose language and bending it to Openhab use will probably also introduce ugliness and a need to learn a bunch of quirks.
By no means take this as an argument against progress, more that we need to make sure the grass on the other side is genuinely greener before we go there. I tend to agree that for most users some form of UI, drag and drop, configuration type approach will be best suited. The higher end users can probably live with whatever coding language we give them - they’re a smaller percentage of the user base anyway.
To me the real magic is some way for people to make snippets of code that do things (using whatever language we end in - Xtend or JSR223 or whatever), and then expose those as objects to the drag and drop configuration UI. That means that whenever one of our more expert users makes a block of code to do a task they can then expose that to everyone else in the community - and a small percentage of coders can probably make the features that the large majority of users want. Note here that I’m not talking about people coding new bindings or services in Java and checking them in - that’s beyond a large proportion of our user base. I’m talking about that section of our user community that currently write rules in Xtend being able to package up a section of their rules file into some sort of plugin or library that people can use without needing to know how to code in Xtend. That might be wishful thinking, but if we could work out a way to do that, I think we’d be able to enable a lot of our user base to do things they never could code themselves.
This probably belongs in it’s own thread so I’ll be brief.
you seem to be under the impression that jsr223 only supports JavaScript. In addition to JavaScript Nashorn (a JavaScript variant that comes with Java), it also supports Jython (a Python 2.7 variant that runs on Java), and Groovy which I don’t know a lot about.
-there was effort to get jRuby to work too but technical challenges arose and the work was abandoned.
the issue of strongly typed versus weakly typed is philosophical with no real answer.
when the whole project can move to Graal VM in newer versions of Java we will be able to support even more languages.
in all three currently supported languages all the core Java classes are available for use. Many core OH classes are also available for use.
the ability to create and distribute Rule Templates is a key feature of the Next Gen Rules Engine and pretty much everything is in place to support it already except for an easy way to create them and a way to distribute them.
What most people seem to forget, probably because the documentation is not there (but I’m working on it): You can write your logic also in Java.
Java is already a very simple to use language. And it has very powerful means to hide complexity via annotations, e.g. something like this is possible
@OpenhabExtension
class MyLogic {
@ThingReference(uid = "binding:thingID")
Thing myThing;
@Every(10, TimeUnit.Minutes)
void checkWaterLevel() {
// Do something with myThing
}
}
You have full type checking and IDE support, so no runtime syntax errors etc and full debug support on top. You also have full access to all Core classes and services, your code runs native with full speed and if you indeed do something “stupid”, Core can protect you and output meaningful error messages.
Maybe another way for openHAB to not die is to build up on this, because HomeAssistant and python cannot provide live debugging and step through from within an IDE. Let’s use our strengths here.
(I want to point out here that Jython has annotations too and with the helper libraries it is also very easy to use. Just doesn’t provide live debugging.)
Why is this topic focusing on the rule language?..
Ofcouse, rules are a major feature of a smart home system. But without a prober interface and huge support of things, how important is a strong rule langauge then?
We still have more bindings than HomeAssistant and adding about 2 per month. It’s not the problem of not having enough “Things”. We also have a proper interface. The binding interface in its basics hasn’t changed since about 2 years.
In my saying, it is not a competition. It´s basic requirement for any smart home system to support alot of things, (devices etc). I couldn´t care less if openhab got more binding than HA, if it means it doesn´t support whats needed. So it´s not the actual amount of bindings which is important.
In my opinion, a smart home system should:
Have a huge support for devices/things.
Easy to setup and maintain.
Strong possibiliies through rules.
If any one of these dependencies is lacking or struggling to keep up with the needs, the whole system will more or less fail, or be less attractive. Which is why I fail to understand the focus on rules language only.
But this is a general speaking ofcouse.
Sorry, I meant user-interface. Not the binding interface. (I have no idea about bindings are created).
It’s a focus of discussion here because that is where this thread has gone. If you read the full thread you will see that pretty much everything has been mentioned and talked about from OH’s marketing, approval for new bindings, making development of bindings better, UI improvements, etc.
Don’t mistake a few posts focusing on one specific topic to mean that all other topics are being ignored or forgotten.
