Correct the parameter counts: they were cumulative, not per device

An inventory printed at the end of each discovery burst grows as the sweep
proceeds, so what looked like 88 parameters on the air conditioning was 88
seen so far across every device. Keyed per address it reports 32, the
interface 60, and the bus 126 in total.

Also records what each address actually answers for, now that the two can be
told apart.

Author: cgehring-blip

README.md

@@ -35,11 +35,12 @@ Heat/Cool mode.
 everything else goes away. A link that keeps flapping is the signature of a
 missing proxy, and that is only visible if something reports the link itself.
 
-**Sensors — every parameter the bus reports.** The appliance answers parameter
-discovery with everything it knows about itself: 88 values on the air
-conditioning alone, from measured temperatures and mains presence to error
-codes, firmware revisions and timer configuration. Each becomes a diagnostic
-sensor, grouped under the device that reported it.
+**Sensors — every parameter the bus reports.** Each device answers parameter
+discovery with everything it knows about itself: 32 values on the air
+conditioning, 60 on the interface, and a handful each from the rest — measured
+temperatures, mains presence, error codes, firmware revisions, timer
+configuration. Every one becomes a diagnostic sensor, grouped under the device
+that reported it. On this system that is 126 sensors across eight devices.
 
 A Truma system answers on more addresses than it has devices — the interface
 here answers on three, all reporting the same parameters under one

docs/findings.md

@@ -44,14 +44,25 @@ reference's warning that doing so breaks the transport.
 
 Discovered from parameter discovery in capture 1.
 
-| Address | Identifies as | Notes |
+Counted per address, from a sweep where each device was asked separately.
+
+| Address | Identifies as | Own parameters |
 |---|---|---|
-| `0x0101` | **`iNet X Interface AC`**, `Identify.Type` = 10 (INTERFACE) | takes `RoomClimate` commands |
-| `0x0601` | blePeripheral | `BleDeviceManagement`, `DeviceManagement` |
-| `0x0702` | same serial as `0x0801` | `Identify` only |
-| `0x0801` | **`Identify.Name` = `Aventa comfort 2. G`**, `Identify.Type` = 3 (AC) | **takes `AmbientLight` commands** |
+| `0x0101` | **`iNet X Interface AC`**, `Identify.Type` = 10 (INTERFACE), serial `IIIRTEU-A-…`, sw 3.5 | 60 — takes `RoomClimate` commands |
+| `0x0801` | **`Aventa comfort 2. G`**, `Identify.Type` = 3 (AC), serial `AVRLWZZ-A-…`, sw 1.6 | 32 — takes `AmbientLight`, `AirCooling`, `AirHeating` |
+| `0x0702` | same serial as `0x0801` | 7, `Identify` only |
+| `0x0601` | blePeripheral | 10 |
+| `0x0600` | `Blemcu`, `DeviceManagement` | 6 |
+| `0x0800` | `DeviceManagement`, `ErrorReset` | 6 |
+| `0x0200`, `0x0400` | `DeviceManagement` only | 3 each |
+| `0x0500` | app slot 0 | 6 |
 | `0x0501` | app slot 1 | address assigned to us at registration |
 
+Careful with cumulative counts: an inventory printed after each burst grows as
+the sweep proceeds, so "the appliance reports 88 parameters" was really "88
+parameters had been seen by then, across every device". Keyed per address, the
+air conditioning reports 32.
+
 `0x0801` is not in the reference's address table, which lists `0x0800` as
 CAN_SLAVE and `0x0202` as `tinAventa`. Our Aventa is neither — so the address
 has to be discovered at runtime rather than assumed.