Plugin KO Classe ou fonction non trouvée

rroblik · Septembre 3, 2024, 8:56

Bonjour,

Suite à un upgrade de mon Raspberry Debian 10 vers Debian 11 un poil douloureux …
Le plugin wifilightv2 est KO, le cron me reporte régulièrement :

[Erreur] Classe ou fonction non trouvée wifilightV2::daemonTuya()
[Erreur] Classe ou fonction non trouvée wifilightV2::daemon()

J’ai tenté de réinstaller le module en stable puis beta : même résultat.
Il me semble que j’ai déjà eu ce cas par le passé mais ma mémoire me fait défaut …
On dirait qu’il manque le code fonctionnel du module ; mais comme je ne trouve pas celui-ci sur github pour comparer avec mon arborescence je suis un peu perdu…

Merci pour votre aide, @bernardfr.caron

NB : je suis sous Jeedom 4.5 alpha

iPapy · Septembre 3, 2024, 9:43

Bonsoir,

Comment avez vous fait cette upgrade ? mise a jour de debian ou installation d’un db11 puis restauration de vote backup ?

bernardfr.caron · Septembre 4, 2024, 3:08

Jeedom 4.4.14 + beta du plugin normalement OK en debian 10/11/12
(11 pas trop testé) à partir d’une fresh install bien sûr.

Si KO quand même, me donner la page santé du plugin et essayer de voir si dans http.error il y a des traces de souci du plugin.

rroblik · Septembre 4, 2024, 6:12

Upgrade pas fresh install parce que j’ai bien d’autres chose que Jeedom sur le Pi, mais ce n’est pas le sujet Jeedom tourne au poil

lperenna · Septembre 4, 2024, 6:23

Jeedom peut être, mais à priori les libs et autres pour les plugins pas forcément.
Et niveau python2 et python3 + pip votre environnement ne doit plus être top non.

Tonio16 · Septembre 4, 2024, 6:41

Si car en ayant ces infos, je ne pense pas qu’un développeur va vous aider.
Il y a deux problèmes en fait:
Un changement de debian pour jeedom se fait par une nouvelle installation et non un upgrade.
Votre système doit être dédié à jeedom, donc pas d’installation d’autres choses. Et pourquoi utiliser jeedom en alpha dans ce cas, cela ne fait pas sens.

Donc oui, c’était bien le sujet, amha.

Antoine

rroblik · Septembre 4, 2024, 8:14

Pardon mon message est parti un peu vite j’étais sur mobile et j’ai enchainé au boulot

Je précise un peux le contexte : je suis passé sous D11 pour pouvoir installer le plugin officiel Jeezigbee qui nécessite node 20+ (cela n’est mentionné nul part dans la doc ) hors celui-ci n’est pas « officiellement » dispo sous D10 donc j’ai fait le grand saut.
Quant à « dédier un hardware complet a Jeedom », j’ai du louper quelque chose en quoi c’est un prérequis ?! Oui Jeedom n’est pas fait pour être proprement conteneurisé / cloisonné par nature, mais dédier un matos a Jeedom est devenu une bonne pratique par la force des choses, mais pas un prérequis, c’est mon point de vue mais là n’est pas le débat (et en plus c’est pas bon pour la planète de multiplier le hardware ).

Ceci étant dit, je recentre juste le sujet sur le plugin-wifilightv2 car c’est bien lui qui pose soucis, et uniquement lui !

Comme tu dis @lperenna je m’interroge aussi sur un soucis côté python; j’ai les version 2 et 3, j’ai essayé avec 3 par défaut puis 2 par défaut (avec update-alternative) mais même résultat.

$ python -V
Python 3.9.2
$ python2 -V
Python 2.7.18

J’ai aussi essayer :

d’installer la version beta du plugin
de retirer le module (dans /var/www/html/plugins/wifilightV2/) puis de réinsintaller pour être sur d’avoir tous les fichier sources

Sans plus de résultat

Je ne peux pas lancer l’installation des dépendances (voir ma première capture) donc je suis bloqué bloqué

Merci

EDIT @bernardfr.caron : rien dans les logs demandés

bernardfr.caron · Septembre 4, 2024, 8:23

Le plugin n’a pas besoin des dépendances pour fonctionner
le souci est d’aider à résoudre le problème sur du nonstandard

bernardfr.caron · Septembre 4, 2024, 8:24

la page santé duplugin est inaccessible ?

rroblik · Septembre 4, 2024, 8:25

Bonjour merci pour le retour, mais debian 11, jeedom installé selon la doc ; qu’est ce qui est non standard ?

Oui page du plugin inacessible

Edit : est-il possible d’avoir un lien vers le code source ou l’archive de celui-ci (beta) pour que je compare mon arbo ?

rroblik · Septembre 4, 2024, 9:03

@bernardfr.caron après une autre réinstall j’ai eu une erreur liée à Monolog et là ça m’a fait tilt

Le plugin wifilightv2 présuppose que Monolog est présent par défaut car Jeedom l’a en dépendance mais… c’est devenu faux ou plutot, l’abandon de guzzle () amène en cascade la non présence de Monolog.

Je pense qu’il faut donc ajouter des dépendances dans le plugin, à minima Monolog du coup.
Fort dommage que le core de Jeedom ne l’utilise plus vu la puissance de la librairie

Après un composer require monolog/monolog (un peu) sauvage dans /var/www/html j’ai du mieux sur la page du plugin qui se charge sans erreur,

Je vais maintenant tenter de récupérer mes objets depuis Tuya … et je clôturerais si c’est ok !

Merci

rroblik · Septembre 4, 2024, 9:10

Malheureusement tout n’est pas ok, en fait le démon ne se lance pas

[2024-09-04 10:42:05] DEBUG  Lancement de : /var/www/html/core/class/../../core/php/jeePlugin.php  plugin_id=wifilightV2 function=install callInstallFunction=1
[2024-09-04 10:45:06] ERROR  Attention je pense qu'il y a un soucis avec le démon que j'ai relancé plus de 3 fois consécutivement
[2024-09-04 10:50:05] ERROR  Attention je pense qu'il y a un soucis avec le démon que j'ai relancé plus de 3 fois consécutivement
[2024-09-04 10:55:03] ERROR  Attention je pense qu'il y a un soucis avec le démon que j'ai relancé plus de 3 fois consécutivement
[2024-09-04 11:00:04] ERROR  Attention je pense qu'il y a un soucis avec le démon que j'ai relancé plus de 3 fois consécutivement
[2024-09-04 11:01:29] INFO  Début d'activation du plugin
[2024-09-04 11:01:30] INFO  Info sur le démon : {"launchable_message":"","launchable":"nok","state":"nok","log":"nok","auto":0}
[2024-09-04 11:05:04] ERROR  Attention je pense qu'il y a un soucis avec le démon que j'ai relancé plus de 3 fois consécutivement

Je sèche !

bernardfr.caron · Septembre 4, 2024, 9:11

crée un équipement

rroblik · Septembre 4, 2024, 9:16

J’ai essayé à l’instant, j’ai une erreur en rouge:

Type incorrect, (classe commande inexistante)wifilightV2Cmd

Je vois aussi un soucis dans la liste du moteur de taches :

rroblik · Septembre 4, 2024, 9:18

Bonsoir,

Du nouveau concernant mon soucis, et la solution (enfin, plutot le pourquoi, et le « fix »)

Le plugin à besoin des librairies php monolog/monolog ET guzzlehttp/guzzle hors comme dit plus haut celle-ci ont été (seront) purement et simplement retirées du core de Jeedom presque sans vergogne :

pour moi a elle seule cette modification nécessite un taggage de la prochaine version en v5 tant les effets de bord sont potentiellement importants …

// OFF TOPIC : J’ai du mal a comprendre comment / pourquoi une application qui part nature log énormément et fait des requêtes peut faire le choix de se passer de ces deux librairies (20.9k / 23.1k sur github) et utiliser du fait maison plutôt que de s’appuyer dessus
// OFF TOPIC END

Concernant monolog/monolog comme dit plus haut le module ne le charge pas du tout en considérant que Jeedom le fait (via l’autoloader composer).
Concernant guzzlehttp/guzzle c’est un peu différent, car on voit que core/class/wifilightV2.class.php s’occupe de charger une version « locale »

# L10
if (!class_exists('GuzzleHttp\Client')) {
	require_once dirname(__FILE__) . '/../../3rdparty/lib/guzzlehttp/guzzle/Client.php';
}

Mais ce code n’est pas fonctionnel et lève une erreur. Après débogage XDebug la voici :

# 3rdparty/lib/guzzlehttp/guzzle/Client.php
class Client implements ClientInterface, \Psr\Http\Client\ClientInterface
{
...
}

ClientInterface n’est pas trouvé ; problème de namespace.

Fix temporaire

A la racine de jeedom

composer require monolog/monolog:^2 guzzlehttp/guzzle:^6

Tout fonctionne ensuite (Mais à chaque MAJ Jeedom c’est KO vu que le dossier vendor est systématiquement supprimé pendant l’update, la aussi pour une raison qui m’échappe…)

Fix permanent

Je ne connais pas les « bonnes pratiques » spécifiques à Jeedom pour utiliser des librairies php tiers dans les modules mais la bonne pratique php (et pas que!) est de ne pas les embarquer et de s’appuyer plutot sur composer. Donc pour moi à minima il faudrait embarquer un composer.json (et composer.lock) dans le module. Lors de l’installation des dépendances faire un composer install. Enfin dans le code source du module, charger l’autoloader généré par composer.

Merci

bernardfr.caron · Septembre 5, 2024, 4:55

Merci beaucoup pour le diag.

Pour monolog j’utilise 4 logs différents et c’est bien utile, je vais ajouter cela.
Pour guzzle la version locale c’est pas joli mais je ne sais plus pourquoi j’ai fait cela, c’était en bas de la todolist ça vient de remonter.
Reste à revenir à curl, je n’aime pas être dépendant.

rroblik · Septembre 5, 2024, 6:07

Garde plutôt la couche d’abstraction grâce a guzzle, pour la même raison que tu garde monolog !

Bon courage belle journée j’attends la prochaine bêta du côté de ton module !

Loic · Septembre 5, 2024, 7:09

Bonjour,
Poste a charge mais je vais faire l’effort d’y repondre :

pour moi a elle seule cette modification nécessite un taggage de la prochaine version en v5 tant les effets de bord sont potentiellement importants …

Une version v5 car la mise à jour impact deux plugin qui n’utilisent pas correctement les fonctions du core et ne suivent pas les recommandations ? Pour rappels il y a une fonction pour les logs dans le core il ne faut donc pas se servir de monolog, tous les plugins qui utilise la fonction du core n’ont subi aucun impact

// OFF TOPIC : J’ai du mal a comprendre comment / pourquoi une application qui part nature log énormément et fait des requêtes peut faire le choix de se passer de ces deux librairies (20.9k / 23.1k sur github) et utiliser du fait maison plutôt que de s’appuyer dessus
// OFF TOPIC END

Plusieurs raison, guzzle n’est plus utilisé du tout par le core et cette lib est une horreur lors des montées de version (os ou php) ou meme des montés de version de lib autour, si tu regarde ya meme des sujet ou cette lib pose soucis a des plugins car le core la possède avec une version qui ne leur convient pas, le core n’a pas vocation a avoir toute les libs du monde surtout quand il y a un systeme pour gerer composer dans les plugins (c’est 2 fichiers le core fait tout le reste).
Pour monolog oui la lib fait seulement quelques ko mais je l’ai remplacé avec moins 50 lignes et le tout est bien plus rapide avec moins de charge pour le jeedom et totalement transparent si les plugins utilisent bien la lib de log de jeedom.
De plus moins de lib permet de simplifier grandement la maintenance, les risque de bugs (on maitrise mieux l’ensemble), les risques de failles de securité et la charge (le meilleure exemple et la lib de cache qui a été supprimé et remplacé par du code maison ou le gain de perf est d’environ 20%)

Tout fonctionne ensuite (Mais à chaque MAJ Jeedom c’est KO vu que le dossier vendor est systématiquement supprimé pendant l’update, la aussi pour une raison qui m’échappe…)

Sinon en mettant un fichier composer.json et en indiquant dans le packages.json du dossier plugin_info qu’il y a du composer jeedom va s’occuper de lui meme lors de l’installation du plugin de rajouter les dépendances composer. Pourquoi ne pas utiliser ce systeme ? Pourquoi critique le fonctionnement de jeedom alors que ce cas et prévu et correctement geré.
Une voiture peut rouler en marche arriere, roules tu en marches arriere sur l’autoroute pour autant ? Pas sur c’est pas prévu pour et les gens ne font pas de proces au fabricant de voiture pour autant non plus.

Dans l’ensemble vos soucis viennent d’une mauvaise comprehension du core et de son fonctionnement on ne peut pas ralentir le developpement de celui-ci pour ce genre de raison…

rroblik · Septembre 5, 2024, 9:32

Merci Loic pour cette réponse ce n’était pas vraiment à charge juste un point de vue. Je l’ai déjà d’ailleurs évoquer, à mon sens (et ça n’engage que moi) les « Jeedomisme » (les manières de faire spécifiques à Jeedom) rendent l’accès aux développements plus compliqué et de part mon métier je fais directement le parallèle avec le Drupalisme jusqu’à la version 7. Une courbe d’apprentissage très raide avec un résultat assez typique : peut de développeurs et de grosses difficultés à maintenir (le core ET les plugins tiers) peut être aussi un problème de doc pour les dev je pense que @bernardfr.caron n’a pas volontairement raté les Jeedomismes!

Je caresse toujours l’espoir d’une refonte en profondeur du core de Jeedom en se basant sur un framework PHP pour le back + un autre pour le front, connus et reconnus (quoi encore un parallèle avec Drupal 8+ ?! ) voir headless, pour apporter la sécurité, la robustesse, et la pérennité que Jeedom et notre domotique mérite. Jeedom v5 sous stéroïdes ! La pérennité de Jeedom m’inquiète toujours face à la concurrence, HA en premier .

Bon courage et encore bravo pour le taff que je ne manque pas de reconnaître même dans des off topic « à charge » !

Loic · Septembre 5, 2024, 9:51

Il n’y a aucun intérêt a ramener un framework type drupal dans jeedom, c’est une déformation de ce qui utilise des framework de toujours vouloir des framework.

Faire ca aurait plusieurs conséquences :

énorme lourdeur dans le code sans justification
ralentissement globale de jeedom, un framework est fait pour tout faire, la nous on fait de la domotique le core est codé et optimisé dans ce sens. Pas oublié que souvent Jeedom tourne sur des petite machine (rpi)
plus d’utilisation cpu, même principe que précédemment, les frameworks sont fait pour tout faire et donc moins optimisé qu’un système développé spécifiquement pour ce pour quoi il est fait
idem sur les écriture disque, pas oublié que jeedom pour protéger la durée de vie des cartes SD limite les écriture disque et essaye de les grouper par lot
moins de flexibilité, un framework c’est génial mais faut rentrer dans le modele, un système domotique est bien particulier et ne rentre pas dans les modeles de framework

Ne pas utiliser de framework n’a aucun impact sur la pérennité de jeedom au contraire même :

ca rend le code plus simple, en vrai si tu regardes le code il est relativement simple, le temps pour apprendre le framework jeedom (backend) est seulement de quelques jours (il y a globalement que quelques classe a comprendre pour commencer : DB, log, eqLogic, cmd)
moins de soucis lors des montées de version, sur un framework vu que c’est pas toi qui fait les évolutions c’est compliqué de voir les impacts, c’est pas le cas ici

Tu compares a HA, très bonne comparaison ils utilisent aucun framework sur le backend ils ont fait comme jeedom un développement maison pour coller au plus près du besoin de la domotique.

Pour le frontend ils utilisent pas plus de framework que jeedom, globalement jeedom est compatible avec bootstrap v3 (meme si on la adapter et pas mal réécris leur doc reste valable).

Le plus gros défaut de jeedom c’est peut être le manque de doc dev (même si ca a énormément progressé les dernières années). Malheureusement quand on est une petite structure on doit faire des compromis et c’est la doc de dev (et encore je pense qu’elle est suffisante pour des plugins simple).

Mais pour moi aucune inquiétude sur la pérennité de jeedom, le code est sur github, il n’y a pas que un seul dev et pas que des devs issue de la société jeedom (c’est sur on a pas autant de dev que HA mais on en a plus que certain projet type ntp par exemple) ce qui montre que le code est compréhensible. Et la dernière année a montré que jeedom s’ouvré de plus en plus (plugin passé public, gestion du projet par issue permettant d’avoir la roadmap, plus de PR, changelog plus détaillé et j’en passe)