Discover devices

[dolby360]

What did you have in mind?

I think the API shall have the ability to get all discovered devices.

Are you trying to fix a problem?

I can do that if this request is approved.

Any lead on how this feature can be implemented?

No response

[welcome[bot]]

Thanks for opening your first issue here!

[dolby360]

@TomerFi I'm building a client that needs to use this feature. I need to know if it is OK with you :)

[TomerFi]

I think the API shall have the ability to get all discovered devices.

WDYM?

[dolby360]

@TomerFi I mean this project uses the aioswitcher and provides a REST API for its functionality. But in the documentation, I don't see any request that can search available switcher devices and give some details about them. Although aioswitcher has this ability.

[TomerFi]

That's where aioswitcher's UDP Bridge comes into play, it listens to a specific UDP port, Switcher devices broadcast status messages every approximately 4 seconds if you're listening on the specific port (currently there are two ports), you can pick information about the devices from the status messages.

This is how aioswitcher provides discovery and status updates for devices. Other than that, every other functionality offered by aioswitcher, such as turning on/off and including manually retrieval of a device status, is handled with TCP requests, and this part is what we refer to as the TCP API part of aioswitcher.

As you might have noticed, Home Assistant's is the main client of aioswitcher, it makes use of both layers, the UDP Bridge and the TCP API.

This project, however, originated to be a solution for users who were unable to use Home Assistant's integration, more often than not because of UDP network-related issues, so AFAIK most users of this project, use it with automation processes in Home Assistant. Of course, this project is also usable for anyone who doesn't use Home Assistant as well.

Regardless... What you're suggesting, if I understand correctly, is to have the user send an HTTP request, which we will, in return, create a UDP bridge and listen to it for approximately 5-6 seconds, before constructing an HTTP response from the data we got from the bridge.

I must say... this sounds a bit unnatural to me, combining TCP/UDP like this. And it should be pointed out that this web server is running in a container, so I guess proper configuration will be required by the user to allow the container access to the host's UDP traffic.

Nevertheless, this is open-source and I am open-minded (or so I try to be), so please feel to keep discussing this further, as long as we don't mess up the current goal of this project which was to allow easy no-UDP control, then I guess we're should be good.

[dolby360]

@TomerFi Thank you for your detailed answer. I will describe my issue and more clarification on the suggestion, And maybe you will have a better idea. Right now if I want to get the state of a device I need to send this request:

GET /switcher/get_state?id=ab1c2d&ip=10.0.0.1

This request construct of the id and ip which I need to know in advance somehow. My suggestion is not to take TCP requests and transform them into UDP. But storing the information of discovered devices in some file or database, and get this stored data on http reques.

Maybe I'm just missing some straightforward way to get the above-mentioned data about IP and id and this whole suggestion is not relevant.

Please let me know what you think.

[dolby360]

@TomerFi So you think it's not feasible to request every 6 sec? BTW I'm not sure why you think we should check for the device IP that many times. In my experience, internal IPs are not frequently changed (Not in a matter of sec).

Anyway, how otherwise do you think the users of this repository know the id for the requests?

[TomerFi]

Unless users assign static IP addresses to all of their Switcher devices, which is not always possible on the user's end. Then no database will do, we'd still need to bring up the bridge for approximately 6 seconds every now and then to update the database, and we'll also need to take this into consideration for all other endpoints, because now, for every failed request, we would want to update the database and try again to make sure we have the correct info, or at the very least inform the user that they need to ask us to update the database just-in-case our latest failed request was caused by a changed IP address, which makes this thing way less robust.

And technically, users will still need to provide some sort of ID to identify the correct device from the database records, so we'll just be saving them the need to include the IP in the query params, and if the user assigns a static IP address, which will always be the preferred approach for what you're describing, then the user already knows the IP address.

I think we are looking at a potentially huge difference in latency and response times, for this application. And besides that, honestly, I'm a "microservices-kind-a-guy", I like to keep stuff small, and what you're describing, is actually taking this "container" and making it into a "deployment", because we're now talking about multiple containers, multiple protocols, a bunch of extra configurations, and a lot more done on the user's end.

When technically, this can be done as-is with some simple automation processes and out-of-the-box thinking, i.e. scripts, I'll explain: Users will still need to maintain some sort of data source with the IDs of their devices, whether it be a database, environment variables, a file, or whatever. They have to, they need the device IDs for the HTTP requests' query params, right?

And this is also true today, users need to maintain a "list" of their devices' IDs and IPs. And if that's the case, why not simply periodically run this script for discovering devices from aioswitcher's project, and populate whatever data source you're working with? To me, this sounds way more flexible and robust.

[dolby360]

@TomerFi Fair enough, I highly appreciate your patience. Thanks for all :)

[TomerFi]

@dolby360 Thank you for participating. BTW what you're describing is not a bad idea at all, I just think it should be like in a repo/project of its own as a project build out of some script and a container orchestration framework configuration leveraging this container and a database container. Keep me posted if this project comes to life, I'll be happy to contribute and pitch in if I can.