To 2) A system only seems complicated as long as you don’t know too many answers yet… As I said, maybe the freedom to use JavaScript already helps you?
There are always arguments for or against it. But even with a change you will encounter limits, other limits, which you were not so aware that they exist. I mean, try to address the problems first and then solve them one by one. Go into the depth, we help with all problems.
Why should you have to rewrite your existing DSL rules? Absolutely not! DSL will be around for a long time to come. Even if it can be that they will be announced sometime, the time will be very long until DSL Rules will stop to run in openHAB.
New ones you can write e.g. with JS. And rules that have to be changed can be rewritten in JS.
Not really, no. It doesn’t take long to realize that isn’t actually a great binding. To quote a recent comment from the developer of that binding:
He does not provide a hopeful outlook. My problems with the binding have been patched up with messy rules, added xml files, and a setup that is not very stable in the long term. If I have a device that needs to be replaced I’ll be stuck with a few weeks of reprogramming. It took me over a month the first time and didn’t get easier over time. Example: the method available in that binding to build a group scene (so each light turns on together) involves running a python CLI program with a steep learning curve and very little documentation…
I said “complicated” I should have said “complex” … the amount of stuff it does and features it has gets me going down far too many rabbit holes for my own good. Like I said, I’ve got a functional system in OH and am enjoying and using the automations daily.
Essentially I’m scared of messing with my OH deployment in the same way I wouldn’t poke a bear in the forest. It’s fine how it is, I’ll almost certainly break it if I try anything.
I’ve considered running insteon-mqtt linked to OH. But the complexity of the MQTT binding and having to manually link things/items/channels to a non-standard (non homie protocol) is not worth the effort to me. Especially since I’ve been moving over to node red slowly with my first move being HomeKit…
The node red developing environment works better for me. As I said in my first comment, there are arguments and fixes to everything I have problems with but I personally would rather invest the time into node red.
Another thing that has turned me “off” about OH is using new-ish bindings. My understanding of the milestone builds is they’re generally development/beta versions, not really recommended for full deployments or non-advanced users. Full disclosure: I do not understand the OH development process. I have tried and failed several times to load a binding from github using maven. Some specific examples:
MQTT 2.4. This was released recently, generally works, but I ran into issues immediately. I tried to use the new built-in broker and was left with error logs. Then I tried to use the new MQTT discovery feature which was shipped with a breaking bug. No big issue here, each of these things are known and fixed in milestone 2.5.
The active-development bindings are generally milestone-only. The Unifi binding is currently under development and to use the new version that works with fewer errors than the 2.4 add on - guess what you need to go to milestone 2.5.
the apple tv binding is a new development. It has huge potential and is going to be very cool. Milestone 2.5.
the new work on HomeKit I believe is also milestone 2.5.
So new development is happening but to get involved I either have to wait months for a 2.5 release (then maybe 2.6 if there were bugs!) or I have to run the potentially unstable 2.5 milestone.
In the case of Apple TV, I’ve been running PYATV for months inside of node-red as a command line program with great success. No milestone build necessary.
In the case of HomeKit, there has been a little progress in OH finally but I’ve had a great system up and running inside of node-red… Based on my homekit/nodered tutorial thread I think a lot of others here have been moving their homekit setup over, too.
In the end, I know OH could work - if I stuck with it I could have a good system eventually once development has progressed more. I’ve found fixes for my openhab deficiencies in node red - once I move away from the Insteon binding the only thing left in OH for me is basically timers. It doesn’t seem worth the effort to keep OH running just for Astro and Expire bindings…
But you are trying to change the focus by shutting down and discouraging discussion on any topic that isn’t, in your opinion, what matters most.
I don’t disagree with your opinions or your ability to express them. I disagree with your insistence that in this case what the rules language is not relevant and should not be discussed in this thread.
Why is this topic focusing on the rule language?..
But I get concerned when I see a discussion about which language to use for rules, insted of focusing on creating a UI for drag and drop rules. Then the actual rule language doesnt really matter for the common user.
But I find it strange to discuss something which isn´t a main concern, when other things such as UI´s are in a desperate need of a makeup.
If the UI´s can take care of the rule process like a drag and drop, then it really doesn´t matter which language beeing used behind.
Discussion of which language to use for rules is, in my opinion, a high level discussion, which belong beside any other discussion of how to make opehab better for new/ordinary users, or discussion of whats wrong with openhab.
But question is, if this is a major concern above other things…
I´m concerned that high level discussions may drive even more potential new users away, rather than trying to welcome them at their level which, in my opinion, is highly needed.
trying to change the focus to where I believe would matter most for openhab in general.
I could be wrong
Its me trying to put the priorities into perspective.
But it can also become a signaling problem
Because they´re already advanced users. They dont struggling trying to comprehend openhab.
All of these outright state or imply that we shouldn’t be discussed in this thread. I vehemently disagree and fully expect that stuff like this would and should be a part of the “Is openHAB Dying?” discussion.
They might be making a bet that the cost of migration will be great enough that most users will just pay the money to avoid that hassle. Couple that with the fact that, as mentioned, openHAB isn’t even part of the conversation in home automation communities outside of this forum. I’ve seen a bunch of “Home Automation Comparisons” that all include HA and none of them even mention openHAB. In maybe one post out of 10 on the smarthome and homeautomation subreddits mentions openHAB as an option. This is what I mean by our community not being good at marketing. Those HA users may get fed up and want to leave but wouldn’t even know about the existence of OH because we are not part of the conversation.
I posted another thread already and will repeat it here. If you are at all active on reddit or follow the internet taste makers, please contribute and speak up in the comments. Let the wider community know that we are here, we are active, and we are a viable option.
I believe David already has one written and it’s awaiting approval for merge. One of the improvements that we should see from this big merge of ESH and change of the build system is a much easier getting started building bindings process.
w3schools is a much larger organization with far more people contributing to their tutorials. We do what we can with the people we have and that means not reproducing documentation that exists somewhere else. But don’t confuse bindings with Rules. They are totally different things.
My assumption was hass.io was akin to openHABian. Maybe I’m wrong.
Unfortunately, there are two places where this analogy fails in the OH context. First of all, there is no authority to say what the developers actually work on. So there are no army commanders to direct the engineers to start work on that. But, that also means there is no one in authority to tell that one guy working on other areas he can’t do that.
Honestly, I don’t believe they are. It takes a huge amount of time to monitor threads like these and I suspect most of the developers prefer to spend their time writing code instead. That’s why I get frustrated with “OH should do it this way or focus on this first or else I’ll quit/you won’t attract new users/the apocalypse.” By the time these sorts of comments get made in these threads, what few developers who were following the thread have long since abandoned the thread. It’s just users who are strongly expressing their opinions at each other.
Bingo!
Just to be clear for future readers, you can write rules in OH in JavaScript right now. And in the future, it will be one of the “default” languages instead of Rules DSL.
Write JSR223 Rules using JavaScript would be a good option. Though the JSONPATH Transform and MQTT2 binding should be adequate in most cases. But if you are comfortable in JavaScript, I is (and always has been) an option.
Probably not. Deprecating Rules DSL doesn’t mean eliminating it. It just means that it won’t be the language recommended for use any more. IMHO we cannot afford to force all current user of OH to rewite all their Rules. The developers I know working on this agree and appear to be working towards continue support. It just might mean you have to install something separate rather than support coming with the base install in OH 3.
I’m not arguing that @crxporter is making a bad decision, just providing clarity about some alternatives and options for future readers.
I find a solid backup and restore process and/or running a separate development instance of OH is freeing in this regard.
Don’t necessarily take Lewie’s and my responses as arguing that you are making a mistake or a bad decision. But these posts persist forever and future readers may come to a different decision based on the additional information we provide.
All OH releases are essentially “At this point in time we are aware of no major breaking bugs.” The only difference between a release and a milestone is the release gets a little more testing immediately prior to release. Based on my experience, the milestone builds are no more or less likely to contain errors than the release. And the closer the milestone is to the release the less likely it is to have problems. I would say that 2.5 M1 is exactly as reliable and usable as 2.4 Release and do not hesitate to recommend it’s use, particularly if you use MQTT or Zwave as there were bugs discovered after the 2.4 release that got fixed.
All new development takes places on the next version. Since 2.4 is released, all new development, including bug fixes, takes place on 2.5. If a major bug is discovered, it might be back ported to prior versions of OH, but I’m not aware this has ever happened.
And for OH 3, this too is being addressed, or at least talked about. There are discussions about separating the bindings from the core in a way that would let us choose which version of the bindings we want to install rather than needing to manually install or wait for a new version.
Err…I think you got some fundamentals wrong and that mislead you in choosing which software to run.
As a user, you don’t neither need to mess with Github nor Maven nor wait for another release.
You can simply choose to install milestones or snapshots, just see the install docs how to do that.
We recommend to use stable releases but that does not mean we recommend against using milestones (or even snapshots) in your production.
Milestones are stable to run and freed of first/most obvious bugs.
There’s nothing wrong with using them if they work for you.
You just need to be aware that they’re betas of the new version so there might be compatibility issues you might hit when migrating there just like there can be breaking changes when upgrading between releases.
You can also choose to run snapshots or even combine a release or milestone with the snapshot or custom version of one or more bindings if you think you need the latest version of that.
Again, no Github or Maven involved.
Just like a number of people to complain about rules syntax I think you just should have asked sooner …
@rlkoshak very good points as always. I need to point out that when I got started with OH I didn’t know that JavaScript would be my favorite. My previous programming experience at that point was HTML in junior high and MatLAB in college. I had found shortcommings in HA and was moving to OH so I used the xtend rules as they are well documented in the forums and that’s where I was learning things.
From there I started “branching out” into the openhabian optional installs, found Node red, and got hooked. JavaScript didn’t “click” for me until after having a full setup in OH.
Obviously if someone is a JavaScript pro they should use JSR223 rules.
My reasoning for having to rewrite my rules is not completely to get away from the “old” rules. It’s also going to be caused by evolution of my house, abandonment of the OH 1.x insteon binding, and the desire to add more into my system.
Also if the DSL is depreciated there’s very likely going to be new features of whatever causes that depreciation… At that point I assume users will either run two sets of rules: old stuff in DSL that they are reluctant to change and the “new rules engine” (which is still experimental?) with new features.
Are there even more ways to program rules? The rules link on the “introduction to openhab” page goes right to a document on DSL rules in Xtend. There is no mention of any other language there. There is a link to JSR223 Scripting on the sidebar but honestly I didn’t know what that meant until the last couple of days reading this thread… “JSR223” looks to me like another layer of OH that I don’t fully understand and isn’t well enough used in the forums that I feel like there will be decent support. Everything seems so complex to someone like me who hasn’t used JSR223 and too often you have to know what you’re looking for to find what you’re looking for.
I did ask sooner here. It was my first day according to that comment. Two comments down I was trying to install his fork of the homekit binding (I tried this for about 2 weeks actually) with no success. At that point I didn’t know where to get help - now I know I should have come to these forums.
Even installing a beta binding is something I’ve never gotten to work. I’m sure I’m doing it wrong but reading the forums I decided I may be interested in the apple tv binding which has a link to a jar file and I’m only about 75% sure I know where in my system to put that jar file.
My experience updating from 2.3 to 2.4 was that it broke random of my insteon switches each time I restarted. I eventually got my .items files cleared up and cleared the catch which cleared up my issues after about 2 days of struggle. The risk of another upgrade issue does not (for me) outweigh the benefits of dropping a bug on mqtt or being able to use experimental bindings…
Future readers:
Don’t get me wrong, OpenHAB is a great program and can do many things. At this point in time (May 3, 2019) I am planning to move on in the next few months sometime. The main cause of concern for me are the downfalls of the Insteon binding and my own personal unwillingness (or lack of time) to commit to learning more about OpenHAB. Check with me in a couple more months, there’s a huge chance I’ll have changed nothing.
You are fully right and we are on it. I have started a discussion thread to improve this for the future.
Improve the jsr223 doc and show users that there is more than rules dsl in the docs directly.
It’s always been there but until some recent pushes it’s always been nitch. In the past few months Scott, Lewie, David, and others have made great efforts to improve the usability and capability of JSR223. And the Next Generation Rules Engine, which will let us create Rules through the REST API (e.g. PaperUI) uses the JSR223 languages for custom code AND it both sets run on the same Rules engine. But in answer to your question, yes. JSR223 allows you to write rules using JavaScript, Jython, or Groovy. There are other external tools that aren’t part of the OH project that some users use as well, including NodeRed.
Jerome has started a thread to begin to address the documentation problem and over the next six months or so I expect that we will see many more postings showing those languages instead of Rules DSL. I’ve a task on my plate to add at least one JSR223 version of all of the Design Patterns (where applicable).
So yes, for a time and even now, the documentation and usability of the JSR223 Rules are not as high as Rules DSL. But we are working to change that. And for OH 3, these will replace Rules DSL in those sections of docs. Like I said, none of this is really directed at you because given your path you are heading in the direction that makes sense for you. But a new user on this forum will not have the history or decisions to deal with and choosing JavaScript might be a good choice for them.
The new developer documentation has been merged. It will be amended once more when the migration is complete (which should be in a few days).
@Confectrician I’d say we rename Rules DSL to “Legacy Rules” and put all related documentation in a “Legacy support” section. I’d really not want any new person coming to openHAB to write Rule DSL rules. But yeah have to be decided on the corresponding thread.
openHABian’s counterpart, in Home Assistant, is Hassbian. It’s a ready-to-burn disk image for a Raspberry Pi, containing a tweaked version of Raspbian and a pre- partially-installed version of Home Assistant (in a python ‘venv’). The counterpart of openhabian-config is hassbian-config. All-in-all, very much like openHABian.
Hass.io is unlike anything I’m familiar with in openHAB. It is available as a disk-image for an RPi but, unlike Hassbian, employs two Docker containers (one is Home Assistant, the other is a hypervisor) and a bare-bones Linux OS.
The goal is to shield the user from the Linux command-line and make most everything GUI-based. One of its strengths is the ability to add a major functional piece, like Influxdb, Grafana, nginx, etc, by simply selecting it as an ‘Add-on’ from the ‘Add-on Store’. There are official Add-ons and user-built Add-ons available. Configuration is reduced to filling out a form and, presto, you have nginx running.
The hypervisor can do maintenance chores like create ‘snapshots’ (backups) and even perform automatic upgrades.
In a nutshell, Hass.io and its Add-ons are customized Docker containers. Naturally, anyone who knows their way around Docker, and a docker-compose.yaml file, can duplicate most of this functionality. However, Hass.io doesn’t require you to know anything about Docker.
Personally, I don’t run hass.io but, according to the last published statistics (many months ago) at least half of the community uses it. My own impression is that it’s a clever concept but can be quite taxing even for an RPi 3B. Users who love its convenience but not its lethargic performance, migrate to installing it on a micro PC (like an Intel NUC). In other words, Hass.io is also available as just the two Docker containers minus the bare-bones Linux OS.
So the goal of Hass.io is to create a software appliance. I’d like to see OH move in that direction at some point but there are clearly more important things to do first, and it’s a huge effort.
I think the main point everyone forgets that iot is in its infancy, jeez I can’t even get a Zwave double plug socket for the uk market. I feel it’s just starting to really boom, pushed along by the likes of Apple HomeKit, amazon Alexa and google home.
From a ‘normal’ (and by this I mean no offence, non developer type of person), they go and buy a hue bulb and an Alexa, then they get the bug… just like me, before long they are adding all sorts. Then it dawns… I’ve got an app for this and an app for that I just want it all together.
Ok, HomeKit does this to a degree, but then you have to have Apple TV/iPads to do very basic automations, the same goes with google/amazon. It’s not customisable enough and only really works for mainline big brand retail companies. So they go looking…
I started out with an rf light switch which led to a harmony hub to control my entertainment… now it’s pretty much everything in my house, even my tumble drier and coffee machine.
When I first started out I wasn’t bothered about overly complex rule engines and lovely gui’s for control panels, I just wanted something that could combine ALL my devices.
What I’m trying to get at is I chose openhab for 3 reasons only:
1: it supported out of the box 80% of my gear
2: it was easy to setup and get the basics working
3: it was stable
In my opinion if openhab is to continue to grow these are the 3 most important things to draw new run of the mill gadget guys in. Yes more advanced users may want new rule engines and more JavaScript, but the foundation and building block shouldn’t be ignored as this is what I feel stands it out from the crowd in the first place and the quality and selection of bindings is by far the most important as we all have different gear in the first place.
I feel like I’m moaning, but I’m not, I think openhab is a great platform, and I therefore want it to survive and grow. I will input as much as I can, which will probably be in spits and spats due to work, but I get a lot out of it and it’s free so will put back in where I can. If anyone’s watched the box set ‘Scorpion’ I feel it’s much the same, it just needs a bit more EQ rather than IQ.
Great news as the way it was worded from memory was that future features would be delivered (plural, more than 1) and did not name the feature/s perhaps the scope had not been defined at that stage. Of course written posts can convey confusion, so thank you for clearing it up. I have no idea if in the long run the move to a $5 a month cost is a smart or dumb move, it could go either way and I suspect it could take 1-2 years to know. My concerns would be the same if Openhab took this route. Push requests from entry level coders (I count myself as one of these so I mean no offence) that constantly change code are not the same as quality coders written by a limited number of users that fully test and refine code before it is pushed. I really do hope it works out as I like the fact that there is another package besides Openhab in case my goals do not line up with the direction that Openhab takes in the future. I am more than happy that my choice with Openhab is the better one just as I am sure you feel the same with your choice.
BTW congrats on getting into the list of fastest growing opensource projects on Github. If there is ever a way that both projects can work together please feel free to suggest it.
Yes true and also the fact that as home automation becomes more mainstream and popular the number of ‘noobs’ increases that do not know how to safely secure remote access. Only 6-8 months ago there were a number of HA users that had people hacking in and leaving notes to them that they were open to the world. The statement that the clouds for both HA and OH are “optional” is for some people I feel is wrong as they lack the skills or time to learn how to do it. My personal goal is to remove the need for a cloud which is why I love and hope to check out Habot soon.
I have never seen a single call for donations and that makes me feel comfortable that OH is not Dying and also the cloud has a number of times needed upgrading as it has been growing in use. All good signs.
Maybe you and others should check this first video out and consider subscribing to the channels and like the vids to say thanks for making the videos.
yoyoTech (Spoiler alert he likes Openhab and mentions HA in multiple other videos)
If there was the desire to pay for a developer then presumably we could simply set up a new entity to do that. In the UK one would do this with a company limited by guarantee; it wouldn’t usually be taxed on the contributions it receives (on the basis those contributions are non-taxable gifts). The time/cost/administration of registering as a charity wouldn’t be worthwhile.
I expect this isn’t a runner for a variety of reasons, but if it ever was, and the entity was to be established in the UK rather than Germany, I’d be happy to help with the legal side.
I don‘t think there was a need to pay a developer in the past, so we are fine with the foundation. I don‘t know if there will be such a desire in the future.
Yoyotech MK Smarthouse, and, BK Hobby are active on this forum and I do watch their videos. My comment was meant to be hyperbole and not taken literally. BK Hobby (i.e. @bartus) is the person who got me on the marketing kick in the first place.
All of these changes are great and doing great work and not leaving it oh.
I’m a User since OH 1.6. For me OH is dying slowly. The last Update from 2.3 to 2.4 with the new MQTT almost got me to stop using it.
Why?
OH does strange things I’ve never seen before:
my beloved MQTT is gone
understanding the new MQTT 2 takes me hours of reading the documentation again and again - without this forum i would still be reading…
the MQTT 2 stops working after a while - i’m sending too many MQTT-Actions in Rules - this never happens with MQTT 1
with MQTT 2 the mqtt-eventbus is gone (using MQTT1 with MQTT2 is not recommended)
in Configuration - System - Add-on Management - include Legacy 1.x Bindings is disabled but i get error-Messages in the Log from an old use of max-cul-binding.
I had no luck finding an old .jar Binding File
Settings for Persistence Service MariaDB changed apparently to older values - while running
Network Binding is unable to Discover (fixed in 2.5 M1 thanks to @Rich)
some more i’ve forgotten (luckily)
Text based configuration in OH 1.x was the way go. After a while, the syntax was learned and the system works as expected. OH 2 became automated with Paper UI - but not entirely- you still need to have a text based sitemap. Confusing.
As often pronounced - OH 3 plans to cut off text based configuration. A nightmare if you use hundreds of items - created easily with find&replace in a Text-File.
Can you quote the sections of this thread where people in development have pronounced that?
This conversation has now featured comments from people who believe OH cares too much about text-based configuration, and comments from people who believe OH is completely doing away with text-based configuration. I’m not sure why people only see the one-sided text-vs-GUI claims, yet ignore all of the people saying that OH can do both.
Not gone. There is a behavior that has been part of OH 2 since the beginning that no one realized would impact the roll out of MQTT2. In short, if you have “Show legacy 1.x bindings” turned off, OH will not show a 1.x binding that also has a 2.x version. What no one realized is that on the upgrade it will also uninstall the 1.x binding and replace it with the 2.x version. This one thing was the source of a huge amount of the problems experienced by most of us.
But if you enable “Show legacy 1.x bindings” you can install and run MQTT 1.x just as you always have.
If you are using the MQTT 2 binding, you should be running the 2.5 M1 version. There were tons of bugs fixed in that short month between 2.4 release and 2.5 M1. Do you have the same problems with 2.5 M1? Have you filed an issue?
Why? I’ve not seen that recommendation. Quite the opposite in fact. And there is a way to duplicate the eventbus using a short rule and an event Channel that subscribes to all the topics below a certain point.
That setting does not remove 1.x bindings (except in the situation described above). Fixing problems like this are almost always solved with Clear the Cache.
The big thing I notice though is that all of the problems sited are with individual bindings. While certain bindings like MQTT should be rock solid and reliable (and the roll out of MQTT 2.x was a huge problem and the 2.4 version was neither rock solid nor reliable at the 2.4 release) there will always be a mix in the quality of individual bindings. Every binding has it’s own set of developers and maintainers. Some have been all but abandoned. Some are new and undergoing active development. So there will be problems like these. It can’t be helped as far as I can tell without limiting the number of bindings to just a dozen or so highly controlled and maintained bindings as opposed to the 330+ we have now.
But even for this problem there have been some talk about ways to address it. I’ve seen ideas floated to allow OH to run multiple versions of bindings which will let us break the binding versions from the OH core version. That way we can find and install any version of a binding through the PaperUI interface. I’ve also seen talk of having a rating and comment system so we can rate and comment about the quality and usability of individual bindings.
No no no no! OH 3 plans to change the format of text based configuration and provide a way to migrate your existing text based configs to the new format. The way that text based configs are loaded will like change too (i.e. you have to initiate the load instead of OH polling a directory).
And the replacement for PaperUI will also have text based find & replace in the text configs through the browser if you don’t want to maintain your configs separately in text files. And OH 3 will have a way to do everything through the UI for those who prefer to, including sitemaps (or whatever sitemaps become).
As I said, maybe the freedom to use JavaScript already helps you?