jojo

tu continues suivant le même principe

j'avais fait une faute de frappe mes -> les (chez moi, j'ai PAC et PV)

les chauffages électrique ne sont plus d'actualité

tu es tombé sur LE bon forum

tu me l'avais fait connaître, mais je croyais qu'il était mort car je ne pouvais plus rajouter d'objet (utiles ou intulies)

comme on est voisin, si tu venir voir à la maison tu es le bienvenu

de mémoire, le FGBS peut être ,alimenté en AC ou DC => un seul transfo 220 - 24 devrait suffir. pour le relais, d'un coté il est en contact sec, et de l'autre ce que tu veux à condition qu'il supporte la charge de courant/voltage de ton EV (donc un relais classique pour couper du 220 Vac, sera ok pour couper du 24V ac)

je ne connais pas ton moteur, mais il devrait y avoir un commun également. (20 ?) ce n'est absolument pas indiscret, mais à l'époque j'ai fait de très nombreux test avec mon multimètre, car je n'avait pas de doc. Mes portes sont des Horman, mais les moteurs ??? Tout ce que je sais, c'est que j'ai 2 contacts secs : porte en mvt et porte ouverte

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