We have a bot that does automatically link a discourse topic in GitHub if an issue/PR is mentioned there. At least for me I can say, I follow those links nearly always if there is one, to get more context and understand the use cases. I’d say GitHub is no place for user discussions like this one. In my opinion, GitHub discussions should be on a concrete change of the code that is requested within a specific repository. It’s not for high-level round-up discussions (apart from AC discussions) - if such discussions are about development, they should be done in our development section. If a user feels lost here at discourse and need some maintainer input or desperetely feels that maintainers have to read something or give an opinion, there is the possibility of pinging the maintainers group.
Rich -
All great replies as usual, your contributions to OH and this forum are truly immeasurable.
Couple of thoughts…
Maybe there should be a roadmap/status board that us mere mortal users could look at and see where things are at. I do bounce back and forth between the forum and GH, but I would venture a guess that most users don’t…a simple page that could show whats being worked on, what’s not would be helpful.
And this is where someone like KAI should have jumped in and set the messaging straight. There’s been a big silence from him for quite sometime…it was a bit tough to swallow that everything you knew and loved felt like it was getting tossed aside.
This completely makes sense, but these are compartmentalized so that changes made by these don;t impact the whole system - usually! 
THIS - if we communicated information like this the way @chris communicated what he was doing with ZWAVE the process would have been much better.
I want to make sure this is not an attack on David or anyone else. His efforts will certainly make OH a better platform for us all.
Oh, I didn’t mean discussions like this one. But if there is an issue it pr for a charger that may impact users, talking about that on GitHub will get more traction than opening a thread here is what I meant.
I’m not sure what that could look like and be useful. It would have to be automatically generated. If not it would be seen as busy work by the devs and not get updated. Then one needs to cover up with a minimum set of information to present and I’m not sure that the minimum wouldn’t be too much and we would just be repricing three issues.
Kai did step in on at least one of the forums and I relayed some of the comments he sent to me as well. But it got lost in the hundreds of replies. And like I said, he asked that the threads not be opened in the first place.
Right, but the two things you complained about breaking for 2.4 were bindings.
Ah, but the AC is a developer entity. It’s an arbiter among the maintainers.
Changes to the core are usually well documents and discussed prior to release. See how Member of triggers were rolled out.
Coordinating the testing and documentation and informing the community is an exercise for each individual binding developer though. Some will do it better than others. I think this will always be a weakness in OH’s releases but don’t see any way to address it without massively slowing down binding development.
I would love to see a discourse channel to chat with people in real time would be great. I think the biggest change Openhab could make to ‘fix’ things is to have a NEWS section on its website that is updated with at least 1 post a month and make it easy to find this. The webpage has no navigation menu. If a “whats new this month” post was made it gives the youtube streamers a place to check and use what to make videos about. They make money by making regular videos and if you make it easy for them to learn what is new they will follow. I had a quick look at our webpage and the last blog was from December.
I have felt that as well. But since the forums for eclipse development have moved here it feels like we are getting more binding developers starting out which is great to see. Shame the old build system gets trashed before a new replacement is fully finished.
Yes I agree on the quick and dirty comment, but the lengthy list of rules to contributing to Openhab can also turn some people away. Also HA has an extra dimension to their architecture that Openhab is missing and I believe this is key to why they are gaining users faster. This extra functionality I refer to is if you add a camera to Home Assistant you instantly get a snapshot updating in your UI, then if you click it it opens up to a full screen stream. The alarms are automatically hooked up to alarm code and you have buttons to set the alarm to away or armed and home. This instant gratification for a new user will win them over as minimal work when starting gives them a big jump in functionality. I know that Openhabs framework supports a lot of this stuff already (as I have implemented a lot of it in bindings) but the UI does not respond anywhere near what HA does.
and yet one of the guys trying to fix this with a new UI get stuff like this written about him
really? really squid???
you realize this person volunteering his own person time and programing talent right?
Andrew -
If you are going to quote me, at least have the courtesy of including the whole chain of consciousness…and not cherry picking a part of it to make what ever point you are trying to do.
Yes, I realize he is volunteering his time and I appreciate all of his dedication - I said just that…
For those who only read replies…the full context and my quote is below.
No I don’t believe it will address what I was describing and I suspect the framework needs new features to implement what HA does to create a complex initial sitemap from minimal work. It may be easy to start with, but in the long run both platforms require the same amount of work to create exactly what you want, but a new user just goes WOW this is easier than Openhab. First impressions last, and what I described in my last post is how HA makes a good first impression to someone that installs both to compare… I welcome the new UI changes and wait to check them out as they are sorely needed. One example is tagging a light so google home can use it, the framework already has this taken care of, yet Openhab does not honor and automate the tagging for a end user and the PaperUI can not add the tags manually. Something like this could easily and probably is going to get added into the next paperUI replacement.
@KidSquid is passionate about OH and I think that is great to see as they clearly like Openhab and want to see it improve, however just like others I wish some things posted by multiple people are a little more careful not to attack someone who is willing to donate huge amounts of time and no doubt will do a great job. I gave up reading David’s thread after it turned toxic and the information got lost in hundreds of replies that I simply had no time to read.
Maybe because HA is much easier to use.
I had started with OH and was just messing around to get everything up and running after 2 months of fattening, I tried HA for a short while and in no time I had everything working.
The advantage of HA is that you have everything together in one config file (you can split it if you prefer but that is not necessary)
Especially now that HA also has ESPhome, it makes everything even easier so that you need less MQTT (extra POF). Devices with ESPHome on it are immediately recognized by HA.
I don’t want to say that HA is better or worse than OH, but I find it a lot easier to work (and the dashboard also looks much better with lovelace) than with OH.
Now I also read that with HA you have to pay for the cloud. but you don’t necessarily need that. there are enough options to work around it. and then HA is just as free as OH.
I also read that OH is only maintained by volunteers,
HA is also maintained by volunteers, but I think the comunition for HA is much larger due to the user-friendliness.
In addition, you can also run HA and OH side by side then you can use the benefits of both.
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.
Cheers, David
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.
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.
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.