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
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:
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
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
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
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
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?
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.
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)