[michaelarnauts]

Summary

register() started a session first on a LAN C, to find out whether the app was registered already, and registered directly on a ComfoConnect Pro, since a Pro doesn't answer a session of an app that isn't registered (it times out). That made the bridge type necessary for registering, so Home Assistant had to discover a bridge before a reauth.

A LAN C accepts registering an app that is registered already, as long as the PIN is right, without adding another entry (it keeps the first name); a wrong PIN is refused with NOT_ALLOWED, also for a registered app. A Pro was already always registered directly, also on a reauth of an app that was still registered. This is now in docs/PROTOCOL.md too. The official app also registers directly: it creates a new UUID and sends RegisterAppRequest without starting a session first, with PIN 0 and then the PIN the user enters. It only learns that a bridge is a Pro from the session confirmation ("ccpro").

So register() now registers directly on every bridge and then starts a session.

With that, nothing in the library uses the bridge type anymore, so it goes: bridge_type, the bridge_type argument of Bridge() and ComfoConnect(), GatewayType, and recognising a Pro by the "ccpro" of the session confirmation. The node of the bridge tells the same with its product id (222 a ComfoConnect Pro, 5 a LAN C, 9 the WiFi module of a ComfoAir Flex, see #169). The official app uses "is a Pro" for a few features we don't have (UK time, zones through whoami); the product id of the bridge node can tell that if we ever need it. docs/PROTOCOL.md still describes "ccpro".

Breaking changes: Bridge() and ComfoConnect() no longer take bridge_type, the bridge_type attribute and GatewayType are gone, and discovery no longer reports the type. register() no longer returns whether the app was newly registered; we can't tell anymore. The CLI prints "UUID … is registered." Registering a UUID that is registered already now needs the right PIN: register for it without --pin on a bridge with another PIN than 0 used to say "already registered", and now fails with "check the PIN". Home Assistant only registers a new UUID, or one the bridge no longer accepts, so it isn't affected.

Testing

• test_registers_then_starts_session (LAN C, the WiFi module of a Flex, Pro) and test_wrong_pin.
• pytest, pylint (10/10) and black pass.
• On a LAN C, with a temporary UUID that was deregistered afterwards, listing the registrations after every step: registering it twice, and once more with another name, keeps one entry with the first name; deregistering it leaves the list as it was before.
• Also on the LAN C: starting a session before registering gives NOT_ALLOWED; registering, registering again, and starting a session succeed; registering again with a wrong PIN gives NOT_ALLOWED. register from the CLI twice in a row succeeds both times.

🤖 Generated with Claude Code