feat: add Sagemcom F3896LG driver (Virgin Media Hub 5 / Liberty Global REST API) - #754
feat: add Sagemcom F3896LG driver (Virgin Media Hub 5 / Liberty Global REST API)#754sparkleHazard wants to merge 2 commits into
Conversation
…l REST API) The F@st 3896 ships with two incompatible firmware families. The existing sagemcom driver handles the Tele2/Com Hem XMO JSON-RPC variant (itsDNNS#163); Liberty Global units (Virgin Media Hub 5 F3896LG-VMB, Ziggo) instead expose an unauthenticated read-only REST API at /rest/v1/ and return 404 for /cgi/json-req. - New F3896LGDriver: downstream (SC-QAM + OFDM), upstream (ATDMA + OFDMA), device info from state_, provisioned rates from serviceflows - Handles the firmware quirk where OFDM/OFDMA power is reported scaled x10 (380 == 38.0 dBmV); SC-QAM/ATDMA power is unscaled - login() verifies the REST API is reachable so the setup wizard test is meaningful despite there being no actual authentication - Unit tests with payloads captured from a real Virgin Media (UK) Hub 5 in modem mode (identifiers anonymised) Verified against a live Virgin Media Hub 5: 31 SC-QAM + 1 OFDM downstream, 5 ATDMA + 1 OFDMA upstream parse correctly.
|
Thanks for the contribution. I’ve added a few corrections and regression tests to the branch. Could you please test the current version against your Hub 5 and confirm that the downstream and upstream values, device information, and provisioned rates still look correct in DOCSight? If everything works as expected on your device, let us know and we’ll merge the PR after your feedback. |
|
Tested the current branch (e8ba9a8 + your 249ea58) against a live Virgin Media Hub 5 (F3896LG, modem mode). All the values look correct and match the hub:
Two notes: (1) OFDM/OFDMA frequency now renders Otherwise functionally correct — happy for it to merge. Thanks for the quick review and extra tests. |
Summary
Adds a driver for the Liberty Global firmware variant of the Sagemcom F@st 3896 — the Virgin Media Hub 5 (F3896LG-VMB), also used by Ziggo (NL) and other LG-footprint ISPs.
This follows up on #163: the existing
sagemcomdriver targets the Tele2/Com Hem XMO JSON-RPC firmware (/cgi/json-req, SHA-512 login). On Liberty Global units that endpoint simply doesn't exist (404 — which is exactly how I found this, trying to add my Hub 5 with the existing driver). The LG firmware instead exposes a read-only REST API at/rest/v1/that requires no authentication for cable-modem status. It's the same API documented by the community client ties/sagemcom-f3896-py, which you referenced in #163 before it turned out the Swedish units were the other firmware.What the driver does
login()— no real auth exists, so it verifies/rest/v1/cablemodem/registrationanswers, making the setup-wizard connection test meaningfuldocsis30, OFDM →docsis31(channel ID, frequency, power, SNR/MER, corrected/uncorrected errors, modulation)docsis30, OFDMA →docsis31/rest/v1/cablemodem/state_(DOCSIS version, status, uptime)/rest/v1/cablemodem/serviceflows→ConnectionInfopoweris reported scaled ×10 (380= 38.0 dBmV,-118= −11.8 dBmV) while SC-QAM/ATDMA power is unscaled. Confirmed against the modem GUI values.rxMer: 0on the OFDM channel is treated as "not reported" →NoneTesting
tests/drivers/f3896lg/with fixture payloads captured from a real Hub 5 (identifiers anonymised): parsing for all four channel types, unlocked-channel skipping, the ×10 power quirk, device/connection info, registry entrypytest tests/drivers/→ 125 passed (Python 3.13)Notes
https://192.168.100.1(modem-mode management IP, self-signed cert — driver usesverify=Falselike other HTTPS-modem drivers)credentials_required: Falsehint, since the API is unauthenticated