WTF Rules? in OH 2.1

VS Code is an open source multi platform IDE which is not the same as Visual Studio.

You are not required to run an Microsoft OS as it runs on OSX, many flavors of Linux and Windows.

It’s licensed under the MIT License.

It also has support for many other languages and platforms…

The sky is not falling because product development was funded by Microsoft…

No, it is open source, MIT License, and available on Linux, Mac, and Windows. I run it on a Linux Mint VM.

Beat me to it. :slight_smile:

Download the .deb or .rpg file and install through your package manager. Or add the repo and key to your package manager and install like you would any other software.

For me it was already part of the distro so I just ran:

apt-get update; apt-get install vscode

Though I might have added the repo so I’d get the latest version, I’d have to check my Ansible scripts.

You are mixing conversations. I was responding to your “A DSL (language based) engine must have a good IDE tooling.” I was showing that the existing Rules DSL does in fact have pretty good and getting better IDE tooling.

This is independent of any conversation we were having on the Experimental Rules Engine. And the existing Rules Engine is not going to go away anytime soon even once the Experimental Rules Engine is released so creating and maintaining good IDE support for it is not wasted effort. And no one is suggesting that the VSCode extension is a replacement for or solves the goals of the Experimental Rules Engine.

Only binding developers would have two separate IDEs and they make up an insignificant minority of OH users. “Normal” users of OH would only have one IDE, VSCode.

You can go read the issues and PRs on the Eclipse based IDE. Essentially there was an attempt to continue development on ESHD but something broke in version 0.9, an attempt was made to correct it but the problem was never solved. The developers who would have been the best able to corect the problem would rather (and correctly IMHO) spend their time on the Experimental Rules Engine than fighting with the thorny problem discovered in ESHD.

But anyone who is willing to take on updating ESHD they are welcome to do so.

The Issue is located here:

Note though that the Designer code has since been migrated to it’s own repo.

I don’t think Kuba had strong experience with VS, I think he just saw an opportunity to build something and the efforts took off. And it is a good thing too as we were likely faced with having no viable option for OH config editing (both VSCode and Designer work with ALL of the OH conf folder, not just Rules).

As someone who has used Designer since 1.7 and cannot count the number of times I’ve recommended Designer for use on this forum, I can say that VS Code is objectively better than Designer in every way I can think of. It is lighter weight, faster, more attractive, more intuitive to use, has more features, etc.

There is nothing they can do about it. It is MIT licensed. They cannot undo that. They can decide to stop contributions but they can’t prevent others from continuing development nor can they stop others from forking it can going in another direction. They can add proprietary features to it at some point but they can’t take back the MIT licensed code. And the existing MIT licensed code is all we need.

Just to be clear, this is a completely separate conversation. Lots of people currently use NodeRed as their Rules in OH, typically using MQTT as the connection between the two. If you are serious about contributing down this path, I suggest posting on the Eclipse Smarthome project forum and start diving into the Experimental Rules code and open issues to get a feel for their architecture and road map and such.

Unilaterally going off and trying to copy NodeRed in yet another separate rules engine seems like wasted effort to me, though it’s open source so nothing would prevent that.

And sometimes going off and making HUGE changes to the baseline of a project get rejected when they are not discussed with the rest of the maintainers first.

It also comes across as hostile to the developers who have already dedicated a lot of time and effort on an approach to a solution to just show up and present some completely different approach without even giving the courtesy of trying to understand what they have already done and even more importantly WHY they have chosen a given approach.

It may not be intended as such, but it is really insulting because it indicates you do not value their contributions.

But something like Home Automation NEEDS a generic rule engine. These simplified and limited approaches are why so many users abandon SmartThings, Wink, Vera, et al for openHAB. Very quickly the users run into something they should be able to do that they cannot because their rules engines are too tailored for just those use cases those systems felt their users would want to use.

So the challenge is providing something that the layman can be productive in from the start and allows them to grow in any direction they want to go.

IFTTT is very popular but I couldn’t run even a simple home automation system off of it. NodeRed looks simple but don’t be fooled. It is every bit as complex as any generic rules langauge would be. It just does a great job of using visual syntax to build the rules. And I will note that the Experimental Rules Engine is well suited to that sort of representation.

And we are back to shitting all over the community.

I thought we had come to an understanding but I guess not.

Honestly, if you are not planning on contributing something like this back to the OH baseline I am better off spending my time working with those who will.

I was only willing to have these conversations under the assumption that you were planning on contributing back to the OH/ESH community. Since that is not the case, and you do not care what the community has to say anyway, I will no longer waste my time.

I want to spend my time on what will help OH/ESH, not helping you build some parallel system because you can’t be bothered to work with the community and make OH better. Not something based on OH better, but OH better.

You still clearly do not understand how open source communities work. We all want to make our user’s lives better. But your approach only helps your users. It won’t help me. It wont help anyone else on this forum. It won’t help the baseline. So why should we be bothered to help? You don’t care about us?

Goodbye and good luck.

3 Likes

Right, but don’t expect the OH community to help you with your users for nothing in return. We here in this forum prefer to spend our time contributing to OH. It is an OH form after all. It’s not the GaneshAB forum.

This is how open source works. We all help each other as a community to make the ONE baseline better and we all benefit. Why should we help you when you are all but hostile to us.

The openHAB community is all of us.

And it is clear you don’t even want to use OH anyway as most of the stuff that makes it distinct from ESH you don’t like and are looking to replace anyway. You have no understanding of the history of how OH got here, why certain decisions were made or even some of the basics of how OH works. Yet you are ready to replace whole chunks of it unilaterally.

I can’t think of a bigger F@#$ You you can send to an open source community that what you are doing.

So why don’t you just use ESH for your base and stop waisting our time. Or just go ahead and fork OH and start your own forum.

1 Like