[ipcamera] Fix Hikvision cameras stay offline when a 401 reply is given with no www-authenticate header

[t2000]

It might happen that a IP camera (Hikvision) replies with HTTP 401 but does not add a WWW-Authenticate header for our reconnect logic.

This fix reconnects the ThingHandler to the camera in such cases.

Fixes #15413

[lolodomo]

@Skinah : I let you check if that is fine for you.

[kaikreuzer]

lgtm, especially as cameras often behave buggy and thus retrying is the best option.

[jlaur]

FYI, there are some recent discussions/investigations in the linked issue.

[kaikreuzer]

Ah, thanks @jlaur, I missed that discussion.

[t2000]

I have updated the MR according to the discussion here: #15413 (comment)

[lolodomo]

@Skinah : please have a look.

[lolodomo]

LGTM, thank you

[Skinah]

Please do not merge until this is discussed.
In the discussion of the issue thread, I did state that this can be automated by asking the camera if it supports inputs and then removing the channels if the camera replies that it does not. I feel this is a better way to go because it does not cause a breaking change and it is automatic. It also has the benefit of a channel that does nothing is removed from being seen by the user that can cause confusion.

This is what I would like to discuss before this is merged, is there a reason why another config is added that will cause a breaking change? I thank @t2000 very much for their testing and time taken making two lots of changes to address this, please do not feel disheartened by this comment as I appreciate your work, it is just that I would like to discuss this direction taken first before agreeing to the merge if there was a reason.

[t2000]

In the discussion of the issue thread, I did state that this can be automated by asking the camera if it supports inputs and then removing the channels if the camera replies that it does not.

Automatic behavior is nice and I am a fan of it if it works ;-)
In theory we can detect if a camera supports external inputs, but from the community thread we already saw that cameras might respond that they support external I/Os while in reality they don't. For such cases we still would need a configuration to override the automatic behavior :(

This is what I would like to discuss before this is merged, is there a reason why another config is added that will cause a breaking change?

It is certainly not breaking because of the new config parameter, as there is a default for that in case it is not set.

However, I see the point that the default should probably be set to true, so everything stays as is, so for those users who are not having trouble, nothing changes. And if you do NOT have external alarm inputs you have to explicitly configure this new config parameter to false.

Would that be a solution (you could add the automatic detection later anyhow if you like and keep this override for faulty cameras)?

please do not feel disheartened by this comment as I appreciate your work

I absolutely don't feel like that. I am always in favor for the "right" solution. :-)

[Skinah]

Make a call to /ISAPI/System/IO/capabilities

If it is zero like this one or it is missing, you know the camera has no IO outputs.

<IOOutputPortNums>0</IOOutputPortNums>

See
https://community.openhab.org/t/ipcamera-binding-doing-erroneous-isapi-request-to-hikvision-camera/147345/3

It is confusing as they have also posted the output of the status api call.

[t2000]

Reverted to reconnect, see discussion.

[lolodomo]

Waiting for @Skinah approval to merge, we are still in time for 4.1...

[Skinah]

LGTM

[lolodomo]

Thank you