I find it quite amusing that HA (that is written in Python) is more qumbersome than openHAB (written in java) wrt writing rules in Python (via habapp).
And I have learned to hate java thru the years…
As I probably have became a grumpy old man, I DO really like configuration in .conf files.
Configuration that ends up in .json/.xml files seems to be like a sick joke to me 
Ah, well, the world is not a perfect place, so I am eating camels daily… 
I do consider running HA as a paralell instance to openHAB for some things…
Just to add; I see no reason to switch away from opemHAB as the main automation framework in the near future!
4 Likes
It is completely useless to compare HA and OH in detail, because when two do the same thing, it is not the same thing after all, everyone will use the most suitable automation for their own case.
A few notes / suggestions for OH:
- migration from OH 2 to 3/4 is not completely painless, it is always necessary to adjust the configuration (Rules, Items, Channels, Things) it can be done in a few hours even with a clean installation and hand made migration of historical data - don’t worry it’s easy, but isn’t piece of cake,
- from OH3 is not a completely stable solution for GPIO control, which causes reluctance of some users to migrate,
- system changes from OH 3 to OH4 were carried out continuously step by step, but users were often surprised by the result of the changes, some users stopped updating regularly (for example, some links in Transformations and JS stopped working),
- The model is great, but its correct setting takes a lot of time,
- the quality of the documentation has improved,
- responses to https://community.openhab.org/ have been accelerated
- the mobile application provides much more extensive functionality,
- many positive changes in the main UI and Sitemaps,
- perhaps it is worth mentioning more support from OH for the expansion of integration options:
Tasmota Documentation - Tasmota (many different Peripherals and Components for various Modules, options for basic automation - own Rule)
https://docs.openmqttgateway.com/ (many interesting extensions for BLE, RF and others)
https://homebridge.io/ (2000 potential extensions for OH)
maybe even a less complicated way to integrate MQTT Things for Beginners - I believe that many positive changes will come as in the case of TasmotaPlug - Bindings | openHAB
I think it’s worth noting here that the reason that changed before OH 4 was released is so that those migrating from OH 3.4 to 4.0 and were using JS transformations would not have to change anything. This was a change to deliberately avoid a breaking change between 3.4 and 4.0. Unfortunately that meant a breaking change between OH 4 M2 and M3 (IIRC).
HA has Google fit integration.
In Openhab i wrote a python script that should be launched in the exact Moment when im on the scale and send over mqtt…
But no idea how to read Blood pressure and Heart rate…
I like much more openhab…
But openhab Is dead… 4.1 and 4.1.1 doesnt add nothing new…
Just maybe some incompatibilty with old bindings.
Example: in Amazon Echo control stopped working the last command feature…
There Is a new binding that cannot be merged… Because some object names (or something similar) are not conform with new openhab standards…
So are these the new features of openhab?
I have 3 setup One Is stuck on openhab 3… And i don’t see any significant differenze…
Except that in openhab 4 for several months Sonoff integration was broken…
Please freezer developement, and develope bindings … Maybe open a donation channel for developing bindings…
This is absolutely incorrect, read the release notes and blog post.
This is an Amazon issue the community tries to solve. You cannot blame openHAB for it.
As all developers are volunteers, we cannot tell anyone what to do. Their decision.
Feel free to start something like this.
3 Likes
Perhaps nothing new that you use but that doesn’t mean nothing new at all. Believe it or not, you are not the sole audience for openHAB development.
As @hmerk indicates, it’s broken becuase Amazon changed things. OH no longer conforms to Amazon’s standards.
No, but some of the new features include but are not limited to (off the top of my head and not including bug fixes):
- a much better implementation for units of measurement
- reimplementation of Blockly with almost full support for the entire OH API
- lots of new features for Sitemaps including an input field, button grid, support for several third party icon services
- support for storing future timeseries and use those to update Items; for example you only need one forecast temp Item now instead of dozens to hundreds of Items to track the forecast weather info or power cost info.
- ability to create custom semantic tags and the beginnings of a new file format for text file configs
- a new upgrade tool which fixes breaking changes automatically where possible in managed configs to enable smoother upgrades
- ability to define persistence config in the UI
- ability to define transformations in the UI
- a code tab for Items
- support for writing script transformations in any rules language, not just Nashorn JS
- improvements to the transform profile that allows a different transform to be applied in each direction: channel to item and item to channel
- the event passed to a rule now includes more information about how the rule was triggered even for non-Item event based triggers
- the Scenes rule type
- lots of improvements to the developer sidebar in search
- OH will now scan for devices and protocols and recommend add-ons to install based on what it finds
- support for currencies as a unit of measurement
- integrated help
- ability to cause MainUI to open certain pages by commanding an Item (e.g. bring up a view of the doorbell camera when the doorbell is rung)
OH 4 did not bring in a completely new UI like happened in OH 3 nor was it a complete re-architecture like in OH 2, but there were plenty of changes and new features to justify the new version. Perhaps you don’t use any of these and that’s fine. But just because you don’t use them does not make them not a big deal.
6 Likes
This is an Amazon issue the community tries to solve. You cannot blame openHAB for it.
This is perfectly clear.
In fact, I am very grateful to the maintainer who despite being very busy corrected the software quickly including new features to obviate the limitations introduced by amazon.
I refer to the fact that when someone asked if the new version would be included in the release the answer was:
Probably not. When I tried to re-integrate the
httpbinding ([http] Improve binding by J-N-K · Pull Request #15376 · openhab/openhab-addons · GitHub ), the reviewer decided that the channel-types of newly added channels need to follow the new openHAB naming scheme and have to be re-named. Since this is a breaking change for all users that already use these channels (which is not justified by any technical reason and there are tons of binding with “wrong” channel-type naming in the codebase anyway), I decided to decline that and closed the PR.
p.s. I do not criticize the maintainer’s response.
He is a hero because he solved the problem and also because he takes care of the users.
It is a pity that this great work is not in the final version…
We are working on a solution for that.
6 Likes
links to more details on this please?
1 Like
Thanks! There were quite a few useful things I didn’t know about! Icons on sitemap switch mappings, super awesome for me
1 Like
Another one which is a time saver for me is to change the log level of any binding from the main UI’S Settings page.
These are the best features to get, they brake nothing and just work to add to the experience when you do learn they are there.
5 Likes
Going back to the topic, perhaps we should make a comparison table. Most of the comparisons out there seem biased towards HA because they’re written by people who prefer HA.
So let’s make one, by us who prefer OH, whilst objectively include things that HA is definitely better at. This would serve as a kind of feedback for OH to be aware of areas to improve, if deemed necessary/important for the OH users.
5 Likes
If you’re going to do that, I’d suggest speaking only to openHAB and not talking about Home Assistant or any other home-automation system. Anything we say about them is biased by virtue of coming from a group of people who primarily use openHAB, no matter how objective we try to be.
As well, anything we say about other systems can quickly become outdated/incorrect, because we aren’t investing the same time and energy into using them or closely following their development. Better to focus on what we know, and not worry about others.
4 Likes
I’ve come to think if we should create a new forum category to put up and discuss feature requests ahead of time and to inform users about (fixed) developer plans and ongoing implementation activities.
While there’s Github for all developer stuff, we’re lacking a UI i.e. a user facing interface into development activities.
@Kai if you agree please create one.
8 Likes
I was going to suggest something similar. I guess, since people ask for a roadmap (which cannot be provided), at least we could have a place where developers can post the main topics they are working on. Maybe not open for discussion, but as a means of information.
How would it be managed and by whom? New feature will be worked on, then once it’s completed, or abandoned, the information needs to be updated.
This may be harder to look through but at least it’s automatically updated:
1 Like
Agree that would be great. I am working on a very exciting new binding for the past year and just put it into the marketplace for Beta testing.
I think that at least 20% of our user base will want to use it when done. A place to ask for donations to pay for hardware or software keys can shave months of work off the development time, when it is only 5 hours a week that can be spared before family starts to complain. An area to post what you’re working on and promote and ask for donations. It is pointless having a (now broken) bounty source system, when no one knew what they could support.
It would also be great to know if people want something to warrant the time being spent on it. If no one wants it, then I could just use a script or two and be done and move onto something else.
Agree, because it would be great to find 2+ other people that can work on the development of a certain feature instead of grinding the wheels trying to solve a hurdle that someone could do in seconds. If we work on our own with no one knowing what we are working on, you risk someone else doing the work on the same thing and its a waste of resources, or you can work together and get it done much faster.
2 Likes
I’d suggest the same process as used for the Announcements category and marketplace bindings, where the OP opens and links to a separate thread for discussion. I’d also suggest that moderators have to grant developers the ability to post in it. That’s not to limit what developers can say, but to prevent new people (who are unfamiliar with the community) from posting in it.
I’d add it to this tutorial as a category to watch.
1 Like
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.