Upgrade or move to Home Assistant?

Lucky you I guess. I put the coordinator on a powered usb hub, tried usb3 and usb2, tried different length usb3/2 cables, to no avail. In the end, openHAB must’ve been the culprit.

It’s not that odd when you switch from OH3 to 4 and the upgrade being tedious because it fails without additional preparation and/or work to fix the botched installation afterwards. I gave OH4 a shot because starting from scratch was the better option anyways. After experiencing old and new problems I started looking for alternatives to at least try out, running both OH4 and HA side-by-side for a while. Switching from OH to HA was in fact easier than switching from OH3 to OH4 and troubleshooting my existing setup as to why things stopped working or didn’t work as expected anymore.

My new OH4 ran on 64bit Debian and 64bit java, this did not fix my issue. Also, it wasn’t even on first run but the delay appeared every other day even without a reboot.

I think my main point is that OH is an all volunteer project. The only way OH gets better is if the community pitches in and helps. You kind of robbed us of the opportunity to make OH better for everyone and then you turn around and blame the community because the stuff you failed to report wasn’t working.

If it didn’t work for everyone you can bet it would have been fixed. When it doesn’t work for a small minority of users, it’s harder to fix but it’s down right impossible to fix if it’s never reported.

The first run of a rule happens after it’s been reloaded. So every time you open (due to a since fixed bug) or save a rule with or without changes means the next time the rule runs it will be the “first run”.

If rules are taking a time to run without being touched, that’ often a sign that you’ve run out of resources on the machine. The limited resource is usually RAM and the delay in that case is coming from the use of SWAP.

As much as I agree that OH is a volunteer project, the majority of people (the end users) might not care about that as much as this community do, especially if it does not solve troubles for the end user (if it happens).
For the later part of above paragraph, about robbing, I think its simply inappropriate. I hope this is meant to be your personal opinion Rich, and nothing else. Blaming someone else or external factors will not lead this discussion anywhere.

Not true: https://github.com/openhab/openhab-addons/pull/11718#issuecomment-1888797027. SMA Smart Meter binding is completely broken for years. I even made a post with full chronology of this issue. And fix was available within several weeks issue occurred.

And yes, we can again say - its community project. But who cares about that, once it doesn’t work?

1 Like

Unless otherwise stated and made clear, all postings, utterances, and words posted by me are my own opinion and are not those of the openHAB community, openHAB foundation, or anyone or anything else.

If you think my post violates the code of conduct of the forum I’ll gladly remove them.

Ironically, that’s kind of my point. OH is being blamed for inadequacies that it never got the chance to correct because it was never reported. No one can guarantee that it will get fixed if it’s reported. But I can guarantee that it will never get fixed if it’s never reported, particularly if it’s a subtle issue few people run into.

I don’t blame @HanMandled for having the problems in the first place. I don’t blame them for moving to HA because of those problems. But you are darn right it is my opinion that they bear some responsibility for never having reported the problems in the first place and then blaming those problems as the reasons to drop OH. In my opinion, that doesn’t seem like too much to ask.

1 Like

I might read your message counter wise. This is free software and user can abstain from reporting issues. Instead of making assumptions, maybe we will dive into sequence of “why” questions? The foundation misconception presented above is that only reported issues are being fixed. If maintainer is present, issues do not even reach github as they are being fixed as part of updates done with i.e. new features. In case when maintainer is gone, and there are some cases such this, it doesn’t matter if issue is known or not serious or not, it will remain open for very long time.

I don’t think you overstretched community rules. However, this is a topic about people considering to change, so I’d be extra careful with any blame reasoning towards end users, especially in context of what lead them to change. Clearly there is a circle - lack of maintainers, dropping quality/innovation rate, resigned users. I believe this been discussed in marketing topic, thus there is no point in bringing it back.

1 Like

I can think of two possible causes, in case others have issues, as you no longer need help.

  1. USB hard drive of some kind connected to the USB3 port can create radio noise that wreaks havoc with zigbee radios. The problem and solution is well documented, just not well known to end users. If you purchased different hardware or physically changed the way it was plugged together when you moved to HA this may be the cause.
  2. Its possible you have a zigbee router or device that breaks the zigbee standards (a lot of the cheaper ones do) and HA has implemented a work around of some kind that is missing here. You could try zigbee2mqtt and use that instead to see if the network issues stay the same or change. Both OH and HA support zigbee2mqtt so it would make a good fault finding step.

I also have an Ember zigbee network working very well, that never breaks, and it is always flat batteries that’s the cause of minor issues. I have not been hit with any breaking changes in the 3 years of use of Zigbee and it is hands off till a battery is needed. If you now have the same using HA, then I am truly happy that you have a working system that never needs changes to stay working, that is all that matters.

It is pointless to try and convince a person that has already left and is happy. Any form of defense can be seen as an attack and can turn other people away. The difference between defense and offense is which end of the stick your at :slight_smile: @HanMandled is just defending their choice and your seeing it as an attack as your at the opposite end of their “stick”.

We have people that come the other direction and say the same things about HA as they had a bad experience and left to come here. Its going to happen.

Smartthings does as well as Homekit, Google Home and Alexa. This is being worked on for OH and will get released when its mature, stable and passes our QC. Whilst Matter support is ‘out’ in HA and the other platforms, from what I hear from 2-3 months ago it could be considered BETA, not the fault of HA and others, but because the matter standard kept changing and what some manufacturers are doing by not following the standard or its their interruption of the standard. I’m not following it closely and I’m sure it will improve over time. For now there are not many devices that you can actually buy, and the ones you can, cost 3 times as much as a zigbee version. Zigbee is fully private, mature and cheaper so gets my vote and dollars.

@AndrewFG has done some work getting this going, any chance this can be released via the marketplace so users can trial it or better it gets merged? Basic stuff like this makes users find HA easier and we could have the same thing going here.

Agree and there are plenty of other reasons why issues, documentation updates or new features don’t get submitted or approved. Its a shame that 1 persons comments can totally ruin the motivation of a volunteer. Hopefully mine and others here which are all valued do not feel this way.

7 Likes

Unfortunately the PR is in deep hibernation. The Java code is fine. But the issue is that the upgrade process requires shell scripts and batch files (or whatever) to do the actual installation, and as we have so many OS variants and sub platforms it is pretty much hell on earth to code it.

By definition a domotic system has interface with hundreds of different device types. Not being able to react in time to API changes is a major reason for OH users start looking for alternatives. This is not a toy, it’s becoming almost mission critical. I would love to hear from OH core team how they plan to cope with these increasingly fast changes. Is a pure open source model adequate ? I don’t think so

I’m not trying to convince them. I hope they are happy. But misstatements and miss characterizations that are left unaddressed get read by future readers of the forum who then make decisions or try to do things in suboptimal or impossible ways. because of the missinformation.

The OH Foundation, as it is incorporated as an entity in Germany, cannot pay for development of any kind.

hmmm… really?
I can’t say but from the responses here, I get the feeling OH is more complex and people don’t want to spend a lot of time.

This statement I agree with. Once a home automation system is set up and running, if it breaks down, for whatever reason, it is a problem. Stability is paramount.

It seems some folks run OH versions for years without upgrading. If it isn’t broke, don’t fix it. In many facets of life, this holds true but when it comes to software, skipping upgrades for years at a time always comes to grief.

You could make use of openHABian. It doesn’t cover all platforms but the most prominent ones, and has those scripts available as functions.
But that now really is off topic.

2 Likes

This implies never upgrading device’s firmware. It’s an option, until something forces an update (like old java not supporting new authentication methods), and then you are in a difficult situation.

I’ve found relatively simple to upgrade from OH 2 to OH4 as soon as a new stable release is published. Starting with OH4, I’ve installed every milestone release. There were lots of breaking changes, so I had to deal with small changes every time. If I had waited 3 years to move from OH2 to OH4 directly it would have been a nightmare. My option (it doesn’t mean a generalized one) is to move progressively.

I don’t think that OH is more complex than HA. Sure, in HA there are more pre-built things, but when it comes to automations you have a vast catalog of cards. It’s not easy to pick the ones that suit you best, and in some cases you have to modify an existing one, and this seems to be very complex. Lot’s of HA users prefer to use NodeRed to avoid this complexity. Frankly I prefer a more basic system like OH where I can do what I want very easy.

The posts from people that moved from OH to HA also reveal that they do not believe in OH’s future. I don’t know what wheighted more in their decision, if this or HA’s apparent simplicity. But I understand why they say so.

For example, I use TAPO switches. I am not going to update their firmware for the time being because a new binding version is needed. But what if I need to buy more devices and they come with the new firmware installed. Right, I can install a jar in addon folder. But this should not be the case. I really can’t understand why the pull request approval process takes so long. It has been there for almost one month. It’s all right to use addon folder and jars during the development process, for updates it’s not acceptable for long periods IMHO. And what if the binding author has a problem or decides to leave ? Who will take care ?

I really think that, sometime in the future, OH has to evolve to some sort of paid model as HA and Homey have done.

I think no

1 Like

So do I.
I’d even see OH staying free as a chance of people to move from HA to OH at some point in time, maybe when NabuCasa attempts to squeeze more money out of HA.

1 Like

Yeah I got those. And Windows I think.

This is not as simple to answer as you might hope or think. We cannot tell anybody to take over an unmaintained binding. This can only be done if you pay for it. Furthermore, you have to find someone who owns that type of hardware. Development without having the hardware at hand can be really painfull and time consuming. I know what I am talking about, as I did this with many devices supported by the Wemo Binding. One reason for not having the hardware was there have not been European versions, just US ones and it was not worth for me to buy those, just for development.

If it is coming to updates cause of core changes, I have seen a lot of fixes/updates provided by our maintainers. They really care about not breaking stuff. But they cannot provide updates issued by vendors changing their APIs or firmware.

2 Likes

So probably the best strategy is to have two systems, one for production and another for testing, and do not update device’s firmware.

Sometimes users fund the binding developer, it happened with the Tapo binding.

I know, received a bounty for the Wemo Binding myself. But this is not usual.

I am not part of the core team, but what you’re worried about is nothing to do with the openHAB core. An outside API change is purely about bindings/addons/integrations. To use a recent example of how openHAB can respond quickly, is a Reolink camera user brought up issues due to the API changed to a V2, within a few days of knowing about the problem, I had fixed the issues and supplied a fixed jar that can be dropped into a folder and the problem is solved for the user/s. OpenHAB is fantastic for this as parts can be ripped out and replaced whilst it is running and even no reboot needed. You can stay on the stable core and just swap out the module that is causing you an issue.

The problem is having enough volunteers, especially as you need a volunteer that has that exact piece of hardware or uses the cloud service etc… People could crowd fund hardware to gift to willing volunteers, it is just up to the community to volunteer to organize that. The loss of coding volunteers can be from sickness, busy with starting a family or new job, to the volunteer not getting code accepted and merged feeling their hard work is wasted. We need to constantly attract new volunteers to replace the ones that get lost for whatever reason, and also fix any reasons they leave that are in our control to change.

The other factor is quality control, to then get changes merged we have a strict QC that requires a volunteer to go over every line of code and then approve it. Not many PR pass without needing to make changes here at OH. This means it takes longer but we will get less breaking changes and less bugs due to a person suggesting a better way to implement something that the writer did not consider.

Compare that to HA since this is the reason for the thread…

HA makes you have to approve 2 other PR, before you can get your own approved. So the person doing the review may not be the best person to do the review, or they may want to do bare minimum to someone else’s, just to get their one merged. What will the result will be? Faster changes merged, but more bugs and breaking changes. I just checked 5 random PR for HA, and all of them had zero feedback and zero requested changes and just got approved. Which way is better? Whilst it may be painful to wait, you do not have to with openhab, as you can just drop in the jar file or install from the marketplace. Of course this can be improved in many ways but that’s off topic. @moody_blue it’s great that you care, so will you and others help to improve something? If so link at bottom of this post.

Nothing stops end users from starting a crowd funding project, raise money and pay/tip/gift hardware to a developer. In fact we already have the bounty system setup for many years now, but if someone wants to setup another way, the only thing stopping it is a volunteer willing to step up if the foundation legally can not do it. There are many different ways to fund development, or reward volunteers to encourage them further, it does not have to be the same as other projects. I want openHAB to remain free, but if there is a way to tip to reward that also includes the reviewing volunteers, the ones that write guides, do an awesome job helping on the forum ( @rlkoshak), and fixing documentation, then I am all for it. Maybe a yearly award/gift to the person that contributes the most in each key area.

5 Likes

The donation link works but not the BountySource one.