henri-allauch

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 🤣