Temporarily disabling Things altogether

Hi.
Often there are devices which are only used parts of the year, like automower on summer or all those extra light switches around christmas. All those Things in openHAB shows as OFFLINE the rest of the year and I see in the logs bindings trying to constantly talk to them. Which is kinda natural since they are plugged out. Anyway I would like to tell the system that those Things are currently disabled, so I don’t have to see them at all until it’s time for them again. Any good way of doing this?

I’m talking about 2.x style Things now, configured using openHAB. Otherwise I guess I’d just comment them out in the files…

I don’t know if there is a good way to do this.

I suppose you could remove the Thing in PaperUI and it should go back to the Inbox. I’ve not tested this so cannot guarantee that it will go back to the Inbox though.

If you remove the links to the Items the bindings should be less concerned about trying to talk to those things since there is nothing in OH that cares about them, perhaps that will reduce the logs.

Beyond these two ideas, I know of nothing that would let you do this.

Ultimately, if it is primarily the logs that you are concerned about, you can push that binding’s logs to some other file and/or use filtering as you look through or watch the logs.

Nah, it’s not primarily the logs, it’s me getting irritated over a lot of Things showing as OFFLINE. And knowing that for example the Robonect binding will try polling my automower in vain every minute for half a year (that’s approximately 250000 polls!).

Removing the linking or the Things might do it but it would feel more logical to just be able to disable it since I knkow i’ll need it again. But I guess that would turn out to a feature request. And I guess I’m the only one requesting it so in the end it would be a feature I’d have to implement myself :slight_smile:

I dabbled in OH 1.8 but 2 was on the horizon so I shelved it and only really started when OH 2 came out. At that point I thought I’d be a model user and follow the ‘use PaperUI’ advice and not text files. With that in mind if you delete a Thing it won’t go back to the Inbox, it’s gone. I think depending on the binding implementation it might be easy to rediscover but you’ve definitely lost stuff: names, links, settings etc.

But text files do still work don’t they or is there somethings you can’t do with text files that PaperUI does allow? I’ve got it the other way a few text file based items because I couldn’t find ways to get PaperUI to do them, so my Alexa proxy ‘items’ are declared in text files because I need them linked to myopenhab.org.

So @DanielMalmgren could you re-implement your setup of those Things via text files (say mower.things and mower.items) and then you’d be in control and could ‘disable’ and ‘enable’ at will by renaming those files. Might be easier than implementing the feature.

Sadly even if dozens of people are asking for it you are probably stuck implementing it yourself. :frowning: That’s the nature of open source I guess.

There is nothing that you can’t do theoretically in the text config files. However, with certain bindings, in particular, the zwave binding, the documentation for how to write the .things file and the sheer variety of supported Things makes it impractical to do so unless you have a really good reason to and the perseverance to figure out how to do it. For the average user, it is far easier to just let automatic discovery find and create the Things.

Indeed, you cannot bind and 1.x version bindings to a PaperUI created Item. I don’t think you can use tagging in PaperUI either.

1 Like

I configure everything in text based files, so yes you can still use them and when configuring the items you want to enable disable through text files I would guess it’s just a matter of commenting those out when you want to turn them off.

1 Like

Tagging seems to ring the bell of why I had to use text files, the exposed items need them for Alexa to understand what they are Lighting/Switchable etc.

If I started again I’d be using text files for sure. I like PaperUI for lots of things (and appreciate for some bindings like zwave it may be ideal) but as I’ve been developing and learning I’m wanting to refactor more and more and it’s painful having to drive that through the UI. Groups being a prime example, I will likely want to change those a lot more but it’s painful having to individually click through and edit each item one at a time, which triggers a multitude of system start events :slight_smile:

Yes I know I could work on a Group Management enhancement feature of PaperUI but I’m only just getting in to using the system not changing it. Maybe one day but no promises for now it’ll be forum and sample contributions.

I guess I just wanted to now if text files will remain supported going forward to OH3.x or whatever is the next major release. I may be tempted to slowly migrate to text files…

While not strictly recommended, you could stop OH and edit the JSONDB files yourself. That would be faster than clicking around in the UI.

I do not foresee the text-based configs ever going away, or if they do there will be an extended period to give everyone a chance to migrate. The primary reason is because as long as OH supports 1.x bindings there really is no other way.

1 Like