Vaultia : mon petit projet self-hosted pour gérer objets, achats, factures… avec API et webhooks pour Home Assistant

[Mulinet]

Salut à tous,

À la base, je cherchais simplement un moyen de gérer correctement tout ce qu’on accumule à la maison : objets, matériel, achats, factures, garanties, documents, valeur des biens, lieux de stockage, etc.

J’ai testé/regardé plusieurs solutions, mais je ne trouvais jamais exactement ce que je voulais. Du coup, comme souvent dans ce genre de situation… j’ai commencé à bricoler mon propre truc

Le projet s’appelle Vaultia.

Je l’ai développé assez « à la cool » avec Claude Code, mais en essayant paradoxalement d’être plutôt rigoureux sur ce qu’il y a derrière : beaucoup de tests unitaires/intégration/E2E, contrôles de sécurité, isolation des données, RGPD, sauvegarde/restauration, migrations de BDD, tests Docker, ARM64/AMD64, etc.

L’idée est d'avoir une application self-hosted pour centraliser son patrimoine matériel : objets et équipements, achats et dépenses, factures et documents, garanties, immobilier et pièces de la maison, véhicules, travaux, valeur des biens, historique, etc. Le projet continue d'évoluer, donc tout n'est évidemment pas terminé.

Et comme je suis un gros utilisateur de Home Assistant, je me suis dit qu’il serait dommage que Vaultia reste complètement dans son coin. J’ai donc ajouté une API et des webhooks. Par exemple, je viens de valider en conditions réelles un événement item.created envoyé par Vaultia vers Home Assistant : création d’un objet dans Vaultia → webhook → automatisation HA. Ça fonctionne.

J’avoue que je n’ai pas encore énormément réfléchi aux usages concrets avec Home Assistant . C’est justement aussi pour ça que je poste ici : certains auront probablement de bien meilleures idées que moi.

Quelques pistes qui me viennent : réagir à l’ajout ou la modification d'un équipement, faire communiquer l’inventaire avec les appareils connus de HA, exploiter les garanties/entretiens/documents, créer des automatisations autour des véhicules ou de la maison… mais il y a certainement des choses beaucoup plus intéressantes à imaginer.

Pour l’instant c’est encore jeune, donc je suis surtout intéressé par vos retours, vos idées d’intégration avec HA et les usages auxquels je n’aurais pas pensé.

Pour ceux qui veulent suivre/tester le projet :

Reddit : r/Vaultia

GitHub / installation self-hosted : multinet33/vaultia-selfhosted sur GitHub

Et si certains ici jouent avec les API/webhooks de Home Assistant, je suis vraiment curieux de savoir : qu’est-ce que vous feriez communiquer entre Vaultia et HA ?

[bastgau]

@Mulinet

Et comme je suis un gros utilisateur de Home Assistant, je me suis dit qu’il serait dommage que Vaultia reste complètement dans son coin. J’ai donc ajouté une API et des webhooks. Par exemple, je viens de valider en conditions réelles un événement item.created envoyé par Vaultia vers Home Assistant : création d’un objet dans Vaultia → webhook → automatisation HA. Ça fonctionne.

Tu as prévu que ton application envoie des données sur HA ? Dans ce cas là, il faudrait plutôt que l'API les envoie via un broker MQTT ou via l'API de HA.
C'est pas très classe de passer par des webhooks.

Dans l'autre sens, si HA doit venir récupérer des informations, ton API devrait suffire. Je n'ai pas trouvé la documentation de l'API (mais j'ai peut-être mal cherché).

[Mulinet]

Merci pour ton retour. En effet le webhook signale un evement et HA vient le chercher via API. Je note le MQTT pour plus tard. Pour la doc tu as raisonc'est un oublie de publication je corrige !

[bastgau]

Tu as une integration HA ? Elle est dispo où ?

[Mulinet]

Non pas d'intégration, le principe est que Vaultia publie un evenement Webhook vers HA pour le notifier d'une action (sans le détail), HA recoit ce Webhook a les clef pour faire un appel API vers Vaultia et recupere le détail :

[bastgau]

Pourquoi ne pas directement fournir l'information sur le call du webhook ? Ca veut dire que le lien porte toute l'authentification pour pouvoir se connecter sur l'API ?

Ca fait un A/R un peu inutile.

[Mulinet]

@bastgau

Pourquoi ne pas directement fournir l'information sur le call ? Ca veut dire que le lien porte toute l'authentification pour pouvoir se connecter sur l'API ?

Ca fait un A/R un peu inutile.

Le lien du webhook ne contient aucune authentification. C'est juste l'URL canonique de la ressource. Si le consommateur veut relire la ressource, il utilise son propre token API avec les scopes adaptés.

Le webhook est volontairement un événement léger et non une copie complète de l'objet, ce qui explique le GET supplémentaire. Ça évite notamment de pousser inutilement toutes les données vers chaque destinataire et ça permet de récupérer l'état courant.

Par contre ta remarque est pertinente : je pense enrichir le payload avec quelques données
directement utiles (nom de l'objet, contexte de l'événement, etc.). Comme ça, pour les automatisations simples il n'y aura aucun aller-retour supplémentaire, et resource.href restera disponible quand on a besoin de la fiche complète.

[bastgau]

Ah donc il faut gérer la connection dans chaque automatisation. Ce n'est pas très clair sans la doc de cette automatisation.

Il y a tout intérêt donc de créer une integration HA car là, on risque de devoir ré-implémenter toute l'api dans des automatisations.

[bastgau]

Et si tu veux toucher les utilisateurs HA, il faudrait créer une app (ex-addon) de ton application car beaucoup d'utilisateurs passent par HAOS et donc n'ont pas de docker sous la main.