jojo

oui mais pourquoi pas alors (comme chez nous) un FGBS avec 2 contacts aimantés, pour savoir quelle porte s'ouvre. . Je tirerais un câble 3 brins depuis ma BAL, et le FGBS est alimenté avec une alim (donc plus de soucis de pile) à l'intérieur => facile et fiable

Thank you @jang for this detailed info. As I'm not a developper, I'll to re-read your post 10 times to start understanding it , but one day I will understand ...

tu n'auras pas réponse ici. Pose ta question dans le topic Support GEA. Merci

j'ai lu ton topic, très instructif en effet. en résumé : "fait comme on te dit de faire, sans discuter, ni essayer de comprendre pourquoi" => oui chef, de toute façon c'est comme ça. Je n'ai toujours pas compris l'avantage , si ce n'est de m'obliger à changer mes habitudes de vieux.

j'avais bien l'intention de lire le lien, mais c'est vrai, JE suis stupide, pourquoi faire simple, quand on peut faire compliqué ?

Merci, je confirme que dans le debug, je vois l'instruction qui est après mon call http avant le résultat. Il doit surement y avoir une bonne raison à cela, mais je ne la vois pas. Pourquoi exécuter des actions alors que la précédente n'est pas finie ??? Je vais regarder ton lien, il y aura sûrement une réponse à mon questionnement, mais d'ici là, je considère cela comme TRES stupide et profondément illogique.

il y a un truc vraiment étrange : Dans ma fonction il n'rxécute pas les instructions après le http:request(url, { success = function(response) ... } ) voici mon code "complet" : je souhaite traiter resp ensuite. http:request(url, { success = function(response) if response.status == 200 then self:trace("OK, réponse : ".. response.data) resp = json.decode(response.data) else self:error("Erreur : réponse avec statut = " .. tostring(response.status)) end end, error = function(err) self:error("Erreur : " .. err) end, options = { method = 'GET' } } ) local id = resp[1].nukiId self:trace("nukiId = ".. tostring(id)) Merci

@minaetdave, je ne comprends pas parfaitement la logique de ce que tu veux faire. Ai-je raison si je crois me souvenir qu'en France les BAL sont différentes qu'en Belgique ? En France on relève le courier par le même endroit que le facteur le dépose ? Alors questions : où as-tu l'intention de mettre toon FGMS (une photo m'aiderais à comprendre) comment savoir avec une seule port si on l'ouvre pour retirer du courier (toi) ou pour en déposer (facteur). Et qui s'il dépose le courier en deux fois ? (chez moi c'est plus facile : le facteur a sa porte et moi la mienne => avec un FGBS et un contact sur chacune des portes, et le tour est joué). @Yannick, j'aurais fait comme toi

Bonjour, Je bloque sur ce bout de code. Et il me semble que c'est ok, mais apparemment non ... http:request(url, { success = function(response) if response.status == 200 then self:trace("OK, réponse : ".. response.data) local resp = json.decode(response.data) self:trace("resp = "..tostring(resp)) local id = resp.nukiId self:trace("nukiId = ".. tostring(id)) else je cherche à extraire le nukiId de la response. et voici le log : [27.07.2022] [18:47:57] [DEBUG] [QUICKAPP258]: onInit [27.07.2022] [18:47:57] [DEBUG] [QUICKAPP258]: State [27.07.2022] [18:47:57] [TRACE] [QUICKAPP258]: url = http://192.168.1.xxx:8080/list?token=zzzzzz [27.07.2022] [18:47:58] [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": 32, "keypadBatteryCritical": false, "timestamp": "2022-07-27T09:31:33+00:00"}}] [27.07.2022] [18:47:58] [TRACE] [QUICKAPP258]: resp = table: 0x3f1e6a30 [27.07.2022] [18:47:58] [TRACE] [QUICKAPP258]: nukiId = nil où est mon erreur ? Merci pour vos yeux et votre cerveau.

ce sont donc des idées d'évolution ...

Welcome !

tu dis toi même que c'est une légende. Donc "légendaire" serait le bon mot ?

donc par ton script automatique ce serait possible de le scheduller automatiquement ? Et pour l'espace sur le cloud, ne serait-il pas possible de programmer automatiquement la destruction des backups les plus anciens si : plus assez d'espace pour un nouveau backup ou ne garder que les x backups les plus récents et mettre (car je crois qu'il le demande) une option pour la sauvegarde des historiques (et l'utilité principale d'un backup cloud est un restore sur une HC3 spare, pas besoin des historiques => on gagne de la place

tu as sonné à la bonne porte

mais je n'ai pas vu la possibilité de programmer un backup cloud récurent, comme avec ton script. Du coup, j'oublie ...

Welcome ! Et étant développeur tu pourras rapidement nous aider en LUA

salut @Shad, cela fait plaisir de te relire. Je fais un retour chez Fibaro (HV2 -> Lifedomus -> HC3). J'en profite pour changer tous mes modules en z-wave +. La grosse semaine de migration (changement et inclusion de tous les modules par @mprinfo ()) sera la semaine du 15/8. D'ici là je prépare tout, et la box me semble géniale (tout ce que je voulais faire, est possible, voir plus ...). Pour l'instant, je n'ai qu'un soucis, c'est avec l'intégration du Google Nest : à chaque redémarrage des services (et donc toutes les semaines, car j'ai mis en place la solution de @Lazer de backuo automatique), je dois réautoriser la HC3 à accéder à mon Google Nest (et malgré tout ce n'est pas encore ok, mais ce n'est pas le plus important).

le prgm Silicon je l'utilisais déjà par ailleurs pour régler des prblm z-wave sur ma LD

voici (enfin) le lien promis

Mon premier Tuto HC3 … Idée Le principe est de faire faire des actions à la HC3, sur base d'instructions mises dans un/des calendriers Google. Le script appelle une méthode d'un QA. Perso, avec mon compte Google principal, j'ai créé 9 calendriers pour la domotique. C'est le même et unique script qui permet de tout faire. Il y a deux utilisations principales prévues : 1. Action à faire uniquement au début de l'événement 2. Actions à faire au début ET à la fin des événements. Configuration Commune du script Paramètre de la box : Précisez l'IP externe, le port et le protocole de communication. (un reverse proxy c'est mieux qu'un simple port-forwarding) ! Sécurité : créez un utilisateur spécifique (donc ne pas utiliser admin) qui n'aura accès qu'au(x) QA(s) utilisé(s) par le(s) script(s) Identification des calendriers : Pour trouver l'identifiant du calendrier : Allez dans les paramètres du calendrier Dans la dernière section, tout en bas Intégrer l'agenda ID de l'agenda : d7t37al9xxxxxxxxxxx66o4rg@group.calendar.google.com Action : Si dans les StartVal#/EndVal# il est précisé Title, il transmettra à la box le titre de l'événement. Fréquence d'exécution du script : Par défaut, la valeur est configurée à 1 min. Cette valeur doit correspondre à la fréquence à laquelle le script tourne pour vérifier s'il y a des événements à traiter. (cfr déclencheurs, plus bas) Action à faire au début Mettez "" à toutes les variables End* Exemple de configuration du script : GoogleCalendar.gos Exemples d'utilisation : rappels pour arroser les plantes, pour sortir un certain type de poubelle, … Actions à faire au début ET à la fin de l'événement Exemple de configuration du script : Thermo.gos Exemples d'utilisation : gérer le chauffage de chaque pièce (début = confort, fin = retour en mode éco/réduit) : perso, c'est mon utilisation principale. Pour plus de facilité dans l'interface Google, j'ai créé autant de calendriers que de thermostats, mais tout aurait pu être dans un seul calendrier, puisque j'ai mis le nom du thermostat dans le titre de l'événement. Autre idée d'utilisation : programmation de l'arrosage automatique ou de la pompe de la piscine. Installation finale Créez autant de scripts que nécessaires dans GoogleScript https://script.google.com/home Il faudra ensuite, pour chaque copie du script, lui définir un déclencheur : Lors de sa première exécution, Google pose des questions de sécurité. => à lancer manuellement la première fois. Je joins 3 fichiers de scripts : ○ GoogleCalendar.gos : avec exemple pour traiter uniquement le début d'un événement. ○ Thermo.gos : avec exemple de traitement de début et de fin d'événements. ○ Test.gos : script minimal pour tester la connexion et le QA Ainsi que la version pdf du présent tuto. GoogleCalendar.gos Thermo.gos Test.gos Tuto - Google Calendar vers HC3.pdf

merci pour les liens. En fait le programme utilisé par @tinman, je l'utilisais déjà pour gérer les noeuds morts. Je. continue ma lecture ...

à mettre dans ta to-do list ? (comme ça elle sera prête quand tu en auras besoin, et il y arrivera toujours (sauf si a le psudo @Nico ) un jour où elle sera bien utile... avec une simple clé AEOTEC ? (et comment y "inckure" les device z-wave tout en gardant le HC3 comme ma$itre ?

j'avais entendu que le prgm qui existait sous HC2 pouvait également fonctionner sous HC3, étant donné que le résultat final était sous une page WEB ???

as-tu essayé avec une de ces propriétés ? (on ne sais jamais)

Comme le disait @Lazer, @Steven est une programmeur hors catégorie !