[Discussion] Feasibility & Scope of MyHomeServer1 Backup Import (matrix_mx.db)

[GreenGrassBlueOcean]

Following the reverse-engineering tip shared in #397 regarding extracting matrix_mx/matrix_mx.db from MyHomeServer1 (Home + Project) backups, we wanted to open a discussion on whether this should be supported in the integration, provided as an external community tool, or left out entirely.

1. Legal & Compliance Risk (Anti-Circumvention)

• The extraction relies on a static AES/zip key extracted from proprietary Legrand gateway firmware.
• Bundling or hardcoding manufacturer extraction keys into the repository source code creates real legal exposure under DMCA § 1201 and EU Copyright Directive (Article 6) anti-circumvention rules, putting the repository at risk of DMCA takedowns.
• Any potential tooling would therefore strictly forbid shipping the key in code—at most, it could require user-provided keys or only accept an already decrypted database.

2. Unknown & Undocumented Structure

• matrix_mx.db is an internal, closed SQLite database. We have no documentation on its schema, table relationships, or constraints.
• Legrand can change column names, relational mappings, or backup encryption at any time with a gateway firmware update, leading to broken onboarding and silent failures.
• Handling edge cases (scenarios, multi-bus topologies, DALI, Zigbee/MyHOME bridges) without official specs introduces high maintenance debt.

3. Audience: A Very Small Subset of Installations

• Gateway Specificity: This applies strictly to MyHomeServer1 (and possibly Classe 300EOS) configured via the Home + Project / MyHOME_Up mobile apps. Installations using physical configurators or other gateways (F454, F453, F452, MH200N, serial interfaces, etc.) do not use this database.
• One-Time Value: Importing names is only useful during the initial minutes of onboarding a brand-new Home Assistant instance. Once entities are named and placed into areas, the feature is never used again.
• For typical homes (10–30 actuators), manual area and name assignment in HA is straightforward. This is practically only useful for very large plants with 100+ devices already configured in MyHomeServer1.

---

Options for Consideration

1. Leave Out of Core Integration (Recommended):

   • Keep the core integration focused strictly on OpenWebNet protocol communication and stability.
   • Keep Restore MyHomeServer1 config in HA #397 open as an unsupported, community-maintained tip/recipe for advanced users who wish to inspect their DB manually.

2. External Standalone Script / Gist:

   • Provide an offline community script (outside of the integration repo) that accepts an already extracted matrix_mx.db and exports an address-to-name mapping (e.g. CSV/JSON).

3. Decrypted DB Import in HA Config Flow:

   • Support uploading an already-decrypted matrix_mx.db file during onboarding (never bundling the key).
   • High implementation and maintenance effort for a very narrow use-case.

---

We'd love your input:

• Do we want to support this in any form, or is it better kept completely out of the integration?
• For users with large MyHomeServer1 plants, would an external script/spreadsheet guide suffice?

[anotherjulien]

I'll admit I did not think of the compliance issue of breaking encryption/passwords.

What I thought of was: who is this for?
What is the intersection of people who would not be familiar with OpenWebNet addressing and their home's logical layout, and people able to find and crack open an application backup?

I'm sure it could represent a shortcut for a small subset of users, but how many is debatable.

[sylvainblot]

Yeah in my case I moved to an already configured home. And testing device by device was not an option.

[sylvainblot]

I don't know about the legal part, but the password was there sitting in the firmware ext4 partition in plain text. This feels more like obfuscation than security.