If there was the desire to pay for a developer then presumably we could simply set up a new entity to do that. In the UK one would do this with a company limited by guarantee; it wouldn’t usually be taxed on the contributions it receives (on the basis those contributions are non-taxable gifts). The time/cost/administration of registering as a charity wouldn’t be worthwhile.
I expect this isn’t a runner for a variety of reasons, but if it ever was, and the entity was to be established in the UK rather than Germany, I’d be happy to help with the legal side.
I don‘t think there was a need to pay a developer in the past, so we are fine with the foundation. I don‘t know if there will be such a desire in the future.
Yoyotech MK Smarthouse, and, BK Hobby are active on this forum and I do watch their videos. My comment was meant to be hyperbole and not taken literally. BK Hobby (i.e. @bartus) is the person who got me on the marketing kick in the first place.
All of these changes are great and doing great work and not leaving it oh.
I’m a User since OH 1.6. For me OH is dying slowly. The last Update from 2.3 to 2.4 with the new MQTT almost got me to stop using it.
Why?
OH does strange things I’ve never seen before:
my beloved MQTT is gone
understanding the new MQTT 2 takes me hours of reading the documentation again and again - without this forum i would still be reading…
the MQTT 2 stops working after a while - i’m sending too many MQTT-Actions in Rules - this never happens with MQTT 1
with MQTT 2 the mqtt-eventbus is gone (using MQTT1 with MQTT2 is not recommended)
in Configuration - System - Add-on Management - include Legacy 1.x Bindings is disabled but i get error-Messages in the Log from an old use of max-cul-binding.
I had no luck finding an old .jar Binding File
Settings for Persistence Service MariaDB changed apparently to older values - while running
Network Binding is unable to Discover (fixed in 2.5 M1 thanks to @Rich)
some more i’ve forgotten (luckily)
Text based configuration in OH 1.x was the way go. After a while, the syntax was learned and the system works as expected. OH 2 became automated with Paper UI - but not entirely- you still need to have a text based sitemap. Confusing.
As often pronounced - OH 3 plans to cut off text based configuration. A nightmare if you use hundreds of items - created easily with find&replace in a Text-File.
Can you quote the sections of this thread where people in development have pronounced that?
This conversation has now featured comments from people who believe OH cares too much about text-based configuration, and comments from people who believe OH is completely doing away with text-based configuration. I’m not sure why people only see the one-sided text-vs-GUI claims, yet ignore all of the people saying that OH can do both.
Not gone. There is a behavior that has been part of OH 2 since the beginning that no one realized would impact the roll out of MQTT2. In short, if you have “Show legacy 1.x bindings” turned off, OH will not show a 1.x binding that also has a 2.x version. What no one realized is that on the upgrade it will also uninstall the 1.x binding and replace it with the 2.x version. This one thing was the source of a huge amount of the problems experienced by most of us.
But if you enable “Show legacy 1.x bindings” you can install and run MQTT 1.x just as you always have.
If you are using the MQTT 2 binding, you should be running the 2.5 M1 version. There were tons of bugs fixed in that short month between 2.4 release and 2.5 M1. Do you have the same problems with 2.5 M1? Have you filed an issue?
Why? I’ve not seen that recommendation. Quite the opposite in fact. And there is a way to duplicate the eventbus using a short rule and an event Channel that subscribes to all the topics below a certain point.
That setting does not remove 1.x bindings (except in the situation described above). Fixing problems like this are almost always solved with Clear the Cache.
The big thing I notice though is that all of the problems sited are with individual bindings. While certain bindings like MQTT should be rock solid and reliable (and the roll out of MQTT 2.x was a huge problem and the 2.4 version was neither rock solid nor reliable at the 2.4 release) there will always be a mix in the quality of individual bindings. Every binding has it’s own set of developers and maintainers. Some have been all but abandoned. Some are new and undergoing active development. So there will be problems like these. It can’t be helped as far as I can tell without limiting the number of bindings to just a dozen or so highly controlled and maintained bindings as opposed to the 330+ we have now.
But even for this problem there have been some talk about ways to address it. I’ve seen ideas floated to allow OH to run multiple versions of bindings which will let us break the binding versions from the OH core version. That way we can find and install any version of a binding through the PaperUI interface. I’ve also seen talk of having a rating and comment system so we can rate and comment about the quality and usability of individual bindings.
No no no no! OH 3 plans to change the format of text based configuration and provide a way to migrate your existing text based configs to the new format. The way that text based configs are loaded will like change too (i.e. you have to initiate the load instead of OH polling a directory).
And the replacement for PaperUI will also have text based find & replace in the text configs through the browser if you don’t want to maintain your configs separately in text files. And OH 3 will have a way to do everything through the UI for those who prefer to, including sitemaps (or whatever sitemaps become).
Yes, but with updating OH 2.4 it was replaced with the new Version. So it was intended by the developers. So i have to switch over.
This was a good question. I’ll never do that again.
@rlkoshak: Thanks again for tuning in. I’ll try to use OH 2.5 M1 and use your recommendations. The recommendation for not using MQTT 1 with MQTT 2 came from a Blogpost i can’t find anymore. Sorry.
This I can relate to as well. I do not find PaperUI items having a good overview. The same goes with things, but there are often less things than items, and it´s easyer to find ie zigbee things rather than trying to find items related to zigbee things…
I have no idea yet, how I will react, if text based configuration files is cut. I would prefere to have both available options.
I partly understand your question… But please dont use it in general. If nobody upgrade, because their system is working, I would say developement is beeing challenged.
Not actually intended as I described. The intent was that you would be able to install it at your leisure and upgrade on your own time. It was unexpected that everyone’s 1.x version of the binding would be uninstalled.
There are several schools of thought on this one.
Once it works never ever touch it again. This comes with the risk of security vulnerabilities and potential problems arising that it will become difficult for the community to help with because they have long since moved on (e.g. it’s really hard to get OH 1.8 support on this forum now). There are also opportunity costs as new features and capabilities are written that one may want to take advantage of. But if you don’t touch it, the chances it breaks should be low.
Upgrade rarely. This comes with the problem that when you finally do upgrade, it’s usually a pretty significant effort as the number of breaking changes has continued to build up over time. But this lets you gain a bit of control over when you decide to make the upgrade and choose a time when you can spend to one or two days dealing with all the breaking changes. And it lets you avoid living with known vulnerabilities and bugs forever and take advantage of opportunities that arise from new features and capabilities.
Upgrade frequently. Some people upgrade almost every day. Others stick to the milestones. In this situation the number of breaking changes will be very small and therefore each individual upgrade will be relatively painless. However, you will be running on the bleeding edge and face a higher likelihood of encountering unknown bugs, particularly if you are on the snapshots. If you follow this approach you must have a reliable roll back procedure in case you encounter one of those bugs. This also means that you are “touching” your OH server far more frequently which has it’s advantages (you are restarting frequently so slow memory leaks may not be apparent) and disadvantages (you are spending a little bit of time more frequently dealing with breaking changes as they come up.
Personally, I’ve found that those users of OH who follow 3 have a much easier time dealing with upgrades. I personally stick to the milestones and the upgrade processes have been pretty easy. I find those who wait a long time (e.g. 2.3 to 2.4 or 1.8 to 2.x) have the biggest set of challenges because of the number of breaking changes becomes overwhelming.
It’s misunderstandings. Only briefly was that proposed. There was a huge outcry and by about post 50 in a 300+ posting thread an alternative was proposed which meant a change to the format of the config files and how they get loaded but not elimination of them. There were an additional 200 posts arguing about details.
I’m using openHAB for three years now and I really appreciate all the people spending time on developing/improving the system continously.
Though I have to admit, I’m tinkering for three years - and after EVERY SINGLE update something is not working. I know and understand that openHAB is not a professional solution, but if someone expect just to use it, he will be disappointed. That’s where I’m now - disappointed, not to say fed up. After a few months, I did an update and 30% of my systems aren’t working anymore, the logfiles are full of exceptions and errors - and all my commands (like turning lights on/off) are being executed with a delay of approx. 30 minutes.
If you practice home automation as hobby itself, then openHAB is perfect. If you want just to control your home without having any issues, it seems it’s the wrong system. At least that’s my experience after three years of fiddling around…
Except for possible flaws which could be discovered later. And quite often do - Though I´m not aware of anything related to OH or raspbian (or whatever the damn kernel is called), yet.
How often is rarely?
(I know, somewhere between 1 and 3 ).
Well, if OH 3 keep it to both options, I can live with format change, though I guess I´ll probably have to redo alot manually, cause I dont trust any migrate script or whatever it may be… These migration scripts always seem to forget something or mess things up. Then i might as well do it myself, if possible. It´s just aprox 500 text lines or something like that (I have no idea… I stopped counting long time ago).
Since then the author of the binding has mentioned several times that it is perfectly safe to run the two at the same time. I’ve been doing so personally since before the 2.4 release.
The source of that parenthetical is one of philosophy not technical. The MQTT author would have like to have seen MQTT 1.x completely disappear and all documents and tutorials that reference MQTT 1.x disappear on day one when MQTT 2 was released. I do believe that is neither reasonable nor particularly user friendly. I totally missed that little phrase when the blog posting was made and since then on this very forum the developer has recommended running the two at the same time.
That’s why I said “low” instead of unlikely.
The Kernel is Linux. Most of the software that makes Linux work like Unix comes from GNU. So the proper term would be “GNU/Linux” or “GNU based Linux” which is what the Free Software Foundation would prefer we use.
But then you have tens of thousands of libraries and applications that turn GNU/Linux into something useful. Projects exists to integrate and test some subset of these into a usable operating system. These are called “distros” or “distributions”. Raspbian is one such distro customized for the Raspberry Pi. Ubuntu, Armbian, Fedora, SuSE, and dozens more distros exist. Many of them are based on other distros. For example, Raspbian, Ubuntu, and I think Armbian are based on Debian. Linux Mint is based on Ubuntu.
Given the pace of OH 2 development and the six month release cycle, I’d say waiting between full point releases (e.g. between 2.3 and 2.4) or longer would be considered rarely.
I will later, only have little time now. But this problem is a general problem as I said I can’t remember an update where all my existing devices kept working. I got some of the troubles fixed the past four hours, but still it seems something is blocking the event bus. I get sensor values in the logs immediately, but switching something on or off doesn’t work…at least I thought so until the light I turned on 30 minutes ago came on a few seconds before. Because of the complexity of the system I think it’s the better way to install everything from the scratch…
