Lazer

Article sur la sécurité intégrée nativement dans Matter : [Abavala] Que propose Matter en termes de sécurité et de confidentialité pour la Smart Home ? C'est une bonne nouvelle. Là je me demande dans quelle mesure ça va ralentir (voire bloquer) les fabricants qui ne font pas partie du consortium CSA. Je pense à Fibaro bien sûr, et encore plus aux solutions communautaires (Jeedom, Domoticz, Home Assistant, etc...). Auront-il les moyens de se payer la certifications pour permettre à leur solution de s'intégrer dans l'écosystème ?

Yes, ça revient au même pris que j'avais payé le miens il y a 1 ou 2 mois

En fait là tes 2 règles ne sont pas validées. - 1ère règle : Days OK, mais Time KO (00:26 n'est pas entre 01:01 et 07:00 - 2nde règle : Time est OK, mais Days n'est plus bon (on est jeudi maintenant...) Lors de ton message précédent, les 2 conditions de ta 2nde règle étaient validées, mais c'était la durée qui ne l'était pas (voir GEA:check() difftime(0.0) < 30) Il fallait attendre 30 secondes de plus, au cycle suivant de GEA. Ce qui s'est probablement passé puisque tu dit qu'elle est passée en VALIDATION de couleur verte Pas de problème pour moi, je ne comprends pas bien les tests que tu as fait avec ton Wall Plug, mais le comportement me semble normal. En plus ce sont des règles assez standards.

Pareil que tout à l'heure, on ne voit le log que de la 2nde règle. Cependant cette fois-ci elle "matche" bien, les 2 conditions Days et Time sont valides (result = true), donc la règles est validée (ready = true). C'est normal, tu as fait le test mercredi (Wednesday), à 23:44 (entre 07:01 et 01:00). On ne voit pas la suite, mais GEA vérifie ensuite la durée pour déterminer s'il doit exécuter l'action. Je ne vois pas de problème en fait. Sinon tu as raison, je pense qu'on peut utiliser les jours en français, voici la fonction dans le code de GEA qui réalise le test des jours. Il faut juste qu'elle renvoie true, et il est trop tard pour que j'essaye de comprendre la logique, mais on voit des "trad" et "traduction" au nom assez explicite. function GEA:checkDays(days) if not days or days=="" then days = "All" end days = days:lower() local jours = days:gsub("all", "weekday,weekend") jours = jours:gsub(self.trad.weekdays, self.traduction.en.weekdays):gsub(self.trad.weekend, self.traduction.en.weekend) jours = jours:gsub(self.trad.week[1], self.traduction.en.week[1]):gsub(self.trad.week[2], self.traduction.en.week[2]):gsub(self.trad.week[3], self.traduction.en.week[3]):gsub(self.trad.week[4], self.traduction.en.week[4]):gsub(self.trad.week[5], self.traduction.en.week[5]):gsub(self.trad.week[6], self.traduction.en.week[6]):gsub(self.trad.week[7], self.traduction.en.week[7]) jours = jours:gsub("weekday", "monday,tuesday,wednesday,thursday,friday"):gsub("weekdays", "monday,tuesday,wednesday,thursday,friday"):gsub("weekend", "saturday,sunday") return tools:isNotNil(string.find(jours:lower(), os.date("%A", self.runAt):lower())) end

Ce n'est pas le LUA le problème. C'est le QuickApp. Fibaro n'a pas permis d'utiliser de trigger dans les QuickApp, uniquement dans les scènes. On a finalement trouvé que cette fameuse API refreshStates permet de détecter les événements, et de réagir instantanément. Ce ne sont pas des triggers, mais c'est tout comme.

Sur Jeedom ça n'a jamais fonctionné d'après les retours sur les forums, je pense que ce n'est tout simplement par supporté. Sur HC2 c'est censé fonctionner, c'est la base. Jamais testé perso, je n'ai pas de BSO.

Ben disons que l'utilisation de l'API refreshStates, c'est pas ce qu'il y a de plus facile à appréhender. Tu peux déjà lire le lien que je t'ai donné, et voir si ça te semble compréhensible.

@Nico c'est pas une version similaire à la tienne ? Si tu passes par là...

Merci pour le log détaillé, mais attention je pense qu'il manque le détail de la 1ère règle (qui se situe avant ta 1ère ligne de log), et à la fin tu a laissé le log de la règle suivante (qui fait un test de "Power"... donc rien à voir) En tout cas, on voit bien les logs de ta 2nde règle. {"Days", "Monday,Wednesday,Friday"} => est validé OK {"Time","07:01","01:00"} => n'est pas validé Donc à priori ça serait la condition d'heure qui ne matche pas, alors que la condition de jour est OK.

Non pas exactement, regarde plutôt ici pour différencier les deux versions du moteur Z-Wave : Je me rend compte à quel point Fibaro a mal communiqué (comprendre : "pas du tout" communiqué) auprès des utilisateurs, car vous êtes plusieurs à ne pas savoir. Il n'y a que les utilisateurs avertis qui suivent et lisent les notes de version des différents firmwares qui connaissent la différence. Pourtant ce nouveau moteur v3 est bien en beta depuis plusieurs mois, encore instable.

Il faut utiliser l'API refreshStates : Mais pas super facile.... je me demande si pour un scénario aussi simple, il ne serait pas préférable de toute simplement faire une scène, avec comme trigger ton bouton, et qui exécute l'action. Même pas besoin de boucle infinie. Ou GEA (en 2 lignes)

@Dragoniacs tu ne peux pas changer le type d'un module existant. Donc il faut bien que ça soit un nouveau QuickApp, qui gère le Qubino. Comme avant en fait.

Comme je le disais sur l'autre topic, j'ai finalement réussi à intégrer le support de l'injection dans le QuickApp Et j'ai aussi préféré tout partager d'un coup, car il faut supprimer l'ancien enfant Teleinfo, puis changer une ligne de configuration, puis le recréer, donc autant profiter d'une seule mise à jour pour tout faire d'un coup. Mais attention, c'est théorique, je n'ai pas pu le tester chez moi vu que mon compteur Linky est toujours en mode historique. Voici donc la version 1.20 du QuickApp GCE pour IPX800 et EDRT2 : Lorsque le QuickApp parent est désactivé (disabled), les enfants sont également désactivés automatiquement, et un message figure sous l’icône (log) => et donc exclus de DomoCharts Amélioration de l'état de nœud mort (dead) lors d'un problème de communication réseau Le QuickApp répond aux sollicitations de réveil (wakeUpDeadDevice) Ajout des nouveaux types EnergyMeter (com.fibaro.energyMeter) et PowerMeter (com.fibaro.powerMeter) Le type PowerSensor (com.fibaro.powerSensor) est déprécié par Fibaro et ne devrait plut être utilisé (mais il est toujours fonctionnel, comportement identique au nouveau type PowerMeter) Le type Teleinfo est maintenant de type "com.fibaro.energyMeter" afin d'être configurable comme Compteur d’énergie principal dans les paramètres de la HC3 Le type Teleinfo ne remonte plus la puissance apparence (en VA) dans sa propriété value (de toute façon c'était une information peu utile) Le type Teleinfo remonte l'index d'énergie (en kWh) dans sa propriété "value", et la puissance active (en W) dans sa propriété "power". Le type Teleinfo supporte l'injection dans le cas où le compteur Linky est paramétré en mode Standard Correctifs et améliorations divers Nouvelle syntaxe de configuration pour le type Teleinfo : Il faut maintenant spécifier pin = EAST (Energie Active Soutirée Totale) pour la value, à coté de argument et pin déjà existant (c'est valable qu'on soit en téléinfo Historique ou Standard) Eventuellement ajouter une seconde ligne Teleinfo avec pin = EAIT pour connaitre l'injection, uniquement si le compteur Linky est en mode Standard. Exemple : CONFIG = { {device = {name = "Consommation", type = "Teleinfo", options = {VG = "TELEINFO_Tarif"}}, value = {command = "Get", argument = "TI", pin = "EAST" }}, {device = {name = "Injection" , type = "Teleinfo" }, value = {command = "Get", argument = "TI", pin = "EAIT" }}, } Comme on peut le voir, s'il y a des options, il ne faut les mettre qu'une seule fois. Procédure de mise à jour si vous n'utilisez pas la Téléinfo : Mettre à jour les fichiers LUA du QuickApp avec la nouvelle version (copier/coller le contenu des 3 fichiers main, GCE, et tools) Procédure de mise à jour si vous utilisez la Téléinfo : Supprimer child device Teleinfo Mettre à jour les fichiers LUA du QuickApp avec la nouvelle version (copier/coller le contenu des 3 fichiers main, GCE, et tools) Modifier la ligne Teleinfo dans le fichier config pour ajouter : pin = EAST Eventuellement, ajouter une seconde ligne Teleinfo avec pin = EAIT pour l'injection Créer nouveau child device Teleinfo (cliquer sur le bouton dédié du QuickApp parent) Eventuellement, mettre à jour la base de données de DomoCharts via phpMyAdmin afin de refléter le changement d'ID (copier les lignes ci-dessous, modifier les 2 ID, et les coller dans la fenêtre SQL de phpMyAdmin ou équivalent) : -- Définition des ID : SET @OLD_ID = 285; SET @NEW_ID = 416; -- Requêtes SQL (ne pas toucher) : UPDATE IGNORE domocharts_power SET device_id=@NEW_ID WHERE device_id=@OLD_ID; UPDATE IGNORE domocharts_power_day SET device_id=@NEW_ID WHERE device_id=@OLD_ID; UPDATE IGNORE domocharts_energy SET device_id=@NEW_ID WHERE device_id=@OLD_ID; UPDATE IGNORE domocharts_energy_day SET device_id=@NEW_ID WHERE device_id=@OLD_ID; UPDATE IGNORE domocharts_device SET id=@NEW_ID WHERE id=@OLD_ID; UPDATE IGNORE domocharts_device_type SET device_id=@NEW_ID WHERE device_id=@OLD_ID; Téléchargement : Fichier main : GCE v1.20.lua Fichier GCE : Library - GCE v1.20.lua Fichier tools : Library - tools v2.20.lua

Les 14 To se seront les prochains qui partiront au rebut (*)... dès que les 20 To seront disponibles. (*) en réalité ils iront dans le serveur de backup, avec les 8 et 10 To que j'ai déjà retiré, car Google arrête le stockage illimité et gratuit dans le cloud, adieu les 34 To de backups en ligne Et j'ose pas imaginer le tarif s'il fallait payer....

70 To en ligne, il assure le vaillant Proliant Gen8

Pour info, bug identifié et confirmé par Fibaro concernant les entrées IN1 et IN2 du Smart Implant sur le firmware 5.093 BETA, il sera corrigé dans la prochaine version Beta : https://forum.fibaro.com/topic/58223-bug-in1-and-in2-from-smart-implant-dont-work-with-zw3-engine/ Je constate que tu as mis le numéro de série de ta box dans ton profil, essaye d'y mettre le numéro de version, ça sera plus utile. Par ailleurs j'aurais dû commencer par te demander quel moteur Z-Wave tu utilises, car là c'est le v3 qui est concerné. Pour rappel le moteur Z-Wave v3 est en Beta et ne dois pas être utilisé en production, il faut utiliser le moteur v2. (sauf si on sait ce qu'on fait) (Je le met en rouge pour que le message passe, car tu n'es pas le premier à tomber dans le panneau)

Hum, c'est une bonne idée et je n'avais pas du tout pensé à ça @MAM78, mais @flacon030 va te détester, car je viens de finir il y a 30 minutes la dernière version du nouveau QA... avec, ô surprise, la remonté d'injection car j'ai finalement réussi à l'intégrer dans le QA Du coup je suis obligé de reporter la publication du QA et d'ajouter les child devices multiPosition Ou alors plus raisonnable je partage en l'état et j'ajoute ça après....

Je ne connais pas ton pack alarme, mais attention, si tu branches le même capteur sur 2 appareils, tu risques d'avoir des problèmes d'impédance, et l'alarme risque de ne plus fonctionne correctement.

C'est fantastique, merci Enfin un QuickApp multi-position pour le Kamasutra Qubino Fil Pilote Cette fonction self:dispatch(), c'est quoi ?

Pourquoi un QA ? Si je peux me permettre, 2 suggestions : - ajouter une fonction au QA existant qui prend 2 paramètres : numéro du port, et statut true/false. Comme ça elle peut être appelée depuis n'importe où, et même depuis des boutons que tu ajoutes dans le QA existant - encore mieux faire des modules enfants de type binarySwitch => intégration native HC3

Ah oui en effet, c'est normal, il manque un Repeat dans les actions : GEA.add(true, 60*60, "", {{"Repeat"}, {"TurnOn", id, 15*60}})

ILS c'est juste le nom technique pour les capteurs sans contact à aimant, comme on pose traditionnellement sur tous les ouvrants (porte, fenêtre, etc... donc même principe sur une porte de garage) D'ailleurs le plus simple aurait même été d'utiliser des modules Fibaro Door Window Sensor, en Z-Wave. IPX800 c'est un automate de chez GCE Electronics, boite française, assez populaire chez mes domoticiens amateurs. Et en effet, Z-Wave est un réseau maillé, c'est un principe fondamental à bien assimiler. Contrairement au Wi-Fi par exemple.

Tu abordes différents sujets, qui auraient mérité des topics différents, classés dans la bonne rubrique, car finalement tes questions n'ont pas grand chose à voir avec la HC3 elle-même. Donc déjà pour traiter la partir HC3 / HCL => oublie la HCL, c'est un produit qui n'aurait jamais dû exister. Reste le choix entre la HC3 et la HC3L => la HC3L a moins de ressources, donc capable de gérer une 20aines de modules, guère plus. Au delà, elle va ramer. Autre sujet, même si elle supporte le LUA, elle est limitée à 32 bits, donc certains QuickApps exploitant la cryptographie (aspirateur Xiaomi Rorobock par exemple) ne fonctionnent pas. Il faut donc faire ton choix HC3 / HC3L en fonction de ce que tu prévoies de faire. Ce que tu prévois : Z-Wave est un réseau maillé, si tu as moins de 10 modules alimentés sur secteur, alors ça fonctionnera mal. Si tu prévois d'avoir plus de modules, alors c'est parfait, plus on ajoute de modules sur secteur, puis le réseau est stable. Les volets sont un bon départ, tu peux aussi avoir des dimmers, des wall plugs, etc, partout pour couvrir toute la maison, le jardin, et le garage. Le garage justement, le miens est également à 10 ou 15 mètres de la maison. J'y ai mis des modules Z-Wave, et ça fonctionne très bien car ils bénéficient des modules déjà déployés partout dans la maison (plusieurs routes possibles pour rejoindre la box). J'ai fait l'expérience avec 1 autre box (et donc un autre réseau), si j'avais que la box dans la maison, et 1 module au garage, ça ne fonctionnerait pas bien. Il est donc impératif de commencer par mailler son réseau correctement avant d'envisager de déployer des modules excentrés. Aujourd'hui je couvre ma maison, de la cave au grenier, le jardin (>500m², depuis la sonnette du portail jusqu'au puits enterré tout au fond du jardin, ainsi que l'abri de jardin encore plus éloigné), et le garage séparé de la maison, tout cela sans aucun problème. Parce que le réseau est bien maillé. Pour domotiser ta porte de garage, oui il faut un FGS pour le contact sec nécessaire au mécanisme. Perso j'ai ajouté 2 détecteurs ILS sur les 2 fins de courses de la porte (haut et bas), ce qui me permet d'en déduire 3 positions (complètement ouvert, complètement fermé, et intermédiaire). J'ai un QuickApp dans la HC3 pour afficher le statut correct de la porte. Les 2 contacteurs sont branchés sur un IPX800 car j'en avais un à proximité, mais j'aurais pu utiliser 1 modules FGBS Smart Implant, qui dispose justement de 2 entrées. L'alarme, sujet à traiter dans la section adaptée. Mais il est généralement admis que rien ne remplace une alarme dédiée, la domotique n'a pas le niveau de fiabilité requis pour ce genre de solution. Après tu feras ton choix en fonction de tes exigences (connectivité, niveau de sécurité, etc... sachant qu'aucune alarme n'est parfait et ne couvre tous les sujets, il faut faire des compromis) Les liens sont peut être HS, mais les discussions sont toujours d'actualité, le marché de l'alarme n'a pas évolué (si on exclus les jouets à la mode vendus par Amazon Netatmo & co qui osent appeler ça des alarmes)

Bienvenue sur le forum

Mon QA Yamaha MusicCast ne répond pas à ton besoin ? Le type de requête que tu fais, ça ressemble à du XML, donc pour les vieux amplis, avant MusicCast. Et le XML ne se met pas dans la requête GET, mais plutôt dans les données d'une requête de type POST ou PUT. Après la syntaxe exacte je ne sais pas, je n'ai jamais utilisé, puisque je me suis concentré sur l'API MusciCast. Pour faire tout type de requête HTTP, voir :