La prise connectée est un élément phare de la domotique de la maison. Il permet d’allumer ou d’éteindre un équipement branché dessus ou encore de connaitre sa consommation en énergie. Dans mon cas, j’avais besoin d’allumer ou d’éteindre les enceintes de mon média center automatiquement lorsque ce dernier était démarré.

Découvrons ensemble comment créer sa prise connectée avec un ESP8266.

Prérequis

Pour ce tutoriel, il vous faut :

• Un bloc prise avec un interrupteur
• Un transformateur AC/DC 5v
• Un ESP-01 (ESP8266)
• Un régulateur de tension 3.3v
• Un relais 220V pilotable en 5v
• Un transistor, des résistances, des leds, une diode, des condensateurs
• Du fil électrique
• Un pistolet à colle et une drémel
• Un serveur Constellation

Etape 1 : Construire la prise

Dans un premier temps, il nous faut un boitier abordable que nous pourrons ouvrir pour insérer notre ESP à l’intérieur. Après quelques recherches, j’ai opté pour le boitier Renkforce disponible chez Conrad pour 3€ environ.

On commence donc par l’ouvrir pour la vider littéralement :

Puis tous les supports plastique à l’intérieur doivent être cassés pour libérer un maximum de place. Je les ai cassés avec une pince coupante et j’ai fini de retirer le maximum de plastique avec un dremel. Sur cette photo j’avais retiré une partie du fond de la prise pour un autre projet.

Il faut ensuite préparer un câblage avec le relais pour qu’il s’intercale entre l’arrivée de la phase (mur) et la phase distribuée à l’élément branché sur la prise. Mais il faut également garder en tête que l’alimentation de l’ESP doit être permanente :

Mon principal problème dans ce tutoriel a été de tout faire rentrer dans la prise. En effet, l’alimentation + le relais prennent beaucoup de place et tout est rentré au chausse-pied, avec le câblage noyé dans la colle chaude afin d’assurer l’isolation.

Le transformateur alimente donc en 5v un régulateur de tension LM1117 3.3V avec deux condensateurs pour lisser du 3.3v pour l’ESP01.

Il alimente également directement la bobine du relais dont le circuit est interrompu par un transistor NPN BC547 dont la base sera pilotée en saturation par un GPIO de l’ESP.

L’ESP pilote deux leds de statut : une rouge et une verte et possède également son dernier GPIO en input pour un bouton physique placé sur le dessus du boitier. Si vous avez suivi jusque-là et que vous connaissez l’ESP01, vous aurez compris qu’il est impossible de le programmer directement dans la prise, deux des 4 GPIO devant normalement être utilisés pour la communication série.

Pour combler le « trou » du bouton physique original, j’ai choisi de coller par l’intérieur du boitier un petit bout de plexiglas translucide. Je l’ai ensuite percé pour faire passer les deux leds rouge et verte.

Et voilà, on obtient une prise connectée par Wifi avec un ESP8266 avec un bouton poussoir et deux LEDs, reste plus qu’à le programmer !

Etape 2 : la programmation

La fonction de base de la prise est assez simple : couper le courant ou le laisser passer. Dans un premier temps, j’ai uploadé un sketch de base Constellation avec Arduino sur l’ESP01 à l’extérieur de la prise. Je l’ai ensuite branché dans la prise que j’ai enfiché dans le mur. Bazinga, le régulateur 3.3v fait son job, l’ESP boote, se connecte à mon réseau wifi et envoie un « hello world » dans la console Constellation. Pour découvrir comment connecter un ESP8266 à Constellation, suivez ce guide.

Ensuite, j’ai utilisé la librairie Constellation pour ajouter un MessageCallback pour activer ou désactiver le GPIO de la prise, couplé à un StateObject pour maintenir l’état de la prise dans Constellation :

constellation.registerMessageCallback("Switch", MessageCallbackDescriptor().setDescription("Switch le statut du relais."),
  [](JsonObject & json) {
    statutRelais = !statutRelais;
    digitalWrite(gpioRelais, statutRelais);
    constellation.pushStateObject("Status", stringFormat("{ 'IsActivated':%s }", statutRelais ? "true" : "false" ));
  });

Ainsi Constellation a toujours connaissance de l’état de la prise via le StateObject nommé “Status” :

Et tout le monde peut maintenant découvrir et utiliser le MessageCallback “Switch” exposé par notre ESP pour permuter l’état de notre prise :

Bingo, on a donc une prise 220V connectée à Constellation qu’on pourra piloter depuis une page Web, un programme Python ou autre.

Pour vous donnez quelques idées, n’hésitez pas à relire ce tutoriel : Créer un relais connecté.

Etape 3 : Lier sa prise connectée à l’état de son média-center

Dans ma Constellation, je dispose d’un package « brain » développé en C# avec Visual Studio qui contient l’ensemble des règles de la maison (gestion du chauffages, lumières, volets, etc..).

Je l’ai enrichi pour faire en sorte que si Kodi est en train de lire un média (audio ou vidéo) et que la prise n’est pas allumée, alors il invoque le MessageCallback pour allumer la prise. Et inversement pour l’éteindre !

J’ai donc dans une classe C#, ajouté deux StateObjectLinks, c’est à dire que j’ai deux propriétés de mon code C# qui sont liées à mes StateObjets représentant l’état de mon media-center de l’état de ma prise !

Il me reste plus qu’à ajouter un handler sur le changement d’état du State Object de Kodi, afin d’ajouter deux conditions “if” :

• Si la prise est éteinte alors que Kodi joue quelque chose (PlayerState différent de null) alors on allume la prise
• Si la prise est allumée alors que Kodi joue rien (PlayerState null) alors on éteint la prise

Pour allumer ou éteindre la prise, il suffit d’invoquer le MessageCallback “Switch” exposé par notre code Arduino en créant un proxy vers notre package.

public class KodiDemo
{
    /// <summary>
    /// StateObject XBMC. Permet de connaitre les infos de lecture.
    /// </summary>
    [StateObjectLink(Package = "Xbmc", Name = "Kodi Salon NUC")]
    public StateObjectNotifier KodiNotifier { get; set; }

    /// <summary>
    /// StateObject de l'ESP controlant le relais d'activation. Permet de synchroniser les infos de lecture avec la valeur du relais.
    /// </summary>
    [StateObjectLink(Sentinel = "ESP8266-01-001", Package = "ESP_Relay_Button", Name = "Status")]
    public StateObjectNotifier PriseKodi { get; set; }

    public void Start()
    {
        this.KodiNotifier.ValueChanged += (s, e) =>
        {
            if (this.PriseKodi.DynamicValue.Status == false
                && e.IsNew == false
                && e.OldState.DynamicValue.PlayerState == null
                && e.NewState.DynamicValue.PlayerState != null)
            {
                // démarrage.
                PackageHost.WriteInfo("Activation de la prise.");
                PackageHost.CreateMessageProxy("ESP8266_01_002/ESP_Relay_Button").Switch();
            }

            if (this.PriseKodi.DynamicValue.Status == true
                && e.IsNew == false
                && e.OldState.DynamicValue.PlayerState != null
                && e.NewState.DynamicValue.PlayerState == null)
            {
                PackageHost.WriteInfo($"Arret de la prise.");
                PackageHost.CreateMessageProxy("ESP8266_01_002/ESP_Relay_Button").Switch();
            }
        };
    }
}

Et voilà comment en quelques lignes de C# et grâce à Constellation, mes enceintes seront automatiquement allumées ou éteintes selon que mon media-center diffuse ou non un média vidéo ou audio !

Pour aller plus loin

Pour aller plus loin, j’ai ajouté quelques fonctionnalités intéressantes :

• J’ai pluggé le bouton poussoir ajouté sur le dessus de la prise pour qu’il change l’état du relais et mette à jour le state objet en conséquence.
• J’ai ajouté la possibilité d’associer les leds de façade au fonctionnement de la prise en m’inspirant de ce qui existe sur les prises connectées du marché. La led rouge indique le statut de fonctionnement (power on / connexion au wifi en clignotant), la led verte indique l’état du relais.
• J’ai ajouté également un mode « blind », je trouve que c’est une fonctionnalité intéressante mais qui est absente des prises sur le marché : Quand il fait noir dans une pièce et que la prise se reconnecte au wifi, cela peut être gênant de la voir clignoter. Un package de « brain » peut alors gérer les leds directement en fonction de mes volets
• Ensuite, en cas de déconnection du wifi ou de coupure de courant, j’ai prévu un bout de code permettant, au démarrage de l’ESP, de requêter son propre StateObject. Cela permet à la prise de revenir à l’état dans lequel elle était avant la coupure.
• J’ai également fait intervenir l’activation de mon projecteur. Ce dernier push un StateObject. Si le média center est éteint, il envoie un paquet WOL via le package networktools pour l’allumer et envoie une notification de fermeture des volets du salon. Le démarrage de la lecture du média sur kodi pilote la prise d’allumage des enceintes sans action manuelle. Ainsi, le démarrage du projecteur et la lecture sur kodi lancent l’ambiance parfaite pour profiter de mes séries en un seul geste.

The post Créer une prise connectée avec un ESP8266 appeared first on Constellation.

L’idée est très simple : lorsque vous déverrouillez (ou ouvrez) votre session Windows on allumera automatiquement la lampe du bureau et lorsque vous verrouillez (ou fermez) votre session, la lampe s’éteindra automatiquement.

On peut même aller plus loin si vous avez un capteur de luminosité connecté pour n’allumer la lampe que lorsqu’il fait trop sombre.

Prérequis

• Un serveur Constellation
• Une lampe pilotable par Constellation
• Le package WindowsControl déployé sur la sentinelle de l’ordinateur Windows à synchroniser avec la lampe
• Optionnellement un capteur de luminosité connecté dans Constellation
• Le SDK Constellation pour Visual Studio

Etape 1 : piloter une lampe par Constellation

Bien entendu il faut d’abord pouvoir piloter une lampe par Constellation pour réaliser ce tutoriel !

Vous pouvez par exemple piloter un relais depuis un Raspberry en créant un package Python ou bien depuis un Arduino ou un ESP8266 comme vu dans ce tutoriel. Il suffit de créer une fonction pilotant un relais (simple manipulation d’une sortie digitale) et d’exposer cette fonction comme MessageCallback. On pourra ainsi invoquer votre méthode pour ouvrir et fermer le relais et donc piloter une lampe depuis n’importe quel système connecté dans votre Constellation.

Autre solution utiliser une carte de relais connectée par USB qu’on pilotera avec le package RelayBoard. Ce package expose des MC permettant d’ouvrir ou fermer les relais et publie l’état de chacun d’entre eux comme StateObject. Il ne reste plus qu’à connecter une lampe sur l’un des relais.

On peut aussi utiliser des prises Wifi Belkin Wemo qu’on connectera à Constellation avec le package Wemo. Encore une fois ce package expose des MC permettant d’allumer ou d’éteindre la charge connectée dessus et publie son état en tant que StateObject. Il suffit d’y brancher une lampe !

Dans la même idée, on peut utiliser des prises Somfy qu’on connectera à Constellation avec le package RFXCOM nécessitant une passerelle RFXcom connectée en USB. Le package expose un MessageCallback permettant d’envoyer des ordres par radiofréquences aux équipements RTS (protocole Somfy) pour piloter par exemple des prises. Il n’y a pas de retour d’état sur ce protocole, donc il ne sera pas possible de récupérer son état mais on pourra allumer ou éteindre la prise et donc une lampe !

Encore une autre possibilité, utiliser des prises ou des modules Z-Wave. Il faut pour cela un contrôleur Z-Wave qu’on connectera à Constellation. Vous pouvez soit utiliser le package Jeedom ou soit le package Vera.

On pourrait également utiliser des lampes ou des ampoules connectées de la gamme Phillips Hue qu’on connectera à Constellation grâce au package Hue.

Pour ma part la lampe de mon bureau est contrôlée par une prise Z-Wave AN158 appairée sur une Vera Lite. Ce contrôleur Z-Wave est connecté à Constellation grâce au package Vera.

J’ai donc dans ma Constellation des StateObjets pour chaque périphérique Z-Wave et des MessageCallbacks pour envoyer des ordres Z-Wave. Par exemple depuis le MessageCallbacks Explorer, on retrouve le MC « SetSwitchState » permettant de définir l’état d’un switch (On/Off) Z-Wave.

Depuis l’API.net il me suffit d’invoquer le code suivant pour allumer le device #42 :

PackageHost.CreateMessageProxy("Vera").SetSwitchState(new { DeviceID = 42, State = true });

Vous pouvez appuyer sur le bouton  pour obtenir les exemples de code pour chaque MessageCallback. Par exemple toujours pour allumer le device Z-Wave #42 depuis un Arduino :

constellation.sendMessage(Package, "Vera", "SetSwitchState", "{ 'DeviceID':42, 'State':true }");

Bref il existe différente méthode de piloter une lampe (ou n’importe quelle charge) depuis Constellation, soit en mode DIY en créant vous-même votre package réel (C#, Python, …) ou virtuel (Arduino, ESP8266, Gadgeteer, …) ou bien en utilisant des technologies telles RTS de Somfy, le Z-Wave, les lampes et ampoules Philips, les prises Wifi de Belkin, etc… avec les packages déjà disponibles dans le catalogue en ligne.

Et quand bien même il n’existe pas de connecteur Constellation pour piloter votre lampe, libre à vous de créer votre propre package créant ainsi la passerelle, le connecteur entre Constellation et votre lampe.

Etape 2 : connaitre l’état de la session avec le package WindowsControl

Maintenant que nous avons un MessageCallback pour piloter la lampe du bureau, faut-il encore savoir si la session est ouverte ou non.

Pour cela vous avez dans le catalogue en ligne, le package WindowsControl qui expose différent MessageCallbacks pour verrouiller ou fermer une session, pour arrêter ou redémarrer l’ordinateur, pour contrôler le volume ou la luminosité (comme vu dans ce tutoriel).

Ce package produit également un StateObject nommé « SessionLocked » de type booléen qui indique si la session est verrouillée (ou fermée) ou non.

Il suffit donc de déployer ce package depuis la Console Constellation sur la sentinelle UI du PC à synchroniser avec votre lampe. On suivra ainsi ce StateObject pour savoir quel est l’état de votre session et réagir tout changement d’état.

Etape 3 : synchroniser la lampe avec la session en C#

Passons au chose sérieuse, nous avons d’un côté un StateObject nous indiquant si la session est ouverte ou non et un MessageCallback nous permettant d’allumer ou d’éteindre la lampe du bureau, reste juste à créer le lien.

Pour cela nous allons créer un package .NET en C# depuis Visual Studio.

Dans la classe principale (Program), nous allons ajouter un StateObjectLink, c’est à dire une propriété dans notre code liée au StateObject représentant l’état de la session en ajoutant les lignes :

[StateObjectLink("WindowsControl", "SessionLocked")]
public StateObjectNotifier SessionLocked { get; set; }

Prenez garde toutefois, si vous avez déployé le package WindowsControl sur plusieurs sentinelles de votre Constellation, le StateObjectLink ci-dessus sera lié à plusieurs StateObjects et non au StateObject de votre ordinateur à scruter. L’unicité d’un StateObject est obtenu par le triplet : “Sentinel + Package + Nom” car un nom de StateObject est unique pour une instance de package (couple Sentinel / Package), de même qu’un package est unique pour une sentinelle et qu’une sentinelle est unique dans une Constellation.

De ce fait pour lier la propriété « SessionLocked » au StateObject « SessionLocked » de votre ordinateur on écrira :

[StateObjectLink("PC-SEB_UI", "WindowsControl", "SessionLocked")]
public StateObjectNotifier Session { get; set; }

Dans l’exemple ci-dessus, la machine est nommée « PC-SEB » et donc le nom de sa sentinelle « PC-SEB_UI » étant donné que le package WindowsControl est déployé sur la Sentinelle UI d’où le suffixe « _UI » dans le nom de la sentinelle. Vous pouvez bien entendu vérifier le nom exacte de votre sentinelle sur la Console Constellation.

Maintenant que l’état de la session de notre PC est synchronisé dans cette propriété .NET de notre code C#, nous allons ajouter un « handler » pour réagir au changement d’état :

this.SessionLocked.ValueChanged += (s, e) =>
{
    if ((bool)this.SessionLocked.DynamicValue)
    {
        PackageHost.WriteInfo("Verrouillage de la session : fermeture de la lampe");
    }
    else
    {
        PackageHost.WriteInfo("Session déverrouillée : allumage de la lampe");
    }
};

Maintenant pour allumer la lumière, il suffit d’envoyer un message pour déclencher le MessageCallback permettant de contrôler votre lampe. Comme expliqué ci-dessus, dans mon cas, la lampe sur mon bureau est contrôlée par une prise Z-Wave AN158 pilotable par le package Vera via le MessageCallback « SetSwitchState« .

On crée donc un proxy dynamique vers le package Vera et on invoque le MC comme on invoquerait une méthode .NET en passant en paramètre un objet contenant l’ID du device Z-Wave et l’état souhaité :

PackageHost.CreateMessageProxy("Vera").SetSwitchState(new { DeviceID = 42, State = true });

Pour connaitre l’ID du device Z-Wave on peut soit le rechercher dans le StateObjects Explorer et l’écrire en dur dans notre code C#, ou soit ajouter un autre StateObjectLink afin de récupérer dynamiquement son Id (car contenu dans le StateObject du device).

Le code de notre package sera donc :

public class Program : PackageBase
{
    [StateObjectLink("Vera", "Lampe Bureau Seb")]
    public StateObjectNotifier LampeBureau { get; set; }

    [StateObjectLink("PC-SEB_UI", "WindowsControl", "SessionLocked")]
    public StateObjectNotifier SessionLocked { get; set; }

    static void Main(string[] args)
    {
        PackageHost.Start<Program>(args);
    }

    public override void OnStart()
    {
        this.SessionLocked.ValueChanged += (s, e) =>
        {
            if ((bool)this.SessionLocked.DynamicValue)
            {
                PackageHost.WriteInfo("Verrouillage de la session : fermeture de la lampe");
                PackageHost.CreateMessageProxy("Vera").SetSwitchState(new { DeviceID = (int)this.LampeBureau.DynamicValue.Id, State = false });
            }
            else
            {
                PackageHost.WriteInfo("Session déverrouillée : allumage de la lampe");
                PackageHost.CreateMessageProxy("Vera").SetSwitchState(new { DeviceID = (int)this.LampeBureau.DynamicValue.Id, State = true });
            }
        };
    }
}

On peut maintenant lancer notre package en mode « Debug On Constellation » pour le tester depuis Visual Studio tout en le connectant dans votre Constellation :

Vous pouvez tester le fonctionnel de votre package : on verrouille la session, la lampe s’éteint, on la déverrouille, la lampe s’allume !

Une fois votre package testé et validé, vous pouvez le publier dans votre Constellation et le déployer sur une de vos sentinelles (voir le guide).

Etape 4 : ajouter un capteur de luminosité

Jusqu’à présent dès que la session est déverrouillée la lampe du bureau s’allume et dès qu’on la ferme elle s’éteint. Seulement en pleine journée ce n’est peut être pas très judicieux d’allumer la lumière !

Pour cela nous pouvons ajouter une condition supplémentaire basée sur la luminosité ambiante.

On pourrait utiliser un capteur sans fil du marché comme le Chacon DIO54783 connecté via le package RFXcom ou bien un capteur Z-Wave via le package Vera ou Jeedom. On peut aussi concevoir son propre capteur avec un Arduino ou un ESP8266 comme vu dans ce tutoriel ou avec un Raspberry Pi comme vu ici.

Dans notre article, prenons par exemple l’un des deux capteurs ci-dessus qui publient chacun un StateObject nommé « Lux » composé de 3 propriétés : Broadband, IR et Lux.

Pour intégrer cette « information » dans notre code C#, ajoutons un StateObjectLink vers le StateObject « Lux » :

[StateObjectLink("LightSensor", "Lux")]
public StateObjectNotifier LuxSensor { get; set; }

On peut maintenant modifier la condition d’allumage avec un « else if » qui vérifiera que la luminosité est inférieure à un seuil qu’on va déclarer dans les settings Constellation de façon à pouvoir modifier cette valeur à la volée depuis la Console Constellation :

else if (this.LuxSensor.DynamicValue.Lux < PackageHost.GetSettingValue<int>("DaylightThreshold"))

Bien entendu comme tout setting, il est vivement recommandé de le déclarer dans le manifeste du package (le fichier PackageInfo.xml). De plus on pourra y définir la valeur par défaut ici fixée à 50 (lux) :

<Settings>
  <Setting name="DaylightThreshold" type="Int32" defaultValue="50" description="Seuil de luminosité minimale pour l'allumage de la lampe du bureau" />
</Settings>

Pour finir, prenons le cas où la session est déjà déverrouillée et la soirée arrivant, la luminosité passe en dessous du seuil : il faut alors allumer la lumière bien que l’état de la session n’a pas changé !

Pour cela nous allons ajouter un « handler » pour réagir à chaque mise à jour du StateObject « Lux » du capteur de luminosité. A chaque nouvelle mesure, si la valeur est inférieure au seuil défini dans les settings et que la session est bien déverrouillée, on allumera la lumière :

this.LuxSensor.ValueChanged += (s, e) =>
{
    if (e.NewState.DynamicValue.Lux < PackageHost.GetSettingValue<int>("DaylightThreshold") && (bool) this.SessionLocked.DynamicValue == false)
    {
        PackageHost.WriteInfo("Session déverrouillée à la tombée de la nuit : allumage de la lampe");
        PackageHost.CreateMessageProxy("Vera").SetSwitchState(new { DeviceID = (int)this.LampeBureau.DynamicValue.Id, State = true });
    }
};

Ainsi notre lumière de bureau est maintenant synchronisée à notre session et ne s’allumera que si la luminosité est faible. Elle sera donc éteinte dès qu’on ferme ou verrouille la session et s’allumera si la luminosité baisse sous le seuil défini dans les settings alors que la session est déjà déverrouillée ou vient d’être déverrouillée.

Etape 5 : fermer la lampe en cas de déconnexion du PC

Pour vraiment aller au fond des choses il y a encore un cas à gérer : que faire si le PC s’arrête proprement ou brutalement. En somme l’idée est de fermer la lampe si le PC est déconnecté de Constellation, que ce soit suite à un arrêt de l’ordinateur, un crash, une déconnexion quelconque, etc..

Pour savoir si le PC est bien connecté on va surveiller l’état de la sentinelle UI de votre PC. Pour cela il faut se connecter sur le hub de contrôle.

L’utilisation du hub de contrôle depuis un package C# est expliqué en détail dans cet article que je vous recommande de lire.

La première étape consiste donc à déclarer dans le manifeste du package (le fichier PackageInfo.xml) l’utilisation du hub de contrôle par votre package en ajoutant l’attribut suivant sur la balise Package :

EnableControlHub="true"

De plus il faut également, sur votre package, définir une clé d’accès ayant les droits d’accès au hub de contrôle. Vous pouvez vérifier la bonne connexion au hub de contrôle dans votre code par la propriété : « PackageHost.HasControlManager« .

Une fois connecté au hub de contrôle on va demander à recevoir les mises à jour des statuts des sentinelles de notre Constellation par la ligne :

PackageHost.ControlManager.RequestSentinelUpdates();

Cela nous permet ensuite d’attacher un « handler » qu’on filtrera sur notre sentinelle (ici nommée « PC-SEB_UI »). On stockera dans la variable « pcConnected » un booléen indiquant si la sentinelle de notre PC est connectée ou non. Si notre sentinelle n’est pas/plus connectée, on fermera immédiatement la lampe du bureau.

PackageHost.ControlManager.SentinelUpdated += (s, e) =>
{
    if (e.Sentinel.Description.SentinelName == "PC-SEB_UI")
    {
        this.pcConnected = e.Sentinel.IsConnected;
        PackageHost.WriteInfo("Le PC de Seb est '{0}'", e.Sentinel.IsConnected ? "connecté" : "déconnecté");
        if (!this.pcConnected)
        {
            // Éteindre la lampe si le PC est déconnecté !
            PackageHost.CreateMessageProxy("Vera").SetSwitchState(new { DeviceID = (int)this.LampeBureau.DynamicValue.Id, State = false });
        }
    }
};

De plus, dans la condition d’allumage, on rajoutera le fait de vérifier que le PC est bien connecté avant de prendre la décision d’allumer la lampe :

else if (this.pcConnected && this.LuxSensor.DynamicValue.Lux < PackageHost.GetSettingValue<int>("DaylightThreshold"))

Et voilà, notre package est opérationnel ! La lampe est parfaitement synchronisée avec l’état de notre session Windows en tenant compte de la luminosité ambiante et des différents cas de figure pouvant apparaître, comme le redémarrage, l’arrêt ou le crash de notre PC !

Le code final est :

public class Program : PackageBase
{
    // Nom de la sentinelle Windows à syncrhoniser avec la lampe
    private const string SEB_PC_SENTINEL_NAME = "PC-SEB_UI";
    
    // PC Connecté? oui ou non !
    private bool pcConnected = false;

    // Lien vers le SO de la lampe du bureau
    [StateObjectLink("Vera", "Lampe Bureau Seb")]
    public StateObjectNotifier LampeBureau { get; set; }

    // Lien vers l'état de la session Windows
    [StateObjectLink(SEB_PC_SENTINEL_NAME, "WindowsControl", "SessionLocked")]
    public StateObjectNotifier SessionLocked { get; set; }

    // Lien vers le capteur de luminosité
    [StateObjectLink("LightSensor", "Lux")]
    public StateObjectNotifier LuxSensor { get; set; }

    // Démarrage du package
    static void Main(string[] args)
    {
        PackageHost.Start<Program>(args);
    }

    // Méthode de démarrage de notre package
    public override void OnStart()
    {
        // Si accès au ControlHub
        if (PackageHost.HasControlManager)
        {
            // Demande de reception des mise à jour des sentinelles
            PackageHost.ControlManager.RequestSentinelUpdates();
            // En cas de mise à jour de l'état d'une sentinelle
            PackageHost.ControlManager.SentinelUpdated += (s, e) =>
            {
                // Si cela concerne notre sentinelle
                if (e.Sentinel.Description.SentinelName == SEB_PC_SENTINEL_NAME)
                {
                    // On stocke dans la variable "pcConnected" l'état connecté ou déconnecté de notre PC
                    this.pcConnected = e.Sentinel.IsConnected;
                    PackageHost.WriteInfo("Le PC de Seb est '{0}'", e.Sentinel.IsConnected ? "connecté" : "déconnecté");
                    // Si le PC est maintenant déconnecté, on ferme la lampe !
                    if (!this.pcConnected)
                    {
                        SetLight(false);
                    }
                }
            };
        }
        else
        {
            // Pas d'accès au COntrolHub, on log une erreur ! Vérifiez votre clé d'accès !
            PackageHost.WriteError("Accès au ControlHub impossible !");
        }

        // En cas de mise à jour du StateObject "Lux" du package "LightSensor"
        this.LuxSensor.ValueChanged += (s, e) =>
        {
            // Si le PC est connecté, que la luminosité actuelle est inférieure au seuil défini dans les settings et que la session est bien dévérouillée
            if (this.pcConnected && e.NewState.DynamicValue.Lux < PackageHost.GetSettingValue<int>("DaylightThreshold") && (bool) this.SessionLocked.DynamicValue == false)
            {
                // On allume la lampe !
                SetLight(true);
                PackageHost.WriteInfo("Session dévérouillée à la tombée de la nuit : allumage de la lampe");
            }
        };

        // En cas de mise à jour du StateObject "SessionLocked" du package "WindowsControl"
        this.SessionLocked.ValueChanged += (s, e) =>
        {
            // Si la session est vérouillée (ou fermée)
            if ((bool)this.SessionLocked.DynamicValue)
            {
                // On eteint la lampe
                SetLight(false);
                PackageHost.WriteInfo("Verrouillage de la session : fermeture de la lampe");
            }
            // Si le PC est connecté, que la luminosité actuelle est inférieure au seuil défini dans les settings et que la session est donc dévérouillée
            else if (this.pcConnected && this.LuxSensor.DynamicValue.Lux < PackageHost.GetSettingValue<int>("DaylightThreshold"))
            {
                // On allume la lampe !
                SetLight(true);
                PackageHost.WriteInfo("Session déverrouillée avec luminosité faible : allumage de la lampe");
            }
        };
    }

    private void SetLight(bool state)
    {
        // Pour allumer la lumière, on invoque le MC "SetSwitchState" du package "Vera" en passant l'ID de la lampe (récupérée par son StateObjet)
        PackageHost.CreateMessageProxy("Vera").SetSwitchState(new { DeviceID = (int)this.LampeBureau.DynamicValue.Id, State = state });
    }
}

The post Synchroniser la lampe du bureau avec sa session Windows appeared first on Constellation.

Cette nouvelle version amène beaucoup de nouveautés que je vous propose de découvrir dans cet article. La librairie a été testé avec succès sur différentes cartes animées par un ESP8266 (ESP-01, 05, 07 et D1 Mini) ainsi qu’un Arduino/Genuino MKR1000.

Pour la mise à jour, téléchargez la libraire ci-dessous et dézippez les fichiers dans le dossier “Constellation” dans votre répertoire de libraire Arduino.

Attention : cette version 2.x de la librairie Constellation pour Arduino/ESP nécessite la version 1.8.1.16249 ou plus récente du serveur Constellation pour fonctionner correctement. Pour mettre à jour votre plateforme Constellation, lancez le Web Platform Installer.

Réception de message et StateObject “asynchrone”

Il s’agit d’une grosse évolution par rapport à la version 1.x. Pour “récupérer” du serveur Constellation les messages à destination de votre package virtuel ou les StateObjects pour lequel votre package (virtuel) s’est abonné, il faut invoquer les actions “GetMessages” et “GetStateObjects” sur l’interface REST.

Ces méthodes supportent le “long-polling” c’est à dire qu’elles mettent en attente la requête tant qu’il n’y a pas de messages ou StateObjects à retourner avec la notion de timeout (par défaut 60 secondes).

Le problème sur les versions 1.x de la libraire Arduino est que le client HTTP est “synchrone”, c’est à dire qu’il envoi la requête HTTP et attend la réponse du serveur pour traitement ce qui est incompatible avec du long-polling car cela bloquerait le code de l’Arduino. De ce fait, les anciennes versions spécifiées le “timeout” de ces requêtes à 1 seconde.

Ainsi jusqu’à maintenant, l’interrogation des messages et SO pouvaient bloquer jusqu’à 2 secondes votre Arduino (1 seconde pour le GetMessage et 1 seconde pour le GetStateObject) et engendrait donc 1 requêtes HTTP toutes les secondes entre votre ESP/Arduino et le serveur Constellation.

Dans cette nouvelle version, la librairie utilisent 3 clients HTTP différents : un pour toutes les requêtes synchrones, un pour la réception de message (GetMessage) et un pour la réception des StateObjects (GetStateObjects).

Le client synchrone est donc toujours disponible et il n’y a aucun blocage, aucune attente pour la réception de message et de SO. De plus il n’y a plus besoin de “poller” ou “flooder” le serveur d’une requête toute les secondes, en réactivant le long-polling le 2ème et 3ème client HTTP, on lance une requête toutes les minutes (60 sec par défaut) dans l’attente de message et SO.

De ce fait, il y a quelques modifications à apporter dans votre code !

Premièrement, vous ne devez plus passer la référence de votre client réseau mais plutôt spécifier le type de votre client dans le template de la classe Constellation. Par exemple, si vous utilisez un ESP8266 ou un Arduino MKR1000, vous utiliserez la classe “WifiClient “” :

/* Create the Constellation client */
Constellation<WiFiClient> constellation("constellation.monserveur.com", 8088, "MyVirtualSentine", "MyPackage", "MyAccessKey123!");

Ensuite, il n’y a plus besoin d’invoquer la méthode “poll” dans votre boucle principale avec un timer, vous devez tout simplement appeler la méthode “loop” autant de fois que vous voulez :

void loop(void) {
  // Process incoming message & StateObject updates
  constellation.loop();
}

Cette méthode vérifie en fait si il y a eu une réponse sur le client utilisé pour la réception de message et sur le client pour la réception de SO afin de les dispatcher dans votre code.

Support du PackageDescriptor

Autre nouveauté majeure pour cette version 2, le support du “Package Descriptor”.

Pour rappel le “Package Descriptor” est un objet envoyé par un package au serveur pour décrire ses StateObjects et ses MessageCallbacks exposés par le package.

Le MessageCallback Explorer de la Console Constellation s’appuie sur le “Package Descriptor” de chaque package pour lister chaque MessageCallback avec un formulaire de test. Sans cette description cela serait impossible !

Les versions 1.x ne supportaient pas “Package Descriptor”, de ce fait il n’était pas possible d’explorer/découvrir les MessageCallbacks d’un package Arduino/ESP. Vous devez nécessairement connaitre par vous même les MC exposés par le package et le type des StateObjects qu’il pouvait publier.

Avec la version 2.0, l’Arduino/ESP envoie au serveur la description des MC exposés et des types utilisés par les SO et arguments des MC.

Dans la suite de cet article, vous découvrirez comment ajouter des types dans la description de votre package, mais n’oubliez jamais d’envoyer votre “Package Descriptor” en invoquant la méthode “declarePackageDescriptor”, typiquement une fois votre code Arduino initialisé (par exemple à la fin de la méthode setup()) :

// Declare the package descriptor
constellation.declarePackageDescriptor();

Amélioration du PushStateObject

La méthode “PushStateObject” permet de publier un StateObject sur le serveur Constellation.

Tout d’abord la méthode expose des surcharges vous permettant de spécifier comme “value” de votre SO des int, uint, double, float, long et bool et supporte en paramètre optionnel le “lifetime”, c’st à dire la durée en seconde de “vie” de votre StateObject avant d’être considéré comme expiré.

// Dummy data
uint16_t lux = 123;

// Push a simple type on Constellation 
constellation.pushStateObject("DemoLux", lux);  

// Push a simple type on Constellation with lifetime of 20 seconds
constellation.pushStateObject("DemoLux", lux, 20);

Vous pouvez toujours publier des StateObjects dont la valeur (value) est un objet complexe (formaté en JSON).

Le JSON peut être formaté sous forme d’une chaine de caractère avec la méthode “stringFormat” :

// Push a complex object on Constellation with stringFormat
constellation.pushStateObject("DemoLux", stringFormat("{ 'Lux':%d, 'Broadband':%d, 'IR':%d }", lux, full, ir));

Vous pouvez également définir votre propre type pour ce StateObject, par exemple nommons cet objet “MyLuxData” :

constellation.pushStateObject("DemoLux", stringFormat("{ 'Lux':%d, 'Broadband':%d, 'IR':%d }", lux, full, ir), "MyLuxData");

Sans oublier d’ajouter ce type “personnalisé” dans le “package descriptor”. Par exemple, dans le “setup()” et avant de faire un “declarePackageDescriptor”, on aurait décrit “MyLuxData” de la façon suivante :

constellation.addStateObjectType("MyLuxData", TypeDescriptor().setDescription("MyLuxData demo").addProperty("Broadband", "System.Int32").addProperty("IR", "System.Int32").addProperty("Lux", "System.Int32"));

Pour finir, vous pouvez toujours publier un StateObject en construisant la valeur dans un objet JsonObject de façon suivante :

// Push a complex object on Constellation with JsonObject
const int BUFFER_SIZE = JSON_OBJECT_SIZE(5);
StaticJsonBuffer<BUFFER_SIZE> jsonBuffer;
JsonObject& myStateObject = jsonBuffer.createObject();
myStateObject["Lux"] = lux;
myStateObject["Broadband"] = full;
myStateObject["IR"] = ir;
constellation.pushStateObject("DemoLux", myStateObject);

Dans les surcharges de cette méthode, vous pouvez également spécifier le type de votre StateObject et/ou sa durée de vie :

constellation.pushStateObject("DemoLux", myStateObject, "MyLuxData", 20);

Pour finir, nouveauté de la librairie 2.0, vous pouvez également spécifier des “meta-données” à vos StateObjects. Par exemple :

// Ajout de metadatas au StateObject
JsonObject& metadatas = jsonBuffer.createObject();
metadatas["ChipId"] = ESP.getChipId();
metadatas["Timestamp"] = millis();
constellation.pushStateObject("DemoLux", myStateObject, "MyStateObject", 20, &metadatas);

Les StateObjectLinks

En version 1.x de la librairie Arduino, vous pouvez :

• interroger des StateObjects de la Constellation en invoquant la méthode “requestStateObjects” qui vous retourne les StateObjects à l’instant T correspondant à votre requête :

// Example : print the all SO's value named "/intelcpu/0/load/0" and produced by the "HWMonitor" package (on all sentinels)
JsonArray& cpus = constellation.requestStateObjects("*", "HWMonitor", "/intelcpu/0/load/0");
for(int i=0; i < cpus.size(); i++) { 
  constellation.writeInfo("CPU on %s is currently %d %", cpus[i]["SentinelName"].asString(), cpus[i]["Value"]["Value"].as<float>());
}

• vous abonnez aux mises à jour des StateObjects pour être notifié en temps réel des que les SO changent :

// set a StateObject update callback and subscribe to SO
constellation.setStateObjectUpdateCallback([] (JsonObject& so) {
constellation.writeInfo("StateObject updated ! StateObject name = %s", so["Name"].asString()); 
});
// Subscribe to SO named "/intelcpu/0/load/0" and produced by the "HWMonitor" package (on all sentinels)
constellation.subscribeToStateObjects("*", "HWMonitor", "/intelcpu/0/load/0");

Vous pouvez invoquer plusieurs fois la méthode “subscribeToStateObjects” pour ajouter des abonnements à d’autre StateObjects mais il n’y a qu’un seul callback de réception des SO (défini par la méthode setStateObjectUpdateCallback). C’est à vous de “dispatcher” les SO reçus.

La nouveauté en 2.0 vient de l’ajout de la méthode “registerStateObjectLink” qui vous permet d’associer un callback à un abonnement laissant ainsi à la librairie la charge du “dispatch”.

Par exemple, on peut désormais écrire :

constellation.registerStateObjectLink("*", "HWMonitor", "/intelcpu/0/load/0", [](JsonObject& so) {
  constellation.writeInfo("CPU on %s is currently %d %", so["SentinelName"].asString(), so["Value"]["Value"].as<float>());
});

Ici on enregistre un “StateObject Link” sur tous les SO nommés « /intelcpu/0/load/0 » produits par le package “HWMonitor” de toutes les sentinelles de votre Constellation. Dès qu’un de ces StateObjects changent on exécutera le callback associé, qui ici écrit dans le log un message indiquant la nouvelle valeur du CPU.

Vous bien entendu enregistrer autant de StateObjectLink que vous souhaitez.

Enregistrement des MessageCallbacks

Le principe est le même que celui décrit ci-dessus pour les abonnements aux StateObjects.

En version 1.x, on devait définir un callback pour réception de message et invoquer la méthode “subscribeToMessage” :

// Set callback for all incoming messages
 constellation.setMessageReceiveCallback([](JsonObject& json) { 
   constellation.writeInfo("Message receive ! Message key = %s", json["Key"].asString());     
 }); 
 // Subscribe to message
 constellation.subscribeToMessage();

C’était donc à votre charge de “dispatcher” les messages reçus en fonction du “MessageKey”.

Désormais avec la version 2.0, vous pouvez enregistrer un callback pour un “MessageKey” donné. Par exemple :

constellation.registerMessageCallback("HelloWorld",
  [](JsonObject& json) {
    constellation.writeInfo("Hello Constellation !");
 });

Dans l’exemple ci-dessous, on ajoute/expose un MessageCallback “HelloWorld” qui écrit dans les logs !

Il n’y donc plus besoin de “dispatcher”, un MessageCallback est donc associé à un “MessageKey” unique et un callback. Il n’y a plus besoin non plus de faire un “subscribeToMessage” (cette méthode est invoquée implicitement par le registerMessageCallback).

De plus cette méthode ajoute implicitement les MessageCallbacks dans le Package Descriptor de sorte que chaque MC soit ainsi référencé dans la Constellation

(console)

Vous pouvez également passer un “MessageCallbackDescriptor” dans l’enregistrement de vos MC pour ajouter une description par exemple :

constellation.registerMessageCallback("HelloWorld",
  MessageCallbackDescriptor().setDescription("Say Hello to Constellation"),
  [](JsonObject& json) {
    constellation.writeInfo("Hello Constellation !");
 });

Et même définir les paramètres de vos MC :

constellation.registerMessageCallback("SayHello",
  MessageCallbackDescriptor().setDescription("Say hello !").addParameter("FirstName", "System.String").addParameter("LastName", "System.String"),
  [](JsonObject& json) {
    constellation.writeInfo("Hello %s %s", json["Data"][0].asString(), json["Data"][1].asString()); 
 });

Ici on déclare un MC nommé “SayHello” prenant deux paramètres de type String avec un texte de description. Dans la code nous verrons :

(console)

Tout comme les StateObjects, les types des arguments des MC peuvent être des types complexes.

Par exemple enregistrons un MC prenant un seul argument de type “SampleUserData” que nous allons décrire avec la méthode “addMessageCallbackType” comme un objet composé de deux propriétés de type String :

// Expose a MessageCallback with complex parameter :
constellation.registerMessageCallback("SayHello2",
  MessageCallbackDescriptor().setDescription("Say hello with complex object!").addParameter("User", "SampleUserData"),
  [](JsonObject& json) {
    constellation.writeInfo("Hello %s %s", json["Data"][0]["FirstName"].asString(), json["Data"][0]["LastName"].asString()); 
});  
// and describe the complex parameter "SampleUserData"  
constellation.addMessageCallbackType("SampleUserData", TypeDescriptor().setDescription("This is a smaple user data").addProperty("FirstName", "System.String").addProperty("LastName", "System.String"));

Enfin la méthode “registerMessageCallback” accepte également des callbacks prenant en paramètre le “MessageContext” :

constellation.registerMessageCallback("HelloWorld",
  MessageCallbackDescriptor().setDescription("Say Hello to Constellation"),
  [](JsonObject& json, MessageContext ctx) {
    constellation.writeInfo("Message received from %s", ctx.sender.friendlyName);
 });

L’objet “MessageContext” est défini de la façon suivante :

typedef struct {
    const char* sagaId;
    bool isSaga;
    const char* messageKey;
    MessageSender sender;
    ScopeType scope;
} MessageContext;

typedef struct {
    SenderType type;
    const char* friendlyName;
    const char* connectionId;
} MessageSender;

Vous pouvez donc récupérer les informations sur l’émetteur (Sender) du message, le scope et l’identifiant de Saga si c’est une saga (isSaga = true).

Support des Saga (messages avec réponse)

Une saga est un identifiant unique qu’on affecte à des messages pour les lier entre eux. Cela permet de faire des couples de message “Requête / Réponse”. Une “réponse” étant un message renvoyé à l’émetteur de la requête avec le même identifiant de saga pour que ce dernier puisse l’identifier comme la “réponse” à son message d’origine.

Vous pouvez exposer des MessageCallbacks qui “répondent”, c’est à dire des  MessageCallbacks qui retournent un message de réponse.

Par exemple, exposons un MC pour réaliser des Additions sur un Arduino. Vous enregistrerez un MC “Addition” prenant en parametre deux entiers et qui en retourne un (le résultat) :

constellation.registerMessageCallback("Addition",
  MessageCallbackDescriptor().setDescription("Do addition on this tiny device").addParameter("a", "System.Int32").addParameter("b", "System.Int32").setReturnType("System.Int32"),
  [](JsonObject& json, MessageContext ctx) {        
    int a = json["Data"][0].as<int>();      
    int b = json["Data"][1].as<int>();
    int result = a + b;
    constellation.writeInfo("Addition %d + %d = %d", a, b, result);      
    if(ctx.isSaga) {
      constellation.writeInfo("Doing additoon for %s (sagaId: %s)", ctx.sender.friendlyName, ctx.sagaId);   
    // Return the result :
      constellation.sendResponse<int>(ctx, result);
    }
    else {
      constellation.writeInfo("No saga, no response !");
    }
 });

Vous remarquerez dans le “MessageCallbackDescriptor” l’appel de la méthode “setReturnType” pour spécifier le type de retour (et que le fait qu’il s’agit d’un MC acceptant les sagas).

L’envoi de la réponse étant réalisé par la méthode sendReponse. Cette méthode a plusieurs surcharges :

template<typename T> bool sendResponse(MessageContext context, T data);
bool sendResponse(MessageContext context, const char* data, ...);
bool sendResponse(MessageContext context, JsonObject& data);

Notez aussi que vous devriez faire un “sendResponse” si et seulement le message reçu est associé à une saga, c’est à dire que le champs “isSaga” du contexte (MessageContext) est “vrai”. Sinon ca ne sert à rien de répondre

Pour finir, cette nouvelle version supporte également l’envoi de message dans une saga. C’est à dire que vous pouvez envoyer un message qui attend une réponse et donc enregistrer un callback de traitement de la réponse.

Par exemple le package “NetworkTools” expose un MC “Ping” permettant de faire un ping. Le package retourne dans la saga un message contenant le temps en milliseconde du ping. On pourrait alors invoquer cette méthode depuis notre Arduino de la façon suivante :

const char* ip = "192.168.0.10";
// Send message in a saga and attach a callback for response :
constellation.sendMessageWithSaga([](JsonObject& json) {
  constellation.writeInfo("Ping response in %s ms", json["Data"].asString()); 
}, Package, "NetworkTools", "Ping", "[ '%s' ]", ip);

Ici on envoi un message au scope “Package” pour atteindre le(x) package(s) “NetworkTools” afin d’invoquer le MessageCallback “Ping” en passant en argument l’IP à pinger. Vous remarquerez qu’on utilise le formatage implicite des arguments.

La méthode n’est pas la traditionnelle “sendMessage” mais “sendMessageWithSaga” qui prend un argument supplémentaire : le callback de traitement de la réponse.

Ainsi quand le package “NetworkTools” répondra, on executera le callback associé qui ici affichera le temps de réponse de notre ping (Data) dans les logs Constellation (writeInfo).

De ce fait, avec cette nouvelle libraire vos Arduino/ESP peuvent invoquer des MC dans sagas pour exploiter la réponse mais également exposer des MC qui retournent des résultats.

Autres nouveautés

En vrac, vous disposez maintenant une méthode “purgeStateObjects” permettant de supprimer des StateObjects de votre package.

De plus la méthode “setDebugMode” accepte en argument l’énumération “DebugMode” composée des valeurs suivantes :

• “Quiet” (mode silencieux, la libraire ne produit aucune trace dans l’interface Serial)
• “Normal” (mode par défaut, écrit quelques informations dans l’interface Serial)
• “Verbose” (écrit beaucoup d’information dans l’interface Serial comme par exemple les requêtes et réponse HTTP v ers Constellation)

Enfin les exemples fournis dans la libraire ont été complètement revus.

The post Nouvelle librairie Constellation pour Arduino / ESP8266 en version 2.0 appeared first on Constellation.

Par exemple si vous voulez récupérer en temps réel le StateObject correspondant à un thermostat Nest (partant de l’hypothèse où le package Nest est déployé dans votre Constellation).

Via le StateObjects Explorer de la Console Constellation, on retrouvera le StateObject ici nommé “Living Room” publié par le package Nest qui représente l’état du thermostat du salon :

On peut donc écrire une méthode qui sera liée à ce StateObject pour afficher un message de log à chaque fois que l’état du thermostat sera mis à jour :

@Constellation.StateObjectLink(package = "Nest", name = "Living Room")
def OnNestTargetTemperatureChanged(stateObject):
    Constellation.WriteInfo("The Nest target temperature has changed to : %s°C" % stateObject.Value.target_temperature_c)

Le décorateur “StateObjectLink” accepte les paramètres suivants : “sentinel”, “package”, “name” et “type”. Tous ces paramètres sont optionnels et par défaut défini à “*”, c’est à dire qu’aucun filtre n’est appliqué !

Une méthode décorée “StateObjectLink” doit accepter qu’un seul argument : le StateObject.

Un StateObject contient les propriétés suivantes :

• SentinelName : nom de la sentinelle qui a produit le StateObject
• PackageName : nom du package qui a produit le StateObject
• Name : le nom du StateObject
• UniqueId : identifiant unique du StateObject dans la Constellation (concaténation des 3 propriétés ci-dessus)
• Type : type du StateObject
• Lifetime : durée de vie en seconde du StateObject avant d’être considéré “expiré” (0 si infini)
• LastUpdate : date de la dernière publication du StateObject
• IsExpired : indique si le StateObject est expiré (c’est à dire que DateTime.Now >  LastUpdate  + Lifetime si et seulement si Lifetime > 0)
• Metadatas : dictionnaire de clé / valeur
• Value : la valeur du StateObject (peut être un type simple ou un objet complexe)

Important : la méthode sur laquelle est appliquée cet attribut sera invoquée au démarrage de votre package avec la valeur actuelle du ou des StateObjects (Request) puis à chaque mise à jour des StateObjects (Subscribe).

Autre exemple, affichons dans les logs de notre package Python la consommation des CPU de l’ensemble des sentinelles Windows connectées dans notre Constellation en utilisant le package HWMonitor :

@Constellation.StateObjectLink(package = "HWMonitor", name = "/intelcpu/0/load/0")
def CPUUpdated(stateobject):
    Constellation.WriteInfo("CPU on %s is currently %s %" % (stateobject.SentinelName, stateobject.Value.Value))

Dans le cas où vous souhaiterez conserver la valeur de votre StateObject dans une variable de votre script Python pour pouvoir vous en servir dans d’autre méthode, il suffit tout simplement d’affecter le StateObject dans une variable globale depuis un StateObjectLink.

Reprenons l’exemple du thermostat Nest ci-dessus. Commençons par déclarer cette variable globale au niveau de notre script :

global nestThermostat

Puis ajoutons un StateObjectLink vers le StateObject du thermostat Nest pour mettre à jour notre variable globale :

@Constellation.StateObjectLink(package = "Nest", name = "Living Room")
def OnNestThermostatChanged(stateObject):
    global nestThermostat
    nestThermostat = stateObject.Value

Ainsi la variable « nestThermostat » contiendra la dernière valeur du StateObject représentant le thermostat Nest. Vous pourrez y accéder depuis n’importe quel endroit de votre script.

The post Consommer des StateObjects depuis l’API Python appeared first on Constellation.

La base : le Request & Subscribe de StateObjects

Le hub Constellation comporte deux méthodes :

• RequestStateObjects : permettant d’interroger « à un instant T »  des StateObjects de votre Constellation
• SubscribeStateObjects : permettant de s’abonner aux mises à jours des StateObjects de votre Constellation

Ces deux méthodes acceptent jusqu’à 4 paramètres, tous optionnels :

string sentinel = "*", string package = "*", string name = "*", string type = "*"

Vous devez définir le ou StateObjects que vous souhaitez récupérer (Request) ou suivre (Subscribe) en appliquant des filtres. Le wildcard “*” permet de tout sélectionner, c’est à dire de ne pas filtrer.

Par exemple, pour récupérer tous les StateObjects du package “MonPackage” (et peut importe le nombre d’instance du package) :

PackageHost.RequestStateObjects(package: "MonPackage");

Si vous souhaitez tous les StateObjects du package “MonPackage” qui tourne sur une sentinelle en particulier, nommée ci-dessous « MA-SENTINELLE » :

PackageHost.RequestStateObjects(sentinel:"MA-SENTINELLE", package: "MonPackage");

Pour cibler un StateObject en participer sur une instance d’un package :

PackageHost.RequestStateObjects(sentinel: "MA-SENTINELLE", package: "MonPackage", name:"MonStateObject");

Bien entendu, vous pouvez définir la combinaison que vous souhaitez !

Par exemple, récupérons tous les StateObjects de type “HWMonitor.HardwareList” dans notre Constellation :

PackageHost.RequestStateObjects(type: "HWMonitor.HardwareList");

Comme on sait que ce type de StateObject ne peut être publié que par le package “HWMonitor”, on pourrait écrire :

PackageHost.RequestStateObjects(package: "HWMonitor", type: "HWMonitor.HardwareList");

Dans les deux cas (Request ou Subscribe) les StateObjects sont reçus un par un par l’événement .NET : “PackageHost.StateObjectUpdated”.

Par exemple, déployons le package”HWMonitor” et analysons le StateObject “Hardware” via le StateObject Explorer :

On retrouve un StateObject de type “HWMonitor.HardwareList” qui contient une liste du hardware de la machine.

Dans notre package nous allons récupérer tous les StateObjects de type “HWMonitor.HardwareList” (donc autant de StateObjects que nous avons d’instance de ce package dans notre Constellation).

On pourrait écrire :

PackageHost.StateObjectUpdated += (s, e) =>
{
    PackageHost.WriteInfo("Hardware sur la machine {0}", e.StateObject.SentinelName);
    foreach (dynamic hw in e.StateObject.DynamicValue)
    {
        PackageHost.WriteInfo("{0} ({1})", hw.Name, hw.Identifier);
    }
};
PackageHost.RequestStateObjects(package: "HWMonitor", type: "HWMonitor.HardwareList");

En testant notre package dans Constellation :

Notez qu’ici nous avons utilisé la méthode « RequestStateObjects » c’est à dire que nous récupérons tous les StateObjects du package HWMonitor (quelque soit la sentinelle) de type « HWMonitor.HardwareList » au moement de l’invocation de la méthode.

Allons un peu plus long en affichant en temps réel la consommation du CPU. Cette valeur est publiée dans le StateObject “/intelcpu/0/load/0” par le package HWMonitor.

Pour suivre en temps réel la consommation du CPU des machines (sentinelles) sur lesquelles le package HWMonitor est déployé, on commence par s’abonner à ce StateObject :

PackageHost.SubscribeStateObjects(package: "HWMonitor", name: "/intelcpu/0/load/0");

Puis dans l’événement “StateObjectUpdated” il faudra différencier le traitement en fonction du StateObject reçu.

Le code final :

PackageHost.StateObjectUpdated += (s, e) =>
{
    if (e.StateObject.Name == "Hardware")
    {
        PackageHost.WriteInfo("Hardware sur la machine {0}", e.StateObject.SentinelName);
        foreach (dynamic hw in e.StateObject.DynamicValue)
        {
            PackageHost.WriteInfo("{0} ({1})", hw.Name, hw.Identifier);
        }
    }
    else if (e.StateObject.Name == "/intelcpu/0/load/0")
    {
        PackageHost.WriteInfo("CPU de {0} = {1}%", e.StateObject.SentinelName, e.StateObject.DynamicValue.Value);
    }
};
PackageHost.RequestStateObjects(package: "HWMonitor", type: "HWMonitor.HardwareList");
PackageHost.SubscribeStateObjects(package: "HWMonitor", name: "/intelcpu/0/load/0");

Notez qu’ici nous avons utilisé la méthode « SubscribeStateObjects » c’est à dire que nous nous abonnons à tous les StateObjects nommés “/intelcpu/0/load/0” du package HWMonitor (quelque soit la sentinelle). C’est un abonnement, donc à chaque modification des StateObjects respectant notre filtre, nous recevrons dans notre code les nouvelles valeurs des StateObjects.

Cependant, si les StateObjects changent peu fréquemment, nous n’obtenons rien immédiatement. C’est pourquoi il est parfois nécessaire de faire un Request suivi d’un Subscribe pour obtenir la version actuelle du/des StateObject(s) et s’abonner aux mises à jour futures.

Les StateObjectLink

Pour simplifier l’exploitation des StateObjects dans votre code, l’API Constellation introduit la notion de “StateObjectLink”.

Avec l’API.NET, il vous suffit simplement de déclarer une propriété .NET dans votre code que vous allez décorer avec l’attribut [StateObjectLink].

Votre propriété .NET peut être privée ou publique, d’instance ou statique. De plus le type de votre propriété .NET peut être :

• Un type de base
• Un type complexe
• Un dynamic
• Un StateObject
• Un StateObjectNotifier
• Un StateObjectCollectionNotifier

Par défaut seules les propriétés .NET de l’instance de votre package (IPackage) sont enregistrées. Si dans votre package vous instanciez des classes contenants des StateObjectsLink vous devez appeler la méthode “PackageHost.RegisterStateObjectLinks” en passant l’instance de votre classe pour l’enregistrement de ses StateObjectLinks (autrement les propriétés resteront nulles).

PackageHost.RegisterStateObjectLinks(monObjet);

Lier la valeur d’un StateObject à une propriété NET

Prenons l’exemple du StateObject “MyNumber” que vous avons publié dans cet article par la ligne :

PackageHost.PushStateObject("MyNumber", 123);

Pour qu’un autre package puisse l’inclure dans son code, on peut simplement écrire :

[StateObjectLink(Name = "MyNumber")]
public int MyNumber { get; set; }

Ici la propriété est de type “int” (car la valeur du StateObject est un int) et est liée à la valeur de ce StateObject.

Dès que le StateObject est mis à jour (PushStateObject) par le package qui la produit, votre propriété est également mise à jour de sorte que vous ayez toujours la dernière valeur du StateObject dans votre propriété.

Bien entendu la valeur du StateObject doit être compatible avec le type de la propriété liée (même type ou cast implicite possible), sinon la valeur du StateObject lié ne sera jamais affecté à votre propriété.

Vous pouvez également utiliser des types complexes. Par exemple prenons l’exemple déjà cité ci-dessus :

PackageHost.PushStateObject<MyCustomObject>("MyObject",  new MyCustomObject() { String = "test", Number = 123 });

Pour créer le StateObjectLink depuis un autre package, on pourra écrire :

[StateObjectLink(Name = "MyObject")]
public MyCustomObject MyObject { get; set; }

La propriété “MyObject” sera bien du type “MyCustomObject” et sera lié au StateObject nommé “MyObject”.

Cela sous entend que votre package ait la même définition du type “MyCustomObject” : soit en recopiant la classe ou soit en partageant une assembly commune. Notez toutefois que, comme Constellation connait la description des types utilisés par les StateObjects ou MessagesCallbacks, il est possible de générer le code (lire ici).

Maintenant si le StateObject est un type anonyme ou que vous n’avez pas la définition du type dans votre code, vous pouvez utiliser le type “dynamic”.

On pourrait alors écrire :

[StateObjectLink(Name = "MyObject")]
public dynamic MyObject { get; set; }

Pour terminer reprenons notre StateObject “Hardware” publié par le package HWMonitor :

[StateObjectLink(Package = "HWMonitor", Type = "HWMonitor.HardwareList")]
private dynamic Hardware { get; set; }

Et à tout moment dans votre code pour pourrez itérer sur cette liste :

foreach (dynamic hw in this.Hardware)
{
    PackageHost.WriteInfo("{0} ({1})", hw.Name, hw.Identifier);
}

On pourrait reprendre également l’exemple du CPU mais nous aurions un problème : comment savoir quand le StateObject à été mis à jour pour afficher la nouvelle valeur ? C’est que nous verrons avec le StateObjectNotifier ci-dessous.

L’unicité des liens

Dans les exemples ci-dessus, nous lions des propriétés .NET aux StateObjects de votre Constellation en utilisant seulement leurs noms (Name). Or comme vous le savez il peut y avoir, dans votre Constellation, plusieurs packages sur plusieurs sentinelles qui publient des StateObjects avec le même nom !

De ce fait, je peux par exemple écrire :

[StateObjectLink(Package = "MonPackage", Name = "MyObject")]
public dynamic MyObject { get; set; }

Ici, je crée un lien entre cette propriété .NET et les StateObjects nommés “MyObject” et publiés par le package “MonPackage”. Mais je ne sais pas combien d’instance du package “MonPackage” je trouverai dans ma Constellation (je pourrais déployer ce package sur toutes mes sentinelles).

L’unicité ne peut se faire qu’avec le triplet : Nom de la sentinelle + Nom du package + Nom du StateObject.

[StateObjectLink(Sentinel = "MON-PC", Package = "MonPackage", Name = "MyObject")]
public dynamic MyObject { get; set; }

Dans ce dernier cas j’ai la garantie de lier cette propriété .NET à un et un seul StateObject : celui nommé “MyObject” publié par le package “MonPackage” et déployé sur la sentinelle “MON-PC”.

Dans le cas où votre lien correspond à plusieurs StateObjects, chaque mise à jours de l’un d’entre eux est affectée à la propriété.

Ainsi si vous avez un package nommé “MonPackage” qui tourne sur deux sentinelles (disons “PC1” et “PC2”), votre propriété “MyObject” définie ci-dessous sera tantôt liée à la valeur du StateObject publié par le package sur PC1 tantôt sur l’instance de PC2.

[StateObjectLink(Package = "MonPackage", Name = "MyObject")]
public dynamic MyObject { get; set; }

Soyez donc vigilant aux liens que vous créez, ou sinon utilisez les StateObjectCollectionNotifier comme nous le verrons dans la suite de cet article.

Lier le StateObject entier à une propriété .NET

Jusqu’à présent nous avons lier des propriétés .NET avec les valeurs de StateObjects. Une fois la liaison établie, vous pouvez utiliser ces propriétés pour accéder à la valeur des StateObjects mais non au StateObject lui même.

Le StateObject contient à la fois la valeur du StateObject mais également les propriétés du StateObject comme son nom, le couple sentinelle/package qui l’a publié, sa date de publication, sa durée de vie (lifetime), son type ou encore des métadonnées (dictionnaire de string/object).

Pour cela, il suffit simplement de créer une propriété de type “StateObject”.

Par exemple pour le StateObject “Hardware” du package “HWMonitor” de la sentinelle “MON-PC” (pour n’avoir qu’une seule valeur), on peut écrire :

[StateObjectLink("MON-PC", "HWMonitor", "Hardware")]
private StateObject Hardware { get; set; }

Vous aurez ensuite accès aux différentes propriétés de votre StateObject :

La valeur du StateObject peut être obtenue par la propriété “Value” ou “DynamicValue”.

La propriété “DynamicValue” retourne la “Value” en tant qu’objet dynamique. Dans le cas d’un objet complexe, la “Value” sera de type JObject ou JArray.

Il est donc conseillé de travailler directement avec la “DynamicValue” pour résoudre dynamiquement la valeur de votre StateObject.

Vous disposez également d’une méthode GetValue<T> (ou son équivalent TryGetValue) qui se chargera de convertir votre valeur de StateObject en T .

StateObjectNotifier : être notifié des mises à jour des StateObjects liés

Jusqu’à présent nous lions des propriétés .NET avec la valeur d’un StateObject ou le StateObject lui même.

Dans les deux cas, vous pouvez accéder à tout moment à la dernière version de votre StateObject (ou sa valeur) publié dans votre Constellation car un StateObjectLink réalise implicitement un RequestStateObjects à l’initialisation de la propriété puis s’abonne aux StateObjects (SubscribeStateObject) pour mettre à jour en temps réel votre propriété dès que le ou les StateObjects liés sont mis à jour.

Seulement vous ne savez pas “quand” vos StateObject liés sont mis à jour, autrement dit quand est-ce que vos propriétés .NET sont mises à jour.

Pour cela il existe les StateObjectNotifiers. Le principe est simple, vous devez simplement créer une propriété liés de type StateObjectNotifier.

Reprenons le StateObject du CPU publié par le package HWMonitor sur “MON-PC” :

[StateObjectLink("MON-PC", "HWMonitor", "/intelcpu/0/load/0")]
private StateObjectNotifier CPU { get; set; }

La classe StateObjectNotifier un container de StateObject. Elle comporte une propriété “Value” dans laquelle est contenu le StateObject.

StateObject stateObjectActuel = this.CPU.Value;

On peut donc afficher la consommation à instant T :

PackageHost.WriteInfo("CPU = {0}%", this.CPU.Value.DynamicValue.Value);

Pour détailler :

• this (l’instance courante)
• .CPU (le StateObjectNofitier lié au StateObject de notre CPU)
• .Value (l’objet StateObject en question)
• .DynamicValue (la valeur du StateObject sous forme dynamique)
• .Value (la propriété de l’objet publié par le package HWMonitor)

Notez que le StateObjectNotifier comporte une propriété “DynamicValue” qui retourne la “DynamicValue” du StateObject (en clair : StateObjectNotifier.DynamicValue = StateObjectNotifier.Value.DynamicValue).

On peut donc simplifier  le code par :

PackageHost.WriteInfo("CPU = {0}%", this.CPU.DynamicValue.Value);

Lorsque le (ou les) StateObjets liés sont mis à jour, l’instance du StateObjectNotifier reste inchangée, c’est seulement sa propriété Value qui est mis à jour. De ce fait il est possible de s’abonner à des événements sur un StateObjectNotifier.

A ce sujet, le StateObjectNotifier implémente l’interface bien connue en .NET et notamment dans le monde WPF : “INotifyPropertyChanged”.

De ce fait, un StateObjectNotifier comporte un événement “PropertyChanged” qui vous informera lorsque le StateObject change.

this.CPU.PropertyChanged += (s, e) =>
{
    PackageHost.WriteInfo("Le StateObject a été mis à jour");
    PackageHost.WriteInfo("CPU = {0}%", this.CPU.DynamicValue.Value);
};

Très pratique notamment pour rafraichir une interface graphique WPF (binding WPF).

De plus le StateObjectNotifier comporte un 2ème événement qui se déclenche lui aussi à la mise à jour du StateObject : le “ValueChanged”.

La différence avec le PropertyChanged réside dans l’EventArgs passé lorsque l’événement se déclenche :

Le “StateObjectChangedEventArgs” fourni trois propriétés :

• NewState : la nouvelle version du StateObject
• OldState : l’ancienne version du StateObject
• IsNew : un booléen qui indique si c’est un “nouveau” StateObject (c’est à dire que OldState est null)

On peut donc comparer l’évolution du StateObject

this.CPU.ValueChanged += (s, e) =>
{
    if (e.IsNew)
    {
         PackageHost.WriteInfo("CPU = {0}%", e.NewState.DynamicValue.Value);
    }
    else
    {
         double difference = (double)e.NewState.DynamicValue.Value - (double)e.OldState.DynamicValue.Value;
         PackageHost.WriteInfo("CPU = {0}% - TENDANDE: ", e.NewState.DynamicValue.Value, difference > 0 ? "A LA HAUSSE" : "A LA BAISSE");
    }
};

StateObjectLink et Notifier personnalisés

Notez que vous pouvez créer vos propres attributs “StateObjectLink” personnalisés en héritant de la classe “StateObjectLinkAttribute”.

De la même façon vous pouvez également créer vos propres StateObjectNotifier en créant simplement une classe qui hérite de “StateObjectNotifier”.

StateObjectCollectionNotifier : collection de StateObjectNotifier

Comme nous l’avons vu plus haut, si un StateObjectLink peut lier plusieurs StateObjects dans la même propriété .NET. Chaque mise à jour d’un des StateObjects “remplace” le précèdent !

Pour pouvoir lier plusieurs StateObjects dans une seule propriété .NET, nous pouvons utiliser les StateObjectCollectionNotifiers. La classe StateObjectCollectionNotifier est une ObservableCollection de StateObjectNotifier.

Prenons cet exemple :

[StateObjectLink("HWMonitor", "/intelcpu/0/load/0")]
public StateObjectCollectionNotifier CPUs { get; set; }

Nous utilisons le constructeur du StateObjectLink où le 1er argument est le nom du package et le 2ème le nom du StateObject.

Pour faciliter la compréhension, on peut également utiliser les paramètres nommés :

[StateObjectLink(Package = "HWMonitor", Name = "/intelcpu/0/load/0")]
public StateObjectCollectionNotifier CPUs { get; set; }

Nous créons donc un lien vers le StateObjects “/intelcpu/0/load/0” du package HWMonitor (celui qui correspond à la consommation du CPU).

On aura donc un StateObject par sentinelle où ce package est déployé.

Par exemple, dans ma Constellation on trouve 9 StateObjects qui correspond, un par machine (sentinelle) :

Comme il s’agit d’une collection de StateObjectNotifier, vous pouvez itérer pour chaque StateObject afin d’afficher par exemple le CPU de chaque sentinelle où le package “HWMonitor” est déployé :

foreach (StateObjectNotifier stateobject in this.CPUs)
{
     PackageHost.WriteInfo("CPU sur {0} = {1}%", stateobject.Value.SentinelName, stateobject.DynamicValue.Value);
}

Tout comme le StateObjectNotifier, la classe StateObjectCollectionNotifier comporte aussi l’évènement ValueChanged :

this.CPUs.ValueChanged += (s, e) =>
{
     PackageHost.WriteInfo("CPU sur {0} = {1}%", e.NewState.SentinelName, e.NewState.DynamicValue.Value);
};

Générer du code

Le principe est le même que la génération de code pour les MessageCallbacks.

Ouvrez le générateur de code (clic-droit sur votre projet dans Visual Studio > Constellation > Generate Code) et sélectionnez votre Constellation puis cliquez sur “Discover”. Sélectionnez ensuite les packages que vous souhaitez ajouter dans votre code et cliquez sur “Generate”.

Comme pour les MessageCallbacks, vous devez ajouter le namespace correspondant aux “StateObjects” du package que vous souhaitez manipuler.

Par exemple pour inclure les StateObjects du package “MonPremierPackage” :

using ConstellationPackageConsole1.MonPremierPackage.StateObjects;

Ensuite créez votre propriété .NET liée à un StateObject mais en utilisant le StateObjectLink généré par package.

Exemple, pour les StateObjects du package “MonPremierPackage”, vous avez la classe “MonPremierPackageStateObjectLink”.

Inutile de définir le “PackageName” sur ce StateObjectLink par il est nativement fixé par cet attribut personnalisé.

Pour le nom du StateObject, vous pouvez utiliser l’énumération MonPremierPackageStateObjectNames générée par le générateur de code :

Par exemple, pour lier notre propriété “MonObject” au StateObject “MyObject” publié par le “MonPremierPackage” (revoir l’exemple ici), on peut écrire :

[MonPremierPackageStateObjectLink(MonPremierPackageStateObjectNames.MyObject)]
public StateObjectNotifier MonObject { get; set; }

Ensuite, sur chaque StateObject ou StateObjectNotifier, vous trouverez des méthodes d’extension permettant de convertir la valeur du StateObject dans le type généré dans votre code à partir de la description du package :

Par exemple, pour convertir votre StateObjectNotifier en “MyCustomObject”, le type du StateObject défini dans le package “MonPremierPackage” :

MyCustomObject myObject = this.MonObject.AsMonPremierPackageMyCustomObject();

Chaque type de StateObject décrit dans la Constellation est reproduit par le générateur de code dans votre projet.

Vous retrouvez alors toutes les propriétés du StateObject proprement typées et documentées :

N’hésitez pas lire cet article très complet sur la génération de code C# dans Constellation.

The post Consommer des StateObjects appeared first on Constellation.

Chaque package UI pourra invoquer ou exposer des MessageCallbacks, consommer ou produire des StateObjects, etc…

Hello World WPF

Dans Visual Studio, vous créez un package WPF :

Le template est une application WPF classique :

Le IPackage de ce package est la classe “App” (App.xaml.cs). Ce package lance la fenêtre MainWindow au démarrage (méthode “OnStart”).

La “MainWindow” est une Window WPF classique à l’exception que dans le constructeur, on enregistre automatiquement les [StateObjectLink] et les [MessageCallback] de la classe. De plus on renvoie la description du package (dans le cas où vous avez ajoutez des MessageCallbacks).

public partial class MainWindow : Window
{
    public MainWindow()
    {
        PackageHost.RegisterStateObjectLinks(this);
        PackageHost.RegisterMessageCallbacks(this);
        PackageHost.DeclarePackageDescriptor();
        InitializeComponent();
    }

    private void Window_Loaded(object sender, RoutedEventArgs e)
    {
        this.Title = string.Format("IsRunning: {0} - IsConnected: {1} - IsStandAlone: {2}", PackageHost.IsRunning, PackageHost.IsConnected, PackageHost.IsStandAlone);
        PackageHost.WriteInfo("I'm running !");
    }
}

Au chargement de la fenêtre on logge un message dans Constellation et on affiche quelques propriété sur l’état du package dans le titre de cette fenêtre !

Ajoutons un simple label “Hello World” au centre de notre fenêtre :

<Label x:Name="label" Content="Hello World" HorizontalAlignment="Center" VerticalAlignment="Center" FontSize="48"/>

Le code XAML sera donc:

<Window x:Class="MonPackageWPF.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525" Loaded="Window_Loaded">
    <Grid>
        <Label x:Name="label" Content="Hello World" HorizontalAlignment="Center" VerticalAlignment="Center" FontSize="48"/>
    </Grid>
</Window>

Pour tester notre package en debug sans être connecté à Constellation : “F5”

Vous noterez que les WriteLog Constellation sont toujours afficher dans la fenêtre de sortie de Visual Studio.

Maintenant pour lançons le debug de notre package dans Visual Studio tout en le connectant à Constellation (raccourci Ctrl+Alt+F8)

Invoquer des MessageCallbacks

Vous pouvez invoquer ou exposer des MessageCallbacks comme n’importe quel package connecté dans votre Constellation.

Pour exposer des MessageCallbacks (des méthodes NET), il suffit d’ajouter l’attribut [MessageCallback] sur vos méthodes.

Pour invoquer des MessageCallbacks, il faut créer un scope et envoyer le message. Grace au proxy dynamique, vous pouvez invoquer un MessageCallback comme vous invoquerez une méthode .NET.

Dans cet exemple nous allons invoquer des MessageCallbacks des packages WindowsControl et GoogleTraffic. Vous pouvez suivre le guide ici pour déployer ces deux packages.

En vous rendant sur la page “MessageCallbacks Explorer” de la Console, vous pouvez explorer les MC exposés par les packages.

Par exemple, le package WindowsControl expose plusieurs MessageCallbacks pour arrêter, redémarrer, mettre en veille ou verrouiller l’ordinateur (= la sentinelle) sur lequel le package est déployé.

Le package GoogleTraffic expose un MessageCallback “GetRoute” pour calculer le temps de route en spécifiant un point de départ et d’arrivée. Ce MessageCallback  est une saga pour vous retourner la réponse.

Pour simplifier le développement et éviter de travailler avec des types dynamiques, nous allons auto-générer le code.

Cliquez sur le bouton “Generate Code” :

Sélectionnez votre Constellation, cliquez sur “Discover” et sélectionnez les packages que vous souhaitez ajouter dans le code généré puis cliquez sur “Generate” :

Editez le code de la MainWindow (MainWindow.xaml.cs) pour ajouter le code généré des MessageCallbacks pour les packages GoogleTraffic et WindowsControl :

using MonPackageWPF.GoogleTraffic.MessageCallbacks;
using MonPackageWPF.WindowsControl.MessageCallbacks;

Dans la vue XAML, ajoutons deux boutons : l’un pour mettre en veille et l’autre pour faire un test d’itinéraire :

<Button x:Name="btSleep" Content="Sleep !" HorizontalAlignment="Left" VerticalAlignment="Bottom" Margin="10" Width="75" Click="btSleep_Click"/>
<Button x:Name="btTestRoute" Content="Test Route" HorizontalAlignment="Center" VerticalAlignment="Bottom" Margin="10,0,0,10" Width="75" Click="btTestRoute_Click" />

Pour le premier bouton, nous allons sélectionner l’instance du package “WindowsControl” sur la sentinelle “PO_SEB” pour créer un scope afin d’invoquer le MessageCallback “Sleep” :

private void btSleep_Click(object sender, RoutedEventArgs e)
{
    MyConstellation.PackageInstances.PO_SEB_WindowsControl.CreateWindowsControlScope().Sleep();
}

Prenez garde à créer un scope sur une instance (sentinelle + package) car sinon, si vous créez un scope sur le package “WindowsControl”, toutes les sentinelles hébergeant ce package se mettront en veille !

Pour le deuxième bouton, nous allons demander les différentes routes pour un “Lille-Paris”. Comme il s’agit d’une saga (message avec réponse) nous allons l’invoquer en “async/await” et afficher dans le label la meilleure route :

private async void btTestRoute_Click(object sender, RoutedEventArgs e)
{
    label.Content = "Calcul en cours ...";
    var route = await MyConstellation.Packages.GoogleTraffic.CreateGoogleTrafficScope().GetRoutes("lille", "paris");
    var bestRoute = route.OrderBy(r => r.TimeWithTraffic).FirstOrDefault();
    label.Content = $"{bestRoute.Name}\nDistance:{bestRoute.DistanceInKm}km\nTemps : {bestRoute.TimeWithTraffic}";
}

Lancer le debug dans Constellation :   (ou Ctrl+Alt+F8).

Premier test, en cliquant sur Sleep, vous allez envoyer un message pour invoquer le MessageCallback “Sleep” du package “WindowsControl” sur la sentinelle ici nommée “PO-SEB”. Ainsi le Windows “PO-SEB” se mettra instantanément en veille !

Deuxième test, pour invoquer le MessageCallback “GetRoutes” du package GoogleTraffic :

Consommer des StateObjects dans votre vue XAML

Assurez-vous d’avoir dans votre Constellation au moins un package “HWMonitor” déployé sur une sentinelle. Au besoin, vous pouvez suivre ce guide ici.

Pour comprendre en détail, la consommation des StateObjects dans vos packages n’hésitez pas à relire cet article.

Par exemple, pour afficher en temps réel la consommation CPU (StateObject nommé “/intelcpu/0/load/0”) mesurée par le package HWMonitor sur sa sentinelle (ici “PO-SEB”), ajoutons un StateObjectLink :

[StateObjectLink("PO-SEB", "HWMonitor", "/intelcpu/0/load/0")]
public StateObjectNotifier CPU { get; set; }

Vous pouvez également générer du code en sélectionnant le package HWMonitor. Vous pourrez ensuite ajouter un “using” vers les StateObjects de ce package :

using MonPackageWPF.HWMonitor.StateObjects;

Cela vous permettra d’utiliser un le “HWMonitorStateObjectLink” avec des énumérations générées pour vos sentinelles et nom de StateObjects :

[HWMonitorStateObjectLink(MyConstellation.Sentinels.PO_SEB, HWMonitorStateObjectNames._intelcpu_0_load_0)]
public StateObjectNotifier CPU { get; set; }

Comme vous le savez, le StateObjectNotifier implémente l’interface INotifyPropertyChanged. Vous pouvez donc lier cette propriété dans votre vue XAML pour voir votre StateObject en temps réel sur votre interface.

Nous allons modifier le label “Hello World” pour afficher en temps réel votre consommation CPU. Pour cela changeons le contenu (Content) du label avec la propriété “Value” du StateObject publié par le package HWMonitor.

Cette propriété contient la valeur (ici de l’utilisation du CPU) avec un nombre décimal. Nous ajoutons également l’attribut “ContentStringFormat” pour n’afficher que 2 chiffres après la virgule.

<Label x:Name="label" Content="{Binding Path=CPU.DynamicValue.Value}" ContentStringFormat="{}{0:N2}%" HorizontalAlignment="Center" VerticalAlignment="Center" FontSize="48"/>

Pour pourvoir utiliser des propriétés .NET comme binding dans votre vue XAML, vous devez spécifier le DataContext de votre fenêtre vers votre classe MainWindow soit via le code (this.DataContent = this) ou soit directement dans votre vue XAML en ajoutant cette attribut sur l’élément Window :

DataContext="{Binding RelativeSource={RelativeSource Self}}"

Résultat, vous pouvez suivre en temps réel le CPU ici de la machine “PO-SEB” :

Allons un peu plus loin en ajoutons dans notre code C#, un nouveau StateObjectLink :

[HWMonitorStateObjectLink(HWMonitorStateObjectNames._intelcpu_0_load_0)]
public StateObjectCollectionNotifier CPUs { get; set; }

Ce “lien” ne précise que le nom du StateObject (ici “/intelcpu/0/load/0”) et le package (HWMonitorStateObjectLink est la classe générée qui spécifie implicitement le package à “HWMonitor).

De ce fait, toutes les consommations CPU mesurées par les instances du package HWMonitor seront captées par ce “link” ! On utilisera donc un StateObjectCollectionNotifier car on aura autant de StateObjects qu’on a d’instance de ce package.

Dans la vue XAML, ajoutons un menu déroulant (combobox) pour afficher le nom des sentinelles (= le nom des machines) des StateObjects de votre collection “CPUs” :

<ComboBox x:Name="comboBox" ItemsSource="{Binding Path=CPUs}" DisplayMemberPath="Value.SentinelName" HorizontalAlignment="Left" Margin="10" VerticalAlignment="Top" />

Enfin, modifions une nouvelle fois notre label. Cette fois ci la valeur à afficher n’est pas celle du StateObject “CPU”, mais celle du StateObject sélectionné par la combobox :

<Label x:Name="label" Content="{Binding ElementName=comboBox, Path=SelectedItem.DynamicValue.Value}" ContentStringFormat="{}{0:N2}%" HorizontalAlignment="Center" VerticalAlignment="Center" FontSize="48"/>

On obtient donc la possibilité de suivre la consommation de chaque machine (= sentinelle) où le package HWMonitor est déployé :

Pour terminer on pourrait également ajouter un StateObjectLink qui contiendrait TOUS les StateObjects produits par les packages HWMonitor, peut importe le nom du StateObject et la sentinelle :

[HWMonitorStateObjectLink]
public StateObjectCollectionNotifier HWMonitor { get; set; }

Pour afficher toutes ces données, on peut utiliser un DataGrid lié à votre collection de StateObject “HWMonitor” :

<DataGrid ItemsSource="{Binding HWMonitor}"></DataGrid>

On obtiendrait une vue avec deux colonnes, la propriété DynamicValue et Value des StateObjectNotifier :

Pour rendre cela plus visuelle, définissions explicitement des colonnes avec le nom de la sentinelle, le nom du StateObject, la propriété “Name” de la valeur du StateObject  (le nom du compteur), la “Value” et l’unité de la mesure (Unit).

En XAML cela se traduit par le code suivant :

<DataGrid ItemsSource="{Binding HWMonitor}" AutoGenerateColumns="False" Margin="0, 0, 0, 40">
    <DataGrid.Columns>
        <DataGridTextColumn Header="Sentinel" Binding="{Binding Path=Value.SentinelName}"></DataGridTextColumn>
        <DataGridTextColumn Header="StateObject name" Binding="{Binding Path=Value.Name}"></DataGridTextColumn>
        <DataGridTextColumn Header="Counter name" Binding="{Binding Path=DynamicValue.Name}"></DataGridTextColumn>
        <DataGridTextColumn Header="Value" Binding="{Binding Path=DynamicValue.Value}"></DataGridTextColumn>
        <DataGridTextColumn Header="Unit" Binding="{Binding Path=DynamicValue.Unit}"></DataGridTextColumn>
    </DataGrid.Columns>
</DataGrid>

Le résultat :

Prenez garde car les StateObjects sont mis à jour dans le StateObjectsCollectionNotifier par des threads différents. Vous risquez donc d’avoir des exceptions du type “An ItemsControl is inconsistent with its items source”. Afin d’éviter ce genre d’erreur, utilisez la  méthode “BindingOperations.EnableCollectionSynchronization”.

Pour cela, dans votre classe, ajoutez un objet de synchronisation :

private static object _syncLock = new object();

Puis dans le constructeur de votre fenêtre, après le InitializeComponent(), activez la synchronisation de la collection sur votre StateObjectCollectionNotifier (ici nommé ‘HWMonitor’) :

BindingOperations.EnableCollectionSynchronization(HWMonitor, _syncLock);

Si lancez votre package dans une Constellation avec plusieurs instances du packages HWMonitor sur vos différentes sentinelles, vous aurez une vision temps réel de l’ensemble de vos machines Windows avec seulement ces quelques lignes de XAML et Constellation :

Déployez votre package UI

Publier le package

Le sujet a été traité dans le guide de démarrage, il suffit de cliquer-droit sur votre projet et sélectionner dans le menu Constellation “Publish On Constellation” ou directement depuis la toolbar :

Vous pourrez alors choisir le type de publication (Local ou Upload sur le serveur Constellation) :

Déployer le package sur une sentinelle UI

Vous devez impérativement déployer un package “UI” sur une sentinelle UI. Si vous tentez d’ajouter un package UI sur une sentinelle service, le package démarrera mais aucune fenêtre ne pourra être visible (le service ne peut pas interagir avec le bureau Windows).

Les sentinelles UI ont le suffixe “_UI” dans leurs noms. Ici pour cette Constellation, il y a deux sentinelles connectées, l’une de type “Service” et l’autre “UI”, toutes deux sur la même machine (nommé “PO-SEB”).

Pour ajouter notre package à la sentinelle UI, vous pouvez éditer la configuration de vos Constellation directement depuis Visual Studio :

Ou bien depuis la Console Constellation :

Pour déployer la configuration, cliquez sur le bouton “Save & Deploy” depuis la Console, ou directement sur la page des “Packages” cliquez sur “Reload & Deploy”.

Votre package UI sera démarré et vous pourrez le contrôler depuis la Console comme pour les autres packages.

Démarrer son package “manuellement”

Si vous créez une application à destination d’une borne d’affichage, comme un miroir, le package est démarré automatiquement par la sentinelle (comportement par défaut) et est relancé si le package plante !

Cependant, si votre package est destiné à être utilisé par un utilisateur comme une application Windows classique vous voudriez certainement ne pas la lancer automatiquement au démarrage de la sentinelle. Au contraire vous voudriez que ce soit l’utilisateur qui décide de la lancer en lançant un raccourci Windows par exemple sans devoir se connecter sur la Console de votre Constellation.

Pour cela vous pouvez lancer la sentinelle en passant un ordre en paramètre :

Constellation.Sentinel.UI.exe <action> <package>

Les actions peuvent être :

• Start
• Stop
• Restart
• Reload

Par exemple, créons un raccourci sur le bureau vers :

Constellation.Sentinel.UI.exe Reload MonPackageWPF

Ainsi dès que vous double-cliquerez sur ce raccourci, la sentinelle téléchargera la dernière version du package sur le serveur et lancera votre package (Reload) :

Bien entendu, l’état du package sera automatiquement synchronisé dans la Constellation. Vous pourrez donc contrôler l’état du package depuis la Console par exemple.

Par défaut, une sentinelle démarre tous les packages qui lui sont assignés. Si c’est un package destiné à être lancé manuellement par l’utilisateur, vous voudriez peut être ne pas lancer automatiquement le package. Vous pouvez donc définir l’attribut “autoStart” à false au niveau de la configuration de votre package.

Aussi l’ordre d’arrêt d’un package doit provenir du hub de contrôle de Constellation, qui se chargera de communiquer l’ordre au package lui même (de s’arrêter) et à sa sentinelle (de tuer le package si il ne s’est pas arrêté dans le temps imparti).

Seulement, dans un package UI de ce type, c’est à dire “application Windows classique”, l’utilisateur fermera naturellement l’application en cliquant sur la croix rouge en haut à droite !

La sentinelle détectera la mort du processus du package alors qu’elle n’a pas eu l’ordre de Constellation d’arrêter le package ! Du point de vue de la sentinelle, c’est un arrêt brutal !

Elle appliquera donc les options de récupération qui par défaut redémarre un package 30 secondes après un arrêt brutal :

Les options par défaut sont définis dans la configuration de la Constellation :

Dans notre cas, nous allons redéfinir ces options de récupération au niveau du package lui même pour ne pas redémarrer un package suite à un arrêt forcé et ne pas démarrer automatiquement notre package au démarrage. La configuration du package sera :

The post Créer des packages UI en Winform ou WPF appeared first on Constellation.