newbee to HC3, probleme avec les VDs et Scenes

[ygi 0]

Bonsoir le groupe,

 

Me voila avec une HC3, apres 10 ans avec une HC2.  J'ai reussi a migrer mon backup.. et j'ai eu de la chance car mon HC2 ne redemarre plus..

Je me retrouve donc sans VD et sans scene .. bien que je trouvais dommage que sur la HC2, les scenes n'etaient pas trigerees.. j'avoue me retrouver un peu perplexe a la nouvelle plylosophie.

 

 - pour les scenes, je n'arrive pas a trouver ni en block, ni en lua, comme trigerer un changement d'etat sur un relais par exemple, je peux trigerer une valeur 1 ou 0.  J'ai un crepusculaire connecté sur un relais FGS,  en fonction, allume ou eteint des lampes...  Comment faut il faire pour le trigger d'un changement d'etat ?

 - j'ai converti mon ex VD en QA.. cette derniere est un player multimedia et ouvrait un socketTCP et envoyait des commandes en fonctions des boutons, et envoyait regulierement des demandes de status pour l'afficher.  le programme principal attend sur le read, alors que les boutons envoit les commandes.  mais je voudrais un timer qui envoit la commande a une certaine frequence.. or on dirait que le QA n'est pas multithread, alors que l'interface avec les boutons est capable d'envoyer des commandes...  Comment faire ? j'ai mis un timeout sur le read, mais helas, il me revoit une erreur commune, identique a celle ou le server se deconnecte.. et je ne veux pas rentrer dans la retry policy de reconnection... comment faire ? une idee ?

 

yves

 

[Lazer 8 497]

Pour les scènes, voir la doc officielle pour écrire les conditions (trigger) de déclenchement des scènes, effectivement c'est très différent de la HC2 :

https://manuals.fibaro.com/home-center-3-lua-scenes/

 

Pour les QuickApps, c'est beaucoup plus compliqué que ça...

Effectivement, ils ne sont pas multithreads (pas plus que les VD), mais plusieurs requêtes sont asynchrones (et ça c'est nouveau), donc un fonctionnement très différent.

J'ai écris un mini-tuto pour la gestion des retours asynchrones d'une requête HTTP :

 

 

Pour du TCP c'est le même principe, mais encore plus compliqué, car il faut enchainer les appels de fonctions asynchrones : connecte, write, read, close...

Il y a quelques exemples de QA utilisant ce principe sur le forum. Il me vient à l'esprit les QA onduleurs Eaton et APsystems que tu retrouveras facilement. Si ça peut t'aider...

 

[ygi 0]

Hello, 

 

Merci ces infos..

oui la philosophie sur les VD et scene sur la HC2 etait monothread; d'ailleures, la scene tournait sans cesse, il fallait gerer les verification de changement d'etat pour poursuive la tache.. maintenant que c'est un trigger, c'est top.. mais meme si le thread principal d'une scene ou d'une QA est bloquante, les boutons exterieures sont asynchrones.. ce qui est troublant quon ne puisse pas faire du multithread. en HC2, pour chaque bouton appuyé, j'ouvrais la socket, Write, Read, Close.. avev un polling de 5 sec dans le main pour lire les status.. je voulais eviter la creation et la connection intempestive en HC3, mais je n'y arrive pas.... j'ai essaye avec le HTTPClient, WebSocket et WebSocketTls.. mais rien n'y fait, cela ne fonctionne pas.. c'est une simple conexion TCP client a un TCP server que je dois faire.. je n'ai pas le choix de refaire la conexion et de la fermer pour chaque commande.

 

 

Autre chose, @lazer, comme tu es une reference sur ce site.. j'ai une QA pour les panneaux d'energie que je modifie pour moi.. dans les datas, j'ai l'information de savoir quel compteur est active (bi-horaire) que je voudrait afficher

 

- Ou trouve t on les types de devices disponibles, genre "com.fibaro.binarySensor"  ? car je voudrai faire un pannel qui affiche HC ou HP avec lequel il n'est pas possible d'interagir.. en ce moment il est declare comme PowerMeter mais il apparait dans la pannel d'energie. Quel serait le plus adequat d'apres toi ?

 

merci de ton aide.. 

 

bien à toi

 

yves

 

[Lazer 8 497]

Ne raisonne pas multithread, car que ça soit VD/Scene/QA sur HC2 ou HC3, ça ne change rien, il n'y a jamais eu de multithread.

Sur HC2 quand tu cliquais sur un bouton ça déclenchait carrément un nouveau processus au niveau de l'OS, et ça explique d'ailleurs pourquoi on n'a jamais pu échanger d'information entre la Main Loop et les boutons d'un même VD : processus étanches, mémoire cloisonnée.

 

Bref, dans un QA, tu as un seul process monothreadé.

A toi de gérer "intelligemment" le temps afin de laisser la possibilité aux appels asynchrones de pouvoir s'exécuter.
Et pour cela... il faut rendre la main au système.

Chaque chaque appel de bouton, retour d'une fonction http, tcp, timeout etc ne sont que des appels asynchrones.

En conséquence, tu dois bannir toute commande sleep() qui bloque le thread. Bon à la limite on peut s'autoriser un tout petit sleep de quelques millisecondes voire secondes, mais jamais au delà.

Donc tu dois écrire l'équivalent de la Main loop des VD à la main avec du code LUA qui s'appelle lui-même en asynchrone avec une commande setTimeout()

Pendant ce temps, ça permettra aux autres appels asynchrones (boutons, retours de requêtes http/tcp etc) de pouvoir s'exécuter.

C'est une gymnastique qui n'est vraiment pas simple au début... mais terriblement puissance quand on a compris le truc, car ça permet de faire un faux multi-thread en quelque sort, mais sans les difficultés induites par le vrai multi-thread (je pense notamment à la gestion des Mutex)

 

Pour ton autre question, je gère la gestion des compteurs différemment avec mon QA EDRT2, surtout qu'il ne faut pas te limiter à 2 tarifs horaires... penses à TEMPO et ses 6 tarifs ! Et c'est rien à coté de ce que nous réserve l'avenir (les tarifs qui varient plusieurs fois dans la journée...)

Donc dans la HC3, je stocke le nom du tarif en cours (BASE, HC, HP, HPJB, HCJB, etc...) dans une variable globale, tout simplement, car un module de type binarySensor ne convient pas.

Et j'ai un seul module de type energyMetter qui porte la somme des index des différents tarifs horaires.

En alternative, tu peux imaginer avoir un module energyMetter pour chaque compteur remonté par le Linky (jusqu'à 6 en Tempo donc), chacun s'incrémentant à tout de rôle selon la tranche horaire.

[ygi 0]

hello lazer,

Oui effectivement, c'est pas evident de retourner vers une reflexion STA alors que j'ai l'habitude du MTA, je suis developpeur depuis 30 dans le milieu industriel, je jongle avec les process asynchrones avec object d'intersynchronisation.

 

Mais il y a une difference avec la HC3, que j'ai remarquee.. mon process etait bloqué en lecture sur le socket, et mes fonctions trigers sur les boutons se passent correctement, donc l'os ne peut creer qu'un thread pour l'execution de celles ci.. sinon, je serai bloqué et la pompe a message ne pourrait pas fonctionner.

Par contre, je suis perdu pour le SocketTCP, je n'ai pas reussi a l'utiliser en asynchrone, et tu as confirmer dans un message precendant que pas trop le choix de faire OPEN,WRITE/READ, CLOSE.. or dans le precedent tu le site dans les objets asynchrones  "aux autres appels asynchrones (boutons, retours de requêtes http/tcp etc)". Qu'en est il ?

 

J'ai aussi un EDRT2, je n'ai pas encore intégré. si tu as un bon QA pour celui la et que tu veux bien partagé .  Je suis en Blelgique et il n'y a pas plusieurs tarifs horaire, a ma connaissance, soit HeurePleine, soit HeureCreuse, et je n'ai aucun moyen de communiquer a mon EDRT2 le changement effectif.  Depuis un an, j'ai un SmartCompteur, sur lequel on peut communiquer via le port P1 en RS485 me semble t il, mais une societe neerlandais a creer un module wifi ; HomeWiazrd P1, par lequel on peut aller lire les infos du compteur.  En ce moment j'ia un QA connecté a celui-ci, et c'est la que j'essaie d'avoir l'information de quel tarif horaire est actif et l'afficher.. et surtout trigerer un event au changement.. ce qui ne fonctionne absolument pas

 

As tu trouvé une documentation concernant les differents types d'objet que la HC3 nous fournit ? genre BinarySensor, EnergyMeter, etc...

 

yves

[Lazer 8 497]

Je ne comprends pas bien ta question concernant les appels asynchrones des boutons / TCP.

Je t'ai indiqué plus haut quelques noms de QA qui utilisent les requêtes TCP, tu peux regarder sur le forum... ou dans la doc Fibaro car il y a un exemple : https://manuals.fibaro.com/home-center-3-quick-apps/

 

Idem, mon QA EDRT2 est déjà partagé sur le forum et prêt à l'emploi.

 

Pour les types de modules :

/api/quickApp/availableTypes
/api/devices/hierarchy

Et en complément, sur le forum officiel, @tinman a fait un gros travail d'identification des interfaces, propriétés, etc, présents sur les QA en fonction de leur type :

https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/58/#comment-227370

 

[ygi 0]

Merci pour toute ces infos...

 

Ce n'etait pas une question mais une constation concernant les evenements asynchrones des boutons...  ils sont fonctionnels et realisent leurd taches, dans mon cas, une communication avec la socket TCP deja ouverte lors de l'init, alors que le thread principal est bloqué sur la lecture du socket.

 

belle journee

Modifié 13 octobre 2023 par ygi

[Lazer 8 497]

En fait une lecture TCP ne doit pas rester en attente, sinon effectivement vu vas bloquer le thread (et donc les boutons et autres traitements)

La logique, c'est d'ouvrir la socket, puis de faire des enchainements de write suivis de read.
Normalement si tu fais ton read juste après ton write, tu vas recevoir la réponse de l'équipement en face, et donc le read va rendre la main au bouts de quelques millisecondes, ainsi le thread ne sera pas resté bloqué longtemps.
Ce que tu ne fois pas faire, c'est lancer des read en aveugle, en attente infinie d'octets envoyés par l'équipement, car dans ce cas tu te retrouves dans des situations de blocage.

 

Si vraiment ton programme ne peut pas faire des séquences de write/read, mais que tu doit attendre en "aveugle" des octets en maintenant un read, je te suggères ceci : définir un timeout très court, par exemple de 1s

Alors si le read n'a rien reçu au bout de 1s, il va tomber en timeout, tu gères l'erreur pour relancer un read, etc en boucle...

C'est pas hyper propre, mais ça devrait fonctionner.

 

Ce qui manque pour pouvoir travailler proprement, ça serait de pouvoir définir une fonction de callback sur octets reçus par la socket, mais ça n'est pas possible avec la librairie mise à disposition par Fibaro.

(en revanche ça l'est pour la librairie de gestion des WebSockets avec les Event Listenners)