Le package à publier est celui marqué comme “Projet de démarrage” dans le cas où vous avez plusieurs projet dans votre solution Visual Studio.

Autrement cliquez-droit sur le projet que vous souhaitez publier et cliquez sur “Publish Constellation package” dans le menu “Constellation” :

Vous pourrez ensuite publier votre package en local ou directement sur un serveur Constellation.

Publication locale

Il suffit d’indiquer un répertoire de sortie et un nom de fichier :

Publication sur un serveur Constellation

Pour publier votre package sur un serveur Constellation sélectionnez la méthode “Upload on Constellation Server” et indiquez le serveur à utiliser :

Pour gérer les serveurs Constellation depuis Visual Studio, consultez cet article.

Une confirmation vous indiquera le bon déroulé de la publication :

Notez que vous pouvez suivre le détail du processus de publication dans la fenêtre “Output” de Visual Studio :

Une fois publié, votre package sera disponible dans le Package Repository de votre Constellation et sera prêt à être déployé sur une de vos sentinelles :

The post Publier un package depuis Visual Studio appeared first on Constellation.

C’est grâce à cette description, que l’on nomme le “PackageDescriptor” que fonctionne le “MessageCallback Explorer” de la Console Constellation par exemple.

L’interface est capable de lister chaque MessageCallbacks  de chaque packages de votre Constellation avec un formulaire pour la saisie des paramètres (simples ou complexes) afin de tester simplement vos MC.

En cliquant sur le bouton , le “MessageCallback Explorer” de la Console Constellation vous propose des “code snippets” pour différents langages (C#, Python, Arduino, JS, etc.).

Pourquoi générer du code ?

Comme vous le savez, en C# pour envoyer un message et donc invoquer un MC d’un autre package, vous devez créer un scope et invoquer le MC en utilisant un proxy dynamique.

Par exemple pour invoquer le MC “AreaArm” du package Paradox, on pourrait écrire :

PackageHost.CreateMessageProxy("Paradox").AreaArm(new { Area = Paradox.Core.Area, Mode = Paradox.Core.ArmingMode, PinCode = System.String });

Il est important de noter ici que la méthode “CreateMessageProxy” retourne un “proxy dynamique”, c’est à dire que la méthode invoquée, ici “AreaArm” sera la clé du message.

Autrement dit, comme tout est dynamique, il y a aucune aide ou auto-complétion. On pourrait très bien écrire ceci :

PackageHost.CreateMessageProxy("Paradox").CeciEstUnExemple();

Votre package enverra un message “CeciEstUnExemple” au(x) package(s) Paradox de votre Constellation. Vous devez donc être vigilent sur le nom des MC invoqués car une erreur de frappe passera inaperçu !

Pour plus d’information sur l’envoi de messages & invocation de MessageCallbacks en C#, veuillez lire ceci.

Le “problème” est le même avec la consommation des StateObjects (lire ceci). Par exemple pour injecter dans votre code, le StateObject “/intelcpu/0/load/0” produit par le package “HWMonitor” sur la sentinelle “MON-PC”, on peut écrire :

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

Je peux donc ensuite exploiter la valeur de mon StateObject :

dynamic value = this.CPU.DynamicValue;

La propriété “Value” du StateObjectNotifier  me donne la valeur du StateObject et la propriété “Value” de ce StateObject me donne la valeur du StateObject. Vous pouvez utiliser la propriété “DynamicValue” directement sur le StateObjectNotifier  pour récupérer la valeur du SO sous forme d’un ”dynamic”.

Comme chaque StateObject est différent, je ne sais pas ne que je trouverai dedans (une valeur simple, un objet complexe, …). D’où l’intérêt d’utiliser le StateObject Explorer de la Console Constellation pour explorer les SO de votre Constellation.

Par exemple, le StateObject “/intelcpu/0/load/0” produit par le package “HWMonitor” est un objet complexe contenant 4 propriétés :

Alors que le StateObject de type “CarbonDioxideMeasurement” produit par le package “NetAtmo” est un entier :

C’est pour cela que dans votre code, la valeur d’un StateObject est “dynamique” : tout dépend du StateObject que vous consommez !

Que ce soit pour l’invocation de MessageCallback ou la consommation de StateObject, la forme “dynamique” permet de s’adapter à toutes les situations. En revanche vous perdez l’auto complétion ce qui peut vous ralentir mais aussi être une source d’erreur. D’où l’intérêt de générer du code dans votre package!

Générer du code depuis Visual Studio.

Le générateur de code inclut dans le SDK Constellation pour Visual Studio ne fonctionne que pour un projet C#.

Commencez tout d’abord par cliquer le bouton “Generate Code” dans la barre de menu :

Le code sera généré pour le projet marqué comme projet de démarrage dans le cas où votre solution contient plusieurs projets.

Autrement, en cliquant-droit sur le projet de votre choix, sélectionnez “Generate Code” dans le sous-menu “Constellation” :

Vous serez amené à sélectionner dans la liste déroulante la Constellation à cibler. Pour configurer des connexions vers vos Constellations, lisez ceci.

Une fois le serveur Constellation sélectionné, cliquez sur “Connect and Discover”. Vous obtiendrez la liste de toutes vos sentinelles et packages de votre Constellation :

Sélectionnez tout simplement la liste des packages que vous souhaitez inclure dans votre code. Par exemple, ici nous allons générer du code pour les packages “DoorBell”, “LightSensor”, “IRRemote”,”Paradox”, “Pionner” et “Vera”.

Après avoir cliqué sur le bouton “Generate”, un message de confirmation vous indiquera le bon déroulé de l’opération :

Le SDK génère le code dans le fichier “MyConstellation.generated.cs” :

Attention, vous ne devez pas modifier ce code directement car ce fichier est écrasé à chaque fois que vous relancer une génération.

Utiliser le code généré

Organisation du code généré

Le code généré dans le fichier “MyConstellation.generated.cs” s’organise dans plusieurs espaces de nom (namespaces) :

• Dans le namespace de votre assembly vous trouverez :
  • La classe statique “MyConstellation” représentant votre Constellation
  • Les classes utilitaires RealNameAttribute et RealNameExtension indispensable au fonctionnement du code généré
• Des namespaces par package
  • VotreNamespace.NomDuPackage.StateObjects : code généré pour les StateObjects (si des StateObjects sont déclarés pour le package)
  • VotreNamespace.NomDuPackage.MessageCallbacks : code généré pour les MessageCallbacks (si des MessageCallbacks sont déclarés pour le package)

Des énumérations pour les sentinelles, packages et instances de votre Constellation

La classe statique “MyConstellation” contient trois énumérations :

• Sentinels : contenant la liste des sentinelles de votre Constellation
• Packages : contenant le liste des packages de votre Constellation
• PackageInstances : contenant la liste des instances des packages de votre Constellation

Comme les noms de sentinelles ou packages peuvent contenir des caractères interdits en C# (comme par exemple les tirets), les valeurs des énumérations sont “nettoyées” et la valeur réelle se trouve dans l’attribut “RealName” que vous pouvez récupérer avec la méthode d’extension “GetRealName()”.

Dans notre exemple l’énumération “Sentinels” générée est la suivante :

/// <summary>
/// Specifies the sentinels in your Constellation
/// </summary>
public enum Sentinels
{
    /// <summary>
    /// Sentinel 'CEREBRUM'
    /// </summary>
    [RealName("CEREBRUM")]
    CEREBRUM,
    /// <summary>
    /// Sentinel 'ESP8266'
    /// </summary>
    [RealName("ESP8266")]
    ESP8266,
    /// <summary>
    /// Sentinel 'ESP-DoorBell'
    /// </summary>
    [RealName("ESP-DoorBell")]
    ESP_DoorBell,
    /// <summary>
    /// Sentinel 'ESP-LightSensorSalon'
    /// </summary>
    [RealName("ESP-LightSensorSalon")]
    ESP_LightSensorSalon,
    /// <summary>
    /// Sentinel 'esp-senergy'
    /// </summary>
    [RealName("esp-senergy")]
    esp_senergy,
    /// <summary>
    /// Sentinel 'SKYNET-SERVER'
    /// </summary>
    [RealName("SKYNET-SERVER")]
    SKYNET_SERVER,
}

De ce fait on peut manipuler les sentinelles et récupérer le nom réel avec la méthode “GetRealName()” :

MyConstellation.Sentinels sentinel = MyConstellation.Sentinels.ESP_DoorBell;
string realName = sentinel.GetRealName();

De plus, dans cette classe vous trouverez des méthodes d’extension pour créer un “MessageScope” vers une de vos sentinelles, packages ou instances de package.

Par exemple pour créer un scope vers les packages “Hue” :

MessageScope scope = MyConstellation.Packages.Hue.CreateScope();

Ce qui est équivalent à :

MessageScope scope = MessageScope.Create("Hue");

Sauf qu’avec le code généré plus besoin de chercher le nom exact ni même de risquer de faire une erreur de frappe, car tout est énumération !

On peut également cibler une instance d’un package en particulier. Par exemple pour cibler précisément le package “Hue” déployé sur la sentinelle “SKYNET-SERVER” :

MessageScope scope = MyConstellation.PackageInstances.SKYNET_SERVER_Hue.CreateScope();

Code généré pour les StateObjects

Prenons un exemple simple :  dans le code généré ci-dessus j’ai sélectionné le package “Paradox”, un package permettant de connecter les système d’alarme Paradox dans Constellation.

Ce package publie plusieurs StateObjects :

• Des StateObjects de type “AreaInfo” par secteur qui représente l’état d’un secteur (système armé ou non par exemple)
• Des StateObjects de type “ZoneInfo” par zone qui représente l’état d’une zone (zone ouverte ou non par exemple)
• Des StateObjects de type “UserInfo” par utilisateur qui représente l’état d’un utilisateur (nom de l’utilisateur, dernière activité, etc..)

Prenons par exemple le StateObject “ZoneInfo1” de ce package :

On y trouvera plusieurs informations sur l’état de cette zone.

Le code généré pour les StateObjects de ce package sera donc rangé dans le namespace : VotreNamespace.Paradox.StateObjects et contiendra :

• Une énumération “ParadoxStateObjectNames” référençant le nom des StateObjects actuellement connus sur le serveur
• Une classe “ParadoxStateObjectLinkAttribute” (spécialisation de la classe StateObjectLinkAttribute)
• Des classes pour chaque types personnalisés du package, ici le générateur aura généré les classes “AreaInfo”, “ZoneInfo” et “UserInfo”
• Une classe “ParadoxExtensions” contenant des méthodes d’extension pour convertir des StateObjects en type personnalisé

Voyons par exemple comment inclure notre StateObject de la zone “1” dans votre code C# avec le code généré.

Tout d’abord, il faut inclure le namespace :

using Paradox.StateObjects;

Ensuite ajoutons un “StateObjectLink” de type “ParadoxStateObjectLink” où nous préciserons le nom du StateObject avec l’énumération :

[ParadoxStateObjectLink(ParadoxStateObjectNames.ZoneInfo1)]
public StateObjectNotifier Zone1 { get; set; }

Sans le code généré nous aurions écrit :

[StateObjectLink(Package="Paradox", Name="ZoneInfo1")]
public StateObjectNotifier Zone1 { get; set; }

Je peux ensuite utiliser la méthode d’extension générée “AsZoneInfo()” pour convertir la valeur du StateObject en “ZoneInfo” (“ZoneInfo” étant un type personnalisé décrit par le package Paradox) :

Le générateur a “reproduit” ce type dans votre code généré avec les commentaires tel que spécifiés dans le PackageDescriptor du package Paradox.

Sans le code généré, vous devez travailler avec un objet dynamique, donc sans auto-complétion :

Bien entendu tous les Packages (virtuels ou non) peuvent déclarer des Packages Descriptor.

Prenez l’exemple d’un capteur d’électricité basé sur un ESP8266. En utilisant la librairie Constellation pour Arduino, le code C++ de ce package virtuel commence par déclarer le type “SEnergy.Electricity” :

constellation.addStateObjectType("SEnergy.Electricity", TypeDescriptor().setDescription("S-Energy Electricity data").addProperty("Counter", "System.Int64", "Number of revolution").addProperty("Timestamp", "System.Int64", "Internal timestamp of the last revolution").addProperty("RevolutionTime", "System.Double", "The time (in ms) of the last revolution").addProperty("WattPerHour", "System.Int32", "Energy consumed").addProperty("Cumul", "System.Int64", "Total of KWh consumed")); 
constellation.declarePackageDescriptor();

Puis à chaque fois que le capteur détecte une consommation électrique il publie un StateObject de la façon suivante :

StaticJsonBuffer<JSON_OBJECT_SIZE(5)> jsonBuffer;
JsonObject& myStateObject = jsonBuffer.createObject();
myStateObject["Counter"] = counter;
myStateObject["Timestamp"] = ts;
myStateObject["RevolutionTime"] = timePerRevolution;
myStateObject["WattPerHour"] = wattPerHour;
myStateObject["Cumul"] = cumul;
constellation.pushStateObject("Electricity", myStateObject, "SEnergy.Electricity", 600);

On retrouve bien ce StateObject sur la Console Constellation :

Après avoir sélectionné le package “SElectricity” dans le générateur de code, je peux très facilement exploiter ce StateObject avec auto-complétion, description, etc.. :

Par exemple pour suivre en temps réel la consommation électrique dans mon package C# avec le code généré à partir du capteur ESP8266 écrit en C++/Arduino :

namespace ConstellationPackageConsole2
{
    using Constellation.Package;
    using ConstellationPackageConsole2.SElectricity.StateObjects;

    public class Program : PackageBase
    {
        [SElectricityStateObjectLink(SElectricityStateObjectNames.Electricity)]
        public StateObjectNotifier Electricity { get; set; }

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

        public override void OnStart()
        {
            this.Electricity.ValueChanged += (s, e) =>
            {
                PackageHost.WriteInfo($"Current Energy Consumption : {e.NewState.AsSElectricitySEnergy_Electricity().WattPerHour}W @ {e.NewState.LastUpdate}");
            };
        }
    }
}

Code généré pour les MessageCallbacks

Le principe est le même avec les MessagesCallbacks, le générateur de code va créer le code dans le namespace “VotreNamespace.NomDuPackage.MessagesCallbacks” :

• Des classes pour chaque types personnalisés utilisés dans les MC du package
• Une classe “(NomDuPackage)Scope” permettant de référencer les MC sous forme de méthodes .NET
• Une classe “(NomDuPackage)Extensions” : classe d’extension pour créer un scope du package à partir d’un MessageScope ou des énumérations Sentinels, Packages, PackagesInstances générées par le générateur

MessageCallbacks avec ou sans paramètre

Prenons par exemple le package virtuel “IRremote”, un récepteur/émetteur d’infrarouge développé en Arduino/C++ sur un ESP8266. Ce package virtuel expose deux MessageCallbacks : “Restart” pour rebooter l’ESP et “SendCode” pour envoyer un signal IR.

En utilisant la librairie Constellation pour Arduino de ces deux MC se résume par ces quelques lignes de C++ :

// SendCode MessageCallback
constellation.registerMessageCallback("SendCode",
  MessageCallbackDescriptor().setDescription("Send the IR code").addParameter("encoding", "System.String").addParameter("code", "System.Int64"),
  [](JsonObject& json) {
    const char * encoder = json["Data"][0].asString();  
    unsigned long code = strtoul(json["Data"][1].asString(), NULL, 0);
    // send the "code" here !
 });

// Restart MessageCallback
constellation.registerMessageCallback("Restart",
  MessageCallbackDescriptor().setDescription("Restart the ESP"),
  [](JsonObject& json) {
    ESP.restart();
 });

Une fois l’ESP démarré, nos deux MessageCallbacks sont correctement référencés sur Console Constellation avec les listes des paramètres, types et description :

Dans Visual Studio, générons maintenant le code pour notre package “IRRemote” :

Ajoutons ensuite le namespace correspondant aux MessageCallbacks de notre package, ici “IRRemote” :

using IRremote.MessageCallbacks;

Vous pouvez ensuite utiliser l’énumération “Packages” (ou “PackagesIntances”) et accéder à la méthode d’extension “CreateIRRemoteScope” pour créer un scope spécifiquement pour notre package :

Vous avez également une méthode d’extension nommée “ToXXXXSCope()” sur un MessageScope. En clair vous avez plusieurs moyen de créer un scope spécifiquement pour votre package “IRremote” avec le code généré :

IRremoteScope scope =  MyConstellation.Packages.IRremote.CreateIRremoteScope();

IRremoteScope scope = new IRremoteScope(MessageScope.Create("IRRemote"));

IRremoteScope scope = MessageScope.Create("IRRemote").ToIRremoteScope();

IRremoteScope scope = MessageScope.Create(MyConstellation.Packages.IRremote.GetRealName()).ToIRremoteScope();

Ensuite sur la classe Scope généré pour votre package, ici “IRRemoteScope”, vous retrouverez vos MessageCallbacks sous forme de méthode .NET avec les paramètres et descriptions !

De ce fait vous disposez de l’auto complétion sans risque de faire des erreurs de frappe :

Ainsi pour envoyer un code IR sur l’Arduino/ESP depuis mon code C#, on pourrait écrire :

// Send Power ON/OFF to Samsung TV
MyConstellation.Packages.IRremote.CreateIRremoteScope().SendCode("Samsung", 0xE0E040BF);

MessageCallbacks avec des paramètres complexes

Ici le package “IRRemote” expose un MC sans paramètre et un autre avec deux paramètres simples (string et long).

Mais le générateur est également capable de gérer les types complexes. Par exemple prenez le package “Xbmc” permettant de piloter des média-centers Xbmc/Kodi.

Le package expose différents MessageCallbacks pour lancer un média, mettre pause, piloter le volume et également pour afficher un message à l’écran via le MessageCallback nommé “ShowNotification”.

Ce MessageCallback prend deux paramètres : le nom de l’hôte Xbmc (un string) et la notification à afficher. Cette notification est un objet de type “Xbmc.NotificationRequest” :

Sur la Console Constellation, vous pouvez cliquer sur les types personnalisés pour afficher les détails du type, ici un objet avec quatre propriétés :

Lorsque vous générez le code C# pour ce package vous retrouverez bien le MC “ShowNotification” avec le type personnalisé en paramètre :

Le générateur a en effet reproduit le type personnalisé dans votre code C# :

Ainsi pour afficher une notification sur un hôte Kodi, je pourrais écrire très simplement :

MyConstellation.Packages.Xbmc.CreateXbmcScope().ShowNotification("Kodi", new NotificationRequest() { Title = "Constellation", Message = "Hello World !" });

MessageCallbacks avec réponse : les sagas

Une invocation d’un MessageCallback peut donner lieu à une réponse, on appelle cela les “Sagas”. Avec l’API.NET, n’hésitez pas à relire les articles dédiés : Invoquer un MessageCallback avec réponse et Répondre à une saga.

Prenons un exemple, le package “Vera” (interface pour les box domotique) expose des MC pour envoyer des ordres à des périphériques Z-Wave :

Vous remarquerez d’ailleurs que les MC “SetDimmableLevel” et “SetSwitchState” prennent en argument un type complexe comme expliqué dans le chapitre précédent.

Vous remarquerez également que ces trois MC retournent un message de réponse, ici de type “Boolean”. En effet le résultat de l’exécution de l’ordre Z-Wave par la Vera est retourné à l’appellent si celui-ci à attaché un numéro de Saga.

Ainsi dans le code généré, les méthodes générées pour ces MessageCallbacks retournent une Task<T> où T est le type de retour, ici un booléen :

Ainsi dans le C# on peut très facilement invoquer le MessageCallback et récupérer la réponse :

bool result = await MyConstellation.Packages.Vera.CreateVeraScope().SetSwitchState(new DeviceRequest() { DeviceID = 42, State = false });
 if (result)
 {
     PackageHost.WriteInfo("Device #42 turn off !");
 }
 else
 {
     PackageHost.WriteWarn("Unable to turn off the device #42 !");
 }

Pour plus d’information à ce sujet, je vous recommande la lecture de l’article : Invoquer un MessageCallback avec réponse.

The post Le générateur de code C# appeared first on Constellation.

Vous pourrez alors ajouter, supprimer ou éditer des connexions vers vos serveurs Constellation :

Le bouton “Test” permet de tester la connectivité.

N’oubliez pas de sélectionner dans le liste déroulante en haut de la fenêtre, le serveur Constellation à utiliser pour le debug des packages.

The post Gérer les connexions Constellation appeared first on Constellation.

Vous retrouvez aussi ce bouton dans le menu contextuel (clique-droit) sur un projet Constellation:

Par défaut, Visual Studio ouvrira le fichier de configuration du serveur Constellation enregistré si il n’y en a qu’un. Autrement un fenêtre vous invitera à sélectionner le serveur Constellation à utiliser :

Pour gérer les serveurs Constellation dans Visual Studio, consultez cet article.

Une fois la configuration de votre serveur Constellation ouverte dans Visual Studio, vous pouvez l’éditer comme bon vous semble :

Vous disposerez de l’auto-complétion et de la validation du schéma de votre configuration :

Lorsque vous enregistrez ce fichier, Visual Studio vous proposera d’uploader le fichier modifié sur votre Constellation :

Vous pourrez également ordonner le rechargement de votre nouvelle configuration sur votre serveur :

Ici, si vous ouvrez la Console Constellation vous pourrez observer vos modifications :

The post Editer la configuration Constellation depuis Visual Studio appeared first on Constellation.

Nous allons dans cet article créer, tester et déployer sur votre Constellation un package Python avec cet outil.

Prérequis

Le « Constellation Package Tools CLI » est un outil en ligne de commande compatible Windows et Linux. Il est écrit en Python et s’installe via PIP avec la commande :

pip install constellation-pkgtools-cli

Sur Windows vous devriez au préalable avoir installé Python 2.7 ainsi que l’outil « pip » et les libraires « pyzmq » et « enum34 ». La procédure complète d’installation est décrite sur cette page.

Via une invite de commande, tapez la commande ci-dessus :

Sur Linux, vous devez également avoir installé Python 2.7 (généralement installé par défaut),  l’outil « pip » et les libraires « pyzmq » et « enum34 » sans oublier le moteur Mono. Pour cela, utilisez le WPI (Web Platform Installer) pour installer une sentinelle Constellation. Celui-ci se chargera de déployer l’ensemble des prérequis nécessaire.

La commande « ctln »

Une fois le package Python « constellation-pkgtools-cli » installé via PIP, vous aurez accès à une commande nommée « ctln » (abréviation de Constellation)

Cette commande vous permettra de créer de nouveau package, les tester et déployer en local ou directement sur un serveur Constellation.

Créer son premier package Python

Pour créer un nouveau package utilisez simplement la commande “create” en spécifiant le nom de votre package. Par exemple :

ctln create <mon projet>

Et voilà, votre package “MyFirstPackage” est créé dans le répertoire du même nom !

Template de package

Chaque package est créé à partir d’un template. Vous pouvez lister les templates avec la commande :

ctln template list

A l’heure où est écrit cet article il y a deux templates de type “projet” :

• Python Base Template : le template de base (créé par défaut)
• Python Demo template : package Python avec du code de “demo”

Lorsque vous créez un package avec la commande “ctln create”, le template “python-base” est sélectionné par défaut.

Vous pouvez cependant préciser l’Id du template à utiliser dans la commande “ctln create”. Par exemple pour créer un package sur base du template de demo :

ctln create <mon projet> python-demo

Il y a aussi des templates de type “item”, c’est à dire des templates pour les scripts que vous allez rajouter par la suite à votre package.

Mise à jour du template

Comme vous le constatez dans le listing des templates ci-dessus, chaque template comporte un numéro de version car ils sont amenés à évoluer notamment en cas de mise à jour des librairies Constellation.

Avec le SDK Constellation Visual Studio, les nouvelles versions des librairies sont diffusées avec NuGet. Ici avec cet outil en ligne de commande, les nouvelles librairies sont embarquées dans des mises à jour des templates.

Ainsi pour mettre à jour vos packages, vous pouvez tout simplement mettre à jour le template de votre package par la commande :

ctln update

Cette commande doit être lancé depuis le répertorie racine de votre package.

Notez également que la mise à jour est “intelligente” dans la mesure où elle n’écrase pas vos fichiers de configuration, le manifeste du package ou encore vos scripts Python.

Développer son package

Le développement de package Python est expliqué dans cet article. Bien que l’article se base sur Visual Studio, l’API Python est strictement identique.

Ainsi, pour rappel, vous avez à la racine de votre projet le fichier « PackageInfo.xml » qui contient l’ensemble des informations de votre package (plus de détail ici) mais aussi le fichier de configuration nommé « PythonPackageHost.exe.config » qui contient la liste des scripts Python à lancer.

Les bases du développement d’un script Constellation Python sont expliquées ici.

Pour faciliter le développement, vous n’êtes pas obligé de modifier manuellement le fichier de configuration pour gérer les scripts Python. Pour cela vous avez à disposition différentes commandes pour lister, ajouter, renommer ou supprimer des scripts.

Lister les scripts du package

Les scripts Constellation Python lancés par votre package peuvent être listés par la commande :

ctln pyscript list

Ici votre package « MyFirstPackage » ne contient qu’un seul script nommé « Main.py » dans le répertoire Scripts du package.

Ajouter des scripts Python

Pour ajouter un script Constellation Python, vous pouvez soit ajouter un script existant sur votre système de fichier dans votre package ou soit créer un nouveau script à partir d’un modèle (template).

Ajouter un script existant

Pour un script existant, il suffit d’utiliser l’option « add » :

ctln pyscript add <filepath> [--filename=<name>]

Vous devez spécifier le chemin complet vers votre fichier à ajouter (filepath) et optionnellement le nom du fichier une fois ajouté dans votre package.

Par exemple la commande ci-dessous ajoutera dans votre package le fichier « ~/demo/MyDemo.py » sous le nom « DemoSeb.py »

ctln pyscript add ~/demo/MyDemo.py --filename=DemoSeb.py

Ajouter de nouveau script

L’action la plus courante sera de créer un nouveau script Python dans votre package avec l’action « new » via la commande suivante :

ctln pyscript new <filename> [<item_template_name>]

Vous devez obligatoirement spécifier le nom du fichier (filename) avec ou sans l’extension .py (rajoutée automatiquement). Le script sera créé dans le répertoire Scripts de votre package et automatiquement déclaré dans la configuration.

Vous pouvez également spécifier l’identifiant du template à utiliser. Les templates peuvent être listés avec la commande « ctln template list » comme vu ci-dessus.  A l’heure où cet article est écrit il y a trois templates de type « item » :

• « python-base » : le template de base
• « python-demo »  : un template avec du code de demonstration
• « python-empty »  : un squelette vide

Si vous ne précisez pas l’identifiant, c’est le template « python-base » qui sera utilisé.

Par exemple ajoutons à notre package un deuxième script (avec le template de base) :

ctln pyscript new Main2

Rajoutons également un troisieme scriupt de démonstation en utilisant le template de demo (python-demo) :

ctln pyscript new DemoConstellation python-demo

Notre package a maintenant trois scripts : Main.py (créé avec le template du package), Main2.py (créé ci-dessus avec le template de base), DemoConstellation.py (créé avec le template de demo) :

Renommer ou supprimer des scripts

Vous pouvez renommer les scripts du package avec l’option “rename”. Par exemple renommons “DemoConstellation” par “Demo” (les extensions “.py” sont optionnelles) :

ctln pyscript rename DemoConstellation Demo

Pour supprimer des scripts il suffit d’utiliser l’option “remove” en spécifiant le nom du script (avec ou sans son extension .py).

Par exemple supprimons les deux fichiers “Main2.py” et “Demo.py” que nous avons ajoutés (et renommés) ci-dessus :

ctln pyscript remove Main2
ctln pyscript remove Demo

Editer les scripts Python du package

Une fois vos scripts ajoutés, renommés ou supprimés avec la commande “ctln”, libre à vous d’utiliser votre éditeur de texte préféré pour éditer votre code !

Par exemple de le cas ici présent d’un accès SSH Linux, je pourrais utiliser “nano” ou “vim” (ou encore Notepad++ sur ma station WIndows via un tranfert SCP avec WInSCP par exemple).

nano Scripts/Main.py

Ici le script “Main” défini une fonction de démarrage (OnStart) et une fonction de fermeture (OnExit). Pour rappel, les bases de l’API Constellation Python sont expliquées ici.

Notez simplement que dans cet exemple, le WriteInfo déclenché au démarrage (OnStart) écrit un log dasn Constellation de type “Information” en concaténant dans un message textuel les propriétés suivantes :

• “PackageName” : le nom du package
• “SentinelName” : le nom de la sentinelle sur laquelle est déployée ce package
• “IsStandAlone” : un booléen indiquant si le package tourne de façon indépendante ou hébergée au sein d’une sentinelle
• “IsConnected” : un booléen indiquant si le package est connecté ou non à une Constellation

Tester son package

Pour tester notre package en local, il suffit de lancer la commande suivante :

ctln run

Comme vous pouvez le lire sur la console, le nom de la sentinelle affichée est “local sandbox” étant donné que la propriété IsStandalone est true (la propriété SentinelName est None). En effet votre package n’est pas déployé/démarré par Constellation sur une véritable sentinelle. Il est juste démarré en “standalone” par la commande “run”.

De plus la propriété “IsConnected” est false car votre package n’est pas connecté à une Constellation.

Vous pouvez donc tester des éléments de base de votre package mais de façon déconnecté, il manquera donc plusieurs fonctionnalités (les logs produits resterons local dans votre console, pas d’accès aux settings hormis ceux déclarés en local, la publication ou consommation de StateObjects sera impossible tout comme l’invocation ou l’exposition de MessageCallbacks).

Pour tester votre package complètement, il est possible de le lancer en local tout en le connectant à une Constellation.

Tout d’abord, il faudra déclarer des serveurs Constellation dans l’outil ctln.

Ajouter et gérer des serveurs Constellation

Les commandes sont les suivantes :

ctln server list
ctln server (add | set) <name> --url=<url> --accesskey=<key>
ctln server (add | set) <name> --url=<url> --username=<user>
ctln server check <name>
ctln server remove <name>

Vous pouvez lister les serveurs, ajouter ou mettre à jour des serveurs avec la clé d’accès ou un couple login/password, tester la connectivité ou supprimer des serveurs.

Par exemple je dispose d’une Constellation installée à l’adresse : http://pc-seb.ajsinfo.loc:8088. Un credential basé sur le couple login/password “admin/seb” a été configuré. Je peux donc ajouter ce serveur que je nommerai ici “pc-seb” via la commande :

ctln server add pc-seb --url=http://pc-seb.ajsinfo.loc:8088 --username=admin

Le serveur ajouté est testé au moment de l’ajout mais vous pouvez à tout moment tester la connectivité vers cette Constellation avec la commande “ctln server check”. Par exemple pour tester la Constellation nommée “pc-seb” :

ctln server check pc-seb

Tester son package dans Constellation

Maintenant que nous avons ajouté un serveur Constellation dans l’outil, nous pouvons relancé notre package en le connectant à notre Constellation nommée “pc-seb” via la commande :

ctln run --server=pc-seb

Le package démarre toujours dans la « sandbox locale » (IsStandalone = true) mais cette fois ci il est connecté à ma Constellation nommée « pc-seb » (IsConnected = true).

D’ailleurs en lançant la Console Constellation je peux maintenant suivre en temps réel les logs de ce package, les StatesObjects qu’il produit ou encore les MessageCallbacks qu’il expose.

Publier son package

Une fois le package développé et testé, il ne reste plus qu’à le packager pour pouvoir le déployer dans Constellation.

Vous pouvez soit le packager dans un fichier en local (que vous pourrez uploader sur une Constellation ou échanger avec d’autre) ou soit le déployer directement dans une Constellation référencée dans l’outil.

Par exemple pour publier ce package dans un fichier local dans le répertoire “/home/pi” :

ctln publish --output=/home/pi

Maintenant, pour déployer ce même package directement sur une Constellation, il suffit simplement de spécifier le nom du serveur Constellation enregistré sur la commande “publish”.

Par exemple pour publier ce package sur la Constellation nommée ici “pc-seb” :

ctln publish pc-seb

En vous rendant sur le Package Repository de votre Console Constellation, votre package fraîchement publié sera prêt à être déployé sur vos sentinelles Windows ou Linux de votre Constellation.

Next steps

Pour en savoir plus sur le développement de package en Python :

• Retour sur les bases de l’API Python  (produire des logs, accéder aux settings, publier des StateObjects)
• Exposer vos fonctions Python dans Constellation (les MessageCallbacks)
• Invoquer des MessageCallbacks des autres packages de votre Constellation en Python
• Consommer les StateObjects de votre Constellation

The post Créer, tester et déployer des packages Python en ligne de commande appeared first on Constellation.