ucapi-framework 0.1.16__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- ucapi_framework-0.1.16/PKG-INFO +223 -0
- ucapi_framework-0.1.16/README.md +212 -0
- ucapi_framework-0.1.16/pyproject.toml +35 -0
- ucapi_framework-0.1.16/setup.cfg +4 -0
- ucapi_framework-0.1.16/tests/test_config.py +1006 -0
- ucapi_framework-0.1.16/tests/test_device.py +1462 -0
- ucapi_framework-0.1.16/tests/test_discovery.py +607 -0
- ucapi_framework-0.1.16/tests/test_driver.py +1183 -0
- ucapi_framework-0.1.16/tests/test_setup.py +1580 -0
- ucapi_framework-0.1.16/ucapi_framework/__init__.py +48 -0
- ucapi_framework-0.1.16/ucapi_framework/config.py +530 -0
- ucapi_framework-0.1.16/ucapi_framework/device.py +1033 -0
- ucapi_framework-0.1.16/ucapi_framework/discovery.py +474 -0
- ucapi_framework-0.1.16/ucapi_framework/driver.py +1411 -0
- ucapi_framework-0.1.16/ucapi_framework/setup.py +1381 -0
- ucapi_framework-0.1.16/ucapi_framework.egg-info/PKG-INFO +223 -0
- ucapi_framework-0.1.16/ucapi_framework.egg-info/SOURCES.txt +18 -0
- ucapi_framework-0.1.16/ucapi_framework.egg-info/dependency_links.txt +1 -0
- ucapi_framework-0.1.16/ucapi_framework.egg-info/requires.txt +4 -0
- ucapi_framework-0.1.16/ucapi_framework.egg-info/top_level.txt +1 -0
|
@@ -0,0 +1,223 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: ucapi-framework
|
|
3
|
+
Version: 0.1.16
|
|
4
|
+
Summary: ucapi framework that provides core functionality for building integrations.
|
|
5
|
+
Requires-Python: >=3.11
|
|
6
|
+
Description-Content-Type: text/markdown
|
|
7
|
+
Requires-Dist: pyee>=13.0.0
|
|
8
|
+
Requires-Dist: ucapi>=0.3.2
|
|
9
|
+
Requires-Dist: aiohttp>=3.9.0
|
|
10
|
+
Requires-Dist: mkdocs-material>=9.7.0
|
|
11
|
+
|
|
12
|
+
[](https://github.com/jackjpowell/ucapi-framework/actions/workflows/test.yml)
|
|
13
|
+
[](https://discord.gg/zGVYf58)
|
|
14
|
+
[](https://buymeacoffee.com/jackpowell)
|
|
15
|
+
|
|
16
|
+
# UCAPI Framework
|
|
17
|
+
|
|
18
|
+
A framework for building Unfolded Circle Remote integrations that handles the repetitive parts of integration development so you can focus on what's important.
|
|
19
|
+
|
|
20
|
+
## What This Solves
|
|
21
|
+
|
|
22
|
+
Building an Unfolded Circle Remote integration typically involves:
|
|
23
|
+
- Writing 200+ lines of setup flow routing logic
|
|
24
|
+
- Manually managing configuration updates and persistence
|
|
25
|
+
- Implementing device lifecycle management (connect/disconnect/reconnect)
|
|
26
|
+
- Wiring up Remote event handlers
|
|
27
|
+
- Managing global state for devices and entities
|
|
28
|
+
- Handling entity registration and state synchronization
|
|
29
|
+
|
|
30
|
+
This framework provides tested implementations of all these patterns, reducing a simple integration from ~1500 lines of boilerplate to ~400 lines of device-specific code. It even adds features, like back and restore, for free.
|
|
31
|
+
|
|
32
|
+
## Core Features
|
|
33
|
+
|
|
34
|
+
### Standard Setup Flow with Extension Points
|
|
35
|
+
|
|
36
|
+
The setup flow handles the common pattern: configuration mode → discovery/manual entry → device selection. But every integration has unique needs, so there are extension points at key moments:
|
|
37
|
+
|
|
38
|
+
- **Pre-discovery screens** - Collect API credentials or server addresses before running discovery
|
|
39
|
+
- **Post-selection screens** - Gather device-specific settings after the user picks a device
|
|
40
|
+
- **Custom discovery fields** - Add extra fields to the discovery screen (zones, profiles, etc.)
|
|
41
|
+
|
|
42
|
+
The framework handles all the routing, state management, duplicate checking, and configuration persistence. You just implement the screens you need.
|
|
43
|
+
|
|
44
|
+
**Reduction**: Setup flow code goes from ~200 lines to ~50 lines.
|
|
45
|
+
|
|
46
|
+
### Device Connection Patterns
|
|
47
|
+
|
|
48
|
+
Four base classes cover the common connection patterns:
|
|
49
|
+
|
|
50
|
+
**StatelessHTTPDevice** - For REST APIs. You implement `verify_connection()` to test reachability. No connection management needed.
|
|
51
|
+
|
|
52
|
+
**PollingDevice** - For devices that need periodic state checks. You set a poll interval and implement `poll_device()`. Automatic reconnection on errors.
|
|
53
|
+
|
|
54
|
+
**WebSocketDevice** - For WebSocket connections. You implement `create_websocket()` and `handle_message()`. Framework manages the connection lifecycle, reconnection, and cleanup.
|
|
55
|
+
|
|
56
|
+
**PersistentConnectionDevice** - For TCP, serial, or custom protocols. You implement `establish_connection()`, `receive_data()`, and `close_connection()`. Framework handles the receive loop and error recovery.
|
|
57
|
+
|
|
58
|
+
All connection management, error handling, reconnection logic, and cleanup happens automatically.
|
|
59
|
+
|
|
60
|
+
**Reduction**: Device implementation goes from ~100 lines of connection boilerplate to ~30 lines of business logic.
|
|
61
|
+
|
|
62
|
+
### Configuration Management
|
|
63
|
+
|
|
64
|
+
Configuration is just a dataclass. The framework handles JSON serialization, CRUD operations, and persistence:
|
|
65
|
+
|
|
66
|
+
```python
|
|
67
|
+
@dataclass
|
|
68
|
+
class MyDeviceConfig:
|
|
69
|
+
device_id: str
|
|
70
|
+
name: str
|
|
71
|
+
host: str
|
|
72
|
+
|
|
73
|
+
config = BaseDeviceManager("config.json", MyDeviceConfig)
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
You get full CRUD operations: `add_or_update()`, `get()`, `remove()`, `all()`, `clear()`. Plus automatic backup/restore functionality for free. The framework handles all the file I/O, error handling, and atomic writes.
|
|
77
|
+
|
|
78
|
+
Full type safety means IDE autocomplete works everywhere. No more dict manipulation or manual JSON handling.
|
|
79
|
+
|
|
80
|
+
**Reduction**: Configuration management goes from ~80 lines to ~15 lines.
|
|
81
|
+
|
|
82
|
+
### Driver Integration
|
|
83
|
+
|
|
84
|
+
The driver coordinates everything - device lifecycle, entity management, and Remote events. **Most integrations work with just the defaults** - no overrides needed!
|
|
85
|
+
|
|
86
|
+
The framework provides sensible defaults for:
|
|
87
|
+
|
|
88
|
+
- **`create_entities()`** - Creates one entity per entity type automatically
|
|
89
|
+
- **`map_device_state()`** - Maps common state strings (ON, OFF, PLAYING, etc.)
|
|
90
|
+
- **`device_from_entity_id()`** - Parses standard entity ID format
|
|
91
|
+
- **`get_entity_ids_for_device()`** - Queries and filters entities by device
|
|
92
|
+
|
|
93
|
+
**Override only what you need**: Custom state enums? Override `map_device_state()`. Conditional entity creation? Override `create_entities()`. Custom entity ID format? Override `device_from_entity_id()` too.
|
|
94
|
+
|
|
95
|
+
Everything else is automatic. The framework handles Remote connection events (connect, disconnect, standby), entity subscriptions, device lifecycle management, and state synchronization.
|
|
96
|
+
|
|
97
|
+
Device events (like state changes) automatically propagate to entity state updates. The framework maintains the connection between your devices and your remote.
|
|
98
|
+
|
|
99
|
+
**Reduction**: Driver code goes from ~300 lines to ~50 lines (or less!).
|
|
100
|
+
|
|
101
|
+
### Discovery (Optional)
|
|
102
|
+
|
|
103
|
+
If your devices support network discovery, the framework provides implementations for common protocols:
|
|
104
|
+
|
|
105
|
+
**SSDPDiscovery** - For UPnP/SSDP devices. Define your service type and implement `parse_ssdp_device()` to convert SSDP responses into `DiscoveredDevice` objects.
|
|
106
|
+
|
|
107
|
+
**SDDPDiscovery** - For SDDP devices (Samsung TVs). Same pattern: define search pattern and implement `parse_sddp_device()`.
|
|
108
|
+
|
|
109
|
+
**MDNSDiscovery** - For mDNS/Bonjour devices. Define service type and implement `parse_mdns_service()` to convert service info into device configs.
|
|
110
|
+
|
|
111
|
+
**NetworkScanDiscovery** - For devices that need active probing. Scans local network ranges and calls your `probe_device()` method for each IP.
|
|
112
|
+
|
|
113
|
+
For integrations where your device library has its own discovery mechanism, simply inherit from `BaseDiscovery` and implement the `discover()` method to call your library's discovery and convert results to `DiscoveredDevice` format.
|
|
114
|
+
|
|
115
|
+
All discovery classes handle the protocol details, timeouts, and error handling. Dependencies are lazy-loaded, so you only install what you use (ssdpy, sddp-discovery-protocol, zeroconf, etc.). If your integration doesn't support discovery, just return an empty list from `discover_devices()` and focus on manual entry.
|
|
116
|
+
|
|
117
|
+
### Event System
|
|
118
|
+
|
|
119
|
+
The driver base class automatically wires up Remote events (connect, disconnect, standby, subscribe/unsubscribe) with sensible defaults. You can override any of them, but the defaults handle most cases.
|
|
120
|
+
|
|
121
|
+
Device events (state changes, errors) automatically propagate to entity state updates. You just emit events from your device and the framework keeps the Remote in sync.
|
|
122
|
+
|
|
123
|
+
## How It Works
|
|
124
|
+
|
|
125
|
+
You inherit from base classes and override only what you need:
|
|
126
|
+
|
|
127
|
+
**Driver** - Usually works with defaults! Override only if you need custom state mapping or conditional entity creation.
|
|
128
|
+
|
|
129
|
+
**Device** - Implement your connection pattern (verify, poll, handle messages, etc.).
|
|
130
|
+
|
|
131
|
+
**Setup Flow** - Define how to discover devices and create configurations from user input.
|
|
132
|
+
|
|
133
|
+
**Config** - Just a dataclass.
|
|
134
|
+
|
|
135
|
+
The framework provides sensible defaults for common patterns. You override only what's specific to your integration. Everything else is handled automatically: lifecycle management, event routing, state synchronization, configuration persistence, error handling, and reconnection logic.
|
|
136
|
+
|
|
137
|
+
## Architecture
|
|
138
|
+
|
|
139
|
+
The framework is layered:
|
|
140
|
+
|
|
141
|
+
```
|
|
142
|
+
Your Integration (device logic, API calls, protocol handling)
|
|
143
|
+
↓
|
|
144
|
+
BaseIntegrationDriver (lifecycle, events, entity management)
|
|
145
|
+
↓
|
|
146
|
+
Device Interfaces (connection patterns, error handling)
|
|
147
|
+
↓
|
|
148
|
+
Setup Flow + Config Manager (user interaction, persistence)
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
Each layer handles its responsibility and provides clean extension points. You only touch the top layer.
|
|
152
|
+
|
|
153
|
+
## Generic Type System
|
|
154
|
+
|
|
155
|
+
The framework uses bounded generics (`DeviceT`, `ConfigT`) so your IDE knows exactly what types you're working with:
|
|
156
|
+
|
|
157
|
+
```python
|
|
158
|
+
class MyDriver(BaseIntegrationDriver[MyDevice, MyDeviceConfig]):
|
|
159
|
+
def get_device(self, device_id: str) -> MyDevice | None:
|
|
160
|
+
device = super().get_device(device_id)
|
|
161
|
+
# IDE knows device is MyDevice, full autocomplete available
|
|
162
|
+
```
|
|
163
|
+
|
|
164
|
+
No casting, no generic types, just full type safety throughout.
|
|
165
|
+
|
|
166
|
+
## Discovery Support
|
|
167
|
+
|
|
168
|
+
Optional discovery implementations for common protocols:
|
|
169
|
+
|
|
170
|
+
- **SSDPDiscovery** - For UPnP/SSDP devices
|
|
171
|
+
- **SDDPDiscovery** - For SDDP devices (Samsung TVs)
|
|
172
|
+
- **MDNSDiscovery** - For mDNS/Bonjour devices
|
|
173
|
+
- **NetworkScanDiscovery** - For scanning IP ranges
|
|
174
|
+
- **BaseDiscovery** - For custom discovery (inherit and implement `discover()`)
|
|
175
|
+
|
|
176
|
+
Lazy imports mean you only need the dependencies if you use them.
|
|
177
|
+
|
|
178
|
+
## Real-World Example
|
|
179
|
+
|
|
180
|
+
See the PSN integration in this repository:
|
|
181
|
+
|
|
182
|
+
- `intg-psn/driver.py` - 90 lines (was 300)
|
|
183
|
+
- `intg-psn/psn.py` - 140 lines (was 240)
|
|
184
|
+
- `intg-psn/setup_flow.py` - 50 lines (was 250)
|
|
185
|
+
- `intg-psn/config.py` - 15 lines (was 95)
|
|
186
|
+
|
|
187
|
+
Total: ~295 lines of integration code vs ~885 lines previously. And the new code is type-safe, testable, and maintainable.
|
|
188
|
+
|
|
189
|
+
## Migration
|
|
190
|
+
|
|
191
|
+
If you have an existing integration, see [MIGRATION_GUIDE.md](MIGRATION_GUIDE.md) for step-by-step instructions with before/after examples.
|
|
192
|
+
|
|
193
|
+
## Requirements
|
|
194
|
+
|
|
195
|
+
- Python 3.11+
|
|
196
|
+
- ucapi
|
|
197
|
+
- pyee
|
|
198
|
+
|
|
199
|
+
Optional (only if you use them):
|
|
200
|
+
- aiohttp (for HTTP devices)
|
|
201
|
+
- websockets (for WebSocket devices)
|
|
202
|
+
- ssdpy (for SSDP discovery)
|
|
203
|
+
- zeroconf (for mDNS discovery)
|
|
204
|
+
|
|
205
|
+
## Documentation
|
|
206
|
+
|
|
207
|
+
Full documentation is available at [https://jackjpowell.github.io/ucapi-framework/](https://jackjpowell.github.io/ucapi-framework/)
|
|
208
|
+
|
|
209
|
+
To build documentation locally:
|
|
210
|
+
|
|
211
|
+
```bash
|
|
212
|
+
# Install documentation dependencies
|
|
213
|
+
uv sync --group docs
|
|
214
|
+
|
|
215
|
+
# Serve documentation locally
|
|
216
|
+
mkdocs serve
|
|
217
|
+
```
|
|
218
|
+
|
|
219
|
+
Visit <http://127.0.0.1:8000> to view the docs.
|
|
220
|
+
|
|
221
|
+
## License
|
|
222
|
+
|
|
223
|
+
Mozilla Public License Version 2.0
|
|
@@ -0,0 +1,212 @@
|
|
|
1
|
+
[](https://github.com/jackjpowell/ucapi-framework/actions/workflows/test.yml)
|
|
2
|
+
[](https://discord.gg/zGVYf58)
|
|
3
|
+
[](https://buymeacoffee.com/jackpowell)
|
|
4
|
+
|
|
5
|
+
# UCAPI Framework
|
|
6
|
+
|
|
7
|
+
A framework for building Unfolded Circle Remote integrations that handles the repetitive parts of integration development so you can focus on what's important.
|
|
8
|
+
|
|
9
|
+
## What This Solves
|
|
10
|
+
|
|
11
|
+
Building an Unfolded Circle Remote integration typically involves:
|
|
12
|
+
- Writing 200+ lines of setup flow routing logic
|
|
13
|
+
- Manually managing configuration updates and persistence
|
|
14
|
+
- Implementing device lifecycle management (connect/disconnect/reconnect)
|
|
15
|
+
- Wiring up Remote event handlers
|
|
16
|
+
- Managing global state for devices and entities
|
|
17
|
+
- Handling entity registration and state synchronization
|
|
18
|
+
|
|
19
|
+
This framework provides tested implementations of all these patterns, reducing a simple integration from ~1500 lines of boilerplate to ~400 lines of device-specific code. It even adds features, like back and restore, for free.
|
|
20
|
+
|
|
21
|
+
## Core Features
|
|
22
|
+
|
|
23
|
+
### Standard Setup Flow with Extension Points
|
|
24
|
+
|
|
25
|
+
The setup flow handles the common pattern: configuration mode → discovery/manual entry → device selection. But every integration has unique needs, so there are extension points at key moments:
|
|
26
|
+
|
|
27
|
+
- **Pre-discovery screens** - Collect API credentials or server addresses before running discovery
|
|
28
|
+
- **Post-selection screens** - Gather device-specific settings after the user picks a device
|
|
29
|
+
- **Custom discovery fields** - Add extra fields to the discovery screen (zones, profiles, etc.)
|
|
30
|
+
|
|
31
|
+
The framework handles all the routing, state management, duplicate checking, and configuration persistence. You just implement the screens you need.
|
|
32
|
+
|
|
33
|
+
**Reduction**: Setup flow code goes from ~200 lines to ~50 lines.
|
|
34
|
+
|
|
35
|
+
### Device Connection Patterns
|
|
36
|
+
|
|
37
|
+
Four base classes cover the common connection patterns:
|
|
38
|
+
|
|
39
|
+
**StatelessHTTPDevice** - For REST APIs. You implement `verify_connection()` to test reachability. No connection management needed.
|
|
40
|
+
|
|
41
|
+
**PollingDevice** - For devices that need periodic state checks. You set a poll interval and implement `poll_device()`. Automatic reconnection on errors.
|
|
42
|
+
|
|
43
|
+
**WebSocketDevice** - For WebSocket connections. You implement `create_websocket()` and `handle_message()`. Framework manages the connection lifecycle, reconnection, and cleanup.
|
|
44
|
+
|
|
45
|
+
**PersistentConnectionDevice** - For TCP, serial, or custom protocols. You implement `establish_connection()`, `receive_data()`, and `close_connection()`. Framework handles the receive loop and error recovery.
|
|
46
|
+
|
|
47
|
+
All connection management, error handling, reconnection logic, and cleanup happens automatically.
|
|
48
|
+
|
|
49
|
+
**Reduction**: Device implementation goes from ~100 lines of connection boilerplate to ~30 lines of business logic.
|
|
50
|
+
|
|
51
|
+
### Configuration Management
|
|
52
|
+
|
|
53
|
+
Configuration is just a dataclass. The framework handles JSON serialization, CRUD operations, and persistence:
|
|
54
|
+
|
|
55
|
+
```python
|
|
56
|
+
@dataclass
|
|
57
|
+
class MyDeviceConfig:
|
|
58
|
+
device_id: str
|
|
59
|
+
name: str
|
|
60
|
+
host: str
|
|
61
|
+
|
|
62
|
+
config = BaseDeviceManager("config.json", MyDeviceConfig)
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
You get full CRUD operations: `add_or_update()`, `get()`, `remove()`, `all()`, `clear()`. Plus automatic backup/restore functionality for free. The framework handles all the file I/O, error handling, and atomic writes.
|
|
66
|
+
|
|
67
|
+
Full type safety means IDE autocomplete works everywhere. No more dict manipulation or manual JSON handling.
|
|
68
|
+
|
|
69
|
+
**Reduction**: Configuration management goes from ~80 lines to ~15 lines.
|
|
70
|
+
|
|
71
|
+
### Driver Integration
|
|
72
|
+
|
|
73
|
+
The driver coordinates everything - device lifecycle, entity management, and Remote events. **Most integrations work with just the defaults** - no overrides needed!
|
|
74
|
+
|
|
75
|
+
The framework provides sensible defaults for:
|
|
76
|
+
|
|
77
|
+
- **`create_entities()`** - Creates one entity per entity type automatically
|
|
78
|
+
- **`map_device_state()`** - Maps common state strings (ON, OFF, PLAYING, etc.)
|
|
79
|
+
- **`device_from_entity_id()`** - Parses standard entity ID format
|
|
80
|
+
- **`get_entity_ids_for_device()`** - Queries and filters entities by device
|
|
81
|
+
|
|
82
|
+
**Override only what you need**: Custom state enums? Override `map_device_state()`. Conditional entity creation? Override `create_entities()`. Custom entity ID format? Override `device_from_entity_id()` too.
|
|
83
|
+
|
|
84
|
+
Everything else is automatic. The framework handles Remote connection events (connect, disconnect, standby), entity subscriptions, device lifecycle management, and state synchronization.
|
|
85
|
+
|
|
86
|
+
Device events (like state changes) automatically propagate to entity state updates. The framework maintains the connection between your devices and your remote.
|
|
87
|
+
|
|
88
|
+
**Reduction**: Driver code goes from ~300 lines to ~50 lines (or less!).
|
|
89
|
+
|
|
90
|
+
### Discovery (Optional)
|
|
91
|
+
|
|
92
|
+
If your devices support network discovery, the framework provides implementations for common protocols:
|
|
93
|
+
|
|
94
|
+
**SSDPDiscovery** - For UPnP/SSDP devices. Define your service type and implement `parse_ssdp_device()` to convert SSDP responses into `DiscoveredDevice` objects.
|
|
95
|
+
|
|
96
|
+
**SDDPDiscovery** - For SDDP devices (Samsung TVs). Same pattern: define search pattern and implement `parse_sddp_device()`.
|
|
97
|
+
|
|
98
|
+
**MDNSDiscovery** - For mDNS/Bonjour devices. Define service type and implement `parse_mdns_service()` to convert service info into device configs.
|
|
99
|
+
|
|
100
|
+
**NetworkScanDiscovery** - For devices that need active probing. Scans local network ranges and calls your `probe_device()` method for each IP.
|
|
101
|
+
|
|
102
|
+
For integrations where your device library has its own discovery mechanism, simply inherit from `BaseDiscovery` and implement the `discover()` method to call your library's discovery and convert results to `DiscoveredDevice` format.
|
|
103
|
+
|
|
104
|
+
All discovery classes handle the protocol details, timeouts, and error handling. Dependencies are lazy-loaded, so you only install what you use (ssdpy, sddp-discovery-protocol, zeroconf, etc.). If your integration doesn't support discovery, just return an empty list from `discover_devices()` and focus on manual entry.
|
|
105
|
+
|
|
106
|
+
### Event System
|
|
107
|
+
|
|
108
|
+
The driver base class automatically wires up Remote events (connect, disconnect, standby, subscribe/unsubscribe) with sensible defaults. You can override any of them, but the defaults handle most cases.
|
|
109
|
+
|
|
110
|
+
Device events (state changes, errors) automatically propagate to entity state updates. You just emit events from your device and the framework keeps the Remote in sync.
|
|
111
|
+
|
|
112
|
+
## How It Works
|
|
113
|
+
|
|
114
|
+
You inherit from base classes and override only what you need:
|
|
115
|
+
|
|
116
|
+
**Driver** - Usually works with defaults! Override only if you need custom state mapping or conditional entity creation.
|
|
117
|
+
|
|
118
|
+
**Device** - Implement your connection pattern (verify, poll, handle messages, etc.).
|
|
119
|
+
|
|
120
|
+
**Setup Flow** - Define how to discover devices and create configurations from user input.
|
|
121
|
+
|
|
122
|
+
**Config** - Just a dataclass.
|
|
123
|
+
|
|
124
|
+
The framework provides sensible defaults for common patterns. You override only what's specific to your integration. Everything else is handled automatically: lifecycle management, event routing, state synchronization, configuration persistence, error handling, and reconnection logic.
|
|
125
|
+
|
|
126
|
+
## Architecture
|
|
127
|
+
|
|
128
|
+
The framework is layered:
|
|
129
|
+
|
|
130
|
+
```
|
|
131
|
+
Your Integration (device logic, API calls, protocol handling)
|
|
132
|
+
↓
|
|
133
|
+
BaseIntegrationDriver (lifecycle, events, entity management)
|
|
134
|
+
↓
|
|
135
|
+
Device Interfaces (connection patterns, error handling)
|
|
136
|
+
↓
|
|
137
|
+
Setup Flow + Config Manager (user interaction, persistence)
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
Each layer handles its responsibility and provides clean extension points. You only touch the top layer.
|
|
141
|
+
|
|
142
|
+
## Generic Type System
|
|
143
|
+
|
|
144
|
+
The framework uses bounded generics (`DeviceT`, `ConfigT`) so your IDE knows exactly what types you're working with:
|
|
145
|
+
|
|
146
|
+
```python
|
|
147
|
+
class MyDriver(BaseIntegrationDriver[MyDevice, MyDeviceConfig]):
|
|
148
|
+
def get_device(self, device_id: str) -> MyDevice | None:
|
|
149
|
+
device = super().get_device(device_id)
|
|
150
|
+
# IDE knows device is MyDevice, full autocomplete available
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
No casting, no generic types, just full type safety throughout.
|
|
154
|
+
|
|
155
|
+
## Discovery Support
|
|
156
|
+
|
|
157
|
+
Optional discovery implementations for common protocols:
|
|
158
|
+
|
|
159
|
+
- **SSDPDiscovery** - For UPnP/SSDP devices
|
|
160
|
+
- **SDDPDiscovery** - For SDDP devices (Samsung TVs)
|
|
161
|
+
- **MDNSDiscovery** - For mDNS/Bonjour devices
|
|
162
|
+
- **NetworkScanDiscovery** - For scanning IP ranges
|
|
163
|
+
- **BaseDiscovery** - For custom discovery (inherit and implement `discover()`)
|
|
164
|
+
|
|
165
|
+
Lazy imports mean you only need the dependencies if you use them.
|
|
166
|
+
|
|
167
|
+
## Real-World Example
|
|
168
|
+
|
|
169
|
+
See the PSN integration in this repository:
|
|
170
|
+
|
|
171
|
+
- `intg-psn/driver.py` - 90 lines (was 300)
|
|
172
|
+
- `intg-psn/psn.py` - 140 lines (was 240)
|
|
173
|
+
- `intg-psn/setup_flow.py` - 50 lines (was 250)
|
|
174
|
+
- `intg-psn/config.py` - 15 lines (was 95)
|
|
175
|
+
|
|
176
|
+
Total: ~295 lines of integration code vs ~885 lines previously. And the new code is type-safe, testable, and maintainable.
|
|
177
|
+
|
|
178
|
+
## Migration
|
|
179
|
+
|
|
180
|
+
If you have an existing integration, see [MIGRATION_GUIDE.md](MIGRATION_GUIDE.md) for step-by-step instructions with before/after examples.
|
|
181
|
+
|
|
182
|
+
## Requirements
|
|
183
|
+
|
|
184
|
+
- Python 3.11+
|
|
185
|
+
- ucapi
|
|
186
|
+
- pyee
|
|
187
|
+
|
|
188
|
+
Optional (only if you use them):
|
|
189
|
+
- aiohttp (for HTTP devices)
|
|
190
|
+
- websockets (for WebSocket devices)
|
|
191
|
+
- ssdpy (for SSDP discovery)
|
|
192
|
+
- zeroconf (for mDNS discovery)
|
|
193
|
+
|
|
194
|
+
## Documentation
|
|
195
|
+
|
|
196
|
+
Full documentation is available at [https://jackjpowell.github.io/ucapi-framework/](https://jackjpowell.github.io/ucapi-framework/)
|
|
197
|
+
|
|
198
|
+
To build documentation locally:
|
|
199
|
+
|
|
200
|
+
```bash
|
|
201
|
+
# Install documentation dependencies
|
|
202
|
+
uv sync --group docs
|
|
203
|
+
|
|
204
|
+
# Serve documentation locally
|
|
205
|
+
mkdocs serve
|
|
206
|
+
```
|
|
207
|
+
|
|
208
|
+
Visit <http://127.0.0.1:8000> to view the docs.
|
|
209
|
+
|
|
210
|
+
## License
|
|
211
|
+
|
|
212
|
+
Mozilla Public License Version 2.0
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
[project]
|
|
2
|
+
name = "ucapi-framework"
|
|
3
|
+
version = "0.1.16"
|
|
4
|
+
description = "ucapi framework that provides core functionality for building integrations."
|
|
5
|
+
readme = "README.md"
|
|
6
|
+
requires-python = ">=3.11"
|
|
7
|
+
dependencies = [
|
|
8
|
+
"pyee>=13.0.0",
|
|
9
|
+
"ucapi>=0.3.2",
|
|
10
|
+
"aiohttp>=3.9.0",
|
|
11
|
+
"mkdocs-material>=9.7.0",
|
|
12
|
+
]
|
|
13
|
+
|
|
14
|
+
[dependency-groups]
|
|
15
|
+
dev = [
|
|
16
|
+
"pytest>=9.0.1",
|
|
17
|
+
"pytest-asyncio>=0.23.0",
|
|
18
|
+
"pytest-cov>=4.1.0",
|
|
19
|
+
]
|
|
20
|
+
docs = [
|
|
21
|
+
"mkdocs-material>=9.5.0",
|
|
22
|
+
"mkdocstrings[python]>=0.24.0",
|
|
23
|
+
]
|
|
24
|
+
|
|
25
|
+
[tool.pytest.ini_options]
|
|
26
|
+
testpaths = ["tests"]
|
|
27
|
+
python_files = ["test_*.py"]
|
|
28
|
+
python_classes = ["Test*"]
|
|
29
|
+
python_functions = ["test_*"]
|
|
30
|
+
asyncio_mode = "auto"
|
|
31
|
+
addopts = [
|
|
32
|
+
"-v",
|
|
33
|
+
"--tb=short",
|
|
34
|
+
"--strict-markers",
|
|
35
|
+
]
|