Aller au contenu
Barelle

Quick App - HC2 Devices

Recommended Posts

Quick App HC2 Devices

 

 

Contexte

 

Vous avez une HC2 (ou HCL) qui ronronne paisiblement et vous venez d’acquérir une HC3. Vous hésitez sur la stratégie de migration :

  • Le big-bang par Fibaro : tous les dispositifs z-wave seront connectés à la HC3 et vous aurez perdu les scènes et les VD ;
  • Commencer par convertir les VD en QA (en fait, il s’agit pour bien faire les choses d’un redesign complet),
    puis migrer les dispositifs (devices) z-wave soit par exclusion puis inclusion sur la HC3, soit par le big-bang Fibaro, mais en ayant déjà préparé les nouveaux QA et scènes.

 

Ce QA s’adresse donc à ceux qui ont fait ce second choix. Mais les autres aussi peuvent l’essayer…

 

Note : n’en possédant pas, je n’ai pas testé ce QA avec une HCL, mais, en toute logique, cela devrait fonctionner.

 

 

Fonction

 

Ce QA permet de voir sur la HC3, un ensemble de devices (dispositifs) physiques de la HC2. En effet, développer scènes et QA sur une HC3 sans device et parfois un peu gênant.

 

 

Paramétrage lors de l’installation

 

Il est nécessaire de créer pour le QA les variables suivantes :

  • HC2IP : l’adresse IP de la HC2.
  • HC2userPass : <codeutilisateur>:<mot de passe> de la HC2, cet utilisateur devra avoir les droits de modifications sur les devices à voir sur la HC2.

 

Note : après une connexion réussie à la HC2, le QA effacera la variable HC2UserPass  et créera la variable HC2Authorization (soit HC2userPass en base 64).

 

Optionnellement :

  • La variable refreshPeriod permet de modifier la période (en secondes) d’interrogation de la HC2 (par défaut 60 secondes), ce qui parait suffisant pour un emploi en développement, une période trop courte pourra se traduire par une consommation CPU plus conséquente.
  • Une variable iconId permet d’affecter une icône au QA HC2Devices.

 

 

Comme vous le savez bien, il y a sur la HC2 un tas de devices que nous considérons sans intérêt (device master, second relais inutilisé, etc.) le QA ne prend pas en compte que les devices physiques (donc pas les VD) qui en plus :

  • Sont enabled.
  • Sont visibles.
  • Ne sont pas des masters.
  • Qui sont d’un type pris en charge (cf. la table HC2Types pour en avoir la liste), seuls certains ont été testés.
  • Qui sont affectés à une pièce.
  • Qui n’ont pas été explicitement exclus par ajout de leur id dans la table HC2IdExcluded en tête de programme.

 

 

Interface utilisateur

 

HC2Devices-2.jpg.95fdaf5aac406be0f1122326cecac5ff.jpg

  1. Le device de la HC2 en cours.

  2. Affiche le device de la HC2 précédant.

  3. Ajoute le device de la HC2 en cours sur la HC3 (child).

  4. Supprime le device de la HC2 en cours sur la HC3 (child).

  5. Affiche le device de la HC2 suivant.

  6. Affiche dans la fenêtre de log le device en cours.

  7. Affiche dans la fenêtre de log les devices présentes sur la HC3.

  8. Affiche dans la fenêtre de log les devices non présentes dur la HC3.

  9. Affiche dans la fenêtre de log tous les devices de la HC2 connus du QA.

 

 

 

 

 

 

Ajout/suppression sur la HC3 (d’un child reflet d’un device de la HC2)

 

On le sélectionne par son nom et son id à l’aide des boutons (2) et (5), puis par le bouton (3). Pour la suppression, on utilisera le bouton (4).

 

Lors de l’ajout le child sera affecté à une pièce du même nom que celui de la HC2, si elle existe dans la HC3, ou dans une pièce du même nom qui sera créée dans la section de nom "Fibaro HC2".

 

 

Synchronisations HC2/HC3 et HC3/HC2

 

Les changements de valeur des principales propriétés (properties) des devices de la HC2 sont reportés sur les childs de la HC3), lors de chaque rafraîchissement..

 

Les ordres donnés à partir des devices de la HC3 sont transmis à la HC2 (pour les types implémentés). Le retour d'état sera affiché lors du prochain rafraîchissement (60 secondes par défaut).

 

 

Limites

 

Tous les types de devices n’ont pas été testés.

 

Il n’est pas possible de récupérer par le QA les icônes de la HC2.

 

L’utilisateur n’a pas accès à la modification des variables crées par le QA (en version 5.050.13), mais il peut les supprimer ou les modifier par l’API du swagger.

 

Le manque de robustesse de la HC3 qui permet ainsi de tester de manière approfondie le mode de récupération…

 

Des redémarrages aléatoires du QA, sans cause identifiée, heureusement sans impact sur son fonctionnement.

 

La sagesse de Fibaro qui a su conserver une réserve d'améliorations considérable pour les possibilités de personnalisation de l'interface.

 

Les bugs que vous ne manquerez pas de découvrir.

 

Téléchargement

 

HC2_Devices.fqa

 

Modifié par Barelle
Correction HC2userPass et non HC2UserPass.
  • Like 3
  • Thanks 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Super initiative pour ceux qui veulent migrer en douceur

Envoyé de mon BLA-L29 en utilisant Tapatalk

Partager ce message


Lien à poster
Partager sur d’autres sites

Effectivement, on pourrait imaginer une scène côté HC2 qui déclencherait  un refresh du QA quand on a besoin de réactivité ?

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 3 heures, Barelle a dit :

Note : après une connexion réussie à la HC2, le QA effacera la variable HC2UserPass  et créera la variable HC2Authorization (soit HC2userPass en base 64).

J'aime bien cette idée :)

Même si ça n'apporte aucune sécurité, l'encodage en base64 est réversible.

Mais ça évite de se bruler les yeux en voyant son mot de passe en clair.

 

De façon générale, pour la sécurité, je préconise de créer un compte dédié sur la HC2, qui ne sera utilisé que par la HC3, avec les autorisation uniquement sur les devices qui sont pilotés par les QuickApps.

Cela évite d'exposer le mot de passe administrateur, de contrôler finement les droits de chaque utilisateur/appareil se connectant sur la box domotique, et de les révoquer tout aussi simplement, sans perturber le fonctionnement du reste de l'infrastructure.

 

il y a 49 minutes, Dgille a dit :

Effectivement, on pourrait imaginer une scène côté HC2 qui déclencherait  un refresh du QA quand on a besoin de réactivité ?

Oui tout à fait, avec des triggers sur la scène, et un code LUA tout simple qui appelle l'API de la HC3 pour faire le setValue directement sur chaque QuickApp.

 

En fait, cela revient à recréer manuellement le mode Passerelle qui n'existe pas (encore)

Partager ce message


Lien à poster
Partager sur d’autres sites

Éxcellent QA !! 

MERCI 

Toujours sans HC3 :-)

 

je vais vraiment avoir du retard :-)

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Quelle bonne idée ! Je vais essayer d'installer ça :)

Envoyé de mon RMX1993 en utilisant Tapatalk

Partager ce message


Lien à poster
Partager sur d’autres sites

Super QA bravo.

Sinon pour ceux qui comme moi qui ont jute quelques modules sur une HCL/HC2 au bout du jardin je vous invite aussi à regarder par là: https://forum.fibaro.com/files/file/391-slaves-for-hc3/
là le refresh est instantané.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Excellent et effectivement d'une grande aide pour la migration par étapes.

 

Une petite remarque, une des 2 variable à ajouter ce nomme HC2userPass et non HC2UserPass 

Partager ce message


Lien à poster
Partager sur d’autres sites

×