OpenHAB
/
openhab-docs
mirror of https://github.com/openhab/openhab-docs.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Documentation for SDDP discovery (#2298) 

Signed-off-by: Andrew Fiddian-Green <software@whitebear.ch>
pull/2302/head
Andrew Fiddian-Green 2024-05-30 16:20:54 +01:00 committed by GitHub
parent a3accd8278
commit 78acb0c6b6
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 21 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
developers/addons/addon.md
View File

@ -92,6 +92,7 @@ Optionally, if you want the system to scan the user's network for your addon the
| `ip` | Service to discover add-ons by scanning for devices via a UDP 'ping' broadcast on the LAN. |
| `mdns` | Service to discover add-ons by scanning for devices using the mDNS discovery service. |
| `processs` | Service to discover add-ons by checking processes running on the PC. |
| `sddp` | Service to discover add-ons by scanning for devices using the SDDP discovery service. |
| `upnp` | Service to discover add-ons by scanning for devices using the UPnP discovery service. |
| `usb` | Service to discover add-ons by scanning for USB devices attached to the PC. |
@ -107,6 +108,7 @@ Notes:
| `ip` | "response". |
| `mdns` | Frequently used properties are "name", and "application". But mDNS permits any property name depending on the service concerned. |
| `process` | "command", "commandLine". |
| `sddp` | "driver", "host", "ipAddress", "macAddress", "manufacturer", "model", "port", "primaryProxy", "proxies", "type" |
| `upnp` | "deviceType", "manufacturer", "manufacturerURI", "modelName", "modelNumber", "modelDescription", "modelURI", "serialNumber", "friendlyName". |
| `usb` | "product", "manufacturer", "chipId", "remote". |

22
developers/bindings/index.md
View File

@ -661,9 +661,9 @@ To simplify the implementation of custom discovery services, an abstract base cl
Subclasses of `AbstractDiscoveryService` do not need to handle the `DiscoveryListeners` themselves, they can use the methods `thingDiscovered` and `thingRemoved` to notify the registered listeners.
Most of the descriptions in this chapter refer to the `AbstractDiscoveryService`.
For UPnP and mDNS there already are generic discovery services available.
Bindings only need to implement a `UpnpDiscoveryParticipant` resp. `mDNSDiscoveryParticipant`.
For details refer to the chapters [UPnP Discovery](#upnp-discovery) and [mDNS Discovery](#mdns-discovery).
For UPnP, mDNS and SDDP there already are generic discovery services available.
Bindings only need to implement a `UpnpDiscoveryParticipant`, `mDNSDiscoveryParticipant` resp. `SddpDiscoveryParticipant`.
For details refer to the chapters [UPnP Discovery](#upnp-discovery), [mDNS Discovery](#mdns-discovery) and [SDDP Discovery](#sddp-discovery).
The following example is taken from the `HueLightDiscoveryService`, it calls `thingDiscovered` for each found light.
It uses the `DiscoveryResultBuilder` to create the discovery result.
@ -853,6 +853,7 @@ The developer has to take care about that.
UPnP discovery is implemented in the framework as `UpnpDiscoveryService`.
It is widely used in bindings.
To facilitate the development, binding developers only need to implement a `UpnpDiscoveryParticipant`.
Additionally one must add `<feature>openhab-transport-upnp</feature>` to the binding's `feature.xml` file.
Here the developer only needs to implement three simple methods, and may optionally implement a fourth:
- `getSupportedThingTypeUIDs` - Returns the list of thing type UIDs that this participant supports.
@ -973,6 +974,21 @@ Here the developer only needs to implement four simple methods:
To prevent this, a binding may OPTIONALLY implement this method to specify an additional delay period (grace period) to wait before the device is removed from the Inbox.
See the example code for the `getRemovalGracePeriodSeconds()` method under the "UPnP Discovery" chapter above.
### SDDP Discovery
SDDP discovery is implemented in the framework as `SddpDiscoveryService`.
To facilitate the development, binding developers only need to implement a `SddpDiscoveryParticipant`.
Additionally one must add `<feature>openhab-core-config-discovery-sddp</feature>` to the binding's `feature.xml` file.
Here the developer only needs to implement four simple methods:
- `getSupportedThingTypeUIDs` - Returns the list of thing type UIDs that this participant supports.
The discovery service uses this method of all registered discovery participants to return the list of currently supported thing type UIDs.
- `getThingUID` - Creates a thing UID out of the SDDP service info or returns `null` if this is not possible.
This method is called from the discovery service during result creation to provide a unique thing UID for the result.
- `createResult` - Creates the `DiscoveryResult` out of the SDDP result.
This method is called from the discovery service to create the actual discovery result.
It uses the `getThingUID` method to create the thing UID of the result.
### Discovery that is bound to a Bridge
When the discovery process is dependent on a configured bridge the discovery service must be bound to the bridge handler.