-
-
Notifications
You must be signed in to change notification settings - Fork 429
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend service to suggest addons via generic IP scan #3936
Comments
This issue has been mentioned on openHAB Community. There might be relevant details there: |
To summarize what is needed for the ipcamera addon as discussed in the forum link: To discover ONVIF cameras it uses port 3702 and IP multicast address 239.255.255.250 using what is called WS-Discovery. It is just the following SOAP/XML packet sent.
Challenges identified are:
Good news is that because the XML states |
If both bindings define the same discovery criteria, they will both be suggested. It is for the user to decide what to install. No 2 scans are required for this. |
@Skinah Would the following string work? (this is the result of a draft implementation)
|
@stefan-hoehn Mechanism for Govee Developer docs are not yet merged, see #3948.
Not sure about port 4002.... do we have to listen on 4002 or is if source port of the response? |
@stefan-hoehn just updated the comment above to include an example.... |
@holgerfriedrich Looking at this, and the ipcamera request, I think an alternative (non-hex) request should be supported. |
:-) Looks Like.... But we need to make sure to escape tags - otherwise the XML parser might do something wrong.... |
@mherwege I don’t think that is the responsibility of the code. When defining the discovery criteria in the xml, it is sufficient to properly escape the special characters: https://stackoverflow.com/questions/1091945/what-characters-do-i-need-to-escape-in-xml-documents |
@mherwege Yes, lets go for a |
I can confirm that the implementation works well already for the Govee-Binding. See #16109 |
This is about the zway gateways connected to the LAN. The documentation of the zway binding states the following:
This would be the first real "IP scan", i.e. iterating over all local IP addresses finding a gateway. It would require a few new features:
Did I miss something, @andrewfg ? |
I think it pings all port 8083 on the subnet, and if the port is open it does a specific HTTP GET for a URL on that host:8083, and if it returns HTTP 200 it would become a suggestion. |
Yes, this sounds reasonable, thanks. A subnet could be quite large, I would limit it a /24 and exclude the broadcast address (such that we have to scan 255 IPs per interface at max). |
I don’t think we should allow scans on all interface. See discussion here, how it can cause drama with Docker: https://community.openhab.org/t/unsuccess-openhab-updated-from-4-0-2-to-4-1-0-on-docker-openhab-unresponsive/152282/24 OH does have a setting for the primary IP. Could we restrict it to thecsubnet of that iP? I even think we may want to limit the current IP finder implementation to only use one interface (or make that configurable). |
If regex matching is implemented then the epsonprojector and sonyprojector addons could be detected as many newer models respond to Control4 SDDP discovery probes as described here: https://github.com/sammck/sddp-discovery-protocol/blob/main/README.md SDDP is similar to UPNP/SSDP in that a multicast search frame is sent and any supported devices respond back to the multicast address with a packet containing device information. By using a regex these packets would be filtered to determine the device type and manufacturer. |
@mlobstein I created #4234 for this.. |
PR #3920 introduced a (partly) generic addon finder, which allows to discover devices by sending single IP frames. This is useful for devices which do not actively announce and require a search request to a multicast address. Maybe the word scanning is a bit misleading, at the moment it is just a single search frame, and only once at start-up in the current implementation.
Note: if case you can use mdns or upnp, there are separate addon finders for this! If you want to detect a service running locally, there is one for processes as well.
The implementation is rather tuned to a single use right now - detecting KNX installations - but is intended to be extended towards release 4.2. This issue is to collect requirements from other addons which can be used when starting a generalization.
The configuration is via
addon.xml
and looks like this (see #3948 for developer documentation):Frames to be sent are specified in the parameter section, and dynamic replacement of source IP and port is possible. Any return frame is matched, only the catch all .* is supported.
(table to be continued)
Features to be developed (incomplete list):
The text was updated successfully, but these errors were encountered: