-
Compteur de contenus
15 013 -
Inscription
-
Dernière visite
-
Jours gagnés
208
Tout ce qui a été posté par jojo
-
et zut, j'avais édité mon message car il était parti trop vite, et je vois que tout est perdu ...
- 107 réponses
-
- domotiser piscine
- hc3
-
(et 2 en plus)
Étiqueté avec :
-
GEA sous HC3
- 12 406 réponses
-
- support
- script lua
-
(et 1 en plus)
Étiqueté avec :
-
là, je crois que tu dois confondre avec un autre forum où tu as posé la même question. Mais mon doigt fait 10-20 cm histoire d'être bien dans le flux d'eau.
- 107 réponses
-
- domotiser piscine
- hc3
-
(et 2 en plus)
Étiqueté avec :
-
En fait le local technique de ma piscine, se trouve d
- 107 réponses
-
- domotiser piscine
- hc3
-
(et 2 en plus)
Étiqueté avec :
-
merci pour le bon plan : du coup j'ai renvoyé celui que j'ai acheté le 1/4 plus cher, pour acheter celui-ci ...
-
perso, je trouve cela une bonne idée de passer via un IPX car : tu peux tirer un RJ45 entre ton routeur et ton local Piscine toutes les commandes depuis ton IPX seront en filaire => fiables les commandes locales continueront de fonctionner, même si ton IPX et/ou ta box sont HS. j'ai mis une sonde à l'aspiration de la pompe. Donc je remonte cette température que si la pompe tourne depuis 5 min (sinon, non représentatif). Ma box détermine la durée de fonctionnement de la pompe en fonction de la température mesurée (tous les jours, à 3h00, elle calcule la durée de filtration nécessaire en fonction de la température maximum mesurée) En hiver ma box passe en mode hiver, et elle ne peut pas éteindre la pompe (hivernage actif)
- 107 réponses
-
- domotiser piscine
- hc3
-
(et 2 en plus)
Étiqueté avec :
-
je continue ma migration vers la HC3. Pourrais-tu donner le lien vers le fameux QA ? Merci
-
ila fait une auto-exclusion
-
J'ai aussi depuis peu (mais quand précisément ???) un module (FGS-224) qui tombe mort, mais pourquoi ??? Pour le réveiller, pas soucis avec Yubi. Je devrais mettre une règle GEA ...
-
En effet, c'est une méga optimisation indispensable lorsque le QA tourne 4x/sec. et pour voir la structure du retour, il fallait juste décommenter ton exelple ! trop simple
-
et est-ce que une reconfiguration douce du device ne transmettrait pas cette class ? si oui, il faudrait voir si on ne pourrait pas automatiser ceka ? Autre idée : cette class serait-elle transmise au démarrage de la box (ou exclusivement lors de l'inclusion ?) =Tests
-
ok, je peux comprendre cette explication pour la transmission du signal à la bpx., mais pas pour le auto-off. Exple : di tu mets le module sur On via un bouton externe (connecté en S1), Q1 (ou O1?) repassera automatiquement à Off SANS qu'il soit nécessaire que le module soit à portée de signal de la box/
-
ok, c'est un debug commenté, mais je ne connais pas avec plusieurs paramètres. Ce que je connais c'est: self:debug("toto".."tata) et c'est quoi selft_debug ? self_debug(self, nbEvents) aussi, quelle est la structure de event.data idem que le json auquel il se rapporte ? event.data.id event.data.name ... event.data.properties.heatingThermostatSetpoint ...
-
Bon anniversaire cher @Lazer, grâce à qui le mot "domotique" est toujours présent dans le dico.
-
J'avais essayé depuis le parent et depuis 1 des 4 enfant. Je viens réessayer pour toute la famille, sans succès => je crois que je devrai créer une exception dand GEA : test si ce device est mort, et le réveiller si nécessaire. Et concernant mon autre question, 2nd capture ?
-
si le module est dans ton bureau (pour test donc), il fait bien le auto-off après 1s ?
-
A te lire, si j'ai bien compris, tu as 2 problèmes distincts : couverture réseau z-wave : 25 m de la box (qui est dans une baie) c'est trop pour une communication directe. Mais passer via un module volet qui est à 8m (j'imagine en direct et extérieur et que le module volet est alimenté en 220V). Tu peux tenter de refaire un re-maillage de ton réseau z-wave avec les modules à leur place définitive. ordre du auto-off : normalement, il s'agit d'un paramètre du module. Donc, si le module reçoit bien le ON, il n'a plus besoin de connection avec la box pour faire le Off. => je ne comprends pas pourquoi le Off le fonctionne que si la communication avec la box est ok. De plus, en général on met que 0,5sec (donc dans ce délais pas de perte de connexion avec la box)
-
j'ai un FGS224 qui tombe régulièrement mort. Dans sa config avancée si je clique sur le bouton 'Interroger cet appareil", il revient à lui Je me dis donc que si je change le dropdown juste au dessus par "L'appareil utilise la file d'attente d'interrogation globale", ça devrait faire le job. Mais la nouvelle valeur ne reste pas assez longtemps pour que je puisse sauver la config, elle revient après 3 sec à son ancienne valeur (et ce n'est pas mon browser, j'ai testé avec un autre). Ce problème est peut-être lié à celui-ci : je n'arrive pas à modifier la valeur suivant les recommandations de Fibaro J'ai bien l'icône verte à chaque appuis (donc la box reçoit l'info), mais la valeur revient toujours à sa valeur initiale. Suis-je le seul ?
-
mon QA chauffage n'exploite pas encore cette API. Il va falloir que je prenne mon courage à 2 mains pour m'y pencher (et comprendre ton code) sérieusement. Quand de je fais du reverse enginering, je ne comptrnds pas local id = event.data and event.data.id j'aurais compris : local id = event.data.id idem pour : --self:debug("Event :", json.encode(event)) il faut que j'essaie pour voir ce que ça donne
-
su la procédure de reset ne fonctionne pas => échange
-
d'après la box, j'ai 97 appareils z-wave Actuellement, pour la gestion du chauffage, j'ai de la config dans GEA et dans un QA. Afin de réduire les dépendances, je souhaite tout rammer dans le QA (car il fait déjà ce que GEA ne sait pas facilement faire). Et comme dans GEA j'ai des actions qui ne sont faites qu'en fonction du changement d'état d'un appareil, je crois que le refreshState serait plus approprié, mais je me posait la question car il collectait les changements d'état (en fait, uniquement le changement de la propriété Status ou de n'importe quelle propriété ?) de tous les appareils, ou mon QA ne vérifierait qu'un nombre limité de devices ? La question reste donc ouverte ...
-
je me pose une question "philosophique" : qu'est-il plus intéressant (performance, fonctionnalit, ....) entre l'API Refresh state programmée à 250 ms un main loop (qui tourne également toutes les 250ms) pour interroger le status d'une liste de devices ?
-
quelle est la raison réelle de tes économies ? Le divorce ou la domotique ? (j'ai mon idée ...)