Bug: problème à l'import au premier démarrage

[sambonbonne]

Bonjour,

Je ne sais pas si mon ticket sera accepté puisque j'installe l'addon de manière conteneurisées (je construis l'image standalone.Dockerfile et je l'utilise sur Kubernetes sur une carte en ARM64) mais sait-on jamais.

J'ai les logs suivants :

HA Linky is starting
Connection with Home Assistant established
PRM [REDACTED] found in configuration for consumption
[04/07 12:14] New PRM detected, historical consumption data import is starting
Cannot find folder /addon_configs/cf6b56a3_linky
TypeError: Cannot read properties of undefined (reading 'length')

Du coup, le process plante et Kubernetes le redémarre (rien d'inquiétant si ce n'est que ça le redémarre inutilement en boucle puisque l'erreur persiste).

Est-ce que ça peut être dû à une mauvaise configuration ?

À savoir que j'ai bien setup WS_URL et SUPERVISOR_TOKEN, le pont entre HA et HA-Linky semble OK.

Voici mon fichiers /data/options.json :

{
  "meters": [
    {
      "prm": "[REDACTED]",
      "token": "[REDACTED]",
      "name": "Linky maison",
      "action": "sync",
      "production": false
    }
  ]
}

Pour information, j'ai tenté de renouveler le token Conso API, ça n'a rien changé. Idem pour le token de superviseur, sans succès.

Merci d'avance pour tout aide supplémentaire, je serais ravi de répondre aux questions et de tester des choses :)

[bokub]

Salut,

Tu t'es pas planté dans les volumes ?

Avec quelle commande tu lances l'addon ?

[sambonbonne]

Salut,

J'ai bien monté le fichier options.json dans /data (d'ailleurs la configuration semble bien détectée puisque ça détecte mon PMR).

En dehors de ça, le README n'indique pas d'autre volume nécessaire que /data il semble.

Pour la commande, j'ai laissé celle qui est par défaut dans le standalone.Dockerfile (donc node --experimental-modules dist/index.js d'après le fichier).

Est-ce que /data doit être seulement en lecture ou en lecture+écriture ? Edit: le /data est bien en lecture+écriture chez moi en fait, je soupçonnais l'avoir monté en lecture seule mais non.

En dehors de ça, j'oublais de préciser que j'utilise la version 1.4.0 pour construire mon image.

Merci pour ta réponse rapide !

[sambonbonne]

J'ai peut-être mal compris ce que tu voulais demander par « quelle commande pour lancer l'addon », j'utilise un StafulSet sur Kubernetes donc je mets le manifest ici au besoin.

apiVersion: apps/v1
kind: StatefulSet

metadata:
  name: home-assistant-linky
  namespace: home-assistant

  labels:
    app.kubernetes.io/component: addon-linky
    app.kubernetes.io/name: home-assistant
    app.kubernetes.io/part-of: home-assistant

spec:
  replicas: 1
  revisionHistoryLimit: 5

  selector:
    matchLabels:
      app.kubernetes.io/component: addon-linky
      app.kubernetes.io/name: home-assistant
      app.kubernetes.io/part-of: home-assistant

  template:
    metadata:
      labels:
        app.kubernetes.io/component: addon-linky
        app.kubernetes.io/name: home-assistant
        app.kubernetes.io/part-of: home-assistant

    spec:
      containers:
        - name: home-assistant-linky
          image: localhost/home-assistant-linky:1.4.0

          envFrom:
            - secretRef:
                name: home-assistant-linky-environment

          volumeMounts:
            - name: test
              mountPath: /data
            - name: configuration
              mountPath: /data/options.json
              subPath: options.json

      volumes:
        - name: configuration
          projected:
            sources:
              - secret:
                  name: home-assistant-linky-configuration
                  items:
                    - key: options.json
                      path: options.json

  volumeClaimTemplates:
    - metadata:
        name: test
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi

[bokub]

Non mais t'as raison y'a aucun problème avec tes volumes

Il faudrait trouver où c'est qu'il y a un .length sur quelque chose de undefined, je vais essayer de chercher cet après midi

[bokub]

Alors y'a pas beaucoup d'occurences de .length dans mon code: https://github.com/search?q=repo%3Abokub%2Fha-linky%20.length&type=code

Ce qui m'étonne c'est que dans chaque situation, j'ai le sentiment que ça n'est pas possible que la variable sur laquelle on applique un .length soit undefined. Visiblement je me trompe, mais je n'arrive pas à comprendre.

Si vraiment tu veux m'aider à debug, il faudrait que avant chaque ligne où tu vois .length, tu ajoutes un log différent. Par exemple: console.log('a'); avant une ligne, et console.log('b'); avant une autre.

Tu peux ensuite rebuild l'image Docker avec cette commande docker build . -f standalone.Dockerfile -t ha-linky, et la relancer pour connaitre exactement quelle ligne plante (selon le dernier log affiché)

[sambonbonne]

Alors, j'ai rajouté plein de console.log comme prévu sauf que je suis parti de master au lieu du tag 1.4.0 et là, je n'ai plus de problème… Bah mince, ça tombe en marche :)

Du coup il est possible que l'erreur ai lieu si une personne utilise l'addon pour la première fois avec la 1.4.0 précisément.

J'imagine qu'on peut considérer que ce sera corrigé dans la prochaine version si ça fonctionne sur master (je suis sur le commit 97898c2 donc c'est « corrigé » soit dans celui-ci, soit dans bf9ff8e).

[bokub]

Ah mais oui tout à fait c'est la PR #31 qui a corrigé ça, c'est un problème exclusif aux utilisateurs de la version standalone donc je n'ai pas créé de nouvelle version (les versions sont pour les utilisateurs de HAOS)

Tu aurais du construire ton image à partir de master en suivant la documentation, si j'ai bien compris tu a forcé le build à partir du tag 1.4.0 ?

[sambonbonne]

Mince, j'avais cerché si un ticket similaire au mien existait avant de l'ouvrir mais je n'ai pas eu l'intelligence d'esprit de regarder dans les PR s'il y en avait pas déjà une pour corriger ce problème… Toutes mes excuses, j'aurais dû faire plus attention !

Exactement, j'ai clone le dépôt et j'ai fait un git checkout tags/1.4.0 en me disant que ce serait plus « stable » d'utiliser une version plutôt que le dernier commit de master. Et dans l'idée, je souhaitais faire une image à chaque nouvelle version (pas à chaque commit sur master) et pouvoir rollback d'une version stable à une autre.

Mais je comprends qu'il n'y ai pas eu de release pour ce fix qui ne concerne que les installations standalones qui ne sont pas supportées de la même manière que les installations classiques.