henri-allauch

Alors nous sommes voisins

Parfait ok pour les modifs &fix=node (en direct sans elipse) et &fix=global (avec des elipses) mais rien d'urgent ça attendra une prochaine version. Et bienvenue à la future version 6 Attend d'avoir d'autres avis et suggestions Cela va devenir un outil indispensable Merci Au fait Peynier dans le 13 ?

Bravo pour ton travail. Perso j'utilise l'option $Fix = TRUE; sinon je m'enrage à faire une présentation lisible. Il y une option ou un traitement qui à changé le comportement de l'affichage lors du déplacement d'une ellispse ID entre la version V5.php et V5.2.php En V5.php Si on déplace l'élipse verte la flèche entre la rose et la verte se rétabli à une flèche droite V5.2.php ( et en V5.1.php aussi ) la flèche est ovale et son ancrage n'est pas forcément situé du bon coté de l'ellispse Cela devient illisible avec beaucoup de device Si tu as une idée pour corriger ce comportement je suis preneur. Autre idée pour quelqu'un à l'aise avec le php : Le nombre de choix d'options à passer en paramètre devient important et c'est bien pour utile. Plutôt que de les fixer dans le init.php ou modifier les paramètres de l'url peut on faire un formulaire de choix d'option. J'avais fait cela pour le php de sauvegarde des sources mais je ne maitrise pas le choix de plusieurs paramètres

Le feuilleton de l'été (qui dure depuis 11/02/2021) est (((en principe ))) terminé. Le 8/9/2023 le support à installé un "FIX" et depuis une mois je n'ai plus de reboot (alors qu'avec me même QA de simple test j'ai recensé 10 reboot non sollicités en AOUT 2023 ) Ce "FIX" à été installé sur plusieurs box et à priori depuis plusieurs mois il à résolu les problèmes. (Le support proposait soit un retour pour modification en usine, soit une action en ligne mais risquée ! ) A priori il est indépendant des versions proposées, mais je n'ai pas de précisons et Fibaro n'en donne ni sur son niveau d'implantation ni sur ce qu'il corrige. Ma deuxième box qui tourne en exploitation et qui n'a pas ce "FIX" vient de passer les 100 jours sans Reboot ni restart de service (pas de sauvegarde car pas de modifications) Peut être il y aura une explication un jour ... ou pas.

On dirait qu'il y a un problème au téléchargement de z-wave_network_mod V4.php ( Le lien dans le post V4 donne 0 octets erreur serveur ) j'en ai crée un pour essai c'est ok mais autant le format de celui que tu a créé ( pour les futures évolutions ) ip_ss = "192.168.x.x" port = "" user = "LeUser" pass = "DevineLePassword"

Merci pour le partage de ton travail acharné et efficace. Perso pour stabiliser le déplacement des ovales-devices qui provoque "une danse" de tout le graphique j'avais ajouté un flag : physics: false, Dans ta dernière version c'est vers la ligne : 236 $nodes = $nodes . "{id:" . $entree["id"] . ", label:'" . $entree["name"] . "', group:'" . $entree["room"] . "', physics: false, title:'".$entree["room"]."'},"; // Le nom de la pièce sous forme de popup au passage de la souris Voir ICI A voir si cela est préférable pour certains d'entre nous ?

Si tu te sert toujours de cette version manuelle, Tu peux ajouter au traitement du Exit vers la ligne 321 du php initial la fonction window.close() case "Exit": echo "<script> window.close();</script>"; exit(); Ainsi quand tu sélectionne Abandon et que tu valide la fenêtre du Php se fermera.

SI cela peut être utile, La commande refresh pour un split que je recherchais : https://app.melcloud.com/Mitsubishi.Wifi.Client/Device/RequestRefresh?id=Split_ID

Pas grave je vais essayer le la trouver merci

Déjà c'est au niveau de l'appli melcloud sur smatphone que la mise à jour n'est pas systématique Il me faut sélectionner le Split pour qu'il fasse un rafraîchissement Marche Arret et que les états soient corrects Ton QA fonctionne parfaitement mais comme il faut un QA par split ce n'est pas ce que je recherche. Je n'ai besoin que de certaines infos capturée sur Melcloud. Donc j'ai pris tes fonctions d'accès à melcloud et les ai intégrées dans mon appli. c'est parfait je récupère les infos souhaitées des 2 splits Mais si tu connais la commande http qu'il faudrai envoyer à melcloud pour provoquer ce rafraîchissement ça m'interesse Merci

J'ai remarqué sur un redémarrage des splits après quelques jour d'arrêt (off) sur l'appli melcloud le(s) split sont notés Arrêt sur l'onglet bâtiment même une heure après. Il faut sélectionner le Split pour qu'il fasse un rafraissisement et que les états soient corrects. Il y a même un bouton pour forcer cette action. Est ce que tu connais la commande http qu'il faudrai envoyer à melcloud pour provoquer ce rafraissisement depuis la hc3 Merci

Rappel : J'ai donc installé une deuxième HC3 (neuve) : hc3.new J'ai fait le transfert de hc3.old sur hc3.new le 30/05 par l'intermédiaire du cloud Fibaro Suite : La Hc3.new à travaillé sans problème pendant 30 jours puis elle à du rebooter suite à une panne prolongée du réseau Enedis. Depuis ce reboot : 70 jours sans incident. HC3 Version: 5.140.17 Le 04/09/2023 à 12:00:00 En service depuis 69 jours, 13 heures, 39 Minutes et 30 secondes RAM Disponible : 61% Cache : 34% Buffers : 7% Utilisée : 37% Donc cela fait 100 jours sans plantage, tout fonctionne parfaitement et c’est rassurant. Pendant ce temps j’ai un peu travaillé sur des essais de QA sur la HC3.old et j’ai obtenu tout de même 20 reboot non sollicités. Le dernier en date hier à 18h32 : Ce reboot intervient 4 jours après un reboot demandé suite à la suppression des QA d’essais. La configuration est donc : Pas de device, juste un QA qui surveille les reboot. ---------------------------------------------------------------------------------------------------------------- -- QuickApp . QA_CtrlRestartHc3 -- Author . Henri -- Date . Aout 2023 0.00 -----------------------------------------------------------FONCTIONS LOCALES------------------------------------ local loop -----------------------------------------------------------INIT----------------------------------------- function QuickApp:onInit() QuickApp._VERSION = "DVP-0.00" QuickApp._NAME = "Ctrl Restart Hc3" self.admin = 2 __TAG = "QA_" ..self._NAME .."_" .. plugin.mainDeviceId self:trace(" - *** QuickApp " ..self._NAME .." - onInit V: " .. (self._VERSION) .." -") -- Start sur la minute suivante local delta = 60 - math.floor(os.date('%S')) local loopTimestamp = os.time() + delta local message = "Il est : " .. os.date('%H:%M:%S') .. " Start at : " .. os.date("%H:%M:%S", loopTimestamp) .. " dans " .. tostring(delta) .. " secondes..." self:trace(message) fibaro.call(self.admin, "sendEmail", "Start "..self._NAME, message) fibaro.setTimeout(delta*1000, function() loop(self) end) end ---------------------------------------------------- Fonction loop Chaque Minute--------------------- function loop(self) local data = api.get("/settings/info") local Hc3Name = data.hcName local uptime = data.serverStatus or 0 -- self:trace("In Loop()") -- Test Activité HC3 if os.time()-uptime < 120 then local sujet = " ReStart HC3 (Boot ou Backup)" local message = "La Box " ..Hc3Name .." a redémaré : " .. os.date("%H:%M:%S", uptime) self:trace(message) fibaro.call(self.admin, "sendEmail", Hc3Name ..sujet, message) end -- Relancer la boucle dans 1 minute self.timeoutId = fibaro.setTimeout(60 * 1000, function() loop(self) end) end Cette Box à bien un problème. Pendant ce temps : Sur le forum officiel d’autres utilisateurs ayant des reboot intempestif ont aussi ajouté une nouvelle HC3. Certain comme moi n’ont plus d’incident, d’autres ont retrouvé le problème quelques semaines après. Pour ces derniers, le support Fibaro leur a proposé un rapatriement de la box en usine ou un patch de firmware par réseau. Il semble que ce patch ai solutionné le problème. Mais il n’y a que très peu de communication sur le sujet. ( FIRMWARE à Quel Niveau ??? ) A voir : ICI ... LA et d'autres Peut être que nous en serons plus d’ici quelques jour s’il y a une nouvelle version.

On en avait parlé en 2021 j'avais un cas similaire, tu m'avait conseillé de virer le Order By sur le Update (ICI) J'avais modifié trend.php : /***Modif Henri/lazer vers ligne 250 pas de order by dans le update ***/ /***https://www.domotique-fibaro.fr/topic/14935-quick-app-domocharts-graphiques-sur-nas-pour-hc3/?page=3&tab=comments#comment-238265 //*** Energy $query1 = " SELECT DISTINCT(device_id) AS device_id, start_date FROM domocharts_energy, (SELECT DATE_ADD(COALESCE(MAX(`date`), '0001-01-01'), INTERVAL 1 DAY) AS start_date FROM domocharts_energy_day) t WHERE time < start_date "; $sql1 = $bdd->prepare($query1); if ( $sql1->execute() ) { $rowcount = $sql1->rowCount(); $dates = $sql1->fetchAll(PDO::FETCH_ASSOC); foreach ($dates as $key => $row) { array_push($response['data'], ExecuteQuery($bdd, " UPDATE domocharts_energy, (SELECT @prev_index := COALESCE(`index`, 0) FROM domocharts_energy WHERE device_id = :device_id AND time = (SELECT COALESCE(MAX(time), 0) AS last_time FROM domocharts_energy WHERE device_id = :device_id AND time < :start_date)) as temp SET value = CAST(- @prev_index + (@prev_index:=`index`) AS DECIMAL(6,3)) WHERE device_id = :device_id AND time >= :start_date ; ", array('device_id' => intval($row['device_id']), 'start_date' => $row['start_date']))); } //**ORDER BY id; ( était à la suite du where pb erreur pas order by sur update suivant derveur sql ) ***********************************// } else { $errorInfo = $sql1->errorInfo(); array_push($response['data'], array( 'success' => false, 'rowcount' => $sql1->rowCount(), 'error' => array( 'code' => $errorInfo[1], 'message' => 'SQLSTATE['.$errorInfo[0].'] '.$errorInfo[2] ) )); } Et depuis je n'ai plus ce problème. (Linux/mysql) J'espère ne pas être hors sujet ...

ah ok j'ai fait l'essai sur une box qui n'avait que des scènes fibaro (: "Time Light Scenario", "Gate Light Scenario", "Morning scenario" et "Evening Scenario") qui sont de type scénarios donc il doit y voir au autre type scène a autoriser il faut que j'en crée pour tester J'ai ajouté le le type Lua ---- >> à tester. SaveHc3-Auto.php

Exact Merci J'avais essayé sans succès comme dit un peu plus tôt Certainement une faute dans la saisie des variables Je te remercie sincèrement de ton aide et du partage de ton QA

Ok j'ai installé avec Salon et c'est OK j'ai les températures du salon J'ai essayé d'installer un second QA mais a priori ça boucle a fond sur ce QA sans trouver le device avant de parametrer les variables login mdp et Split Il faut installer un QA par Split ?

J'ai jeté un petit coup d'oeil effectivement c'est bien lié aux scènes bloc. La structure du json scènes/content/actions est différente. Tu as raison, même si on récupère le contenu de la structure, il serait difficile de la déposer simplement dans la scène block. Donc la solution serait peut être d'ignorer les scènes mode block En attendant on reste avec un warning ++ Dernière Minute : j'ai fait une version modifiée pour Signaler mais ignorer les scènes Blocs (à vérifier) Modif SaveHc3-Auto.php

Je n'arrive pas à faire fonctionner ce QA et après plusieurs essais je vous soumet mes déclarations et debug obtenus J'ai 2 splits (chacun à son Wifi) connectés à une unité extérieure. Après configuration Melcloud j'obtient un bâtiment Mourguette et deux appareils Salon et Bureau Configuration du QA Mail, Mot de passe, et là ou j'ai un doute : """ Split_Name : MonSPlit -> le nom du split tel que défini dans l'interface MelCloud, que ce QA viendra piloter "" je met le nom du bâtiment Mourguette je comprend pas ce qu'il faut mettre comme nom du split le QA boucle sur [22.08.2023] [15:37:17] [DEBUG] [QA_MELCLOUD_49]: Envoi de la requête de récupération des infos du MelCloud... [22.08.2023] [15:37:17] [DEBUG] [QA_MELCLOUD_49]: Connection au MelCloud réussie [22.08.2023] [15:37:17] [DEBUG] [QA_MELCLOUD_49]: Données collectées depuis le serveur ! [22.08.2023] [15:37:17] [DEBUG] [QA_MELCLOUD_49]: Infos du bâtiment 631907 - Mourguette récupérées [22.08.2023] [15:37:17] [TRACE] [QA_MELCLOUD_49]: Utilisation de la clé : AF41C176EA68498CB56756346B0153 [22.08.2023] [15:37:17] [DEBUG] [QA_MELCLOUD_49]: Vérification des ID batiment & Splits... en continue jusqu'a [22.08.2023] [15:38:25] [ERROR] [QUICKAPP49]: Unknown error occurred: std::runtime_error: 'eventfd_select_interrupter: Too many open files' il y a bien une VG qui est créée MelClous_Key je fais une erreur mais ou ? Debug QA_MELCLOUD_49.lua Debug QUICKAPP49.lua

OK alors la piste que tu suggère ( scènes en mode block ) est peut être la bonne. Je n'ai pas de scène mode bloc ni de scène à part celles les 4 imposés par Fibaro ( Morning Evening , ...) qui à priori ne pose pas de problème Il y a peut être quelque chose de différent dans le json /api/scenes/$deviceId des scènes qui provoque cette absence d'indice de clé

Pour une valeur de tableau non définie : La raison du warning est que depuis la version 8.0 de Php, "Undefined array key" a changé de niveau : de Notice à Warning. Deux solutions. 1 Modifiez les paramètres d'erreur PHP pour ne pas inclure E_WARNING (non recommandé) 2 Inclure un isset() pour vérifier existance de la variable (recommandé). Voir au niveau des lignes de warning obtenues dans debug ex 74 et autres Modifier du style if (isset($c["actions"])) { $n = file_put_contents($file, $c["actions"]); if ($n == false ) { Writelog( "Erreur ecriture" . $scenes["name"]. "_actions.lua"); } else { Writelog ("Sauvegarde de " . $scenes["name"]."_actions.lua : " .$n ." octets"); } } Je n'ai pas PHP 8 pour tester et je n'aurai pas le temps avant la fin de l'année mais je pense que c'est la piste à suivre pour le Pb de warning Le QA remonte les messages de la version modifié Auto.

Je n'avais pas compris ce que tu recherche Dans ce cas je ne sais pas, mais je ne doute pas que la réponse arrivera vite

dans un QA Essaye : Pour Icone User1002.png self:updateProperty("deviceIcon", 1002)

Non tu n'est pas seul ( Ici et sur le forum officiel ) forum fibaro officiel Ici aussi notre forum Et autres ...

@jojo de plus en plus moi non plus ... et je crois que j'affine la preuve Parmi les 4 QA j'ai désactivé les 2 qui utilisent refreshStates ( les plus consomateurs ... ) résultat cette hc3.old à planté encore à 2 reprises en 8 jours. Alors que la hc3.new avec tous les devices et QA tourne parfaitement sans reboot depuis 25 jours Dans la hc3.old , j'ai cette fois tout viré, j'ai un seul QA réveillé à chaque minute qui a trois actions 1 voir si la box à redémarré. 2 à la minute 00 (donc toutes les heure) envoi un mail pour dire en service depuis X Jours X Heures 3 toute les 5 minutes envoi un debug : Display LUA memory consumption every 5 minutes (ID @Lazer) c'est plus pour la faire un peu travailler Donc j'attend la suite si toutefois le peu d'activité reste suffisant pour déclencher le reboot. Faut être patient ... Coté garantie j'ai passé la garantie de 2 ans constructeur, mais je viens de me rendre compte que mon fournisseur ajoute une année supplémentaire (fin février 2024 pour moi) Je verrai donc avec lui en temps voulu ce qu'il peu faire ...

Sur le forum officiel (ICI) @SDeath qui comme moi à acheté une deuxième box ... a été contacté par le support qui aurait résolu 90% de ce problème Son ancienne box à été "patché" par le support, elle est en test et surveillée par @SDeath