Erreur de synchronisation avec plateforme KLF200

[Franck_jeedom]

Suite du sujet Erreur sur la fonction cron du plugin : Non-static method klf200::refreshAll() cannot be called statically :

Je viens d’installer un PI5 avec la seulement le plugin KLF200 pour réaliser des tests

J’ai réalisé un premier scan qui a remonté partiellement l’ensemble de mes équipements avec les bons noms. Avec une erreur 500 : Internal Server Error
N’arrivant pas à avoir l’ensemble des équipements j’ai effacé des équipements dans le plug-in et modifié des noms dans le boitier KLF200 et relancé la synchro. C’est les équipements avec les anciens noms du plug-in qui sont apparus. Donc pas de prise en compte des équipements modifiés dans le boitier. Toujours avec une erreur 500 : Internal Server Error

Pour continuer, j’ai effacé tous les équipements dans le plugin et dans le boitier KLF200.
Dans le boitier KLF j’ai refait une découverte des équipements Velux.
J’ai redémarré Jeedom
J’ai refait la synchro dans le plugin … plus rien ne se synchronise. Toujours avec une erreur 500 : Internal Server Error.

klf200.txt (126,6 Ko)
klf200_dep.txt (10,1 Ko)

Mon problème d’origine et pour lequel je cherche une solution.
A chaque scan des produits sur le boitier KLF200, le KLF200 génère des id différents. Aussi quand on change une fenêtre ou un volet et un rescan complet, il n’y a plus de correspondance entre le plug-in et le boitier ! Dès lors, tous les virtuels ou les scénarios sont désynchronisés avec le plug-in. Un travail monumentale quand on a 20 équipements x N commandes !
Un amélioration serait de rendre éditable l’id des équipements dans le plug-in.

Merci pour vos idées

[ngrataloup]

@Franck_jeedom

Aussi quand on change une fenêtre ou un volet et un rescan complet, il n’y a plus de correspondance entre le plug-in et le boitier ! Dès lors, tous les virtuels ou les scénarios sont désynchronisés avec le plug-in

C’est quand même étrange, n’est-ce pas un bug sur deb12 ?

@Franck_jeedom

travail monumentale quand on a 20 équipements x N commandes !

Synchronisation des velux ne se fait pas

On a toujours pas les logs avec ça… Sinon cf. outil « Remplacer » du core qui est là pour ce genre de cas (remplacement d’un équipement par un autre)

[Franck_jeedom]

Oui c’est moi qui est ouvert le premier message. J’ai monté une plateforme de DEV pour tester et trouver une solution autre que me taper le renommage de plus de 100 commandes dans mes scénarios et virtuels. D’ailleurs, même si je le faisais, à la prochaine resyncro sur le boitier, rebelote ! Je cherche une solution/un processus pour éviter cela.
Mes équipements ont 20 ans, d’autres moteurs vont tomber c’est sûr.

[ngrataloup]

J’ai laissé tomber ce plugin devant son instabilité il y a 2ans
Je suis passé par le plugin-vlx2mqtt et maintenant directement par un docker vlx2mqtt et jmqtt
C’est beaucoup, beaucoup plus stable !!!

Celà dit, je pense qu ela problématique de recreation de tou sles equipements reste un bug. Je n’avais pas souvenir d’avoir ceci à l’epoque

Norbert

[Franck_jeedom]

Je vais finir par regarder ce plug-in aussi
merci

[jpty]

Bonjour,

Dans les noms des produits sur le boitier KLF200, il n’y a aucun espace ?
C’était une cause de crash.

Que vous utilisiez plugin-vlx2mqtt ou plugin-klf200 , derrière c’est la même lib python pyvlx qui est utilisée. Pas certain qu’ajouter une couche de MQTT va résoudre quoique ce soit.

[Franck_jeedom]

Pas d’espace
Nouvelle expérimentation :

• restauration d’une sauvegarde avec jeedom uniquement (avant installation du plugin)
• réinstallation de la version beta du plug-in KLF
• tout remonte avec les noms correcte

ma conclusion : le scan parfaitement bien marche à la première installation du plug-in après le scan dysfonctionne.

[jpty]

Dans le log klf200.txt fourni dans le 1er post, tous les « name » sont vides donc pas de synchro ni de remontée de données possible au plugin Jeedom.

Je viens de lancer une VM Debian 12 avec Jeedom 4.5 et le plugin klf200.
Tout fonctionne. La lib pyvlx est passée en 0.2.26 avec Debian12 ( 0.2.20 avec Debian 11 ).

[Franck_jeedom]

Je me réponds à moi même.
J’ai réalisé, avec ChatGPT, un programme de remplacement des ID Velux dans Jeedom.
Tout les volets/fenêtres/stores ont été réaffectés avec le bon ID Velux.

Premier scénario : liste les équipements existants avec leurs ID Velux

1. Exécuter le scénario pour avoir un tableau de ce type en premier, puis le détail de chaque Velux (si pas de besoin, vous pouvez effacer la deuxième partie du code qui donne les attributs standard de Jeedom). Le tableau sera dans les logs (Menu Analyses/Logs >> dans le log Scénario).
   

   

2. Tester les équipements les uns après les autres pour voir si les ID Velux correspondent bien aux bons équipements Velux

3. Etablir une liste de correspondance pour voir les changements à réaliser (par exemple : le velux 1 devient le 4 et le 4 devient le 1

Pour utiliser le scénario :

• Créer un nouveau scénario et mettre le log en temps réel
• Ajouter un bloc code
• Copier ce code et sauvegarder
• Vérifier dans la configuration Jeedom, onglet Logs, que l’on a bien les scénarios en mode Debug afin de conserver la trace.
  
  

// Tableau des équipements du plugin KLF200
log::add('scenario', 'info', '=== Liste des équipements KLF200 ===');
$klfEquipements = eqLogic::byType('klf200');

// En-tête du tableau
log::add('scenario', 'info', str_pad("Nom", 30) . str_pad("ID Jeedom", 12) . str_pad("id KLF200", 15));
log::add('scenario', 'info', str_repeat('-', 60));

// liste chaque équipement dans le tableau
foreach ($klfEquipements as $equipement) {
    $id = $equipement->getId();
    $name = $equipement->getName();
//    $config = $equipement->getConfiguration('klf200_id', 'non défini');
  $klfId = $equipement->getConfiguration('id', 'non défini');
//   $klfId = $equipement->getConfiguration('klf200_id', 'non défini');


     // Affichage de la ligne de l’équipement
    $ligne = str_pad($name, 30) . str_pad("#$id", 12) . str_pad($klfId, 15);
    log::add('scenario', 'info', $ligne);
  
    //echo "Équipement #$id : $name (klf200_id = $config)\n";

 
    //echo "\n";
}

// Liste le détail pour chaque équipement
foreach ($klfEquipements as $equipement) {
    $id = $equipement->getId();
    $name = $equipement->getName();
    $klfId = $equipement->getConfiguration('id', 'non défini');

    log::add('scenario', 'info', "=== Équipement : $name (#$id / klf200_id = $klfId) ===");

    // Champs de configuration
    log::add('scenario', 'info', "-- Configuration :");
    foreach ($equipement->getConfiguration() as $key => $value) {
        log::add('scenario', 'info', "   $key = $value");
    }

    // Champs d'objet (attributs standard Jeedom)
    log::add('scenario', 'info', "-- Attributs :");
    $props = ['id', 'name', 'logicalId', 'eqType_name', 'object_id', 'isEnable', 'isVisible', 'generic_type', 'comment'];
    foreach ($props as $prop) {
        $method = 'get' . ucfirst($prop);
        if (method_exists($equipement, $method)) {
            $val = $equipement->$method();
            log::add('scenario', 'info', "   $prop = $val");
        }
    }
}

[Franck_jeedom]

Deuxième scénario : réaliser le changement d’ID Velux

Une fois établie la liste des changements, utiliser ce deuxième scénario pour réaliser le changement (à mettre en place comme le premier scénario). La trace des changements sera dans les logs (Menu Analyses/Logs >> dans le log Scénario).

Modifier le code à chaque changement :

• renseigner l’id Velux existant dans votre tableau : $currentId == 97 (97 ici en exemple)
• renseigner l’id Velux à mettre à la place : $newId = 17 (17 ici en exemple)
• sauvegarder et exécuter le scénario
• Voir le changement dans le log et réaliser un test de votre équipement Velux pour vérifier que le changement a bien été fait.

// changement d'ID Velux dans la configuration d'un équipement
$klfEquipements = eqLogic::byType('klf200');
foreach ($klfEquipements as $equipement) {
    $name = $equipement->getName();
    $jeedomId = $equipement->getId();
    $currentId = $equipement->getConfiguration('id');

    // Vérification avant changement
    if ($currentId == 97) {
        $newId = 17;

        // écriture de la trace dans le log
      	log::add('scenario', 'info', "=== Modification de l’équipement '$name' (Jeedom ID: $jeedomId) ===");
        log::add('scenario', 'info', "Ancien champ configuration 'id' = $currentId");
        log::add('scenario', 'info', "Nouveau champ configuration 'id' = $newId");
		
      	// changement de l'ID
        $equipement->setConfiguration('id', $newId);
        $equipement->save();

        log::add('scenario', 'info', "✔️ ID mis à jour avec succès pour '$name'.\n");
         break; // Arrête la boucle après le premier changement
    } else {
        log::add('scenario', 'info', "Aucun changement pour '$name' (ID actuel = $currentId).");
    }
}

[kevinchalet]

@ngrataloup

Je suis passé par le plugin-vlx2mqtt et maintenant directement par un docker vlx2mqtt et jmqtt
C’est beaucoup, beaucoup plus stable !!!

Je confirme, l’option Docker phpmonkeys/vlx2mqtt + jMQTT (ou MQTT Manager) est bien plus stable

Si ça en intéresse certains d’essayer, voilà le Docker Compose que j’utilise sous Portainer (mais ça doit marcher exactement de la même façon avec le plugin Docker Management directement dans Jeedom):

version: "3.8"

services:
  velux:
    container_name: velux
    image: phpmonkeys/vlx2mqtt:latest
    restart: unless-stopped
    network_mode: bridge
    environment:
      - TZ=Europe/Paris
    tmpfs:
      - /tmp
    volumes:
      - /etc/opt/vlx2mqtt.cfg:/vlx2mqtt.cfg

Et le fichier /etc/opt/vlx2mqtt.cfg contenant la configuration qui va bien:

[mqtt]
host = adresse du broker MQTT
port = 1883
login = nom d'utilisateur du broker MQTT
password = mot de passe du broker MQTT

roottopic = vlx2mqtt
statustopic = status

[tls]
enabled = no
allow_insecure = yes
cert_path = /certs/

[velux]
host = adresse de la passerelle KLF200
password = mot de passe de la passerelle KLF200

[log]
verbose = false

(après, quelle que soit l’option retenue, il y aura toujours le bug de négociation TLS… et à part prier pour que Velux corrige ça un jour ou l’autre, y a rien à y faire si ce n’est couper le jus à la passerelle quand elle ne répond plus )

@jpty

Dans les noms des produits sur le boitier KLF200, il n’y a aucun espace ?
C’était une cause de crash.

Que vous utilisiez plugin-vlx2mqtt ou plugin-klf200 , derrière c’est la même lib python pyvlx qui est utilisée. Pas certain qu’ajouter une couche de MQTT va résoudre quoique ce soit.

Pour info, aucun problème avec l’image phpmonkeys/vlx2mqtt quand on utilise des espaces dans le nom des volets.

En parlant du plugin plugin-vlx2mqtt, je me suis toujours demandé pourquoi il était payant :

• Il n’apporte qu’une valeur ajoutée limitée puisqu’il se contente de créer le conteneur vlx2mqtt dans le plugin Docker Management (l’image vlx2mqtt utilisant en effet pyvlx : s’il y avait à payer pour quelque chose ici, ce serait plutôt la bibliothèque qui fait le gros du travail ! ).
• De l’aveu même de l’auteur, ça a été un développement express qui a surtout servi à valider le design des plugins Docker Management et MQTT Manager en beta… et depuis lors, on peut pas dire qu’il y ait eu un suivi régulier: il n’est d’ailleurs jamais passé en version stable…
• Il est indiqué sur la fiche du market qu’il est développé par « Jeedom SAS » mais n’est en réalité pas considéré comme un plugin officiel… du coup, on a droit à un joli bandeau « attention ce plugin n’est pas un plugin officiel en cas de soucis avec celui-ci (direct ou indirect) toute demande de support peut être refusée », ce qui est assez cocasse

J’ai absolument rien contre les plugins payants (bien au contraire, en fait) mais ça doit se justifier. Or là, bon…

[ngrataloup]

pour aller plus avec avec le docker vlx2mqtt, les modifs que j’ai du apporté pour assurer un redemarrage de la connexion en cas de perte du klf200 ou du serveur mosquitto :

Compatibilité pergola?

Vlx2mqtt se connecte au klf200 via les api ( sans doute les meme que celles utilisées par le plugin klf200) et republie les données sur le broker mqtt les données sont ensuite accessibles à tout client se connectant au broker mqtt, donc jmqtt ou mqtt2 ou vlx2mqtt (le plugin !) Corrections à apporter au docker … 1 - modifier le fichier docker-compose.yml en modifiant rajouter la ligne suivante : command: sh -c 'rm -f /tmp/vlx.pid && python /vlx2mqtt.py /vlx2mqtt.cfg' Ceci permet au docker de…

Norbert