Cache supported commands for each WyzeCamera

[jhansche]

This loads the device_config.json and caches the list of supported commands for each camera. As of today this list is checked only in respond_to_ioctrl_10001 for command 10008:

    if supports(product_model, protocol, 10008):
        response: TutkWyzeProtocolMessage = K10008ConnectUserAuth(
            challenge_response, phone_id, open_userid, open_audio=enable_audio
        )
    else:
        response = K10002ConnectAuth(challenge_response, mac, open_audio=enable_audio)

Once this list is loaded for the current camera, it can then be queried later by checking:

if cam.supports_command(11018):
  # has PTZ support

A possible enhancement could be made if memory consumption is a concern, that would only keep track of a smaller list of high-value commands (like PTZ commands in this example), rather than the full list of commands from device_config.json. Since most functionality that would need to check this would only be checking for a relatively small list of commands.

This relates to https://github.com/mrlt8/docker-wyze-bridge/issues/921#issuecomment-1637183749 as a prerequisite to publishing optional entities during discovery, such as the "Pan Cruise" switch, which should be published only if the camera supports it.

NOTE: I do not know what your typical dev environment looks like, or the best way to test changes before submitting a PR. I use the bridge as a HA add-on, so I don't know the best way to spin up a test instance outside of HA just for testing. I also did not see a .github workflow that runs any kind of code style checks, unit tests, or simple "does it work at all" checks. I'm happy to run some sanity checks on my own if you have any documentation for best practices for PRs.

[mrlt8]

Thank you! Will need to look into this as I haven't really maintained device_config.json since porting it over from the original kroo/wyzecam library, and it may need to be updated. However, I'm not too sure how reliable it would be to use it to check for support since some cams will show "support" for a command but not actually do anything (e.g. RTSP 10600).

[jhansche]

So would your preference be that things like PTZ commands check for "PAN" in the model string?

[mrlt8]

Potentially, as most of the PTZ cams will still "work" if you send them to a non-pan cam.

[jhansche]

Right, this wasn't about avoiding the potential for command errors. It's more about not presenting entities during discovery if they aren't relevant to the device. The user could always choose to hide or disable one of the discovered entities, so if you're not that concerned about it, maybe it's unnecessary to go this far?

[jhansche]

Super fast as always 👍

[mrlt8]

I believe I may have copied over the commands from the older Pan cam when updating the device_config.json file to add support for the newer Pans.

I just had a look at the DeviceConfig.plist file from the iOS app, and it seems like several of the PTZ commands are only listed under WYZECP1_JEF so it seems as if wyze may have stopped updating that list with all the supported commands.