On openHAB documentation and some more

[rlkoshak (Rich Koshak)]

@ErikDB

Or it might be an idea to put a link to the blog in the release notes.

It often is but I do see it’s not always included.

@mstormi

Well, parts like voice assistants eventually can make use of them, but they do not rely on it.

You can use them in rules and HABot user the tags to understand what’s being asked (how many of you on this thread knew OH has a chat bot interface since OH 2.5? That’s what the semantic model was originally created for).

@jimtng

This will take hours and hours of work and the risk of rejection is high based on my experience .

As I read that thread your PR appears to come out if the blue and makes major changes without any prior discussion. It would be as if someone came and completely changed the jRuby binding’s architecture in one PR. You might have some concerns and great burn, right? Maybe I’m missing a discussion elsewhere but large changes made without prior discussion and buy in from the maintainer is going to be met with resistance.

For example, I created an issue to rework the rules documentation where I ladies it an outline, invited discussion and established a task list. Then each task was individually implemented in a separate PR. I meet success with that approach.

@rettsan_wf

Perhaps it could be possible, to indroduce a mechanism, that there is no need to store user and password data in config file based configurations.

A PR for secrets handling was started but never finished. I’m not sure why.

@rettsan_wf

Even if I am the sole developer, using Git would have advantages.

A self hosted git is possible and many use that including myself. And I use a 100% managed config.

In the mean time, there are tools for encrypting secrets if you want to use a public service like GitHub. Hopefully secrets handling will get picked back up.

@Nadahar

I think there’s a defensiveness here that often gets in the way of discussing what could be done better.

It’s not defensiveness. My replies are to give people an understanding of what’s possible now to set a more firm foundation for discussing what can be improved. It’s frustrating to see suggestions that either ignore progress already made or requests for things that have already been implemented.

These threads end up going off the rails if they are not based in the complete current state of OH.

---

Here’s a new suggestion. Lots of software will throw up a dialog when there’s a new version of it. After the upgrade, it throws up a dialog with “what’s new” it a link to “what’s new”.

Since many users don’t know or don’t care to look at where OH currently posts this info what if we push it to them instead of relying on them to go find on their own.

This flies in the face of the whole help discussion above but then at least no one would have an excuse for not knowing that the blog and change log exist and where to find them.

Bonus points if it links to all the announcements and change logs between the old version and new version since a distressingly large number of people wait years between upgrades.