DSL Rules: example to disable a thing

[dilyanpalauzov]

No description provided.

[netlify]

✅ Thanks for your pull request to the openHAB documentation! The result can be previewed at the URL below (this comment and the preview will be updated if you add more commits).

Built without sensitive environment variables

Name	Link
🔨 Latest commit	55f939f
🔍 Latest deploy log	https://app.netlify.com/projects/openhab-docs-preview/deploys/69dde33dd6e58b000829e721
😎 Deploy Preview	https://deploy-preview-2700--openhab-docs-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[stefan-hoehn]

@rkoshak @cweitkamp Can you review this?

[rkoshak]

Same as the "runRule" updates, I can't really comment on the code in the example. And I recommend delaying moving on this until we figure out what 's happening with openhab/openhab-core#5481 which will greatly change this.

[dilyanpalauzov]

This example shows how to combine openHAB services, exposed over OSGi, and Xbase. This example should have been included in the OH-documentation some years ago.

Even if openhab/openhab-core#5481 is integrated, it does not yet mean, that the changes offered from it, will be written down as user-visible documentation.

That said I suggest to proceed with the herein proposed change. It can reduce questions on the forum.

[rkoshak]

, it does not yet mean, that the changes offered from it, will be written down as user-visible documentation.

The whole point of openhab/openhab-core#5481 is to create simple Actions users can call so they don't have to go through all the work of pulling the OSGI services to do this. To disable a Thing the user just requires one line of code.

If the work in that PR doesn't get put into the docs, that PR has no point.

[dilyanpalauzov]

If the work in that PR doesn't get put into the docs, that PR has no point.

Currently many things are not documented and it is unpredictable how the documentarion will evolve, in particular if that PR or any other PR will be described in user-visible texts. It is insignificant if documenting that PR makes sense or not.

A reason why options are not documented is, that reviewing proposed changes for documentation takes sooooo long, that one just looses the wish to propose further changes.

Given that, the herein proposed changes reflect the current state of the software and are at this moment useful.