henri-allauch

comme prévu le reboot à solutionné l'incident

OK je 'avais pas compris Oui tout y est exemple Mais

oui c'est ce que je dis : "" J'ai un bout de code php qui récupère le LUA ( /api/quickApp/export/$deviceId ) "" Et bien évidement le code y est puisque les fonctions de tous les QA sont OK ce serait un vrai miracle sinon ! Mais ce qui est surprenant c'est : Pour tous le QA c'est Pareil Pour Domochart Main Tools et Domochart Sont vides Aussi dans l'affichage

Tout marche ... mais Quelques soient les QA je vais dans le code MAIN et surprise : il est vide évidement j'ai vidé le cache, changé de navigateur, déconnecté et re connecté admin ... Idem J'ai un bout de code php qui récupère le LUA ( /api/quickApp/export/$deviceId ) est évidement ils est bien présent . Avant de faire un reboot, y a t'il quelques chose à regarder de plus ?

Un premier essai avec une option vers la ligne 95 : physics : false ... Cela permet de déplacer les nodes plus facilement Remplacer : $nodes = $nodes . "{id:" . $deviceId . ", label:'" . $deviceName . "', group:'" . $room . "', title:'".$room."'},"; // Le nom de la pièce sous forme de popup au passage de la souris Par : $nodes = $nodes . "{id:" . $deviceId . ", label:'" . $deviceName . "', group:'" . $room . "', physics: false , title:'".$room."'},"; // Le nom de la pièce sous forme de popup au passage de la souris

J'ai essayé plusieurs exemples avec https://visjs.github.io/vis-network/examples/ mais tous semblent avoir ce mouvement de remise en forme Je fouillerai un peu plus à l'occasion

Existe t'il une astuce pour supprimer les mouvements dans tous les sens des ovales pour tenter de les placer de manière plus lisible en évitant les chevauchements ?

Des ouvertures par badges rfid distribuès aux intervenant c'est interdit aussi ?

je n'avais pas assez réfléchi Merci @jang

Sur la désactivation d'un parent peut on envisager dans le Init() d'un QA de mettre les devices enfants disabled ? if not api.get("/devices/"..tostring(self.id)).enabled then for _, child in pairs(self.childDevices) do child:updateProperty("enabled", false) end end je dois pas bien m'y prendre car enabled reste à true

14W trop élevé pour une carte mère, mais peut être trop faible pour un chauffe plat ! Il reste la boite en alu pour bricoler.

Nous sommes nombreux à basculer sur une box hc3 Perso j'ai débranché définitivement la hc2 et je ne suis pas le seul Cette belle box qui nous a occupé et rendu de bons servives n'a pratiquement plus de valeur marchande Quelques unes autour de 100 euros sont en vente depuis plusieurs mois... Avait vous des idées... Que pourrait on en faire ?

Ne pouvant utiliser un QA pour faire un reboot, j'ai utilisé la commande redémarrer de l'interface pour effectuer ce reboot. Les voyants ont fait leur cycle chenillard puis blocage en clignotant sur celui de gauche. Au bout de dix minutes j'ai perdu patience. Appui court ( 5 secondes ) sur bouton AR, puis Appui bref pour redémarrer ( ce n'est pas un arrêt mais un suspend) La box à redémarré ( sans chenillard ) les 3 voyants de droite sont passés au vert. Mais toujours en redémarrage des services en cours ... Ping OK, j'ai fait un 192.168.1.53/api/service/servicesStatus et je me suis rendu compte : {"HCServer":{"running":true,"status":"Ok","devicesStatus":{"disconnected":0,"directRoute":27,"indirectRoute":11,"unknownRoute":1,"batteryEmpty":0,"batteryLow":2,"batteryMedium":9,"batteryHigh":5}},"Zwave":{"running":true,"status":"Ok"},"FibaroServices":{"running":true,"status":"Ok"},"RemoteAccess":{"running":false,"status":"Process not running"}} Tout va bien sauf : "RemoteAccess":{"running":false,"status":"Process not running"} Donc j'ai Appui court ( 5 secondes ) sur bouton AR, Puis j'ai débranché et rebranché l'alimentation ( j'aurais dû faire un appui 15 secondes ) Enfin un Appui bref pour redémarrer avec le chenillard ... Et tout est rentré dans l'ordre. {"HCServer":{"running":true,"status":"Ok","devicesStatus":{"disconnected":0,"directRoute":28,"indirectRoute":10,"unknownRoute":1,"batteryEmpty":0,"batteryLow":2,"batteryMedium":9,"batteryHigh":5}},"Zwave":{"running":true,"status":"Ok"},"FibaroServices":{"running":true,"status":"Ok"},"RemoteAccess":{"running":true,"status":"Ok"}}

Exact c'est le même schema que votre schéma de montage mais plus visuel pour tester.

@lazer Oui mais pas que ... car si tu demandes un rapport système c'est l'heure de la page web erronée. Tu peux aussi avoir une deuxième page dans une autre fenêtre qui est correcte ... De plus l'heure erronée affichée évolue ... elle n'est pas figée Fibaro à 2 montres Par contre, perso, je n'ai pas relevé d'action programmée, ni d'historique, ni d'évènements à un horaire décalée

Si tu es a l'aise en électricité tu peux faire des essais sinon je ne te conseille pas. L'électricité c'est DANGEREUX (même quand on est Pro) Tu peux faire un montage simple sur table, en prenant toutes les précautions de sécurité nécessaires pour tester ton module fibaro Pour tester ton relai jour nuit, il faut lui appliquer du 220 sur A1 A2 et tu doit l'entendre coller ( s'il est électromécanique ) et tu vérifie avec un ohmmètre par exemple que les contacts 1-2 et 2-3 sont fermés. Encore une fois si tu n'est pas à l'aise avec l'électricité ne le fait pas. Nota : les bornes cités sont celles du schéma de ton Post précédent, elles peuvent être différentes sur le relai de ton installation ( suivant la marque )

Mais ça c'est OK

Comme le signale @Lazer Ce genre de relai attend une alimentation ( maintenue) entre A1 et A2 pour commuter et donc alimenter le cumulus : ( ce n'est pas le principe du télérupteur : une impulsion ON la suivante OFF et ainsi de suite ) L'impulsion du réseau enedis est traité par un relai interne dans le compteur ( Linky ou génération antérieure ) Ou par un relai annexe pour certaines installation ancienne. Les sorties C1 C2 du compteur c'est un contact d'asservissement ON pendant les heures creuses et OFF pedant les heures pleines. Voir le paramètre 14 ( je crois) -----> tu doit être en impulsionnel ( mono-stable ) au lieu de bi-stable Marche/Arret Insérer un autre média

Pour completer : l'historique est à l'heure Dans Régalges Général temps et Unité c'est aussi à l'heure Mais si tu demandes un rapport système c'est l'heure de la page web

je ne pense pas que ce soit l'horloge interne de la HC3 car 2 fenêtres en // une ancienne n'est pas à l'heure tandis qu'une ouverte récemment est à l'heure Ce serait un problème sur la page web

OK moi aussi je n'avais jamais remarqué car je ne regarde jamais l'heure en haut à droite ( il faut cliquer pour la voir ) Celle dans la console des traces est juste et mes actions prevues sur une heure minutes définies se font correctement.

Erreur de lecture sur petit écran désolé

Dans, le loop c'est volontaire ? Plutôt que dans init

En plus moi j'ai collé un sort de la table ... Je vais regarder de près tes analyses de memoire comme dans tes QA Domocharts ou NetworkMonitor pour aider à optimiser mes codes.

OK je comprend la difference avec GEA, donc c'est le plusieurs QA avec refreshState qui fait réagir @Krikroff, et pour toi c'est l'appel d'un QA vers des fonctions d'autres QA qui pourrait être gourmand en CPU J'ai enregistré un petit diag : ce qui est sur c'est que /api/events/history est gourmand.