henri-allauch

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.

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é

Ce matin j'ai un peu secoué la box avec des erreurs dans des boucles alors suis passé de 45 à 53 % d'utilisation Je viens de faire un backup donc restart des services Après sur 48 heures ca va passer de 43% utilisé à 46% + Quickapp: 25

Oui mais comme j'utilise déjà /api/redreshStates pour lancer des fonctions de QA. ( ça me remplace les trigger de scènes ) et je ne voulais pas alourdir ce code. Disons que J'ai voulu essayer avec autre chose .. de plus c'est un QA un peu marginal . Les événements retournés sont limités par un filtre sur eventType lors de l'api.get. j'en demande numberOfRecords=100 et si #events > 100 - Warning Pour le moment j'en ai entre 2 et 30 par requête toute les minutes; Mais dans le principe tu as raison chacune de ces deux api à une fonction logique spécifique

En fait je m'en suis rendu compte car je voulais journaliser en externe quelques éléments particuliers au fil du temps. Comme tu le dis le lastId c'est utile pour remonter dans le temps. Donc pour réaliser cela, j'utilise le timestamp le plus élevé (récent) du json récupéré pour l'ajouter à la requête suivante par ......&from=" .. tostring( timestamp + 1)

On récupère les éléments antérieurs à lastId alors qu'on devrait les ignorer et retrouver les plus récents non ? Exemple : http://192.168.1.53/api/events/history?eventType=DevicePropertyUpdatedEvent&lastId=1502913&numberOfRecords=5 [ {"data":{"id":136,"newValue":22.38,"oldValue":22.31,"property":"value"},"id":1502911,"objects":[{"id":136,"type":"device"}],"sourceId":0,"sourceType":"system","timestamp":1620291395,"type":"DevicePropertyUpdatedEvent"}, {"data":{"id":135,"newValue":26.69,"oldValue":26.75,"property":"value"},"id":1502909,"objects":[{"id":135,"type":"device"}],"sourceId":0,"sourceType":"system","timestamp":1620291394,"type":"DevicePropertyUpdatedEvent"}, {"data":{"id":130,"newValue":30.56,"oldValue":30.62,"property":"value"},"id":1502907,"objects":[{"id":130,"type":"device"}],"sourceId":0,"sourceType":"system","timestamp":1620291393,"type":"DevicePropertyUpdatedEvent"}, {"data":{"id":129,"newValue":31.31,"oldValue":31.38,"property":"value"},"id":1502905,"objects":[{"id":129,"type":"device"}],"sourceId":0,"sourceType":"system","timestamp":1620291392,"type":"DevicePropertyUpdatedEvent"}, {"data":{"id":127,"newValue":29.75,"oldValue":29.81,"property":"value"},"id":1502903,"objects":[{"id":127,"type":"device"}],"sourceId":0,"sourceType":"system","timestamp":1620291391,"type":"DevicePropertyUpdatedEvent"} ] Dans le swager c'est pareil Pourtant : requests with id<=lastId will be skipped (only more recent entries then lastId will be returned) Quelques chose m'échappe