C’est peut-être brutal, mais au point où tu en es tu as peut-être intérêt à repartir de la plus ancienne sauvegarde et d’avancer jusqu’à celle qui ne marche pas s’il y en a une qui marche bien sûr.
Oui, ma v 4.0.45 fonctionne. à chaque upgrade depuis cette version, j’ai le problème. j’espérais que des versions corrigent un truc, mais le problème doit venir de chez moi.
j’arrive au requetage en bdd, ma base doit avoir un problème en terme de data.
Oui mais ça ne veut pas dire que tout est OK au niveau des fichiers, la preuve:
Bref j’essaye d’aider en réfléchissant avec toi et en donnant des pistes qui me semble judicieuses. à partir du moment où il manque la fin du fichier /var/www/html/desktop/php/display.php ou le fichier core/themes/core2019_Light/desktop/core2019_Light.css après MAJ, je pense (sûrement à tort) que c’est lié.
Tu es très compétent tu vas trouver j’en suis sûr.
Le display.php était déjà corrompu dans ma version, et l’écran ne fonctionnait déjà pas. je ne l’avais pas vu.
la requête exécutée est
SELECT
id,name,logicalId,generic_type,object_id,eqType_name,eqReal_id,isVisible,isEnable,configuration,timeout,category,display,order,comment,tagsFROM eqLogic WHERE object_id=3 AND isEnable = 1 AND isVisible = 1 ORDER BYorder,category
Je découvre ainsi la page cachée pour requêter directement sur la bdd. Merci aux devs Jeedom 
la requête me renvoie bien les 9 équipements visibles et actifs.
Je réussi à renvoyer leur nom côté front, donc les datas sont là.
reste à savoir pourquoi le toHtml ne fonctionne pas pour 8 équipements sur 9. les données semblent complètent pour tous.
Ca se passe donc bien dans le $eqLogic->toHtml(init('version'));
j’avance. il semblerait que pour le widget qui s’affiche (kodi), l’appel $this->preToHtml($_version) renvoie une chaine (le html direct). ce html esta ;ors retourné directement.
pour les autre, c’est un tableau. il y a alors un traitement plus « lourd ».
La commande
je me suis focalisé sur un équipement qui ne s’affiche pas, avec 1 commande visible.
Une porte, avec un état. Un classique
la seule commande renvoyée à afficher est « ouverture »
C’est en fait le $cmd->toHtml($_version, ''); qui ne renvoie rien…
En allant dans cette fonction, on se rend compte que le template n’est pas trouvé pour merger les data et le style. $this->getWidgetTemplateCode($_version); ne renvoie rien.
A la recherche du template
Le template porté par la commande est « cmd.info.binary.window »
la commande getTemplate('core', $_version, $template_name); ne trouve pas le template
la commande getTemplate('core', $_version, $template_name, $plugin->getId());ne trouve pas non plus
l’algo essaye donc avec le nom de template cmd.info.binary.default
mais la commande getTemplate('core', $_version, $template_name);ne trouve pas nom plus ce dernier !
On ressort donc SANS template.
Les templates sont ici:
ceux qui ont « tmpl » dans le nom. Ces fichiers sont-ils bien présents sur ton installation ?
1 « J'aime »
Voilà donc ton problème est bien lié à des fichiers manquants sur ton installation !!!
Donc maintenant faut voir pourquoi il te manque des fichiers un peu partout !! t’aurais gagné ton après-midi à m’écouter plus tôt !
Dans ma version 4.0.45, ces fichiers sont présents. C’est donc l’upgrade vers des versions supérieures qui les écrasent.
Si vraiment je perdais des fichiers comme ça, je ne vois pas pourquoi mon jeedom fonctionne dès que je revert vers ma version. La carte SD ne peut pas être défaillante dans un sens, et pas dans l’autre.
Je n 'ai pas dit que c’était forcément la carte SD, je t’ai invité à tester avec une autre SD pour justement chercher plus loin si ça ne vient pas de là.
Un problème de lecture/écriture sur une SD c’est courant donc à mon sens c’est un point qui se vérifie en premier lieu.
Je ne vais pas non plus me battre avec toi pour essayer de t’aider, je laisse donc ma place à d’autres.
Ton aide a été hyper appréciée t’inquiète. J’ai recopié tous les templates et ça fonctionne, mon dashboard est OK.
Par contre, je ne comprends pas comment sont fait les upgrade, incrémental, bigbang ?
Tu avais déjà un souci de fichier tronqué en 4.0.45 donc je ne pense pas que la mise à jour soit en cause. A mon avis il y a quelque chose qui ne va pas sur ton install et la MAJ le met en évidence…
Je suis bien d’accord sur le côté instabilité, je vais comparer les sources et mon installation pour voir si rien d’autre ne cloche.
Mais j’aimerais mieux comprendre l’upgrade.
Je trouve ça étrange que les fichiers « source », le core de jeedom ne soient pas réécrasés lors des mises à jour par les nouveaux fichiers.
Mon fichier tronque aurait été remis en service, et mes template auraient été rechargés.
Une installation « mal en point » ne peut visiblement pas être réparée via un upgrade, c’est bien dommage, il y a sûrement des raisons à ça.
Ce petit débuggage m’a quand même permis de mieux comprendre quelques trucs, et me remettre au php.
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.