base de connaissances Gestion des appareils enfants

[jjacques68]

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"...

 

 

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 !?

 

 

[jang]

self:createChildDevice({
        name = <name>,
        type=<type>,
        initialProperties = ....
        initialInterfaces = ...
      },
      <Class>
    )

 

[jjacques68]

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é le 17 août 2020 par jjacques68

[Lazer]

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

[jjacques68]

@Lazer  

[jang]

self:createChildDevice always add "quickAppChild" for you.

Some types of device will also add their specific interfaces.

[jjacques68]

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".

[jang]

self:deleteInterfaces({"light"})

or myQuickApp:deleteInterfaces({"light"})

[jjacques68]

YEESSSS ! 

 

it works fine !

Now I juste have "quickAppChild" in interfaces.

 

but there is a bug with the IHM : 

 

"light" is still display...

 

while in the API it's ok :

 

 

 

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

 

Once again, thank you !!!!

[Lazer]

Le 17/08/2020 à 15:27, jjacques68 a dit :

"light" is still display...

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" :

 

 

 

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.

 

[jjacques68]

ah ça c'est top, merci pour l'info !!!

[MAM78]

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 ?

[Lazer]

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

[MAM78]

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

 

[Lazer]

ç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é le 13 décembre 2020 par Lazer

[MAM78]

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

[Lazer]

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

 

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

 

[MAM78]

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,
	})

 

[Lazer]

"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é le 13 décembre 2020 par Lazer

[MAM78]

Merci pour les précisions 

 

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.

[Lazer]

/api/quickApp/availableTypes

[MAM78]

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

[Lazer]

Binarysensor tout simplement

[MAM78]

binarySwitch ou binarySensor. Lequel est plus logique ?

 

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

[Lazer]

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)