[General] Question push & pull


#1

Bonjour,

Je me posais la question de savoir comment Constellation gèrent le rafraîchissement des données ?

Par exemple pour le package tu vas chercher les données tous les x minutes, ok.

Mais par exemple pour ta Vera, tu regardes toutes les x secondes si un équipement à changé d’état ? Cela n’engendre t’il pas une forte consommation de puissance ?

Ne serait-il pas possible pour certain équipement de faire du push vers Constellation ? Je crois que tes modules esp8266 fonctionne d’ailleurs de cette manière ?

Par exemple j’aimerais faire un package Logitech Media Server, mais pour éviter d’interroger le LMS toutes les x secondes j’aimerais que ça soit lui qui le fasse quand il y a un changement.

Merci pour tes éclairements :slight_smile:


#2

Bonjour Hydro,

Excellente question :slight_smile: Tu as bien cerné les différentes possibilités !

Dans le cas d’un package Constellation (Python ou .NET) a toi de voir quelle est la meilleur façon de faire. Quelques exemples :

  • “HWMonitor” : interrogation des compteurs WMI toutes les x ms pour Push vers Constellation (interval à config dans les settings)
  • WindowsControl : qui push l’état de la session Windows (session locké ou non) Push dès que l’état change (event sur le changement d’état au niveau de l’API WIndows)
  • Nest : Push dès qu’un device Nest changent via l’API REST Streaming de Nest (le code est sur mon github pour l’exemple)
  • Vera : la Vera est l’une des rares box Z-Wave a avoir une API REST en “long polling”, ainsi la requete est bloquée tant qu’il n’y a pas de modification! De ce fait, je push seulement les devices qui ont bougé sans devoir faire des requêtes en rafale
  • Hue : par contre là, pas de possibilité de savoir si ca a changé : je suis obligé d’interroger toutes les secondes (bien que l’interval soit configurable dans les settings) l’API Hue pour push l’état des lampes !

Il faut donc “faire au mieux” pour concilier le besoin d’une donnée la plus fraîche possible (quel réactivité veut-on ?) versus les performances !
Dans le cas d’un service comme Nest ou Vera, les deux permettent cela, mais pas sur le Hue ! Mais comme je veux connaitre l’état de chaque lampe Hue en “pseudo temps reel” je suis obligé d’interroger constamment le service même si “c’est pas propre” !

Après pour un package type “Exchange” qui push mon calendrier dans Constellation ou “Google Traffic” qui push les itinéraires avec temps de trafic, je n’ai pas besoin d’une telle réactivité. Un “poll/push” toutes les 10 ou 15 minutes est suffisant !

Autre possibilité comme tu l’évoques : Pusher directement depuis le device ! Pour cela on crée un “Package Virtuel” comme je peux le faire avec les ESP (IR remote, capteur de luminosité ou autre présentés sur mon blog).

Les packages virtuels exploitent l’API REST de Constellation donc tu peux l’utiliser depuis n’importe où! Perso j’ai quelques scripts Powershell qui push des SO dans Constellation via un simple appel HTTP!

En son temps, j’avais fait un POC d’intégration de Domoticz dans Constellation! Comme il n’y a pas d’API en HTTP long polling, j’avais directement dans Domoticz, attaché un événement à chaque modification de device Z-Wave pour appeller l’API HTTP de COnstellation afin de mettre à jour le SO correspondant (évitant ainsi de poller constamenent l’API de Domoticz).

Comme tu le vois, il y a plein de façon de faire :slight_smile:


#3

Oki je comprend mieux, je viens de tester une package virtuel ça fonctionne top.

Par contre si j’ai besoin que ce package possèdent des MessageCallbacks, je dois du coup faire un package normal et utiliser PushStateObject depuis l’api REST en même temps ?

Par exemple pour un package Squeezebox, je fais un package standard pour gérer les actions (play, pause, stop…) et j’utilise un plugin pour le LMS qui envoi les données vers le package via l’api REST ?

Va falloir que j’apprenne le language pour dev les packages :slight_smile:


#4

C’est exactement çà !

Le package virtuel est dit virtuel dans le sens où ce n’est pas un programme .NET ou Python qui s’exécute sur une sentinelle (Linux ou Windows).
Un script Powershell, un code sur un ESP ou Domoticz sont des packages “virtuels”.

Cependant un package virtuel peut être aussi couplé un vrai package ! Par exemple tu peux imaginer avoir un package “Squeezebox” écrit en .NET et qui gère les MessagesCallbacks pour le pilotage et en même temps avoir du code sur ton LMS qui push via l’API REST des infos !

Les deux utilisent le même couple “Sentinel/Package” avec la même AccessKey et sont donc indissociable d’un point de vue Constellation.

A noter que tu peux également dans l’API REST HTTP de Constellation implémenter des MessagesCallbacks (je vais écrire la doc sur l’API HTTP prochainement) mais il faut que ton device ait la main pour lancer des requêtes HTTP en background afin de récupérer les messages qu’il recevrait.


#5

Bonjour,

Je me permets de te poser une autre question.

Comment gères-tu l’interaction entre tes packages ?

Par exemple j’ai le package pushbullet et le package météo. Comment envoyer par pushbullet tous les matins la meteo ?

Bien sûr on pourrait modifier le code du package pour ajouter dans pushbullet une action mais je présume que tu fais pas ça a chaque fois que tu as besoin d’un scénario ?

Si j’ai bien compris tu as un package “cerveau” pour ça ? Comment celui-ci fonctionne t’il ?

Je présume qu’il doit avoir une interface spécial par rapport aux packages “standard” ? Penses-tu le partager ou nous expliquer comment tu l’as codé ?

Perso les scénarios sont les seuls points qui me font garder ma solution actuelle (à part la gestion du contrôler zwave).