PHP Warning dans log suite à passage de Stretch à Buster

Bonjour,

J’utilise depuis plusieurs années le plugin eibd et depuis nombreux mois tout est très stable.
Bravo pour @mika-nt28 pour le travail.
Jusqu’à hier j’étais sous une Armbian Stretch avec un Jeedom en version 3.3.53 et un plugin en version stable du 12/10/2020.
Hier j’ai refais une installation de zéro avec une Armbian Buster et j’ai réappliqué ma sauvegarde. Donc Jeedom et le plugin sont dans les mêmes versions que précédemment

Depuis cette migration, tout est fonctionnel mais j’ai des PHP warning dans 2 logs (scenario_execution et cron_execution). Dans les 2 cas des j’ai un peu de mal à en trouver la source, pas d’horodate dans la ligne de log mais j’ai plusieurs dizaines de lignes de ces logs par jour.
Qu’est ce que je pourrai mettre en oeuvre pour trouver quel(s) élément(s) déclenche(nt) ces lignes de Warning ?

Les traces sont :
Scenario_execution

PHP Warning:  Illegal string offset 'id' in /var/www/html/plugins/eibd/core/class/eibd.class.php on line 864
PHP Warning:  Illegal string offset 'id' in /var/www/html/plugins/eibd/core/class/eibd.class.php on line 864
PHP Warning:  Illegal string offset 'id' in /var/www/html/plugins/eibd/core/class/eibd.class.php on line 864
PHP Warning:  Illegal string offset 'id' in /var/www/html/plugins/eibd/core/class/eibd.class.php on line 864

Cron_execution

PHP Warning:  Illegal string offset 'id' in /var/www/html/plugins/eibd/core/class/eibd.class.php on line 962
PHP Warning:  Illegal string offset 'id' in /var/www/html/plugins/eibd/core/class/eibd.class.php on line 962
PHP Warning:  Illegal string offset 'id' in /var/www/html/plugins/eibd/core/class/eibd.class.php on line 962
PHP Warning:  Illegal string offset 'id' in /var/www/html/plugins/eibd/core/class/eibd.class.php on line 962
PHP Warning:  Illegal string offset 'id' in /var/www/html/plugins/eibd/core/class/eibd.class.php on line 962
PHP Warning:  Illegal string offset 'id' in /var/www/html/plugins/eibd/core/class/eibd.class.php on line 962

merci par avance pour le coup de main

Je vais regarder mais je n’ai pas ça chez moi

ok, s’il faut ajouter des logs supplémentaires ou autre pour mettre en place de mon côté, ça me va aussi.
cela ne me gène pas de passer du temps à chercher ce qui fait mal mais j’avoue ne pas savoir ce qu’il faudrait ajouter où.
n’hésites surtout pas

Bonjour Mika,
Perso, j’ai cette erreur depuis pas mal de temps, même log en V4.0.61, peut être lors du passage en V4, mais je ne pourrais pas te le certifier:


je n’ai pas l’erreur 864 par contre.
Merci pour ton Taf :slight_smile:

Je vais regarder ça

Je viens de pousser une correction en stable et beta a confirmer si le probleme est bien resolue

j’ai mis à jour en stable mais j’ai toujours les 2 warnings tout aussi régulièrement qu’auparavant.
visiblement cela est généré sur le $Option['id']=$this->getId(); mais je ne comprends pas à quoi cela correspond :frowning:
je voudrais bien mettre des traces (par exemple avant/après cette ligne) pour voir quel GAD pourrait poser problème) mais là aussi je ne comprends pas quoi tracer et comment. Peut être peux tu me donner des pistes ? je ferai les essais pour tenter de préciser quel cas génère ces warning

Je comprend pas pourquoi il y a ce warning

oui warning que je n’avais pas en Stretch donc je ne sais pas si du à des versions de dépendances ou autre. Sur Stretch j’ai eu beaucoup de Warning sur le plugin Freebox_OS et il a fallu pas mal de version pour « corriger ». In fine je ne sais pas ce qui a été corrigé.
est ce que tu penses que je pourrais mettre des traces de mon côté pour essayer de piéger le problème ?

Je me demande si c’est pas le tag id qui est interdit par la version php que tu as sur stretch
Pour tracer ça c’est pas facile de plus il devrait apparaître à chaque commande

sans connaitre ton dev etc vu le comportement j’ai l’impression qu’une ou quelques commandes ont des spécificités de configuration que d’autres n’auraient pas et ces spécificités font que cela génère les warning. pour cela que j’aimerai tracer mais j’avoue ne pas bien comprendre comment cela s’articule le code sur un plugin, pas que celui ci mais tous

j’ai trouvé les commandes qui génèrent les warning du scenario_execution, mais je ne comprends pas vraiment ce qu’elles ont


je ne comprends pas pourquoi le message concerne l’id …

Elles n’ont pas de retour d’état. As tu essayé d’en mettre un même bidon ( venant d’une autre commande)?

au départ j’en avais (sur mm GAD). en gros 2 actions (ON et OFF) et 1 info, les 3 pointent sur le même GAD
j’avais l’info en retour d’état de chaque action, mais pas mieux. Au départ ce l’info dans le retour d’état était même erroné dans la syntaxe mais pas mieux, donc visiblement pas ça.
J’ai essayé de rendre visible la commande au cas où ce soit ça mais pas de changement

Il ne faut jamais mettre le même gad pour l’action et la commande info qui est mise en retour d’état. Cela risque de poser problème et puis cela ne fonctionne pas, cela ne représente pas la réalité.

d’accord par contre pour le coup je suis un peu perdu. côté KNX ce GAD est affecté à la fonction voyant de mon interrupteur. GAD à True le voyant clignote dans le cas contraire il est éteint.
J’ai un seul objet pour le voyant sur l’interrupteur. Que me conseilles tu ? de déclarer un GAD « factice » pour le retour d’état ?

Autre exemple : sur mon actionneur de chauffage j’ai un GAD correspondant à la consigne. Côté Jeedom si je veux pouvoir lire et écrire cette consigne, j’ai fais 2 commandes, 1 « _R » et 1 « _W » pour read and write. Les 2 commandes pointent sur le même GAD et je n’ai pas renseigné de retour d’état.
voila ce que cela donne :


Je comprends qu’il ne faut pas faire comme cela, mais je ne vois pas du coup.
Je précise que tout fonctionne je n’ai pas de soucis là dessus, j’ai simplement des PHP Warning depuis le passage en Buster et avant de passer V3 vers V4 j’aurai souhaité les résoudre ou au moins les expliquer.
Je reste preneur tout de même de la solution sur les retour d’état et la non utilisation de 2 fois le même GAD :slight_smile:

pour la consigne, c’est pas grave car tu n’as pas mis de retour d’état, il y aura pas de conflit.
en général, sur les thermostats, tu as 2 gad, un qui reçoit la valeur (action) et un qui renvois l’info depuis le termostat (info).

tu peux me donner les marques et modèle de ton interrupteur et de ton thermostat?

Interrupteur : Hager WKT316
sinon ce n’est pas un thermostat mais un actionneur de chauffage : THEBEN HM12T

pour ton interrupteur, la logique veux que la led soit mise dans le même gad que la lampe que l’interrupteur sert a allumer et donc, le retour d’état est celui du relais de la lampe. tu veux p-e détourner les led pour autre chose.

pour le theben, tu t’es basé sur quelle valeur?


la 10?

Effectivement j’utilise les voyant à autre chose, par exemple synthèse d’une lumière extérieure restée allumée, ou dans le cas qui génère les warning PHP sur jeedom pour alerter d’une température extérieure trop élevée pour ouvrir les fenêtres.

pour le theben j’utilise toutes les valeurs pratiquement. Mais celle qui me pose problème sur la manière de configurer serait plus la « 0 » Elle permet de « forcer » la valeur de consigne alors que la 10 donne la consigne courante correspondant au mode (confort, eco, etc)

Ma copie d’écran précédente avec R et W sont pour ce « 0 ». R permet de connaitre la valeur du moment de cette valeur (comme le « lire » dans diagnostic ETS) et le W permet d’écrire (comme le « écrire » dans diagnostic ETS)