[REST] Add a way to see if a thing is disabled

[spacemanspiff2007]

It's possible to enable/disable a thing with /things/{thingUID}/enable but it's not possible to check/know if the thing is currently enabled or not.

Maybe the status can be transported through enabled in the thing json?

[rkoshak]

Does /things/{thingUID}/status not do what you need? The statusDetail field will show DISABLED for Things that are disabled and something else in all other cases.

[spacemanspiff2007]

It's very confusing that statusDetail is showing that the thing is disabled and not some detail about the status. A new status DISABLED would be much better or even an own property. Additionally since I learned from #2909 the status and the thing are detached so the information might not even be correct.

[rkoshak]

Just based on observation, when the Thing is DISABLED it will always be UNINITIALIZED. In all other cases I've been able to create the statusDetail will either be NONE or indicate what's wrong if the Thing is in some sort of error state.

And based on the discussion on #2909, the result of the REST call will always provide the latest state of the Thing as known at the time of the REST call (see the last part of @splatch 's post). The problem on that thread was the status might not always be accurate at the time that the Thing added event occurs so it could be inaccurate if it's part of that specific event.

What I never understood on that issue is if we have events when the Thing is created, and we have events when Things change their status, why would you need the status as part of the added event or why you need to make the REST call to get the status after that event? Can't you just wait for the ThingStatusInfoChangedEvents that will occur after the Thing is added as the Thing transitions from UNINITIALIZED to INITIALIZING and so on?

As a side note, I am seeing that at least in events.log UNINITIALIZED and UNINITIALIZED (DISABLED) are two separate events/states, for what ever that's worth.

I want to be clear, I'm not arguing against anything here. I'm just trying to understand because there is clearly some sort of important nuance that is not clear to me.-

[spacemanspiff2007]

Can't you just wait for the ThingStatusInfoChangedEvents that will occur after the Thing is added as the Thing transitions from UNINITIALIZED to INITIALIZING and so on?

Is it certain, that the event will come under every circumstance? Using the thing data and waiting for the event is difficult on the client side and adds a lot of complexity.

as the Thing transitions from UNINITIALIZED to INITIALIZING and so on?

You are assuming that the Thing status is UNINITIALIZED when it was created but how do you know? Maybe the initial status was different.

---

I am providing thing access in HABApp and part of that access is the status. To simplify things I want to provide a status as soon as the thing was created and thus I have to use some value. Of course I could just assume something but it would be much nicer if I could get the correct value.

[J-N-K]

I checked the code and indeed if the thing is created for the first time, it depends on the configuration if it is set to UNINITIALIZED or not. If there is a valid configuration, the thing starts with INITIALIZING. I have created #3072 for that.

[spacemanspiff2007]

Another idea would be to always create the thing with UNINITIALIZED. And only then depending on the configuration move to INITIALIZING. That way the thing has a defined initial state. What do you think?

[J-N-K]

Isn‘t this solved now that #3072 has been merged?

[spacemanspiff2007]

No, the issue still remains. It's still not clear when a thing is disabled from an API perspective. I've gained some insights, namely that if the thing is disabled the status is probably UNINITIALIZED or UNINITIALIZED (DISABLED) and there might be some more info in the statusDetail.

However if the thing doesn't initialize properly or e.g. the Bridge is missing it is UNINITIALIZED, too. So it's still not clear without studying the openHAB source code when the thing is enabled/disabled.

Imho there should be either a new status (DISABLED) or a new field in the returned json (isDisabled or isEnabled).

[J-N-K]

If the things is disabled, then the status is always UNINITIALIZED/DISABLED. If the status is something else, then the thing is not disabled. I agree that this is not the best solution and it would have been better to use DISABLED as thing status, but I believe we can't easily change that without breaking existing code now and API clean-up.

We could think about that for OH4, as that will bring quite some breaking changes anyway. @openhab/core-maintainers, WDYT?

[spacemanspiff2007]

We could think about that for OH4, as that will bring quite some breaking changes anyway.

Is there an issue or something where I could make some wishes for OH4?

[spacemanspiff2007]

@J-N-K What is the status now exactly when the thing is disabled? I tried looking at the source but I still don't know what strings the RestAPI will report. You wrote UNINITIALIZED/DISABLED, above we have UNINITIALIZED (DISABLED) and the enum has a field DISABLED. I'm quite confused 😕

[J-N-K]

The full status is a ThingStatusInfo with status=ThingStatus.UNINITIALIZED, statusDetail=ThingStatusDetail.DISABLED, description=null

[spacemanspiff2007]

I tested it locally this is the event I get:

{
    "topic": "openhab/things/astro:sun:00fd3d1560/status", 
    "payload": {
        "status": "UNINITIALIZED", 
        "statusDetail": "DISABLED"
    }, 
    "type": "ThingStatusInfoEvent"
}

Thing status:

  "statusInfo": {
    "status": "UNINITIALIZED",
    "statusDetail": "DISABLED"
  }

The description seems to be missing from the event/thing (see #3309) Any change there will be a simplifictaion for OH4?

[J-N-K]

null fields are always omitted during serialization.

[spacemanspiff2007]

Would it then be possible to mark the field as optional in swagger, currently it shows as mandatory? It's very hard to consume the API if it's not clear which fields are always sent and which are optional.

null fields are always omitted during serialization.

For events, too?

Edit: I think it's possible to mark the field with

@Schema(required = false)

Do you think this would work?