[Topic de travail] Modules Virtuels et Scènes à migrer en QuickApps

[Lazer]

Voilà

 

Pour info c'est l'ancienne API qui date de la v3 sur HC2.

Elle fonctionne toujours, Fibaro l'a conservé, même si ce n'est plus documenté, et c'est indispensable pour les vieux appareils qui ne savent pas faire de requêtes POST/PUT, comme l'IPX800, le Rabiit, et pleins d'autres.

[Dragoniacs]

Du coup c'est même top avec la HC3, car on peut directement appelle une méthode dans un QA.
Je vous paufine mon QA lapinou et je vous poste le résultat.

Envoyé de mon RMX1993 en utilisant Tapatalk

[Lazer]

Et oui, l'appel direct des méthodes des QuickApps, c'est fantastique, je le clame haut et fort depuis des mois sur le forum

 

[BenjyNet]

Moi je vois pas de quoi vous parlez, j'ai pas de HC3 

C'est équivalent aux classes/objets en c++ ?

[Lazer]

Un QuickApp ? Oui complètement.

 

Mais ce dont on parle, à savoir l'appel des fonctions des QA depuis n'importe où, ça serait équivalent aux méthodes publiques des classes/Objets.

 

En fait, toute fonction appartement aux QA est automatiquement exportée et accessible à tous.

Aussi bien pour les fonctions perso qu'on crée nous même que les fonctions prédéfinies (QuickApp:debug() par exemple)

[jjacques68]

Il y a 2 heures, Lazer a dit :

/api/callAction?deviceID=93&name=push&arg1=10&arg2=power

je l'avais oublié celui-là...  

[Dragoniacs]

Publication du lapinou moderne

 

 

[Domodial]

Salut @Lazer 

 

Citation

 

Ubiquiti Unifi => à priori abandonné car le Quick App disponible sur le Market Fibaro semble bien fonctionner

 

Le script fonctionne en effet. Mais contrairement au tient, il n'est pas possible de passer la valeur à une variable pour changer une scène. Je n'ai pas trouvé en tout cas. Je me demande donc l'utilité du truc.

[Lazer]

Si tu veux mon avis : ça n'a aucune utilité

Tu raisonnes encore en mode HC2.

Il faut formater ta mémoire, et penser HC3

 

Sur HC2, on était obligé d'utiliser les variables globales, car c'était le seul moyen de partager des données entre les modules virtuels et les scènes.

 

Sur HC3, tout cela est fini.

Les QuickApps peuvent être correctements typés (capteurs, actionneurs, etc)

En fait, on peut tout faire avec les Quickapps... dit autrement, les scènes et les variables globales sont inutiles (ou à la limite, réservés à certains usages bien spécifiques).

 

Dans le cas du QuickApp Unifi disponible sur le market, le type du QA est Binary Sensor. Donc directement en lisant son état (value = true ou false), tu sais si la présence est détectée ou non.

Plusieurs avantages :

- tu vois l'état directement sur l'interface Web / application mobile, sans avoir besoin d'aller interroger une variable globale

- il n'est plus nécessaire de créer et maintenir des VG... donc c'est plus simple

- le changement de valeur du QA est exploitable directement dans tes scénarios => il peut donc être pris comme déclencheur (trigger) d'une scène si tu le souhaites

 

[Domodial]

J'ai saisi en partit. Il faut que j'essaye et que je pense autrement. Mais ce n'est pas facile. 

Modifié le 10 mars 2021 par Domodial

[Domodial]

Je t'ai relu !

Je vais mieux le matin que le soir lol, cependant c'est simple et compliqué à la fois dans le cas d'une migration sur une base repensé.

Pour GEA (merci pour l'immense travail !) j'ai testé juste sur detection d'un sauron > allume un Wallplug (ça fonctionne).

Pour la migration ça va être coton justement avec toutes les variables je ne m'en sort pas. D'ailleurs je ne sais par ou commencer...

Modifié le 11 mars 2021 par Domodial

[Lazer]

En effet, il faut repenser son installation.

La migration est aussi l'occasion de revoir tout ce qu'on a fait il y a quelques années, aujourd'hui avec la HC3 il y a moyen de faire bien mieux.

Et de toute façon si c'était pour faire comme avant, autant garder son argent, économiser son temps, et rester sur HC2.

 

Tu as de la marge, j'ai acheté ma première HC3 en mai 2020, et je n'ai toujours pas migré.... objectif mai 2021, soit 1 an après. Je profiterai de mon solde de congés et de la fin de la saison de chauffage pour faire ma migration sans risque.

D'ici là ça me laisse encore un peu de temps pour préparer mes nouveaux QuickApps.

[Dragoniacs]

En regardant un autre sujet sur les intervals de réveil des modules, je me suis souvenue qu'on a un VD qui permet de vérifier et corriger régulièrement lrs intervalles automatiquement.

Un volontaire pour en faire un QA ?

 

Envoyé de mon RMX1993 en utilisant Tapatalk

 

 

 

 

[jjacques68]

ah punaise !! j'avais écrit un bout de code qui mettait tous les délai au max...

J'avais renseigner pas mal de type de device différent car les intervalles changent d'une marque à l'autre...

Je l'ai plus dans la HC3, par contre je dois toujours avoir le code source en HC2...

Faudrait que j'arrive à remettre la mains dessus...

[jjacques68]

héhé, retrouvé, voilà ma petite liste : 

  {type = "com.fibaro.doorSensor",       zwaveCompany = "Fibargroup",                 maxTime = 64800}
  {type = "com.fibaro.FGMS001v2",        zwaveCompany = "Fibargroup",                 maxTime = 65535}
  {type = "com.fibaro.FGFS101",          zwaveCompany = "Fibargroup",                 maxTime = 86399}
  {type = "com.fibaro.thermostatDanfoss",zwaveCompany = "Danfoss",                    maxTime = 600} --temps personalisé
  {type = "com.fibaro.FGMS001",          zwaveCompany = "Fibargroup",                 maxTime = 65535}
  {type = "com.fibaro.temperatureSensor",zwaveCompany = "Horstmann Controls Limited", maxTime = 86400}
  {type = "com.fibaro.temperatureSensor",zwaveCompany = "Everspring",                 maxTime = 16056000}
  {type = "com.fibaro.lightSensor",      zwaveCompany = "Everspring",                 maxTime = 14400000}
  {type = "com.fibaro.motionSensor",     zwaveCompany = "Philio Technology Corp",     maxTime = 432000}

bon maintenant faudrait se motiver à (re)faire le script...

Modifié le 11 mars 2021 par jjacques68

[Dragoniacs]

C'est exactement ça !
Très pratique quand on va transférer nos modules dans la HC3

Envoyé de mon RMX1993 en utilisant Tapatalk

[jjacques68]

Bon je m'y colle, (mais modestement hein )

Je partage quand fini (demain normalement)

 

J'ai déjà découvert des surprises... 

[jjacques68]

ben voilà la version 1, ça reste simple on est d'accord  

 

 

 

[Lazer]

Voilà, encore un petit QuickApp terminé

 

 

 

[Bebitoo]

@Lazer,

 

Tu listes (vous listez ?) en première page, dans la catégorie "à faire" :

Citation

KLF-050 => priorité moyenne, nouveau QA pour intégrer proprement en tant que volet-roulant le module Velux KLF-050 avec un double-switch FGS-222

Je suis fortement et doublement intéressé

- "doublement", parce que j'ai cet exact besoin (1 volet roulant sur un vélux avec un KLF-050 et un double-switch), mais aussi des volets battants motorisés avec également des double-switch,

- "fortement" parce que c'est la fonctionnalité majeure en domotique chez moi : la gestion des volets (5 battants, 2 roulants, et 1 rideau de vélux).

 

J'ai envie de me lancer dans la création de QA ad'hoc, et me demandais si tu pouvais me conseiller en amont - histoire que j'arrive plus rapidement et plus facilement à un bon résultat, et qui serait pour pour toi au moins, je l'espère, une v1. Es-tu d'accord ?

 

Perso, j'en suis à prendre connaissance de la HC3 et des QA, mais par la pratique (autrement dit : je me suis amusé, jusque maintenant, avec ma HC3 toute neuve). Prochaine étape : lire les documentations qui vont bien sur les QA, comprendre le fonctionnement et l'intérêt de QA enfants, et décider si c'est utile dans ce cas (pour la télécommande de centralisation ?).

 

Ce que j'ai aujourd'hui, sous HC2 : des modules virtuels comme celui-ci :

Autrement dit, pour chaque volet battant et pour le rideau du vélux :

- Un bouton Ouvrir (respectivement Fermer) qui fait simplement un call "turnOn" sur l'entrée du double switch qui ouvre (resp. ferme).

- Notez l'icône du VD lui-même : volets ni ouverts ni fermés avec un point d'interrogation par dessus. C'est pour l'init, il n'est affiché qu'au redémarrage de la box, le temps d'ouvrir ou de fermer.

- Et notez l'icône des boutons : volets mi-ouverts mi-fermés.

- Et j'ai également une scène (unique) qui surveille les ouvertures et fermetures de ces volets battants, et (entre autres) change l'icône du VD pour un icône représentant les volets ouverts (respectivement : fermés) à l'ouverture (resp. fermeture).

- Enfin, je cache les doubles switch de l'interface.

 

Au final, j'obtiens :

- Non pas un retour d'état au sens strict du terme, mais une mémorisation de la dernière commande réalisée (ouverture ou fermeture) - ce qui correspond, quasi systématiquement, à la position réelle des volets.

- Une animation assez cool (raison d'être des icônes) : pour des volets ouverts par exemple (l'icône représente les volets ouverts), lorsque je clique le bouton Fermer, l'icône change d'abord pour les volets mi-ouverts mi-fermés (c'est l'icône du bouton) puis par l'icône représentant les volets fermés (une fois que la scène s'est déclenchée) .

 

Ce qu'il manque :

- La possibilité de "typer" ces VD comme des volets, pour bénéficier des avantages inhérents dans les IHM Fibaro : voir en un coup d'oeil si tous les volets sont fermés, pouvoir les ouvrir tous d'un coup, etc. Chose qui devrait être possible avec les QA, n'est-ce pas ?

- Pour le rideau du vélux, un icône (et une mémorisation de la position) qui ne correspond pas toujours avec la réalité, car l'utilisation de la télécommande d'origine ne me mets par à jour l'icône du VD (contrairement à l'usage des boutons des volets battants et roulants). Mais là, c'est lié au montage double switch et KLF-050, rien de mieux n'est possible (sauf erreur).

 

@Lazer, comment vois-tu la conversion en QA de tels VD ?

 

Merci d'avance.

 

---
David
 

Modifié le 24 avril 2021 par Bebitoo

[Lazer]

Sur HC2 j'ai quelque chose qui ressemble à ce que tu as fait : un VD, avec une scène pour le pseudo retour d'état.

 

Pour avoir un retour d'état fiable, j'ai supprimé la télécommande d'origine.

Le contrôle du Velux se fait exclusivement au travers de la domotique, c'est à dire :

- directement depuis la box HC2 (scénario, interface Web, application mobile)

- directement sur le module FGS double-relais, que j'ai installé au mur avec un interrupteur double monté/descente (ce FGS agit directement sur le KLF-050, et également sur la HC2 car il déclenche la scène de mise à jour de l'état)

 

Sur HC3, je n'ai pas encore trop réfléchi...

Évidemment le QA sera typé comme un volet roulant, ça va de soi.

Mais je voudrais éviter une scène à coté du QA, je veux que le QA soit 100% autonome. Cela implique donc l'utilisation de l'API refreshStates dans une boucle infinie, car les QA ne supportent les "triggers" comme les scènes.

Je ne pense pas me lancer dans la gestion des modules enfants, donc ça sera 1 QA = 1 volet.
J'avais prévu de faire ça d'ici fin mai... donc dans 1 mois.

[Bebitoo]

Bonjour,

 

C'est une super idée l'interrupteur branché sur le double relais lui même branché sur le KLF-050 du vélux : c'est aussi pratique que la télécommande (qu'on laisse toujours au même endroit), et les "retours d'état" deviennent fiables. Mais j'ai tout ce petit matériel dans les combles perdus, donc ça demanderait un peu de travail à passer des câbles.

 

Sinon, pour le QA volet, je me suis lancé, et j'ai fais quelque chose de très simpl(ist)e.

 

J'utilise le modèle Fibaro d'un roller shutter. Le Quick App est ainsi listé comme un volet dans les IHM Fibaro (cool), et l'icône est bien mis à jour. Alexa le reconnait, et le rideau obéit aux commandes "Alexa, ouvre/ferme le rideau du vélux". Un retour d'état (ou plus exactement une mémorisation de la dernière commande reçue, ou de la position actuelle du rideau) est facilement réalisable.

 

Par contre je ne gère pas les positions intermédiaires pour le moment (je n'en ai pas besoin, mais il le faut pour que les IHM avec les sliders fonctionnent), et sauf erreur les boutons que j'ai créé... ne servent à rien

 

 

 

-- Roller shutter type should handle actions: open, close, stop
-- To update roller shutter state, update property "value" with integer 0-99

function QuickApp:open()
    fibaro.call(self.openDeviceId, "turnOn");
    fibaro.setTimeout(self.openDelay, function()
        self:debug("roller shutter opened")
        self:updateProperty("value", 99)
    end)
end

function QuickApp:close()
    fibaro.call(self.closeDeviceId, "turnOn");
    fibaro.setTimeout(self.closeDelay, function()
        self:debug("roller shutter closed")
        self:updateProperty("value", 0)
    end)
end

function QuickApp:stop()
    fibaro.call(self.openDeviceId, "turnOff");
    fibaro.call(self.closeDeviceId, "turnOff");
    self:debug("roller shutter stopped ")
end

-- Value is type of integer (0-99)
-- NB : bizaremment, cette méthode elle celle invoquée par Alexa, avec les valeurs :
--  0 sur "Alexa, ferme le rideau du vélux", et
-- 99 sur "Alexa, ouvre le rideau du vélux"
function QuickApp:setValue(value)
    if (value <= 0) then
        self:close()
    elseif (value >= 99) then
        self:open()
    else
        self:debug("roller shutter set to: " .. tostring(value))
        self:updateProperty("value", value)
    end
end

-- To update controls you can use method self:updateView(<component ID>, <component property>, <desired value>). Eg:
-- self:updateView("slider", "value", "55")
-- self:updateView("button1", "text", "MUTE")
-- self:updateView("label", "text", "TURNED ON")

-- This is QuickApp inital method. It is called right after your QuickApp starts (after each save or on gateway startup).
-- Here you can set some default values, setup http connection or get QuickApp variables.
-- To learn more, please visit:
--    * https://manuals.fibaro.com/home-center-3/
--    * https://manuals.fibaro.com/home-center-3-quick-apps/

function QuickApp:onInit()
    self:debug("onInit")
    -- Les id des devices déclenchant l'ouverture et la fermeture du rideau de vélux,
    -- et les délais d'ouverture et fermeture sont des variables de ce Quick App ;
    -- on récupère leur valeurs...
    self.openDeviceId  = tonumber( self:getVariable("openDeviceId" )          )
    self.closeDeviceId = tonumber( self:getVariable("closeDeviceId")          )
    self.openDelay     = tonumber((self:getVariable("openDelay"    ) - 2)*1000)
    self.closeDelay    = tonumber((self:getVariable("closeDelay"   ) - 2)*1000)
end

-- Release Notes
-- 03/05/2021
--  Première version d'un Quik App "rideau vélux"
--  de type Roller Shutter => il apparait bien en tant que volet dans les IHM Fibaro
--  ToDo : gérer les positions intermédiaires ?

 

Modifié le 24 mai 2021 par Bebitoo

[Lazer]

Bien, mais pourquoi avoir créé des boutons supplémentaires ?

 

Un QA de type Roller Shutter aura automatiquement les boutons montée/descente/et stop comme un vrai module Z-Wave dans l'IHM (aussi bien Web que Mobile)

[Bebitoo]

En effet
Et je viens de les enlever.

 

Ce Quick App en l'état est bien pour des ouvertures et fermetures totales, pour éclairer / assombrir la pièce lorsqu'on en ressent le besoin.

 

Mais il reste basique. Le slider ne fonctionne pas (sauf si positionné à 0 ou 100), et il semble mal réagir sur des enchainements de commandes (c'est peut-être à cause des mes setTimeout pour mettre à jour les icônes seulement à la fin des ouvertures/fermetures).

 

J'y reviendrais...

Modifié le 25 mai 2021 par Bebitoo

[Lazer]

Oui surement.

 

Sinon pour le slider, ce que tu peux faire, c'est :

- si 0 alors on ferme complètement le volet

- si > 0 alors on l'ouvre complètement.

ça évitera que le slider soit inactif entre 1 et 98.