I like to comment on that: My topics always started with “Suggestion” or “Proposal” or “Personal idea” or similar. It’s very unfair if in retrospective people say that I have spoken for the OH project or anything similar. My ideas have flaws from time to time and without Kai or Wouter or other developers I wouldn’t notice them. It’s always team work.
Not entirely true. You can write a binding in any of the supported script languages (python 2.7 and javascript ES5). Hopefully we can change our java requirement to Java 9 at some soonish point so that we have javascript ES6 and python 3-like syntax. And yes someone would need to write a howto.
Core Development discussions are not allowed in this community forum. The organisation is not allowed to support core development in any way as that might render their tax-free organisation status invalid. That’s one reason why I stopped starting threads in the developer section as soon as I have been told about the situation. That reason might have decreased activity.
I was not invited to the discussion or asked by the webui team about my opinion, they clearly don’t want to collaborate. I was also not informed or did see the hidden work by Yannick when I started my UI. It mean it was work behind closed doors. In an open source community. Stupid if you ask me. And not the way I want to work on OH or with the community.
To round up this post now my personal view on the OPs question.
I’m also afraid of OH dying. And because I spend quite some time on it, I’m doing my best to prevent that. It is true that HA provides the better initial setup and an easier way to contribute because of Python.
That’s why I’m working on:
Binding development with Visual Studio Code. Super simple to use and preferred over Eclipse probably.
A decoupled setup&maintenance UI. Very easy to use with a lot of help and context assistants and tutorials. Text and click-and-point workflows.
Multiple control UIs. At the moment I’m working on Hue emulation to make Hue apps to fully function with openHAB including Rules, Scenes, Rooms, Schedules. Hopefully Yannick will provide his control UI at some point as well.
A full monitoring solution (ram, cpu time, threads, thing status etc).
An integrated backup system with GDrive (one commercial offering just showcase how that’s done), MongoDB (for a personal cloud backup setup) and files (universal way of backups).
We can only win this (friendly) “war” over HA if we make it easier to have
a working system after installation. For example a drop in replacement for the Hue bridge. In your UI you should only need to accept all the Inbox Zigbee devices. In that process you should be asked if you want to have items created for you. You agree and all those items of category “light” are automatically exposed as Hue bridge devices for Alexa or a Hue app to consume
easy “automation”. That’s why we use this software I guess. Easy tasks done by a click-and-point rule UI. More complex tasks by javascript or python-like scripts.
I just want to make it clear that the quoted part were Kid Squid’s words, not mine. I was quitting and responding to him.
I agree and I hope I’m my response to Kid Squid I made it clear that you did state that these were your proposals and not official policy. But even though you started it, more than once, many users responding in those threads either didn’t read that it didn’t understand it. Kid Squid is not alone in that misunderstanding. I’m not sure what more you could have done to about that confusion but it is clear that many who responded on that thread assumed you were speaking for OH.
I thought that was proposed at one point and rejected. It was my assumption that was one reason why Steve left OH.
It would be fantastic if Python were supported for binding development. Would these appear the same as Java bindings from the user perspective it are we looking at having 2+ binding management systems from the user’s perspective?
Those bindings cannot live in openhab2-addons at the moment. There is no tooling to statically check those and we would need maintainers that are able to read python etc. I was merely saying that it is possible from a technical stand point.
My personal solution would be an openhab2-addons-python repository with some community members figuring out how to setup a good tooling and bundling. Personally I would support that, as that helps growing this platform.
@5iver I believe Scott is actively working towards this with Jython - but @David_Graeff is there a way to do this with Python (so we can use more current ie3.5x version) . Personally I would really like to see Python - it would really lower the barrier to entry.
It’s still Jython. We can only use languages that can run in the jvm (java virtual machine). Of course we could offer network/socket/shared-memory solutions to enable more languages, but I see no benefit to start up the python and node.js (javascript) runtimes additionally except a lot of memory usage.
jvm as the oldest runtime is also the most mature (with the advantage that it is used in enterprises).
That is what I have attempted to provide with my Polyglot binding. The binding requires the add-on to be packaged with docker and works best when leveraging homie for discovery. It has some benefits (easily update add-ons independent of openhab, isolation, program in any language that has a homie library) and some drawbacks (memory usage).
And currently there is no timeline when they’ll support the python 3.6 or python 3.7 syntax.
If you want to use python for automation with openhab there is currently HABApp which has the benefit that you can use any python library prom pypi.
I personally switched from OH to HA after trying to implement very simple thing: turn on the light not on time basis, but between sunset and sunrise. Both sunset and sunrise times were in OH already, but I spend 1 hour trying to find how to compare them with current time. I wasn’t able to do that. Things that looks trivial took too much effort with pseudo-java language.
One more things that I disliked in OH is performance. 40% of RPi CPU on standby, 45 minutes for startup.
Comparing to HA, I wrote the rule I told about (after few weeks, of course) in just 2 minutes. I do even more things on HA and CPU usage is rarely more than 20%. It takes only 3-5 minutes to restart whole HA, 10 seconds to restart automations only, scripts are reloaded immediately. Same with UI schemes, it requires just to press F5 on browser and all changes would be pulled up immediately.
There are branch of disadvantages in HA. First, they store each and every event into database in plain text that leads to enormously large database size, that is used for default graphs, so I forced to flush it every day and thus only 1 day of data is available. Second, backward compatibility brakes are very often. I think, most of the people use outdated version of HA due to this reason. Third, there are no such thing as myopenhab. Fortunately, there are instructions that allow to use direct access to HA from Google Home servers, as a benefit, I have almost no downtime which I had with OH.
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.
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.
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?
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.
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.
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.
just kidding… wanted to introduce a bit of humor in this gloomy thread 
