Extension Visual Studio « Asynchrone »

La grande nouveauté de cette mise à jour est la réécriture du « package » Visual Studio en « package asynchrone ».

La notion d’extension (ou package) « asynchrone » a été introduite depuis la version 2015 de Visual Studio (14.0) afin de charger les extensions non plus au démarrage de VS de manière séquentielle mais de façon asynchrone, sans bloquer ou ralentir le démarrage de l’IDE.

L’extension Visual Studio du SDK Constellation a un temps d’initialisation extrêmement rapide et est restée depuis sa première version en Mars 2015 un package « classique » et non asynchrone.

Seulement depuis les dernières versions de Visual Studio, les extensions « non-asynchrones » sont désormais considérées comme obsolètes et sont/seront automatiquement désactivées dans l’IDE :

C’est pourquoi la roadmap concernant le SDK a été accéléré afin de porter le SDK dans une extension de type « asynchrone ».

Le SDK n’est donc plus initialisé au démarrage de Visual Studio, mais en tache de fond afin de se conformer aux nouvelles exigences en matière de performance et UX de l’IDE de Microsoft.

Fin du support pour Visual Studio 2012 et 2013

La migration vers cette notion de « package asynchrone » (introduite depuis VS2015) met de côté Visual Studio 2012 et Visual Studio 2013.

Comme le support officiel de Microsoft pour ces deux versions de l’IDE a déjà pris fin, le SDK Constellation ne supportera plus non plus ces deux versions.

Ainsi, à compter de cette version du SDK 1.8.6, nous supportons officiellement Visual Studio 2015 (14.x), VIsual Studio 2017 (15.x) et  le nouveau Visual Studio 2019 (16.x)

Pour installer ou mettre à jour votre SDK, rien de plus simple, lancez simplement le Web Platform Installer et sélectionnez “Constellation SDK” dans la liste des composants à installer/mettre à jour.

Constellation Web Platform Installer » Article
Constellation-Web-Platform-Installer-1.9.735.exe
Version: 1.9.735

1.2 MiB
2136 Downloads
Détails

Constellation Web Platform Installer pour Windows

Auteur:	MyConstellation.io
Plateformes:	Windows
Catégorie:	Web Platform Installers
Licence:	Constellation License Agreement
Date:	juin 15, 2020

The post Constellation SDK 1.8.6 : extension asynchrone et fin du support pour Visual Studio 2012 et 2013 appeared first on Constellation.

Principale nouveauté de cette version : le support de Visual Studio 2019 !

Vous pourrez donc créer, développer, tester et publier vos packages Constellation depuis Visual Studio 2012, 2013, 2015, 2017 et maintenant 2019 toute édition (de l’édition gratuite Community et l’édition haut de gamme Enterprise).

Pour installer ou mettre à jour votre SDK, rien de plus simple, lancez simplement le Web Platform Installer et sélectionnez “Constellation SDK” dans la liste des composants à installer/mettre à jour.

Constellation Web Platform Installer » Article
Constellation-Web-Platform-Installer-1.9.735.exe
Version: 1.9.735

1.2 MiB
2136 Downloads
Détails

Constellation Web Platform Installer pour Windows

Auteur:	MyConstellation.io
Plateformes:	Windows
Catégorie:	Web Platform Installers
Licence:	Constellation License Agreement
Date:	juin 15, 2020

The post Constellation SDK 1.8.5 avec le support de Visual Studio 2019 appeared first on Constellation.

Il fallait alors sélectionner la source “Constellation” (ajoutée automatiquement par le SDK Constellation pour Visual Studio) pour pouvoir se connecter et récupérer les mises à jour des librairies Constellation.

Pour des raisons pratiques et parce qu’il n’y a plus d’intérêt de conserver ce serveur privé, tous les packages NuGet sont désormais publiés et disponibles sur la galerie publique NuGet.org

Concrètement cela ne change rien du tout côté développement hormis le fait de prendre garde à ne plus utiliser le “Package source” Constellation dans votre gestionnaire NuGet et utiliser la source officielle nommée “nuget.org” ou “nuget v3” :

A noter également que lorsque vous installerez le SDK Constellation à partir de la version 1.8.5 actuellement disponible l’ancienne source sera automatiquement supprimée évitant ainsi les confusions !

Constellation Web Platform Installer » Article
Constellation-Web-Platform-Installer-1.9.735.exe
Version: 1.9.735

1.2 MiB
2136 Downloads
Détails

Constellation Web Platform Installer pour Windows

Auteur:	MyConstellation.io
Plateformes:	Windows
Catégorie:	Web Platform Installers
Licence:	Constellation License Agreement
Date:	juin 15, 2020

The post Migration du serveur NuGet Constellation vers nuget.org appeared first on Constellation.

Vous pouvez mettre à jour votre installation en lançant le « Web Platform Installer » sur Windows :

Constellation Web Platform Installer » Article
Constellation-Web-Platform-Installer-1.9.735.exe
Version: 1.9.735

1.2 MiB
2136 Downloads
Détails

Constellation Web Platform Installer pour Windows

Auteur:	MyConstellation.io
Plateformes:	Windows
Catégorie:	Web Platform Installers
Licence:	Constellation License Agreement
Date:	juin 15, 2020

Ou, sur Linux, en lançant la commande :

wget -O install.sh https://developer.myconstellation.io/download/installers/install-linux.sh && chmod +x install.sh && ./install.sh

Constellation Server 1.8.3

Tout d’abord les dépendances du serveur Constellation ont été mises à jour : Json.NET 9.0.1, NLog 4.4.11, SignalR 2.2.2 et enfin la stack OWIN en version 3.1. Chacune d’entre elles apportant des correctifs et améliorations de performance.

La modification la plus importante de cette version 1.8.3 est la refonte complète de la gestion des packages au niveau du serveur. En effet, jusqu’à présent seuls les packages réels (et non virtuels) étaient gérés par le hub de contrôle. Pour les packages virtuels, il fallait exploiter l’API de Management (ou lire la configuration XML) car ils n’existaient pas sur le hub de contrôle (d’où le terme “virtuel”).

Désormais, chaque package déclaré dans la configuration d’une Constellation, qu’il soit réel ou virtuel, est chargé sur le hub de contrôle. Il n’y a donc plus de Statut en “N/A” sur la Console Constellation : tous les packages ont par défaut un état à “Unknown”. Une simple connexion sur le hub de contrôle permet donc de récupérer l’intégralité des packages d’une Constellation sans devoir combiner des informations venant de la configuration XML pour y ajouter la partie « virtuelle ».

De plus les packages virtuels initialisant des abonnements aux messages ou StateObjects sont maintenant marqués comme “connecté” sur le hub de contrôle permettant de suivre leurs états. Par exemple, un Arduino/ESP est maintenant vu comme connecté sur le hub de contrôle :

Aussi chaque package envoie désormais, en plus de son n° de version et de la libraire Constellation utilisée, le type de la libraire utilisée : il s’agit de la propriété “ConstellationClientType”.

Aussi, il est possible définir le répertoire de base de la Constellation dans lequel trouver le fichier de configuration en spécifiant la clé « Constellation.BaseDirectory ». Cela permet de séparer les binaires Constellation de sa configuration, très utile dans un environnement Docker. Un article sur le sujet sera prochainement publié.

Outre différentes optimisations du code et correction de défauts mineurs on peut aussi noter :

• Server / ControlHub : le ReloadServerConfiguration envoi la liste des packages aux sentinelles seulement connectées et « Update settings » sur les packages connectés seulement et non à tous les groupes
• Server / ControlHub : prise en charge des mises à jour de configuration des packages à volée
• Server / Management API : ajout d’un objet de synchronisation pour les I/O vers le fichier de configuration pour éviter les écritures concurrentes
• Server / Licensing : LeaseLicensing dans le domaine serveur si multi-tenant sinon dans le domaine de la constellation si mono-instance (permettant ainsi de récupérer les erreurs de licence dans la Console Log)
• Server / API REST : le timeout des sessions HTTP est maintenant de 150 secondes par défaut configurable dans le fichier de configuration

Enfin notez que le serveur 1.8.3 est rétrocompatible avec les différents composants Constellation 1.8.x, que ce soit pour la Console, les packages ou les sentinelles. Autrement dit vous pouvez mettre à jour votre serveur en 1.8.3 tout en gardant vos packages et sentinelles 1.8.x fonctionnelles.

Constellation Sentinel 1.8.3

L’autre grande nouveauté de cette nouvelle version 1.8.3 est la refonte complète du gestionnaire de processus sur les sentinelles.

Jusqu’à présent lorsqu’une sentinelle recevait sa liste des packages, elle se chargeait de télécharger et démarrer chaque package de sa liste. Si le package était déjà en fonctionnement elle levait un Warning ce qui avait tendance à “polluer” les logs notamment lorsqu’on déployé la configuration au niveau d’une Constellation. Enfin lorsqu’un package en fonctionnement était supprimé de la liste, elle fermait le processus associé.

Le problème dans ce mécanisme est que si vous arrêtez un package et que vous redéployer la configuration, par exemple en ajoutant, supprimant ou modifiant les settings d’un autre package, la liste était renvoyée à votre sentinelle qui relançait “bêtement” le package vous avez arrêté !

C’est pour cela que le fonctionnement interne de la sentinelle a été profondément revu et a conduit à la réécriture complète du mécanisme de gestion des processus. Ainsi la description de chaque package, démarré ou non, est maintenue en mémoire. Lorsqu’une sentinelle reçoit sa nouvelle liste, elle est toujours capable de charger/démarrer les nouveaux packages et supprimer/arrêter les packages retirés mais les packages existants ne sont pas redémarrés automatiquement, ils conservent leurs états.

Cette refonte a amélioré beaucoup de chose en apportant plus de fiabilité et stabilité dans le suivi du processus et elle apporte une meilleure cohérence des états de chaque package.

Aussi, comme le serveur, les dépendances ont été mises à jour : Json.NET 9.0.1, SignalR 2.2.2, NLog 4.4.11 et NLog.Windows.Form 4.2.3 pour la Sentinelle UI.

Notez enfin qu’une sentinelle 1.8.3 peut fonctionner sans aucun problème dans une Constellation 1.8.x de version antérieure tout comme une sentinelle antérieure à la version 1.8.3 pour fonctionner sur une Constellation 1.8.3.

Constellation Console 1.8.3

La Console Constellation a aussi reçu sont lot de nouveautés à l’occasion de cette nouvelle release 1.8.3.

Etant donné la refonte dans la gestion des packages sur le hub de contrôle, la Console Constellation a été impacté à ce niveau. Elle se base exclusivement sur le hub de contrôle sans devoir interroger la Management API en parallèle pour intégrer les packages virtuels ou non connectés.

Suite à la publication des nouvelles librairies Javascript et AngularJS 1.8.2 du mois dernier, les codes snippets du MessageCallbacks Explorer ont été mis à jour pour intégrer les nouveautés de ces librairies.

On notera aussi l’ajout d’un bouton pour vider la Console Log, l’ajout ConstellationClientType sur les packages ou encore du credential utilisé par une sentinelle sur la fenêtre de détail. Aussi la Console supporte pleinement les utilisateurs connectés sans droits de Management.

Mais aussi :

• Console / Package : Gestion des packages virtuels avec un statut Unknown, menu contextuel synchronisé et mise à jour de l’activité pour les packages virtuels
• Console / Packages : « Update Settings » affiché dans le menu contextuel si le package est connecté et démarré (package virtuel compris)
• Console / Packages : bugfix sur le déploiement de package avec un setting de type DateTime (module $filter non injecté dans le contrôleur principal)
• Console / Packages : bugfix sur le déploiement de la configuration une fois que le SetRecoveryOption est terminé et non en parallèle
• Console : déconnexion des deux hubs (consumer et controller) si l’un des deux est déconnecté (cas très rare où l’un des deux hubs parvient à se reconnecter et pas l’autre)
• Console : Mise à jour de l’API Constellation Javascript & AngularJS en version 1.8.2 et de la librairie SignalR 2.2.2

Autres nouveautés

La librairie .NET pour les packages a été mise à jour en version 1.8.3.17190, et est disponible sur le repository Nuget. Cette nouvelle version envoie le “ConstellationClientType” ( net40 » ou « net45 ») lors de la connexion de votre package à Constellation. De plus les dépendances ont été mises à jour vers JSON.NET 9.0.1 et SignalR 2.2.2.

Notez enfin qu’un package exploitant l’API 1.8.3 peut fonctionner sans aucun problème sur une Constellation 1.8.x de version antérieure tout comme un package antérieure à la version 1.8.3 peut fonctionner sur une Constellation 1.8.3.

Une nouvelle version SDK est également disponible. Il intègre une mise à jour des templates de projet Constellation pour prendre en compte les dernières versions des API 1.8.3.

Pour finir le Web Platform Installer pour Linux a lui aussi été mis à jour. Il garde en mémoire le jeton d’authentification entre les différents installeurs Server, Sentinel et Console de façon à éviter de devoir se ré authentifier à chaque composant mais surtout le pilotage des services Server et Sentinel dans Supervisor est désormais basé sur “supervisorctl” pour une gestion plus fine des services.

Pour consulter le changelog complet de cette nouvelle version cliquez ici. N’hésitez pas non plus à remonter vos feedbacks sur le forum.

The post Constellation 1.8.3 est disponible appeared first on Constellation.

Découvrons ces nouveautés en détail !

PythonProxy 1.8.2 :  amélioration de l’expérience de développement des packages Python

Configuration des scripts à démarrer

Depuis la sortie du “PythonProxy” en décembre 2014 permettant d’embarquer des scripts Python dans un package Constellation, tous les fichiers “.py” présents dans le répertoire “Scripts” étaient chargés à l’exception du fichier “Constellation.py” et des fichiers terminant par “lib.py” ce qui permettait d’inclure des librairies Python dans vos packages. De plus tous ces fichiers Python étaient lancés par ordre alphabétique.

Cela fait désormais partie du passé ! En effet, depuis la mise à jour 1.8.2, il faut déclarer la liste des fichiers Python à charger dans le fichier App.config en ajoutant la section suivante :

<pythonProxy xmlns="urn:Constellation.PythonProxy">
  <scripts>
    <script filename="Scripts\Demo.py" />
    <script filename="Scripts\LightSensor.py" />
    <script filename="Scripts\Camera.py" />
  </scripts>
</pythonProxy>

Sans oublier de déclarer dans la section <configSection> la ligne suivante :

<section name="pythonProxy" type="Constellation.PythonProxy.PythonConfigurationSection, Constellation.PythonProxy, Version=1.8.0.0, Culture=neutral, PublicKeyToken=null" />

Vous pouvez donc maintenant définir explicitement les scripts que vous voulez lancer et dans l’ordre que vous souhaitez sans devoir jouer sur les noms des fichiers.

Cela offre plus de souplesse dans la conception de vos packages avec un fonctionnement beaucoup plus clair et explicit.

Timeout de démarrage

Lorsque le PythonProxy lance un script Python que vous avez écrit, il cherchera à se connecter avec lui avant d’invoquer votre méthode “OnStart”. Seulement en cas de problème, par exemple si votre script comporte des erreurs fatales, la connexion n’aura jamais lieu et votre package sera bloqué !

Désormais cette nouvelle version intègre la notion de “timeout” permettant de définir un temps maximal de démarrage. Si le PythonProxy ne parvient pas à se connecter à votre script dans le délai imparti, il affichera un message d’erreur et passera au script suivant sans bloquer indéfiniment.

Ce timeout peut être configuré pour chaque script avec l’attribut “startupTimeout” ou bien de manière globale.

Notez également qu’il existe un timout d’arrêt : si votre script n’est pas terminé après avoir reçu l’ordre d’arrêt dans un délai imparti, le PythonProxy mettra fin au processus Python qui l’héberge.

Par exemple :

<pythonProxy xmlns="urn:Constellation.PythonProxy" scriptStartupTimeout="20" scriptCloseTimeout="5">
  <scripts>
    <script filename="Scripts\Demo.py" startupTimeout="10" />
    <script filename="Scripts\LightSensor.py" closeTimeout="2" />
    <script filename="Scripts\Camera.py" />
  </scripts>
</pythonProxy>

Le 1er script (Demo.py) doit démarrer en moins de 10 secondes et le 2ème script (LightSensor.py) doit s’arrêter en moins de 2 secondes. Pour le reste, le temps de démarrage est de 20 secondes et 5 secondes pour l’arret.

Notez enfin que si aucune valeur n’est spécifiée (ni sur la balise <script> ni de manière globale sur la section <pythonProxy>), les valeurs par défaut sont :

• 30 secondes pour le démarrage
• 8 secondes pour l’arrêt

Redirection de la sortie et des erreurs Python sur Constellation

Avec cette nouvelle version du PythonProxy, l’ensemble du flux de sortie et d’erreur des processus Python qui hebergent vos scripts seront rédirigés vers les logs Constellation.

Autrement dit un simple “print” sera visible dans les logs Constellation mais surtout la moindre erreur, par exemple une erreur de syntaxe dans votre script empêchant son initialisation, sera remontée dans les logs Constellation vous donnant alors toutes les informations nécessaires pour sa correction.

Avec cette nouvelle version du Python Proxy, fini le côté “Black Box” lors du démarrage de vos scripts !

Surveillance de vos scripts

Il y a désormais un mécanisme de Ping/Pong entre le package Constellation et les scripts Python pour vérifier l’état de vie des deux parties. Si un processus Python ne reçoit plus de Ping reçu pendant plus de 30 secondes, il s’arrêtera automatiquement pour éviter les processus orphelins (notamment en cas de debug).

Mise à niveau

Pour en profiter il suffit de mettre à jour le package Nuget depuis Visual Studio et d’ajouter ensuite la section de configuration présentée ci-dessus dans votre fichier App.config.

Notez que tous les nouveaux projets Constellation créés avec le SDK 1.8.2 (présenté ci-dessous) sont déjà basés sur cette nouvelle version du Python Proxy, il n’y a aucune action à faire pour en profiter !

Mise à jour du SDK 1.8.2

Tout d’abord les templates des projets (C# et Python) ont été mis à jour avec les dernières versions des libraires (.NET et Python). Ainsi les nouveaux projets créés avec cette nouvelle version du SDK profiteront automatiquement des dernières versions de l’API .NET et du Python Proxy 1.8.2 décrit ci-dessus.

Lorsqu’un package est publié (en local ou directement sur un serveur Constellation), l’assistant effectuera un nettoyage de la solution avant de lancer la compilation. Cela permet de purger les fichiers qui ne sont plus utilisés dans votre package.

Autre détail fort bien utile, lorsque vous ajoutez une icone pour votre package, c’est à dire que vous ajoutez cette icone (png ou jpg) dans votre projet Visual Studio et que vous la déclarez dans le Package Manifeste, l’assistant de publication du package Constellation configuera automatique la propriété « Copy to Output directory » sur votre icone !

Suite à la sortie du Python Proxy 1.8.2, le schéma de configuration XSD de la nouvelle section <pythonProxy> décrite ci-dessus sera installée de façon à pouvoir profiter de l’IntelliSense dans Visual Studio lorsque vous éditez ce fichier.

De plus un nouvel « Item Template » nommé « Constellation Python Script » a été ajouté. Il permet de créer des scripts Constellation Python avec un template de base dans vos packages.

Dès qu’un script Constellation Python est ajouté, Visual Studio configurera automatiquement la propriété « Copy to Output directory » pour inclure votre script dans le package et ajoutera la référence de ce fichier dans la section  <pythonProxy> du fichier App.config toujours de manière automatique.

Autre : mise à jour de la Console et de la libraire .NET

Les différentes mises à jour de la Console du mois de Juin permettent de prendre en compte dynamiquement les packages uploadés via la Management API (sans devoir rafraichir la page). De plus plusieurs bugs ont été corrigés comme l’édition des settings de type boolean ou number sur les packages sans manifeste (eg. Virtual Package) ou encore un problème de la mise à jour des StateObjects qui n’étaient pas maintenus en cas de changement de page.

Aussi la libraire .NET Constellation a été mise à jour le 20 mai 2017 (1.8.2.17140) et le 29 juin (1.8.2.17178). Cela corrige un problème sur l’envoi de réponse à des sagas dans un environnement Linux/Mono et permet le déclenchement de la procédure d’arrêt (OnPreShutsown puis OnShutdown) sur les packages lancés hors sentinelle (par exemple depuis Visual Studio en phase de debug).

Retrouvez plus d’information sur le changelog.

The post Mise à jour de l’API Python et du SDK en version 1.8.2 appeared first on Constellation.

Vous pouvez mettre à jour votre installation en lançant le « Web Platform Installer » :

Constellation Web Platform Installer » Article
Constellation-Web-Platform-Installer-1.9.735.exe
Version: 1.9.735

1.2 MiB
2136 Downloads
Détails

Constellation Web Platform Installer pour Windows

Auteur:	MyConstellation.io
Plateformes:	Windows
Catégorie:	Web Platform Installers
Licence:	Constellation License Agreement
Date:	juin 15, 2020

Ou sur Linux en lançant la commande suivante :

wget -O install.sh https://developer.myconstellation.io/download/installers/install-linux.sh && chmod +x install.sh && ./install.sh

Constellation SDK 1.8.2 : support de Visual Studio 2017

La nouvelle version du SDK Constellation est désormais compatible avec toutes les éditions de Visual Studio 2012, 2013, 2015 et maintenant 2017.

Cette version embarque également une mise à jour du générateur de code pour supporter des booléens optionnels dans la signature des MC ou encore l’ajout de méthode d’extension pour les StateObjects de type générique.

Aussi, les fenêtres s’ouvrent maintenant au centre de l’instance Visual Studio et non sur l’écran principal ce qui était peu conviviale sur les environnements multi-écrans. Les templates de projet ont également été mis à jour.

Enfin avec l’arrivée de Visual Studio 2017, le programme d’installation du SDK a été révisé pour supporter cette nouvelle version ainsi que le concept de “multi-instance” de Visual Studio 2017. Vous aurez maintenant le programme “VSIX Installer” qui sera lancé automatiquement lors de l’installation pour sélectionner les instances de VS où installer le SDK Constellation.

Constellation Console 1.8.2 : plus de productivité

Cette mise à jour apporte beaucoup d’améliorations de la Console Constellation.

Déploiement des mises à jour des packages

Depuis Constellation 1.8.1, lorsqu’une mise à jour est disponible dans le catalogue en ligne, vous avez une notification avec la possibilité de télécharger la nouvelle version du package :

La nouvelle version du package est déployée dans votre repository local et c’est à vous, ensuite, de déployer manuellement cette nouvelle version sur les instances en cours de fonctionnement via le bouton “Reload”.

Désormais avec la version de 1.8.2 de la Console, une fenêtre s’ouvre automatiquement à la suite du déploiement d’une mise à jour d’un package pour vous proposer de recharger directement le ou les packages sur les sentinelles de votre Constellation où ils sont déployés :

Détachement des fenêtres

Sur toutes les pages de la Console 1.8.2, vous avez deux nouvelles icones en haut à droite :

La première icone permet de détacher la page en cours dans une pop-up et la deuxième icone permet de détacher la page en cours dans un nouvel onglet de votre navigateur.

Cela permet d’ouvrir plusieurs pages de la Console sur un même écran, pour suivre par exemple les logs, contrôler les packages, visualiser les StateObjects, etc. sans devoir changer constamment de page :

Contrôle de la compatibilité du déploiement des packages sur les sentinelles

Sur la fenêtre de déploiement d’un package, un contrôle de compatibilité est réalisé pour vous indiquer si le package est compatible avec la sentinelle sélectionnée.

Par exemple un package comme HWMonitor ou WindowsControl n’est pas compatible avec une sentinelle Linux, vous aurez donc directement l’information lors du déploiement d’un nouveau package.

Ce contrôle est basé sur les informations définies dans le manifeste du package. A charge au package de spécifier les informations de compatibilité dans leur manifeste.

Les filtres persistants

Les filtres de chaque page sont maintenant conservés lorsque l’on change puis revient sur une page (au sein d’une même session). Cela apporte plus de productivité en nous évitant de devoir constamment réappliquer les filtres lorsque l’on passe d’une page à l’autre.

Plus de réactivité

Outre les nouvelles fonctionnalités, la Console 1.8.2 apporte aussi plus de réactivité. Anciennement il y a certaines opérations comme la suppression de sentinelles ou de packages, la création d’un package virtuel, qui nécessitaient de recharger la Console (via un F5 par exemple). Désormais, les vues se mettent bien à jour en temps réel quelque soit les actions réalisées.

Il est également possible de déployer plusieurs instances d’un même package sur une même sentinelle.

Autre

En vrac :

• Extinction automatique des packages lors de la suppression d’une sentinelle
• Affichage du nombre d’élément filtré et total sur chaque page
• Limite de 500 lignes dans la Console Log et de 20 erreurs max dans la sidebar de notification pour éviter les dérives de performances
• Rafraichissement automatique du cookie d’authentification lorsque l’on est connecté (pour éviter les déconnexions au changement de page)
• Mise en forme des types génériques sur le StateObjects Explorer & MessageCallbacks Explorer
• Bugfix graphique sur le rédimensionnement de la Console log & editeur de configuration
• Mise à jour des codes snippets pour les appels HTTP (exemples pour l’API Constellation et l’API Consumer) dans le MessageCallbacks Explorer
• Appel des ressources JS/CSS et templates HTML avec le numéro de version pour éviter les problèmes de cache lors des mises à jour de la Console

Constellation Server 1.8.2 : section de configuration et compteurs de performance

Premièrement, le nom de la section de configuration “constellationSection” a été renommé en “constellation”.

Le programme d’installation du serveur 1.8.2 renommera automatiquement la section en cas de mise à jour de votre Constellation. Soyez simplement vigilant sur le fait que, désormais, la section est “<constellation>” et non “<constellationSection>”. Les schémas XSD fournis avec le SDK ainsi que l’IntelliSense du “Configuration Editor” de la Console ont été mis à jour dans ce sens.

Ensuite autre modification importante, les compteurs de performance sont activés si et seulement si la clé de configuration  “EnablePerformanceCounters” est définie à “true”.

Si la valeur est “false” ou encore si la clé n’est pas présente, les compteurs ne seront pas activés.

<appSettings>
  <add key="EnablePerformanceCounters" value="true" />
</appSettings>

Par défaut, lors d’une nouvelle installation la clé est définie à “false”. Dans le cas d’une mise à jour, la clé n’est pas ajoutée, autrement dit cette clé sera absente de votre configuration. De ce fait, les compteurs de performance sont désactivés par défaut.

C’est pourquoi, si vous souhaitez suivre les indicateurs de performance du serveur Constellation, vous devez explicitement ajouter ou modifier cette clé dans votre fichier de configuration et redémarrer le service Windows “Constellation Server”. Pour rappel, cette fonctionnalité n’est disponible que sur un environnement Windows.

N’hésitez pas à consulter le changelog complet et remonter vos feedbacks sur le forum.

The post Constellation 1.8.2 est disponible appeared first on Constellation.

Prérequis

La plateforme Constellation se compose :

• d’un serveur qui héberge et expose la Constellation en HTTP/s (un serveur = une Constellation)
• de sentinelles (UI ou Service) à installer sur vos différentes machines (tout système Windows ou Linux)
• d’une Console d’administration : application Web de pilotage de votre Constellation

Vous pouvez installer le serveur Constellation sur une machine Windows ou Linux, que ce soit un laptop, un desktop, un NUC, un SoC, un serveur local ou dans le Cloud.

Dans la rubrique Constellation Server vous retrouverez plusieurs articles sur les différentes installations possibles (système Linux,  Raspberry, cloud Azure ou Amazon, etc…).

Pour démarrer, nous allons déployer dans ce guide une Constellation complète (serveur, sentinelle, console et le SDK) sur une machine Windows.

Vous avez donc besoin pour suivre ce guide :

• d’un ordinateur ou serveur sous Windows (Windows 7/8/10 ou Windows Server)
• Pour installer le SDK : Visual Studio 2015, 2017 ou 2019

Si vous ne disposez pas de licence de Visual Studio, vous pouvez installer la version  “Community”, une version gratuite de Visual Studio compatible avec le SDK Constellation : https://www.visualstudio.com/fr-fr/products/visual-studio-community-vs.aspx

Télécharger la plateforme Constellation

Sur la page de téléchargement vous trouverez plusieurs programmes d’installation pour chaque composant Constellation  :

• Le serveur
• Les sentinelles (UI ou Service)
• La console
• Le SDK Visual Studio

Mais pour gagner en productivité, vous avez à votre disposition le “Web Platform Installer” (WPI), un programme d’installation tout-en-un qui télécharge automatiquement et configure les composants que vous souhaitez installer.

Commencez donc par télécharger le programme  “Constellation Web Platform Installer” pour Windows :

Constellation Web Platform Installer
Constellation-Web-Platform-Installer-1.9.735.exe
Version: 1.9.735

1.2 MiB
2136 Downloads
Détails

Constellation Web Platform Installer pour Windows

Auteur:	MyConstellation.io
Plateformes:	Windows
Catégorie:	Web Platform Installers
Licence:	Constellation License Agreement
Date:	juin 15, 2020

Installer la plateforme

Etape 1 : lancement de l’installation

Lancez le programme “Constellation Web Platform Installer.exe”

Etape 2 : identification

Vous devez dans cette étape renseigner votre compte myConstellation.io afin de pouvoir télécharger les composants Constellation et accéder à vos licences :

Etape 3 : acceptez la licence d’utilisation

Vous retrouverez le détail des licences Constellation sur cette page. Pour résumer, Constellation est gratuit pour un usage personnel ou éducatif sans aucun but lucratif et soumis à l’acquisition d’une licence pour un usage professionnel ou entreprise.

Etape 4 : choix du canal de distribution

Vous devez sélectionner le canal de distribution à utiliser : Stable ou Pre-release (versions Beta) :

Etape 5 : répertoire d’installation

Vous devez choisir le répertoire d’installation racine de la plateforme Constellation :

Etape 6 : sélectionnez les composants Constellation à installer

Vous pouvez sélectionner ici les composants à installer ou utiliser les profils prédéfinis :

• Full server installation : installation typique pour un serveur (le serveur, la sentinelle en version service et la console Constellation)
• Full developer installation : installation typique pour un poste de développement (le serveur, la sentinelle UI, la console et le SDK Visual Studio)
• Custom installation : sélectionnez à la carte les composants que vous souhaitez installer

Notez que le WPI vous indiquera la dernière version de chaque composant à installer et est capable de déployer les mises à jour pour chacun de ces composants si une nouvelle version plus récente est disponible.

Notez également que si Visual Studio n’est pas installé, le composant SDK sera grisé avec la mention “Not applicable”.

Dans ce guide, sélectionnons le profil “Développeur” :

Etape 7 : configuration du serveur Constellation

Entrons désormais dans les étapes de configuration de chacun des composants à installer en commençant par le serveur Constellation.

Etape 7.1 : sélection de la licence

Premièrement, vous devez sélectionner une licence pour l’utilisation du serveur. Vous pouvez utiliser une licence que vous aurez préalablement téléchargée depuis le portail Constellation ou  vous connecter directement sur le service de licence de Constellation depuis le WPI :

Vous obtiendrez l’ensemble des licences associées à votre compte avec la possibilité de créer des licences gratuites pour un usage personnel (plus d’information ici).

Dans notre cas créons une licence personnelle :

Etape 7.2 : choix du répertoire des packages

Dans cette étape vous devez définir le répertoire pour votre catalogue de packages de votre Constellation.

Par défaut, il s’agit du sous-dossier “Packages” de votre répertoire d’installation :

Etape 7.3 : choix du port d’écoute du serveur

Le serveur Constellation utilise le protocole HTTP pour exposer ses différents hubs et API. Pour cela vous avez besoin de choisir le port d’écoute et de l’ouvrir au niveau de votre firewall.

L’assistant peut déclarer le port que vous avez choisi dans le pare-feu de Windows. Si vous souhaitez ouvrir Constellation à l’extérieur de votre réseau local, à vous d’ouvrir le port sur votre routeur.

A noter que vous pouvez déclarer dans la configuration du serveur Constellation sur plusieurs ports HTTP et/ou HTTPS ou même définir un chemin HTTP personnalisé. Il est d’ailleurs conseillé d’activer le protocole HTTPS si vous souhaitez exposer votre serveur Constellation sur Internet. Vous retrouverez plusieurs articles sur la configuration avancée du serveur dans la rubrique Constellation Server.

Etape 7.4 : choix des clés d’accès

Pour se connecter à Constellation vous avez besoin de créer des clés d’accès (les “Access Keys”). Dans le cas d’une nouvelle installation, l’assistant vous proposera de créer deux clés :

• Une clé “Standard” (accès de base) que vous utiliserez pour connecter vos sentinelles et packages
• Une clé “Administrator” qui dispose des droits d’accès au hub de contrôle (pour le pilotage de la Constellation) et à l’API de Management (pour la configuration du serveur) :

Une clé d’accès est une chaîne de caractère. Il est conseillé de choisir des clés d’accès assez longues (> 16 caractères) et compliquées.

Pour simplifier leurs mémorisations et générations, Constellation propose d’utiliser un couple login/password pour créer des clés d’accès. Pour cela, on utilise le hash SHA1.

Exemple : pour le login “Admin” et le mot de passe “Password”, la clé d’accès sera “d882b8721a224d38ebb54559e6b54e5df3a1bc6d » (soit SHA1(“AdminPassword”)). Notez bien que la casse est importante !

Dans l’assistant d’installation, cliquez sur le bouton “Use Password” pour renseigner un couple login/password afin de générer les Access Keys :

Pour finir, vous pouvez ajouter le droit de débogage sur la clé “Administrator” en cochant la case correspondante. Cela nous permettra de tester des packages connectés à votre Constellation depuis Visual Studio.

Etape 8 : configuration de la Console Constellation

Comme la Console Constellation est déployée sur la même machine que le serveur Constellation, l’assistant vous propose héberger la console par le serveur Constellation lui-même.

Si vous désirez utiliser votre propre serveur Web pour exposer la Console (Apache, IIS ou autre) sélectionnez la deuxième option mais dans notre guide laissons le serveur Constellation héberger la console :

Vous pouvez ensuite fixer une clé d’accès en dur ou utiliser une page de login. De plus vous pouvez également restreindre l’accès à la console en local seulement.

Laissons les options par défaut (c’est à dire Console ouverte à tous avec une page de login) :

Etape 9 : configuration de la Sentinelle Constellation

Dans la sélection des composants nous avons indiqué vouloir installer la sentinelle UI. Vous arrivez donc à cette étape de configuration.

Comme la sentinelle est installée sur la même machine sur le serveur, vous pouvez l’inclure automatiquement dans votre Constellation ou bien l’inclure dans une autre Constellation en sélectionnant la deuxième option.

Dans notre cas, laissons la première option sélectionnée pour ajouter notre sentinelle UI à notre Constellation en cours d”installation :

Etape 10 : Installation

La configuration des composants est désormais terminée. Vous retrouverez tout le détail sur l’écran de confirmation :

En cliquant sur le bouton “Install”, le Web Platform Installer va télécharger les dernières versions de composants Constellation à installer :

Puis il déroulera l’installation et la configuration de chacun de ces composants :

A la fin de l’installation, l’assistant vous proposera de lancer la Console et la Sentinelle UI (car ces deux composants ont été installés) :

Etape 11 : Validation de l’installation

En fermant le programme d’installation, la sentinelle UI va être lancée :

En double-cliquant sur l’icone vous pourrez visualiser les logs de cette sentinelle qui doit être correctement connectée au serveur :

Vous aurez également la Console Constellation qui se lancera dans votre navigateur Internet par défaut :

Utilisez le Login/Password de la clé d’accès “Administrator” pour vous connecter. Sur la page “Sentinels” vous devriez voir votre sentinelle UI locale connectée :

Bravo vous avez déployé votre première Constellation avec succès !

Optionnellement : ajouter ou mettre à jour un composant

Vous pouvez à tout moment relancer le “Web Platform Installer” (WPI) pour ajouter ou mettre à jour des composants Constellation.

Ainsi quand des mises à jour Constellation sont disponibles, vous avez juste à relancer le WPI et vous laissez guider par l’assistant.

Dans notre exemple, relançons le WPI. Comme nous le montre l’écran ci-dessous, tous les composants sont bien à jour mais vous pouvez encore ajouter la “Sentinel Service” sur cette machine :

Vous entrez alors dans la configuration de la sentinelle avec la possibilité d’ajouter cette nouvelle sentinelle à votre Constellation locale (car précédemment installée) ou de l’ajouter à une autre Constellation.

Next steps

• Ajoutez des sentinelles dans votre Constellation
• Téléchargez et déployez des packages sur vos sentinelles
• Exposer votre serveur Constellation derrière avec reverse proxy IIS ou Nginx et ajouter le support du HTTPS/SSL

Vous souhaitez installer le serveur et sa console sur un système Linux ?

• Installer Constellation sur Linux

Prêt pour développer avec Constellation ?

• Créez votre premier package Constellation en C#
• Créez des packages UI en Winform ou WPF
• Connectez vos pages Web à Constellation
• Créez votre premier package Constellation en Python
• Connectez un Arduino ou un ESP8266 à Constellation

The post Installer la plateforme Constellation 1.8 appeared first on Constellation.

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.