henri-allauch

Je lis, je trouve cette présentation très instructive, mais je suis un peu largué ... on est très loin des installations des années 2000 sans parler des réseaux que nous installions et maintenons en 1970 avec les protocoles des communications de l'époque Merci de partager cette présentation de ton LazerLab

Ok ça répond à ma question ci-dessus

Est-ce à dire que si l’on veut conserver l’ensemble des messages log comme avant la mise en place de cette version, il faut ajouter self.logLevel = TRACE dans la function QuickApp:onInit() ? si oui : saurait pu être la valeur par défaut pour éviter de modifier tous les QA à la mise en place de ce nouveau firm

Eh bien ça fonctionne…. Dans mes petits souliers, 🎅 avait mis un message de rappel 🤷🏻‍♂️

Et voila la confirmation que les choses peuvent changer au dernier moment par RTE [01.01.2026] [07:00:03] [DEBUG] [QA_TEMPO RTE_591]: Interrogation RTE [01.01.2026] [07:00:06] [DEBUG] [QA_TEMPO RTE_591]: Nouvelle couleur RTE de demain : ROUGE [01.01.2026] [07:00:06] [TRACE] [QA_TEMPO RTE_591]: Nouvelle couleur de demain : ROUGE [01.01.2026] [07:00:06] [TRACE] [QA_TEMPO RTE_591]: Notification : Couleur Tempo demain : ROUGE 🔴 [01.01.2026] [07:00:07] [DEBUG] [QA_TEMPO RTE_591]: Set Global Variable Tempo_Demain to ROUGE [01.01.2026] [07:00:07] [TRACE] [QA_TEMPO RTE_591]: Couleur Demain ROUGE(3) Inscrite dans domochart ( Perso Henri ) [01.01.2026] [07:05:07] [DEBUG] [QA_TEMPO RTE_591]: Rafraîchissement RTE [01.01.2026] [09:51:54] [DEBUG] [QA_TEMPO RTE_591]: Rafraîchissement RTE [01.01.2026] [09:51:58] [WARNING] [QA_TEMPO RTE_591]: La couleur RTE de demain a changé : ROUGE => BLANC [01.01.2026] [09:51:58] [TRACE] [QA_TEMPO RTE_591]: Notification : Couleur RTE de demain changée [01.01.2026] [09:51:58] [TRACE] [QA_TEMPO RTE_591]: Nouvelle couleur de demain : BLANC [01.01.2026] [09:51:58] [TRACE] [QA_TEMPO RTE_591]: Notification : Couleur Tempo demain : BLANC ⚪ [01.01.2026] [09:51:59] [DEBUG] [QA_TEMPO RTE_591]: Set Global Variable Tempo_Demain to BLANC [01.01.2026] [09:51:59] [TRACE] [QA_TEMPO RTE_591]: Couleur Demain BLANC(2) Inscrite dans domochart ( Perso Henri )

Bonne et heureuse année pour 2026 à tous et continuons à faire vivre ce Forum

Ce n’est que des prévisions reste à voir si c’est crédible pour anticiper sur la semaine ?

Je n'ai pas fait cette mise à jour je suis resté sur la stable précédente. Mais sur le forum officiel il y a quelques problèmes signalé sur le réseau ZWave (Strange logs in Zwave after update) et des devices qui changent d'ID (Devices are removed and added back with different IDs out of nowhere, randomly.) Peut-être y a t'il un rapport avec tes plantages ?????

Un Joyeux Noël pour tout le monde

J'avais aussi cette compréhension à un moment ...... mais dans le texte de l'exemple ils parlent d' Affichage et pas insertion dans les logs Cà reste confu . "Example to set Quick App log level to WARNING which will allow only errors and warnings to be displayed in console:"

Pareil maj faites. Pas de problèmes .

Ça j'aimerais bien comprendre. Quand j'étais jeune, à l'école on nous disais toute la difficulté à mettre sur le réseau une production, et qu'il fallait que le 50hz soit pile poil pour faire un couplage ... J'ai du mal à croire (ou à comprendre) que tous les systèmes photovoltaïques (notamment ceux en utilisation plug & play) soient tous pile poil à (à 50Hz) ? Après réflexion, je pense que cela concerne essentiellement les machines tournantes. Pour les onduleurs statiques (normalisés) cela doit moins poser de problème. Ps: désolé mais je ne souhaitais pas détourner ce post sur le zigbee

Après mise à jour, a la "reinit" du device, j'ai eut : [05.12.2025] [11:20:23] [TRACE] [ZWAVE]: ID 314: System hardware failure. Read the manual. [05.12.2025] [11:20:23] [TRACE] [ZWAVE]: ID 315: System hardware failure. Read the manual. [05.12.2025] [11:20:23] [TRACE] [ZWAVE]: ID 316: System hardware failure. Read the manual. [05.12.2025] [11:20:23] [TRACE] [ZWAVE]: ID 317: System hardware failure. Read the manual. [05.12.2025] [11:20:23] [TRACE] [ZWAVE]: ID 318: System hardware failure. Read the manual. [05.12.2025] [11:20:23] [TRACE] [ZWAVE]: ID 319: System hardware failure. Read the manual. Normal : les sondes n'existent plus ( elles sont toutefois déclarées : appareil désactivé )

J'ai aussi cette MAJ en attente, mais je n'ai pas remarqué de "Hardware failure" dans le journal (mais je ne le regarde pas tous les jours) Bien que mes sondes 16B20 fonctionnent correctement, j'ai par contre remarqué que sur coupure d'alimentation du smart-implant il arrive qu' au retour du courant, les sondes passent et restent à 0°. Il faut faire une autre coupure pour rétablir leur fonctionnement. Je l'ai remarqué car deux d'entre elles sont plongées dans l'eau de la piscine, et j'ai une alarme programmée : "Attention Gel " Si j'ai bien compris, avec La correction du firm 5.3 je vais donc devoir modifier cette alarme par : "Attention eau en ébullition"

C'est Noël avant l'heure car en plus de cette BETA il propose aussi : Avis important La version 5.190.39 est un correctif pour la version 5.190.38. Cette mise à jour résout les problèmes suivants : Correction d'un problème d'ouverture du fichier d'archive des événements du Hub. Que d'énergie .....

Voilà ce que j'utilisait quand j'avais mes plantages de la box du au pb de firmware : Obtenir le dump de HC3 : 192.168.1.xx/api/service/logsDump Au bout d'un moment on a un telechargement ex : LogsDump-HC3-00099999-03-05-2021_22_14_12.tar.gz 99999 = N° BOX Il faut le décrypter et le décompresser sur Linux ( je n'y suis as arrivé sur MAC-OS ) openssl enc -d -aes-256-cbc -in LogsDump-HC3-000999999-03-05-2021_22_14_12.tar.gz -out Logs.tar.gz -k fibaro-hc3 ou (fibaro-hc2) On obtient : Logs.tar.gz l'ouvrir, il décompresse en N fichier ( 42 au moins ) ... a exploiter .

data.php et device.php Regarde ICI

Je crois que c'est connu et on en avait parlé Il faut dans les Php Remplacer les FILTER_SANITIZE_STRING par FILTER_UNSAFE_RAW Par exemple dans data.php //$query = filter_input(INPUT_GET, 'query', FILTER_SANITIZE_STRING); $type = filter_input(INPUT_GET, 'type', FILTER_UNSAFE_RAW); On retrouve sur plusieurs autres lignes et dans les autres php

J'ai fais un diff des 2 logs en anglais et c'est strictement identique sauf : Fixed control of venetian blinds when using BiDi-Shutter and BiDi-Awning modules. Fixed the display of the scene list in the interface for the Norwegian language. Donc une nouvelle version pour les norvégiens et les utilisateurs de BiDi-Shutter Mais peut être la log n'est pas exactement le reflet des modifications ?????

C'est un warning (Pas bloquant) de convertion de tableau dans une chaine lors de la sauvegarde des variables de QA Moi je n'ai pas ce problème donc difficile à dire ... c'est soit : Que ce type de warning ne m'est pas signalé (Impléméntation ou Version de Php) Que le problème est spécifique au nom d'un QA ou d'une de ces variables ou à son contenu ? Pour le moment (voir si ça resoud ton PB ) Ignorer les warning ------------------- // en Ligne 19 tu modifie error_reporting(E_ALL); par error_reporting(E_ALL & ~E_WARNING);

pour pouvoir comprendre ce qu'il se passe pourrais tu poster ton SaveHc3-Auto.php car il doit être différent du miens.

J'ai fait une recherche dans mes QA installés (et ceux chargés et installés depuis le forum) et effectivement il n'y as pas des child:setValue mais des child:updateProperty

Je pensais une vg mise à jour par le qa qui incrémente à chaque chech si nas est off quand le nas redeviens on la vg est mise à 0 par le qa Il suffit ensuite un qa qui teste les changement d'état de la vg et qui fasse une notif au passage à 0 C'est compliqué mais si tu as ta solution avec ta config et gea c'est mieux

C'est peut être une solution pour réaliser ton besoin ( je ne sais pas je n'utilise pas de VG)

Eh bien maintenant, plus d'un an après: je peux dire c'est la deuxième fois 21/09/2025 00:07:55;380769;error;QUICKAPP29;"QuickApp crashed" 21/09/2025 00:07:55;380770;error;QUICKAPP29;"Unknown error occurred: LuaEnvironment: opt toolchains aarch64-buildroot-linux-gnu_sdk-buildroot aarch64-buildroot-linux-gnu sysroot usavhttp impl http_stream.ipp:2312: void avhttp::http_stream::handle_skip_crlf(const MutableBufferSequence&, Handler, boost::shared_array<char>, const boost::system::error_code&, std::size_t) [with MutableBufferSequence = boost::asio::mutable_buffers_1; Handler = boost::function<void(boost::system::error_code, long unsigned int)>; std::size_t = long unsigned int]: Assertion failed." 21/09/2025 00:08:14;380790;trace;QA_NETWORK MONITOR_29;" - *** QuickApp NETWORK MONITOR - MyInit V: 2.12 - Initialisation après temporisation de 14 secondes *** -" Mais sans conséquences Le chien de garde à fait son boulot 🤣 Troisième cette nuit de 29/12/2025 mais toujours sans incidence