My front- and backyard each have their own Water Control System for which I have added 2 things to my openhab 3 environment using the Gardena binding. These control systems run on batteries and the battery level is available through a channels linked to items. As I have many more things that run on batteries, I have created a page with a widget that shows the battery level items that actually have a value. When a battery level item is UNDEFINED or above a threshold (i.e. >50%), then it is not shown in the list. So far so good.
In the winter, I need to shut down and physically remove the water control systems to prevent them to be damaged by frost. As a consequence I also disable the associated things in openhab.
Problem 1: The battery level items related to the water control systems keep their last known value and continue to be visible in the list of battery level items. How can I put these battery level items in an UNDEFINED state so they are no longer visible in the battery level list?
Problem 2: After a restart of openhab the water control system things become active again and I need to manually disable them every time. Is this normal behavior? How can I prevent this from happening?
postUpdate UNDEF or NULL to the Items. You can do that from a Rule, maybe set up a widget to do that, or the REST API. You could even set up a quick adhoc Script (-Scratchpad- is accessible from the developer sidebar) to do it. Alternatively you can set up an expire metadata on the Items with a time long enough to be kept current when the devices are active but expire to UNDEF or NULL if an update doesn’t arrive in enough time.
I can’t say. I don’t use that binding. I don’t think it does that for other bindings. It doesn’t really hurt anything to keep them enabled though. They will probably go OFFLINE at some point on their own.
Couldn’t you just use a rule that triggers on the thing status changing?
Rule "Set battery to UNDEF when thing is disabled"
When
thing changed
Then
var thing_status = getThingStatusInfo("thing").getStatus()
if (thing_status.toString() != 'ONLINE') { thing_battery.postUpdate(UNDEF) }
End
These methods rely on the binding setting the Thing to OFFLINE or suchlike when it gets bored by lack of input. Bindings working with battery devices may have a very long timeout for that.
The expire feature on each Item is expressly intended to set it to some state (like UNDEF) if updates stop arriving, with a user configurable timeout.
You might also want to think about if these Items are being restore-on-startup unwantedly, you get that feature by default in OH3
I think it is fully intentional that if you manually set a Thing offline, that’s the way it stays (including across reboots) until you manually enable it again. The ‘manual’ actions can be performed by rules, of course.
I just thought of something. If you’re Thing is defined in .things files, next time the fire is loaded the Thing will come back as enabled. This is because when the file unloads it deletes the Thing and when it releases it creates it anew. So there wouldn’t be anything left to tell it that is been disabled.
Right, I was going on @jebro’s statement that they’re manually disabling the things. This also assumes solving the problem of things being enabled on restart (which Rich may have just done).
postUpdate UNDEF or NULL to the Items. You can do that from a Rule, maybe set up a widget to do that, or the REST API. You could even set up a quick adhoc Script (-Scratchpad- is accessible from the developer sidebar) to do it.
Got it. My focus has been on directly changing the value of an item and didn’t think about these options.
Alternatively you can set up an expire metadata on the Items with a time long enough to be kept current when the devices are active but expire to UNDEF or NULL if an update doesn’t arrive in enough time.
In this case I am not sure on how to define “long enough”, so I’ll first try a rule triggered by a status change.
I can’t say. I don’t use that binding. I don’t think it does that for other bindings. It doesn’t really hurt anything to keep them enabled though. They will probably go OFFLINE at some point on their own.
Yes, these things go offline and indicating a Communications error (which I don’t like ).
Why do you need to manually disable the thing? If the thing is physically not available oh should automatically set the thing status to offline.
Two reasons:
I don’t like to see the communication error messages that these things give when they go offline. Usually error messages trigger me to take action, which is not needed here.
I want to avoid unnecessary network traffic generated by continuously polling for status.
Couldn’t you just use a rule that triggers on the thing status changing?
Yes, I like the proposed rule and will only trigger it when the thing status changed to UNINITIALIZED (which is the status that these things get when you disable them).
I just thought of something. If you’re Thing is defined in .things files, next time the fire is loaded the Thing will come back as enabled. This is because when the file unloads it deletes the Thing and when it releases it creates it anew. So there wouldn’t be anything left to tell it that is been disabled.
I am not using .thing files and define all things through the OH3 UI
The Gardena binding uses a cloud account to get status updates and does not communicate directly to the devices. Even though I manually pauzed the devices in the Gardena app before I shut them down, the binding does not recognize this as it indicates a communication error rather than a uninitialized / disabled status.
I agree on the design principle that when a Thing is manually disabled, it should stay in this status (including across reboots) until it is manually enabled again. This is however not the behavior that I am experiencing with the water control system Things. On the other hand I also have a smart plug Thing that is disabled (because the christmas tree is no longer used ) and this one actually survives a reboot. So my conclusion is that the behavior is dependent on the binding.
Hum, had not realised that but am quite prepared o believe it! Interesting.
Gardena might be ‘special’ here because, as you say, its all to do with a cloud API that still “works” when your devices are absent. It’s going to be doing something like connecting to an account, and setting “child” status according to info from the account.
Disabling the ‘account’ Bridge thing might have lasting effect, but that’s no use to you?
An example managing Things involving 'parent ’ Bridges, its essentially OH2 but might give ideas-
Essentially it detects a ‘child’ Thing error, and sets the ‘parent’ Bridge offline. With automated retry later, which you may or may not want.
That is not an option for me, as I need the Gardena Bridge activated to also receive status updates on the Gardena smart plugs that I am using as well.
Anyway my first problem is now solved through a rule. The second problem still exists.
).