Aller au contenu

Quick App - Gestionnaire d'Événements Automatique - GEA pour HC3


Lazer

Recommended Posts

Pourquoi tu en as deux ?
Parce que je trouve plus simple de séparer 2 groupes de fonction.
J’ai un GEA global qui gère plein d’automatisations diverses pour la vie de tout les jours : robots aspi, lumières, volets le soir, arrosage,...
Et un GEA dedié au chauffage et climatisation, en fonction du profil activé, de la saison, ...


Envoyé de mon SM-T870 en utilisant Tapatalk

  • Like 1
Lien vers le commentaire
Partager sur d’autres sites

  • 1 month later...

Bonsoir,

 

Je me permets un petit message ici pour un retour d'expérience G.E.A. 

Lors de la programmation du volet pour ma fille j'ai malencontreusement inscrit ceci: 

GEA.add({{"Profile",1},{"Time","19:00t"} },30,"",{"Close", id["VOLET_LYANA"]})

Evidement, le "t" est de trop et il s'agit vraisemblablement d'une erreur d'appuis de touche lors de la rédaction. Bref... 

Ceci a eu pour conséquence de bloquer le loop de G.E.A sans inscrire l'erreur dans la console. 

 

Après une longue recherche de pourquoi j'avais rien dans la console et pas de loop j'ai trouvé cette erreur puis tout a refonctionné correctement. 

 

Est-il possible d'ajouter ce type d'erreur dans la console? 

 

Merci à vous ! ;) 

Lien vers le commentaire
Partager sur d’autres sites

@triossrf, ton problème fait furieusement penser à celui que j'avais remonté ici :

 

Je l'au "réglé" avec ... une règle GEA.

 

En toute fin de script GEA, je m'envoie un mail "keep alive" .

Ainsi, si je ne reçoit rien à 00:00 ou 12:00, je sais que je dois regarder

Lien vers le commentaire
Partager sur d’autres sites

Vos 2 problèmes n'ont rien à voir en fait.
Mais dans les 2 cas, ça débouche sur le même comportement : le plantage de GEA. C'est le seul point commun.

M'enfin je suis sûr qu'on pourrait encore trouver 1000 façons différentes de faire planter GEA !

  • Haha 1
Lien vers le commentaire
Partager sur d’autres sites

  • 3 months later...

Bonjour,

Je remonte ici 2 bugs avérés et la solution.

Les actions (je n'ai pas testé les condition) pour les fonctions 'Property" et "DeviceIcon" ne font rien.

Les explications détaillées sont ici :

 

Pour l'action "Property":

Le code original (ligne 420) est :

fibaro.call(id_num, "updateProperty", property, self:getMessage(self:incdec(value, self.options.property.getValue(id_num, property))))

et s'il est remplacé par

fibaro.call(id_num, "setProperty", property, self:getMessage(self:incdec(value, self.options.property.getValue(id_num, property))))

ok !

Pour l'action "DeviceIcon"

Le code original (ligne 769) est :

action   = function(id, value) if type(id) ~= "table" then id = {id} end for i=1, #id do local id_num = self:findDeviceId(id[i]) self.cachedDeviceProperties[id_num] = {} fibaro.call(id_num, "updateProperty", "deviceIcon", tonumber(value)) end end,

et s'il est remplacé par

action   = function(id, value) if type(id) ~= "table" then id = {id} end for i=1, #id do local id_num = self:findDeviceId(id[i]) self.cachedDeviceProperties[id_num] = {} fibaro.call(id_num, "setProperty", "deviceIcon", tonumber(value)) end end,

ok !

 

Je n'ai pas fait la modif pour l'option "CurrentIcon" car elle est une copie de l'action "DeviceIcon".

Merci à @jluc2808 de m'avoir mis sur la piste.

C'est la première fois que je vais dans le code de GEA : qu'il est propre malgré sa complexité

  • Like 1
Lien vers le commentaire
Partager sur d’autres sites

Merci @jojo et bravo pour le travail :)

 

Comme je le disais sur l'autre topic, je suis certain que ça fonctionnait avant car j'ai encore mon fichier des règles de GEA que j'ai testé avant partage sur le forum, ainsi que tout un tas d'URL de la forme suivante que j'ai utilisé dans mes tests pour forcer les propriétés de tel ou tel device directement à l'aide de la fonction updateProperty() depuis le navigateur web :

/api/callAction?deviceID=100&name=updateProperty&arg1=value&arg2=true
/api/callAction?deviceID=101&name=updateProperty&arg1=value&arg2=false
/api/callAction?deviceID=102&name=updateProperty&arg1=value&arg2=0
/api/callAction?deviceID=103&name=updateProperty&arg1=dead&arg2=false

 

Je pense donc qu'on est face à une modification non documentée de l'API de la part de Fibaro.

 

Lien vers le commentaire
Partager sur d’autres sites

Il faudrait poser la question sur le forum officiel pour tirer cette histoire au clair, est-ce que c'est un changement voulu ou non, est-ce que ça s'applique aux QA ou aux autres modules, etc.
Pas eu le temps de faire des tests/recherches de mon coté, mais tout cela semble bien flou pour l'instant.

Lien vers le commentaire
Partager sur d’autres sites

Il y a 6 heures, Lazer a dit :

est-ce que ça s'applique aux QA ou aux autres modules

je n'ai pas compris ce que tu voulais dire.

Donc voici ma question :

API change ? (updatePtoperty -> setProperty) - Home Center 3 - Smart Home Forum by FIBARO

Lien vers le commentaire
Partager sur d’autres sites

à l’instant, jojo a dit :

je n'ai pas compris ce que tu voulais dire. 

Et bien, avant si on utilisait updateProperty pour tous les modules, d'après tes tests maintenant c'est setProperty pour les modules Z-Wave, et updateProperty (comme avant donc) pour les QA.

 

 

Lien vers le commentaire
Partager sur d’autres sites

j'ai édité ma question avec tes explications.

 

N.B. j'ai dit que self:updateProperty() continuait de fonctionner dans mes QA. Je dois encore tester si self:setProperty fonctionne également.

Lien vers le commentaire
Partager sur d’autres sites

il y a 15 minutes, Lazer a dit :

Sinon ton profil n'est pas à jour ;)

je sais j'ai essyé hier, mais je ne me souviens plus le chemin pour le faire ...

 

Ceci dit, je suis bien en 5.150.18, mais comme c'est la première fois que je voulais utiliser cette fonctionnalité dans GEA, donc pas d'info possible sur      la version d'apparition du changement

Lien vers le commentaire
Partager sur d’autres sites

×
×
  • Créer...