jojo

C'était me cas avec le FGBS-221, plus avec le FGBS-222 : cfr doc

Bonjour de Feluy/Seneffe

première question qui me vient à l'esprit : Est-ce que l'ordinateur qui se serait mis en veille van aimer la coupure de courant ? (si shutdown forcé, sans sauvegarde des données, ce n'est pas la même chose qu'une mise en veille). Pour les fans de GEA (dont je suis), cela est fait en une règle d'une ligne : gea.add({"Power-",<id_module>,50}, 10*60, {"TurnOff"})

as-tu essayé en cliquant sur le bouton "remplir paramètresé ?

moi je suis dans la dernière stable ... J'ai lu que la dernière beta était bien pourrie, ceci explique peut-être cela cher voisin

et bonnes vacances

je n'ai pas tout lu en détail, mais il devrait être possible de connaître le statu de la porte et de la commander avec un FGBS-222 : la carte électronique de la porte doit certainement être alimentée par une tension compatible avec ld FGBS-222 il y a 2 contacts secs, qui combinés intelligemment (il faudra analyser leur statu) permettront de dire si la porte est en mouvement, ouverte ou fermée : IN1&IN2 du FGBS222 il y a un contact sec qui permet de faire bouger la porte (en fermeture - arrêt - en ouverture - arrêt - en fermeture - ...) : OUT1 du FGBS222 avantage : pas de pile et tout en local (dans le moteur) et en bonus : grace à la sonde de température intégrée du FGBS222, on a la température du garage (parfaitement inutile ...)

c'est l'interface la plus difficile à configurer

idée : Si tu n'as pas le problème sur tous tes FGBS-222, interchange un qui va bien avec un qui foire, et après réinclusion de ces deux là tu verras peut-être que celui qui ne fonctionnait plus fonctionne à nouveau (et inversement). ou reconfiguration douce d'un qui foire ???

mais non tout a une explication très logique. Avant le bit avait deux valeur possibles : 0 ou 1. Maintenant, avec les avancées de l'informatique moderne, il faut y ajouter une troisième valeur possible : 0,5 CQFD ...

cool, j'avais validé ma solution avec l'option 1, et je suis content parce que ça devient bien

tu as 2 solutions : des FGS224 (pas de FGS222, les 224 sont en z-wave+) : Ils sont alimentés en 220Vac, mais peuvent piloter ce que tu veux (ils ont une entrée sur laquelle tu branches ton transfo qui alimentera tes vannes) des FGBS222 : tu pourrais utiliser la même alim pour le module et tes vannes, mais tu devra mettre un relais entre les OUT1/2 du module et les vannes, car le module ne résisteras pas au courant des vannes (contrairement au FGS224). Mais tu pourris également l'utiliser pour des entrées contact sec et température. Chacune des solution te permet de piloter 2 EV par module

Merci pour ton temps/implication .... En fait pourquoi cette question ? Car je veux faire un QA (à partager avec la communauté) qui soit le plus générique (= qui convient aux plus de cas) possibles. Pour moi perso, le JSON/Table ne contiendra jamais qu'une seule entrée. C'est donc pour pouvoir être général que j'essaie de générer un table JSON à plusieurs entrées , pour simuler une situation où on aurait plusieurs entrées dans la table retournée et ensuite ne traiter que l'entrée qui nous intéresse. Voici que que mon JSON me retourne actuellement (1 seule entrée) : [07.08.2022] [13:27:12] [TRACE] [QUICKAPP258]: OK, réponse : [{"deviceType": 0, "nukiId": 184981569, "name": "Entrée", "firmwareVersion": "1.14.1", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 26, "keypadBatteryCritical": false, "timestamp": "2022-08-07T06:14:14+00:00"}}] Voici le débug demandé : 1 [07.08.2022] [13:11:53] [DEBUG] [QUICKAPP173]: onInit [07.08.2022] [13:11:53] [DEBUG] [QUICKAPP173]: point de départ en table : table: 0x16781df0 [07.08.2022] [13:11:53] [DEBUG] [QUICKAPP173]: on l'utilise comme une table : Entrée1 [07.08.2022] [13:11:53] [DEBUG] [QUICKAPP173]: transformé en chaine : [{"name":"Entrée1","nukiId":1,"deviceType":0},{"name":"Entrée","nukiId":184981569,"deviceType":0},{"name":"Entrée3","nukiId":3,"deviceType":0}] [07.08.2022] [13:11:53] [DEBUG] [QUICKAPP173]: **************************************************** [07.08.2022] [13:11:53] [DEBUG] [QUICKAPP173]: point de départ en chaine : [{"deviceType": 0, "nukiId": 1, "name": "Entrée1"}, {"deviceType": 0, "nukiId": 184981569, "name": "Entrée"}, {"deviceType": 0, "nukiId": 3, "name": "Entrée3"}] [07.08.2022] [13:11:53] [DEBUG] [QUICKAPP173]: transformé en table : table: 0x167d4dd0 [07.08.2022] [13:11:53] [DEBUG] [QUICKAPP173]: on l'utilise comme une table : Entrée1 La question est donc : Lequel de tes 2 scenarios dois-je utiliser pour simuler au mieux le cas d'un retour de JSON sous forme de table à plusieurs entrées (vu que moi je n'ai jamais qu'une seule entrée) Merci (surtout pour les autres)

Merci, mais je n'y comprends rien, car pourtant : 20220807035144 // http://192.168.1.xxx/api/users [ { "id": 2, ... }, { "id": 175, ... } ]

Bonjour, Je dois bloquer sur une bêtise ... Je veux créer une table JSON à plusieurs entrées, car mon instruction resp = json.decode(response.data) ne me retourne qu'une seule entrée (en fait c'est pour faire un tuto/QA bien comme il faut pour gérer les serrures Nuki => teasing ...) resp = [{"deviceType": 0, "nukiId": 1, "name": "Entrée1"}, {"deviceType": 0, "nukiId": 184981569, "name": "Entrée"}, {"deviceType": 0, "nukiId": 3, "name": "Entrée3"}] et voici le debug = [06.08.2022] [16:40:01] [ERROR] [QUICKAPP258]: QuickApp crashed [06.08.2022] [16:40:01] [ERROR] [QUICKAPP258]: main.lua:43: unexpected symbol near '[' La ligne 43 correspond à la première ligne de code. Pourtant il me semble avoir fait exactement comme Google ma l'a recommandé. Merci pour vos yeux

non, à priori pas d'impact sur le QA de la HC3, car @Lazer a précisé plus haut que le QA utilisait déjà AUTH2 comme méthode d'authentification

oui, dans mes tests, quand j'ai coupé l'alim, elle a bien redémarré

je pense en effet qu'une réinitialisation du module serait une bonne chose. Espérons que celà règle le problème. Sinon, pour sécuriser ta maison, tu le débranche du connecteur (et si tu as un autre connecteur, tu peux l'y mettre en test)

tu pleures cfr mon lien plus haut

voici donc le résultat des tests que j'ai fait en appuyant sur le bouton physique : - appui 5 sec sur power : toutes les led se sont éteintes, et erreur de ping. C'est comme si c'était un shutdown ? - appui "bref" pour la rallumer : STRESS : les lampes se rallumment dans l'état qu'elles étaient avant (donc cela correspondrait à un sleep/suspend sous Windows ?) MAIS pas d'interface web (=> la box est mal réveillée). Les seuls moyens pour retrouver une interface WEB qui fonctionne : appuyer 15 sec sur le bouton power = reboot OU couper le courant (et le remettre), ce qui correspondrait à un reboot. Donc ce que je ferais en cas de coupure de courant : box sur onduleur 5 sec sur bouton power Puis au retour : un reboot avec le bouton

=> Google is your friend ... Tu pourrais tou faire en une scène qui se déclenche à 6h: - 6h : ouvrir la vanne - attendre 10 min : fermer la vanne - attendre 50 min (iil est donc 7h) : ouvrir la vanne - ...

ah, ok c'est pour cela que mes leds n'arrêtent pas de clignoter. C'est quoi susppend ? (est-ce idem que sleep ?, est-ce la m^rmr chose que shutdown ?)

dans le manuel Fivaro https://manuals.fibaro.com/document/hc3-buttons-2/ ils parlent de sleep mode. C'est quoi, l'équivalent du shutdown ? Home Center 3 - "Buttons" Power Click – Wake up Hold for 5s – Sleep mode Hold for 15s – Restart c'est @Lazer qui a rajouté cette option => c'est obligé de fonctionner ! mais je fais un test si tu veux

dans GEA, il y a pourtant une option shutdown -- "ShutdownHC3" : Arrête la box HomeCenter -- SYNTAXE : {"ShutdownHC3"} -- CONDITIONS : Ne peut pas être utilisé comme CONDITION -- ACTIONS : GEA.add( {CONDITIONS}, 30, "", {"ShutdownHC3"} ) -- Arrêt de la box HomeCenter