I have a SB8200 and would be happy to help you with any information you need.
Arris SB8200 HW Rev 7
Standard Specification Compliant Docsis 3.1
Hardware Version 7
Software Version AB01.02.053_082120_193.0A.NSH
I have looked through the logs and included the log here.
This error originated from a custom integration.
Logger: custom_components.cable_modem_monitor.config_flow
Source: custom_components/cable_modem_monitor/config_flow.py:137
integration: cable_modem_monitor (documentation, issues)
First occurred: 10:03:34 PM (11 occurrences)
Last logged: 11:00:13 PM
Unexpected exception during validation
Traceback (most recent call last):
File “/config/custom_components/cable_modem_monitor/config_flow.py”, line 137, in get_result
self.info = await self.task
^^^^^^^^^^^^^^^
File “/config/custom_components/cable_modem_monitor/config_flow_helpers.py”, line 222, in validate_input
result = await hass.async_add_executor_job(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
…<6 lines>…
)
^
File “/usr/local/lib/python3.13/concurrent/futures/thread.py”, line 59, in run
result = self.fn(*self.args, **self.kwargs)
File “/config/custom_components/cable_modem_monitor/core/discovery/pipeline.py”, line 281, in run_discovery_pipeline
assert auth.html is not None
^^^^^^^^^^^^^^^^^^^^^
AssertionError
@evilpig Great to hear the XB8 works! The XB7 parser seems to cover the whole XB family — I’ll update the metadata to reflect XB6/7/8 compatibility in v3.13.2.
@dtbelz Glad the latest release got past the connection error. The SB8200 has turned out to have several firmware variants — we have the original AB01.01 covered (#42, #81) and a
completely different AC01 variant tracked in #109. Your AB01.02 firmware on HW Rev 7 looks like it could be a middle revision we haven’t seen yet.
Could you do three things?
Open a Sign in to GitHub · GitHub using the Modem Request template — that’s where I track all the details
Grab your HA error log (Settings → System → Logs, filter for cable_modem_monitor) and paste it in the issue
Run a HAR capture using the har-capture utility and attach the sanitized file to the issue — this lets me see exactly what your modem is serving
Instructions for har-capture are in the issue template. If you run into any trouble I can walk you through it.
This project currently covers 19 modems and with each new one I get a clearer picture of the modem landscape. It’s not an easy problem to solve but it’s incredibly fun to work on.
Just keep in mind this is a side project I work on in my spare time.
I still need to submit data for the XB7 because the login or parser doesn’t seem to be working. I haven’t had the time to update my issue yet. Seeing as the XB8 is working, hopefully it’s something small/simple causing the issue.
Just put it up on github for you. Thank you for the help. if you have any questions just ask. I also have a few other modem types I would be happy to test with you if you want once we get this one sorted.
Question: Does the ability to log in affect how many data points or info the integration gets access to?
I have an Arris S33 which I do see is on the list. I use it on Xfinity, and when they included it on their network, they took away my ability to login to it… and none of the ‘generic’ factory credential pairs work either… I’m locked out.
I’m asking because I can get to its login page, and there’s ‘Current Status’ html button where a few of the data points are offered:
||Firmware Version||
| |Internet Connection||
| |Downstream Frequency||
| |Downstream Signal Power||
| |Downstream Signal SNR||
It’s been a couple of years but i remember when I bought it and set it up i could login for a day or 2 before Xfinity locked it… the channels used, upstream data ect where there.
Thanks for the feedback, updates, and contributions! I’ve been somewhat intentional with not posting here too much because every time I do, the demand for new modems goes up, and unfortunately the project needs to mature a bit more before that’s possible. So first of all, thank you to everyone who is using this integration and for supplying HAR captures and debugging with me. As of now, HACS is reporting 70 installations (opt in metrics), across 19 modems. Months ago I set a goal of reaching 30 modems before I could build a proper architecture around the observed patterns, and we are officially at that point.
@esand - I think we need to capture a new HAR file using the har-capture utility I recently created. This is the single source of truth for all modems and has evolved to capture details like cookie behavior during authentication that are easy to miss from manual descriptions alone.
@dtbelz thank you for your contribution! I plan on adding your modem with v3.14 so stay tuned for the beta.
@paulbates Great question. The integration handles both scenarios — if the modem’s data pages are publicly accessible, no credentials are needed. If they’re behind a login, the integration authenticates on your behalf, but you need valid credentials during setup.
Your S33 is an interesting case. The current S33 parser uses HNAP (a SOAP-based protocol) which requires authentication, so it won’t work if Xfinity locked you out. But that “Current Status” page you can see without logging in is a different access path entirely — HTML, no auth. It has fewer data points (no upstream, no per-channel breakdown), but the v3.14 architecture is specifically designed to support this kind of variant cleanly. A HAR capture of what you can see would be a great starting point.
I was having bad connection issues with Xfinity… this Add-on was super easy to get up and running, and now i have graphs!!! So when my connection starts flaking I can throw this info at them and tell them to come fix it, or at least ask nicely.
Huge thank you to all who helped this guy get it up and running. Wish I could contribute but I dont quite understand the contribution requirements as i am a beginner level when it comes to HTML, Code, Parsing… all that stuff.
I will help by confirming that the Technicolor XB8-T works with the XB7 profie. So far no issues!
Just wanted to drop a note to say a huge thank you for putting this integration together! Getting granular cable modem data pulled natively into Home Assistant is something I’ve been hoping to have for years, and the install and setup process were incredibly smooth.
As a heads-up, I went ahead and installed the 3.14 beta 1 because I was looking for the uptime sensor. I noted a few minor quirks, but I’ll get those submitted as issues on the repo shortly so they are easy to track.
have you considered scraping the information about the devices that are connected to the AP to use the information as a presence detector instead of having to run HA in the background on the devices themselves? hard to convince all the members of the family to install the app on their phone.
Hi everyone. Thank you again for your support on this project.
It has now been 8 months since I started this as an experiment with AI on one modem, and it has grown into a scalable yaml config driven platform with v3.14 (currently on beta.11). The catalog is up to 37 modems across 42 different configurations, with official confirmation of 21.
So if you are interested in helping, I am looking for "sign off" on the pending 21 configurations. The most useful thing you can submit is a diagnostics file through an open issue or the Verify Working Modem form, which walks you through the Download Diagnostics step. You can see which configurations still need confirmation in the catalog status list. Unverified modems will show an asterisk next to them in the modem dropdown.
Please keep in mind the core goal with Cable Modem Monitor is to report in Home Assistant the data your cable modem presents. There are many other ideas that expand beyond that scope, but I strongly believe in doing one thing really well and building separate integrations for ideas that reach beyond this project's core goals.
One important note for some early adopters. If you installed Cable Modem Monitor before it was accepted into the official HACS store, you stopped receiving updates silently when I switched to zip installs to better follow HACS best practices. It has already affected a couple of early adopters, and I expect others are stuck on an old version without realizing it. The one-time fix:
If you added it as a custom repository:
HACS, three-dot menu, Custom Repositories. If solentlabs/cable_modem_monitor is listed, delete that entry.
Reload data, then search "Cable Modem Monitor" in the HACS integrations store and install from there.
Redownload, "Need a different version?", and pick the latest v3.14 beta. Note there is also a v3.13.0-beta.10 in the list, which is the older version, so do not pick that one.
Restart Home Assistant. The integration migrates automatically, with no need to remove and re-add.
If you installed manually with git clone:
In config/custom_components, delete any cable_modem_monitor-hidden folder.
Then follow the steps above.
Most importantly, I am thrilled to hear the success stories. Thanks to recent contributors like @Packers871 and @ccpk1, who shared his story and has helped with bug fixes and fresh ideas.
The CM3000 is already supported, just not in the official release yet. To get it now: HACS → Cable Modem Monitor → Redownload → “Need a different version?” and pick the latest 3.14 beta. It reaches everyone when 3.14 is officially released.
One thing to expect: the provisioned speed sensors stay empty, so you will not see the downstream and upstream limits your ISP gives the modem. The modem loads those separately and the capture I have does not include them. If you ever want to run a har-capture on yours, that would fill the gap.
For bugs or ideas, GitHub is the best place and has a template for each. The bug template asks for the diagnostics download, which tells me a lot more than a forum post can.
Hi @kwschulz!
With the latest update, it seems like the system_uptime sensor has disappeared from my Netgear CM600.
Was that on purpose or is it a side effect of something else?
Thanks!
System Uptime and Current Time both wrote a new recorder row on every single poll for values with no historical worth. Your CM600 still reports uptime, and the integration still reads it. It now feeds Last Boot Time instead of getting an entity of its own, which only changes when the modem actually reboots.
Set the card format to relative and it reads “xx days ago”:
Thanks you @kwschulz for the response and the background info. I adjusted my dashboard accordingly.
On another note:
Unlike most of my other sensors, I don’t keep the detailed data for my cable modem - and for a few other devices - for two weeks; I automatically purge data that’s older than 3 days every day at around 1AM in order to keep the database size in check. Just a thought
Is this an housekeeping automation you can drop into the user if it is selected in the initial configuration screen with a toggle, and maybe a selectable number of retention days?
Some people want to track statistics long term if they are collecting evidence for troubleshooting, while others couldn’t care.
Give them the option, with your (and Claude’s) code making sure the correct sensor entities and parameters are used without too much delving into the Recorder documentation and YAML code. After all, you know exactly what the sensor entities are called, don’t you? Default to purge after three days if that is your preference for those that are not sure and just click past the screen.
Make it so if the configuration screen is brought up again and the recorder database already has content, it will flush older entries if a shorter date is selected so creating, flushing are both in the same place. This will give people that have collected sensor stats and don’t need them any more a convenient place to remove them. Your app creates the sensor entities, collects the data, and should be responsible for cleaning up after itself.
You could offer a brief description of what the values for entities do in the configuration screen as well.
@IOT7712@chairstacker thanks for bringing this up. Keeping the database in check is already on my mind, and it is one of the reasons I removed the uptime sensor in the first place.
As far as I know, recorder.purge_entities takes a keep_days but removes state history only, not statistics. The Home Assistant data docs say “The states and statistics_short_term tables are automatically purged after a predefined period (default is 10 days). The long-term statistics table is never purged.” The only lever I can find for that table is recorder/clear_statistics, which takes statistic ids and no time bound.
If that is right, a retention setting would clear the tier that already expires on its own and leave the one that never does, which isn’t what we are trying to accomplish, unless there’s a mechanism or a best practice I missed?
Database size is already discussed in #178, so I would encourage continuing the conversation there.
