jojo

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

je n'ai pas eu le courage de lire tous vos échanges, mais mon idée serait la suivante : On parle ici d'un module alimenté => faire un test si le module est mort ...

dans ta fonction success, tu dois décoder puis analyser la reponse qui est sous forme de json: local resp = json.decode(response.data) local type = resp[1].type

tu as aussi, sans devoir entrer à fond dans le LUA, GEA : c'est super puissant et idéal pour des scénari plus complexes (mais il faut commencer avec du simple)

évidemment que ça fonctionne ! As-tu déjà vu une publication de @Lazer qui ne fonctionnait pas : il n'est pas le stagiaire engagé à 50% par Fibaro !

comme @Lazer a TRES largement participé au développement de ce QA, je suis sûr qu'il est déjà entrain d'y faire les modifs requises

avec le lien tu arrives pas défaut sur décode, et il faut cliquer quelque part pour aller sur encode

thank you for this resume/summary : that is the language I understand