henri-allauch

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.

C'est un peu le principe de GEA Aussi pour capter les évènements ?

Ce message concerne le message de @Lazer Ou le fait d'avoir un QA avec un appel cyclique à : /api/redreshStates pour lancer des fonctions de QA suivant l'évènement attendu et détecté