Verified masks

A device’s mask version identifies its system software and decides how an application is loaded. Tinkerbus builds load plans for these masks only. For any other mask the load is refused with a message that load plans exist only for the supported versions, which the message lists (MV-0012, MV-0021, MV-0705, MV-07B0 and MV-091A). The application then offers a report so that you can tell the project about the device.

For each family the plan is compared in the test suite with recorded reference downloads (packet captures of a download made with ETS), so the sequence and every written octet match. The hardware column says what was done on real devices.

Notes per mask

0x0021 (BCU 2)

Plan equal to a full reference download (23 property writes, 665 memory octets). The to-do list names no open item for this mask besides partial downloads, which have not been tried on this mask’s hardware.

0x0705

Plan equal to four reference downloads. One-octet differences against live devices are runtime changes in the devices: the image equals what was written. Objects with more than one group address are verified only on this mask.

0x07B0 (System B)

• Image, plan and executor equal five reference downloads. Checksums of the load images equal what the live devices report (knxdownload -verify, read-only).
• The IP interface answers about every 3 to 10 seconds to extended memory reads, so its memory is not read for the backup unless -full-backup is given, and it needs more than 30 seconds to come back from the restart.
• Relative segments are allocated by the device; tables are built from scratch; the load image holds its size and a CRC-16.
• Open: calculation scripts of parameters other than those the heating actuators use are not understood. The heating actuators’ scripts are not needed, because the stored values are used.

0x091A (IP router)

• Plan equal to a 21-step reference download, including the line coupler configuration, the IP configuration of the KNXnet/IP object and the filter table.
• Real reload done. The router keeps its time to live of 64 although 32 is written and confirmed.
• Open: some octets of the image come from a computation that is not reproduced; the load keeps what the device holds there and the image warns. Secure configuration and fixed IP assignment are not built.
• The group filter table is calculated from the group address links of the project and written after the table is cleared. The plans equal several reference downloads that changed the table. Dry runs against the real router are clean. One real write was done where the table on the router was already identical, so nothing changed on the device. Calculation of the table by the rule used here is still treated as a hypothesis until compared with more tables.
• The router is the gateway the tool talks through, so knxprogram connects again after the restart. The application leaves IP routers to knxprogram.

0x0012 (BCU 1)

• No load state machines: each step reads the device in chunks of 12 octets, writes the span between the first and last differing octet and reads it back. The plan has no verify mode, no access levels and no properties.
• Verified with at most one group address. The image warns for more.
• Devices of this mask have no serial number; use -expect-serial none.

Not supported

Any other mask, KNX IP Secure devices that need a secure session, and anything the supported plans do not cover.