Add support for the new ComfoConnect Pro by jvanhees · Pull Request #74 · michaelarnauts/aiocomfoconnect

jvanhees · 2026-05-27T11:51:24Z

I installed a new ComfoConnect Pro a few weeks ago, which seems to be replacing the previous version, and adds Wifi and other functionality that was in another connect box previously. The library didn't seem to properly connect to this new ComfoConnect Pro, even though it does support the same protocol. After some retrying, the library is able to connect, but since it initially fails the HACS integration doesn't really play nice. I used Claude to change the connection logic to also support this device, apparently it keeps the TCP connection open instead of disconnecting after a failed authentication, and just waits for a new registration.

I asked Claude to also add some test for this functionality, all other tests are still working. I do note that whenever I run the discover functionality the first time, it tends to not find the bridge. After running it a second time, it does run. Might need some more investigation but I suspect this won't be an issue with the Home Assistant integration.

Please let me know if you need anything changed or something else. Hopefully we can merge this, update the HACS integration as well with the new version and get the ComfoConnect Pro working in Home Assistant :) .

jvanhees · 2026-05-27T11:53:39Z

Related to this discussion: #55

michaelarnauts · 2026-05-27T17:21:58Z

Thanks!

I think this looks fine, odd that there is such a small difference between the two devices.

Can you take a look at the lint issue?

jvanhees · 2026-05-27T17:32:08Z

I agree it's odd that there is this difference between the two devices, but I suspect that they may have rewritten some of the networking inside the device, but were able to salvage much of the software of the old device? Or they just completely rebuild it using the existing spec, who knows. To be honest, I haven't tested the complete integration yet so I'm not sure if all the addresses are the same - but there's no reason for me to suspect they've changed.

Linting issue has been fixed.

michaelarnauts · 2026-05-27T17:42:14Z

Thanks! I do wonder if maybe the flow should be changed, because currently, we are waiting for a timeout to know that we should register. This can perhaps explain the timeout you are also seeing in Home Assistant.

If you don't have a better idea, I'm okay with merging this.

michaelarnauts · 2026-05-27T17:43:24Z

CI still fails. Can you also run black to format the code?

poetry run black --check aiocomfoconnect/*.py

jvanhees · 2026-05-27T21:38:47Z

The current flow for this fix is far from elegant, I agree. Obviously we could add a flag to the CLI interface but I don't like that and it would require the Home Assistant integration to add another option to the setup wizard. There is an option to do a version call before logging in. I've added the command to my branch, but I don't have a LAN C so I am unable to see the difference, could you run this?

poetry run python -m aiocomfoconnect version --host <your host>

On the Pro, this is the output:

gatewayVersion  : 3222274053
serialNumber    : ENG<my serial>
comfoNetVersion : 1074790400

I've asked my digital junior developer for other options, this is the response:

Here are the remaining avenues worth exploring:

VersionRequest serial prefix (most promising, needs LAN C data)
Your Pro returned ENG<15 numbers>. LAN C serial numbers likely have a different prefix. This works pre-session, so the version command we just added would be the tool — just need someone with a LAN C to run it.

gatewayVersion bit pattern
Your Pro: 0xC0000005. The top byte 0xC0 (1100 0000) might encode the device variant. If a LAN C returns 0x80000005 or 0x40000005, the top bits would be a reliable flag.

CnNodeNotification.productId (post-registration)
Once connected, the bridge broadcasts node notifications that include a productId. Node 1 is the gateway itself — the Pro product number mentioned earlier was 30006323. This would be definitive but only works after a registered session is established.

ListRegisteredAppsRequest pre-session
Worth trying — some older firmware versions respond to this without a session. If it works and the response format differs between devices, that's a data point.

However, I'm not very hopeful we can differentiate with only 2 devices.

One other option is to call the HTTP endpoint that is exposed on port 80 on the device, and search the returned HTML for the text ComfoConnect PRO. But I'm not sure if that option is more elegant than the timeout solution.

I should have fixed the linting and formatting issues btw.

jvanhees · 2026-05-27T21:49:43Z

I might try to get a pcap from the Zehnder application to see how it is handling it later this week, but we could also accept this fix for now and perhaps later (well.... you know ;) ) find a better way.

michaelarnauts · 2026-05-28T07:51:04Z

Using your version call times out on my Comfoconnect LAN C

It's because you are using the same source UUID and destination UUID. Oddly enough, this then works fine on the ComfoConnect PRO?

DEBUG:aiocomfoconnect.bridge:Connected to bridge 192.168.1.170
DEBUG:aiocomfoconnect.bridge:VersionRequest
DEBUG:aiocomfoconnect.bridge:Adding listener for event 1
DEBUG:aiocomfoconnect.bridge:TX 00000000000000000000000000000001 -> 00000000000000000000000000000001: 08122001
type: VersionRequestType
reference: 1

When I change your version code to be like this:

async def run_version(host: str):
    """Request version information from the bridge (no registration required)."""
    bridges = await discover_bridges(host)
    if not bridges:
        raise BridgeNotFoundException("No bridge found")

    bridge = bridges[0]
    await bridge.connect(DEFAULT_UUID)
    try:
        msg = await bridge.cmd_version_request()
        print(f"gatewayVersion  : {msg.gatewayVersion}")
        print(f"serialNumber    : {msg.serialNumber}")
        print(f"comfoNetVersion : {msg.comfoNetVersion}")
    finally:
        await bridge.disconnect()

It works, because the destination UUID is correct then.

DEBUG:aiocomfoconnect.bridge:Connected to bridge 192.168.1.170
DEBUG:aiocomfoconnect.bridge:VersionRequest
DEBUG:aiocomfoconnect.bridge:Adding listener for event 1
DEBUG:aiocomfoconnect.bridge:TX 00000000000000000000000000000001 -> 0000000000251010800170b3d54264b4: 08122001
type: VersionRequestType
reference: 1


DEBUG:aiocomfoconnect.bridge:RX 0000000000251010800170b3d54264b4 -> 00000000000000000000000000000001: 08442001 0881a8c0800c120d44454d30313136333731323034188080c0800c
type: VersionConfirmType
reference: 1

gatewayVersion: 3222279169
serialNumber: "DEM0116371204"
comfoNetVersion: 3222274048

DEBUG:aiocomfoconnect.bridge:Emitting for event 1
gatewayVersion  : 3222279169
serialNumber    : DEM0116371204
comfoNetVersion : 3222274048
DEBUG:aiocomfoconnect.bridge:Disconnecting from bridge 192.168.1.170

michaelarnauts · 2026-05-28T07:55:39Z

Also, calling the HTTP endpoint won't work, because the Comfoconect LAN C doesn't expose a HTTP server, and I don't like to try and wait for a timeout just to know what system you have.

But maybe the Comfoconnect PRO sends a specifc UUID (because in your code, it seemed to accept the default uuid)?

What do you see when you run

$ poetry run python -m aiocomfoconnect --debug discover --host <ip>

DEBUG:asyncio:Using selector: EpollSelector
INFO:asyncio:Datagram endpoint local_addr=('0.0.0.0', 0) remote_addr=None created: (<_SelectorDatagramTransport fd=6 read=idle write=<idle, bufsize=0>>, <aiocomfoconnect.discovery.BridgeDiscoveryProtocol object at 0x7b73387093a0>)
DEBUG:aiocomfoconnect.discovery:Socket has been created
DEBUG:aiocomfoconnect.discovery:Sending discovery request to 192.168.1.170:56747
DEBUG:aiocomfoconnect.discovery:Data received from ('192.168.1.170', 56747): b'\x12#\n\r192.168.1.170\x12\x10\x00\x00\x00\x00\x00%\x10\x10\x80\x01p\xb3\xd5Bd\xb4\x18\x01'
Discovered bridges:
<Bridge 192.168.1.170, UID=0000000000251010800170b3d54264b4>

DEBUG:asyncio:Close <_UnixSelectorEventLoop running=False closed=False debug=True>

jvanhees · 2026-05-28T17:21:25Z

If I run that command:

DEBUG:asyncio:Using selector: KqueueSelector
INFO:asyncio:Datagram endpoint local_addr=('0.0.0.0', 0) remote_addr=None created: (<_SelectorDatagramTransport fd=6 read=idle write=<idle, bufsize=0>>, <aiocomfoconnect.discovery.BridgeDiscoveryProtocol object at 0x105f48e30>)
DEBUG:aiocomfoconnect.discovery:Socket has been created
DEBUG:aiocomfoconnect.discovery:Sending discovery request to 192.168.0.85:56747
DEBUG:aiocomfoconnect.discovery:Data received from ('192.168.0.85', 56747): b'\x12$\n\x0c192.168.0.85\x12\x10\x1f\xffz\x10z\x10@\x00\x80\x00\x14O\xd7\x10\x1a\xde\x18\x01 \x02'
Discovered bridges:
<Bridge 192.168.0.85, UID=1fff7a107a1040008000144fd7101ade>

DEBUG:asyncio:Close <_UnixSelectorEventLoop running=False closed=False debug=True>

jvanhees · 2026-05-28T18:04:47Z

I think this might be the key to recognize the new version. It seems like it is identifying itself with a new GatewayType in the SearchGatewayResponse. I think I'm going to rewrite this PR so we handle the registration flow slightly different for either device.

michaelarnauts · 2026-05-28T18:13:59Z

Nice. What is the version of that response? On my device, it's 1. I think I don't have the gatewaytype, but I should check this.

michaelarnauts · 2026-05-28T18:16:57Z

The protob file I use specifies this

enum GatewayType {
    lanc = 0;
    season = 1;
}

Unsure what season is, but is the comfoconnect pro maybe 2? It might make sense to extract a new protob file from the android apk. That's where I got the current version. Your raw string seems to end with 2.

jvanhees · 2026-05-28T19:01:20Z

Yes, it's 2 indeed. But I think, looking at the current codebase, that this needs to be handled in main.py. The downside of that is that this also needs to be changed in the config flow of the homeassistant repository (https://github.com/michaelarnauts/home-assistant-comfoconnect/blob/master/custom_components/comfoconnect/config_flow.py). The downside is that this logic now resides in both repositories. I think it's up to you if you're ok with that, or if you want to somehow refactor this so the logic is inside the ComfoConnect class.

If we fix it in main.py, I'd probably add a "is_pro" branch after the connect call (https://github.com/michaelarnauts/aiocomfoconnect/blob/master/aiocomfoconnect/__main__.py#L92).

Edit: GatewayType would probably look like this:

enum GatewayType {
    lanc = 0;
    season = 1;
    pro = 2;
}

jvanhees

I've written a refactor that changes some of the function and introduces a new register method on the bridge. Could you test if this also works on the LAN C?

jvanhees · 2026-05-28T20:53:33Z

+        if self.bridge_type != GATEWAY_TYPE_PRO:
+            # LAN C: check whether we are already registered by starting a session.
+            try:
+                await self.cmd_start_session(True)
+                return False  # Already registered; session is now active.
+            except ComfoConnectNotAllowed:
+                pass  # Not registered yet; fall through to register below.


If we are ok with changing the actual behaviour, we could get rid of this part. I'm not really sure how that would work on the LAN C tho.

jvanhees · 2026-05-28T20:53:54Z

 _LOGGER = logging.getLogger(__name__)

 TIMEOUT = 5
+GATEWAY_TYPE_PRO = 2


Might want to get this from the protobuf file.

jvanhees changed the title ~~Add support for the new Comfoconnect Pro~~ Add support for the new ComfoConnect Pro May 27, 2026

michaelarnauts mentioned this pull request May 28, 2026

Support Comfoconnect Pro michaelarnauts/home-assistant-comfoconnect#133

Open

jvanhees added 2 commits May 28, 2026 21:26

Simplify register flow to support the ComfoConnect Pro

76a312e

Add tests and keep old flow in place

b64d45a

jvanhees force-pushed the comfoconnect-pro-connection branch from 80c36d2 to b64d45a Compare May 28, 2026 20:52

jvanhees commented May 28, 2026

View reviewed changes

Uh oh!

Conversation

jvanhees commented May 27, 2026

Uh oh!

jvanhees commented May 27, 2026

Uh oh!

michaelarnauts commented May 27, 2026

Uh oh!

jvanhees commented May 27, 2026

Uh oh!

michaelarnauts commented May 27, 2026

Uh oh!

michaelarnauts commented May 27, 2026

Uh oh!

jvanhees commented May 27, 2026

Uh oh!

jvanhees commented May 27, 2026

Uh oh!

michaelarnauts commented May 28, 2026

Uh oh!

michaelarnauts commented May 28, 2026

Uh oh!

jvanhees commented May 28, 2026

Uh oh!

jvanhees commented May 28, 2026

Uh oh!

michaelarnauts commented May 28, 2026

Uh oh!

michaelarnauts commented May 28, 2026

Uh oh!

jvanhees commented May 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jvanhees left a comment

Choose a reason for hiding this comment

Uh oh!

jvanhees May 28, 2026

Choose a reason for hiding this comment

Uh oh!

jvanhees May 28, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

jvanhees commented May 28, 2026 •

edited

Loading