As far as I understand, this kind of summarizes your whole point.
I’m sorry, but I will never be a “worshiper”. As you should know, I’m fully willing to contribute, there are some obstacles when it comes to OH, but in general I do try to contribute when I “want” something that isn’t there. I’ve written several hundred thousand lines of open source code, I do not share this “god” and “worshiper” view of developers and users. I see all users as potential contributors, it just depends on if their skill sets overlap with the current needs. I’ve never expected to be treated like a “god” when I’m in the position of the developer that has the most knowledge of something, and I don’t expect others to expect that either. We’re all people.
I don’t know how many you “speak for”, but if status and submissiveness is what this is all about, this kind of thread is frankly pointless. The input of those “not deserving” isn’t really desirable, so why pretend? People will just have to accept what the “ruling few” dictates and shut up. They should not imagine that they themselves can in any way impact anything, they should just accept and show gratitude.
I think it’s important that this attitude is clarified, because I certainly have no desire to waste anyone’s time, neither my own nor that of others. If this view is shared by the wider group, I have nothing to do in this community.
Guys the conversation is getting sidetracked here. This thread is about OpenHAB 5, not about inventing another religion.
Please adjust accordingly?
Another wish, to fulfill my previous request of getting back on topic:
Any chance of having the upkeep of the OpenHAB node red node included in the OpenHAB core work?? My question comes from complete ignorance, but I was thinking about the last time I was impacted by an update. And it was when the API was updated, and it broke the node red OpenHAB node for obvious reasons.
Now sure… sure, openHAB already has rules and blocky… but having that node maintained by openHAB would likely imply minimal work in the end, and would offer another solution for rule management.
(And yes.. I am working on moving many of my rules back into openHAB to reduce how affected I would be in a future outage. But node red is pretty cool )
This is a complete misunderstanding.
There are not a few to rule and dictate.
Everyones contribution is welcome and PRs will be reviewed when the maintainers find time for it.
But what we, not for the first time, find in this thread again is a lot of demanding, without proper proposals….
You see demands where I see suggestions. I haven’t seen a single demand, from me or anybody else.
That said, it would be really helpful to know what form a “proper proposal” should take. I have tried to the best of my ability to explain what I am suggesting, when it seems to be misunderstood. I guess that’s where you see the “demanding”. Do you mean that one has to make a full (or close to) PR of what one is suggesting before “suggesting it”? That goes directly against what I have read several other places here, that ideas should be discussed before work is undertaken. So, I’m confused as to exactly how a “proper proposal” looks.
In addition, I didn’t think this thread was about actual changes, but a kind of “brainstorming” of what could do OH better, which makes me understand even less what form you expect.
This is mostly from “modern looking UI”. See my last post, where I answered to a suggestion/wish from today, that this wish can be fullfilled without much effort, out of the box.
A device node RED can do but openHAB cannot?
Hard to believe it cannot be done given OH’s range of flexible binding like HTTP, MQTT, Modbus
and probably merely yet another case of lack of knowledge about how to integrate it best.
And if really so, your feature request should be for an OH binding for that device, not node RED in general as another more or less mighty home automation system.
Humm. I’ll ignore the rude tone. But I’ll make a note of it.
Consider the following: with node red I can easily expose all of home assistant entities to openHAB.
Why this can be useful ?
Because there are things that are only available in home assistant due to the fact that the community is larger there and there’s more devs there working in more stuff.
Like a sonoff binding that we don’t have.
Like a roborock binding that we don’t have.
Like many other stuff that we do not have unless we hack or work around stuff.
Sure we can do it with MQTT but with node red it is more accessible for everyone and quicker to get everything setup because the entities are already there. No creating things or anything. You can interface an home assistant node with an OpenHAB node (item) directly.
So if people have a roborock or sonoff wall switches, setting them up in home assistant and making them available for making automations with openHAB items is possible through node red.
It’s awesome to be honest, and one of the reasons why I’m extremely remorseful for not buying the wifi version of my heat pump, since home assistant has a binding for it
Other things: interfacing with http API is kids friendly in node red, in openHAB I simply cannot do it without going into scripts.
Some things are simply easier there.
That wasn’t directed at you hence not rude. I was rather genuinely referring to the fact that much of the stuff users are requesting here actually already can be accomplished in OH today, without that some developer has to put work into it and that those users just don’t know about that i.e. lack that knowledge. Some examples of that further up in this thread.
You have a very strange definition of rude. I thought you were so rude that I had to bite my tongue not to answer. I see that you have edited your post now, but the original version was well within what I consider both rude and arrogant.
You both have misunderstood my post. It was and still is meant to be a genuine description and not directed at any person and as such is not rude in itself.
Edits were not to ‘throttle back’ but to make that clearer to anyone that misunderstood me.
I’ll attribute that to the fact that we all are not native speakers but suggest to better stop now in order not to derail this conversation and thread.
I’m not sure what more to say, I feel I’ve presented what I’ve been trying to convey to the best of my ability already, and there doesn’t seem to be much interest neither to make OH “easier to use” (via documentation) nor “easier to live with” (via a changelog that gives overview).
That’s your choice, but what more is there to discuss then?
Just for reference, even though the need for a changelog has been clearly rejected, other people view it differently. This page lists good reasons why a changelog is needed, and also tries to establish a standard for how to do it: https://keepachangelog.com/
If anyone feels differently, they can volunteer to take on the job of building a change log. I doubt anyone will say “no! you can’t do that!” and instead might make changes to accomodate it.
But no one here who does volunteer for OH is willing to take up that task. For now, we have the blog, change log posted from github in the announcement, the announcement that points to both which gets pinned on the forum.
Again, no matter how good the idea may be, if no one is willing to volunteer it’s not going to happen. Since you can’t volunteer to do it .
That’s not exactly how I see it: The first step is to agree that it would be useful. Then, and only then, the question of how it should be made/maintained becomes relevant. I was merely trying to address the first part here.
The very nature of a changelog implicates that it must be organized at a lowish level. It’s not something anybody can just put together, since it’s essential that it contains the correct information - and that it doesn’t “miss” important changes. So, in this case, I don’t think it’s that relevant if I can do it or not. That said, if the changelog was hosted on the forum and not on GitHub, I probably could without the CLA hindrance.
I don’t know how the rest of you do it, but I waste a lot of time tracking changes using git blame to compensate for the lack of a changelog. Since we had this discussion, I have done that process at least 4 times - the last time now was to figure out when ECharts were upgraded to version 5.5.1 (4.3.0), and before that when Echarts gauge was included (3.1.0). If a changelog existed, this would be done in no time - using git blame is both time consuming and requires some knowledge of both the structure of the code and git. I doubt everybody that needs this information knows how to do it.
So vounteer or find a volunteer at the “lowish level”. Open an issue on the distro repo. PM some of the maintainers. No one here is going to volunteer and no one here can direct the maintainers to do it. Even if everyone on this thread agreed, we can’t collectively make anyone do anything against their will. So go find a volunteer.
Given in the last six month:
openHAB Core (opens new window)has received 104 pull requests in total, with 23 bug fixes and 52 enhancements resulting in 6,445 lines of code added.
Our openHAB web UIs (opens new window)have also received many contributions: 174 pull requests including 61 bug fixes and 71 enhancements resulted in 2,346 lines of code added.
I wonder if a change log like you are after wouldn’t be too long to be usable. But who knows. Someone may come up with a clever way to handle that. But I’m skeptical given Release openHAB 4.3.0 · openhab/openhab-distro · GitHub which only includes what the maintainers have considered worth mention and is not the full list of all changes has already been sited as too long and unusable.
I don’t consider it “too long” (maybe others do) per se. I think it would make sense to have the add-ons in a separate changelog, because all the add-on changes can “pollute” somewhat. I also think it includes changes that doesn’t bring much information without looking at the underlying issue/PR, like e.g Small improvements to blocks. Those kinds of entries would ideally just be mentioned as “various fixes” or similar, to make it more manageable. But, all in all, those release notes are pretty close to what I think should be in a changelog, except that they aren’t in a changelog. They are separate “documents” if you will, so that you must gather them all to be able to search for/track changes.
If the add-on changes were separated out and the rest presented chronologically per version in “one document”, I think it would be pretty close to what I’m trying to suggest. A bit less of the tiniest details might be desirable to make it more useful for non-technical users, but all in all it’s not that far off IMO.
)
.