Aller au contenu
Krikroff

Gestion des appareils enfants

Recommended Posts

hello !

 

Autre question concernant l'initialisation à la création des QA child :

 

en effet on leur donne leur type avec :

local child = self:createChildDevice({
    name = "toto",
    type = "com.fibaro.binarySwitch",
  }, _MyClass)

Mas par défaut il les déclare en "Light" (avec tout ce qui va avec : propriété isLight = true ; interfaces = ["lights", "quickAppChild"] ; categories = ["light"])

 

et si on veut mettre autre chose !! sans avoir à se taper tous les child à la main !!

 

attention au jeux de mots : "Rôle" = "interface"...

 

image.png.f3ed69975d21f644966330af3b67b92a.png

 

J'ai trouvé comment faire pour l'icone et la catégorie : 

 

dans le code d'init du child

function MyClass:__init(device)

  QuickAppChild.__init(self, device) 
  self:trace(string.format("[%s] %s - init" , self.id, self.name))

  self:updateProperty("deviceIcon", 1011)
  self:updateProperty("isLight", false)
  self:updateProperty("categories", {"other"})    
end

 

y a juste besoin de le faire la première fois.

On peut laisser le code, mais il ne sera plus utile.

 

remarque

J'ai pensé du coup à le glisser dans la fonction de création du child, mais il le prend pas en compte :

local child = self:createChildDevice({
  name = "toto",
  type = "com.fibaro.binarySwitch",
    
  deviceIcon = 1011, 
  isLight = false, 
  categories = {"other"},
}, _MyClass)

fin remarque.

 

 

mais pour le rôle (donc interface), pas moyen d'y arriver, j'ai du me les faire à la main ! :( 

le problème est que le rôle ne fait pas partie de la section "propriété" dans l'API.

 

donc j'ai essayé la bonne vieille méthode du api get/put, sans succès :

local MyApi = api.get("/devices/"..self.id)

MyApi.interfaces = {"quickAppChild"}

res = api.put("/devices/"..self.id, MyApi)

pas de message d'erreur, mais pas de modifications dans l'API...

 

qqun a une idée ??

 

ou je fais complètement fausse route !?

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites
self:createChildDevice({
        name = <name>,
        type=<type>,
        initialProperties = ....
        initialInterfaces = ...
      },
      <Class>
    )

 

  • Like 2

Partager ce message


Lien à poster
Partager sur d’autres sites

yes super !!

 

OK for the properties, but not for Interfaces : 

self:createChildDevice({
        name = "toto",
        type = "com.fibaro.binarySwitch",
        initialProperties = {
            deviceIcon = 1011,
            isLight = false,
            categories = {"other"},
        },
        initialInterfaces = {"quickAppChild"},
    }, MyClass)

 

It still set interfaces with "lights" and "quickAppChild"...

I try with :

initialInterfaces = {}

but same result...

Modifié par jjacques68

Partager ce message


Lien à poster
Partager sur d’autres sites

C'est surprenant, d'autant plus que Toto c'est pas une lumière :94:

  • Like 2

Partager ce message


Lien à poster
Partager sur d’autres sites

self:createChildDevice always add "quickAppChild" for you.

Some types of device will also add their specific interfaces.

Partager ce message


Lien à poster
Partager sur d’autres sites

Ok with "quickAppchild" as default. I understand this type.

But the type "lights" is added too.

I would like to delete the others types.

Just to keep "quickAppchild".

Partager ce message


Lien à poster
Partager sur d’autres sites

self:deleteInterfaces({"light"})

or myQuickApp:deleteInterfaces({"light"})

  • Thanks 1

Partager ce message


Lien à poster
Partager sur d’autres sites

YEESSSS ! 

 

it works fine !

Now I juste have "quickAppChild" in interfaces.

 

but there is a bug with the IHM

 

"light" is still display...

image.png.1034b3d31d67ab337ade3528509c6372.png

 

while in the API it's ok :

 

image.png.ff8c5380098ce54a35c60bc715d5c9a5.png

 

 

all these functions/possibilities are not explain in the manual of Fibaro... :( 

 

Once again, thank you !!!!

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 17/08/2020 à 15:27, jjacques68 a dit :

"light" is still display...

image.png.1034b3d31d67ab337ade3528509c6372.png

Ce n'est pas un bug, en fait l'interface Web se base sur la property deviceControlType qui a toujours la valeur 2 dans le JSON du device, et qui correspond au type Lumière.

 

=> Il faut injecter deviceControlType = 20 dans les properties du Child Device au moment de sa création pour qu'il prenne bien le rôle "Autre appareil" :

 

image.png.e94f5eb530e2dd837b0128d629f61d6c.png

 

 

Je récapitule :

  • Créer le device enfant avec les initialProperties suivantes :
    • deviceControlType = 20,

    • categories = {"other"},

  • Supprimer l'interface suivante :
    • "light"

Exemple de code abrégé :

local child = self:createChildDevice({
		name   = "Mon enfant",
		type   = "com.fibaro.binarySwitch",
		initialProperties = {
			deviceControlType = 20,
			categories = {"other"},
		},
	},
	childClass
)
if child then
	chiild:deleteInterfaces({"light"})
end

 

 

Pour info voici les valeurs de la propriété deviceControlType que j'ai pu identifier pour le type de device Commutateur binaire / Binary switch "com.fibaro.binarySwitch" :

2 Lumière
3 Arroseur
4 PIN
5 Lampe de chevet
6 Bouilloire
7 Applique murale
8 Climatisation
9 Alarme - violation
10 Machine à café
11 Lampe de jardin
12 TV
13 Ventilateur de plafond
14 Grille-pain
15 Radio
17 Fenêtre de toit
20 Autre appareil
21 Etat d'alarme (armé / désarmé)
22 Alarme - Armement
24 Interphone vidéo
25 Ouverture du portail vidéo

On remarque qu'il y a plusieurs types de lumières/lampes qui rétablissent automatiquement la propriété isLight = true.

 

  • Upvote 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Dans un Quick App en cours de construction, j'ai un comportement curieux que je ne m'explique pas.

 

Dans ce QuickApp, j'ai un Child de type "com.fibaro.doorLock" auquel est associé des actions de type "secure" et "unsecure". Ces actions (changement de value) fonctionnent très bien lors de la première exécution qui crée le Child (après la sauvegarde de la Quick App). J'obtient les messages suivants dans les logs :

onAction: {"actionName":"secure","args":[223,"secure"],"deviceId":223}

QuickApp:action("Secure", "Relay_1_Portail", table[2])

Mais si j'effectue des modifications de la QuickApp et dès lors que j'effectue sa sauvegarde, les actions "secure" et "unsecure" ne fonctionnent plus, j'obtient les messages suivants dans les logs :

onAction: {"actionName":"secure","args":[223,"secure"],"deviceId":223}

"Class does not have secure function defined - action ignored"

Pour refaire fonctionner ce Child, je suis obligé de supprimer le Child et relancer mon QuickApp qui recréer le Child. 

 

Auriez-vous une idée de la cause de ce problème et comment y remédier ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Je pense que tu associes la mauvaise classe à ton child lors de l'initialisation au début de la fonction onInit() du device parent.

Partager ce message


Lien à poster
Partager sur d’autres sites

J'ai mis ça :

 

----------------------------------------------------------------------------------------------------
-- QuickApp Child device - MyChild 
----------------------------------------------------------------------------------------------------

class 'MyChild' (QuickAppChild)

--
-- Constructor
--
function MyChild:__init(device)
	QuickAppChild.__init(self, device)
	tools.log(self, "", 0)
end

 

Partager ce message


Lien à poster
Partager sur d’autres sites

ça OK, mais faut que tu associes ta classe MyChild à tes modules enfants maintenant. Ce que tu dois faire dans onInit()


Regarde le log, tu dois voir un message d'avertissement si tu as oublié de le faire.

 

EDIT : avec self:initChildDevices() comme indiqué dans la doc, chapitre "Initializing child devices on Quick App startup" : https://manuals.fibaro.com/knowledge-base-browse/hc3-quick-apps-managing-child-devices/

 

C'est d'ailleurs surprenant que Fibaro nous laisse créer un Child avec une Classe donnée, puis en changer plus tard lors des redémarrage ultérieurs du QuickApp dans le onInit().

Bon l'avantage c'est que ça permet de faire évoluer son code dans détruire/recréer les children.

 

Modifié par Lazer

Partager ce message


Lien à poster
Partager sur d’autres sites

Je l'ai fait il me semble, j'ai mis ça :

 

                    local ChildDevice = {
                        name =                  Device.name,
                        type =                  Device.type,
                        class = MyChild,
                        properties = {
                            deviceControlType = Child.properties.deviceControlType,
                            categories =        Child.properties.categories,
                            manufacturer =      Child.properties.manufacturer,
                            model =             Child.properties.model,
                            value =             Device.defaultValue,
                        },
                        variables = {
                            {name =             "ID",
                            value =             Device.name},
                        },
                    }
                    if not tools.createChild(self, ChildDevice) then
                        self:error("Error : Automatic child device(s) creation failed")
                    end

Partager ce message


Lien à poster
Partager sur d’autres sites

Oui mais non, tu confonds la création du child, et ses initialisations ultérieures

 

relis mon message précédent, j'ai édité.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Faut-il mettre autant de lignes qu'il y a de type ?

 

ou est-ce qu'il faut autant de MyChild qu'il y a de Type différents ?

 

	-- Setup classes for child devices
	self:initChildDevices({
		["com.fibaro.binarySwitch"] = MyChild,
		["com.fibaro.doorLock"] = MyChild,
		["com.fibaro.motionSensor"] = MyChild,
	})

 

Partager ce message


Lien à poster
Partager sur d’autres sites

"autant de lignes qu'il y a de type"

 

Sachant que plusieurs types peuvent utiliser la même classe.

Une autre façon de le dire : une seule classe peut gérer plusieurs types différents

 

Exemple valide avec 2 classes différentes :

	self:initChildDevices({
		["com.fibaro.binarySensor"] = MyInput,
		["com.fibaro.motionSensor"] = MyInput,
		["com.fibaro.doorSensor"] = MyInput,
		["com.fibaro.windowSensor"] = MyInput,
		["com.fibaro.gateSensor"] = MyInput,
		["com.fibaro.rainDetector"] = MyInput,
		["com.fibaro.temperatureSensor"] = MyInput,
		["com.fibaro.humiditySensor"] = MyInput,
		["com.fibaro.lightSensor"] = MyInput,
		["com.fibaro.multilevelSensor"] = MyInput,
		["com.fibaro.powerSensor"] = MyInput,
		["com.fibaro.binarySwitch"] = MyDigitalOutput,
	})

 

Modifié par Lazer

Partager ce message


Lien à poster
Partager sur d’autres sites

Merci pour les précisions :60:

 

Où puis-je trouver la liste différents type de devices disponibles sur la HC3. Je cherche notamment un type de type sonnette (Doorbell). Ca doit bien exister puisqu'il existe des sonnettes Z-wave.

Partager ce message


Lien à poster
Partager sur d’autres sites

MErci, mais il n'y a rien de spécifique pour une sonnette :(

Partager ce message


Lien à poster
Partager sur d’autres sites

binarySwitch ou binarySensor. Lequel est plus logique ?

 

Mais je pense effectivement plus à un binarySensor puisque l'état On est furtif.

Partager ce message


Lien à poster
Partager sur d’autres sites

Un Sensor c'est un capteur

Un Switch c'est un actionneur

 

Pour pour remonter le statut de la sonnette, sans aucune hésitation il faut un binarysensor

C'est déjà comme ça sur HC2, y'a pas de raison de faire différemment sur HC3.

(j'utilise un vrai module, un Fibaro Universel FGBS)

Partager ce message


Lien à poster
Partager sur d’autres sites

×