J'aimerai relancer le projet...
#1
Salut,

J'aimerai relancer le projet d'une version centralisée basée sur le Raspberry pi et voir qui est partant pour en parler un peu.

J'ai plusieurs bouts de code éparpillés sur mon pc et quelques tests concluants mais j'arrive pas à organiser tout ça pour faire un truc fonctionnel. Peu être que si on se fixe de plus petits objectifs en partageant du code on peut y arriver.

J'ai commencé un petit programme en C# qui tourne avec mono grandement inspiré du travail de Bigonoff avec Domogest CE4 qui me sert à interagir avec le flux UDP de l'interface LandTiger. Pour l'instant rien de concret mais ça montre qu'on peu tout à fait reprendre le concept de plugins en C# sous linux. Je voulais mes interfaces en pages web comme Henry et en cherchant l'existant, j'ai découvert Symfony. Je pense que je vais utiliser ça car j'aime bien le concept de route, doctrine, la gestion du cache, les services etc. Le seul problème que j'avais avec tout ça c'est que c'était pas assez interactif.

Je ne sais pas trop comment fonctionne Henry mais moi je me suis embarqué avec un timer javascript qui vérifie l'état des informations affichées toutes les secondes de façon à garder l'interface web cohérente avec l'état de l'installation. J'aimais pas trop et du coup je viens de trouver une solution en utilisant le travail de ce gars qui me permet de relier directement l'interface web à mon programme C# et les premiers essais sont très prometteurs.

Maintenant, le moindre évènement provenant de mon programme C# est traité dans un évènement javascript sur le navigateur web de chaque client et ça me donne envie de continuer dans cette voie.

Je vais essayer d'imager ce que j'aimerai faire et relancer un peu les conversations :o)

A bientôt
Tant que vous avez des dents, croquez des pommes !  (^_^) ♪♫  ♪
Répondre
#2
bonjour koala

c'est pas une mauvaise idée ,moi je suis entrain de regarder pour comprendre un peut mieux le python 3 ,car maintenant les bibliothéque pour crée un petit serveur et aussi celle pour èmetre et recevoir sur le bus can existent.

donc avec une rpi3 comme on a la possibilité de communiqué via éthernet ou wiffi ou bluetools ,on pourrait réaliser qielque chose de bien .

toi ,je vois que tu te dirige vers le c# ; javascript et Symfony etc...

moi je vais utiliser python3 car il peut être un serveur interactif style PHP ,je pourais recevoir et émetre des trames canbus ;je pourrais y inclure une BDD de style sqlite3.

une horloge temp réel DS3231 .

a+
Répondre
#3
Salut,

Je suis pas spécialement fixé sur un langage ou une méthode particulière :o)

Ma première maquette est en C# car déjà j'aime bien et ce que je voulais c'était avoir accès à tout élément dans un même programme tout en le modulant grâce aux plugins. Après j'ai étudié aussi ce qu'on fait les autres et souvent il s'agit de plugin PHP qui manage un deamon indépendant qui peut être en Python, C++, C# ou autre.

Pour l'instant je travail sur l'auto installation / mise à jour et l'interface graphique. Je ne suis pas trop pour proposer une image toute faîte à installer alors j'essaye de créer un script shell à lancer sur un Pi fraîchement installé qui se charge d'installer tous les éléments nécessaires. Le principal avantage c'est quand quelqu'un essaye de comprendre le fonctionnement, il peut suivre pas à pas les actions réalisées pour en arriver à faire fonctionner le truc.

A l'heure actuelle, mon script fait toutes les mises à jours du PI, il install PHP7 Mysql et Nginx, configure l'ensemble pour avoir un serveur web fonctionnel et télécharge le contenu de mon GitHub dans le dossier Web. Maintenant j'étudie Composer et je regarde toutes ces dépendances très intéressantes. Je pense utiliser Symfony car au final ça ressemble à ce que je cherche à faire.

La principale difficulté c'est de savoir quoi faire plutôt que comment ou avec quoi ^^

C'est très difficile d'expliquer une idée sur un forum mais je vais essayer de t'expliquer pourquoi j'ai opté C# plutôt qu'autre chose.

Au début j'ai commencé par la réception des trames Can provenant de l'interface LandTiger. Je voulais un truc natif au Pi alors j'ai opté pour C++ et j'avais le source d'Henry pour un bon départ. Bref, je me bricole une interface UDP qui renvoi les trames vers php et de là je commence mon truc.

Pour faire des scénarios c'est à peu près ce qu'il faut. Du coup j'ai fais un truc du style Produceur => Pile => Consumer
Le programme principale contient une liste de trames CAN (la pile) et démarre l'écoute UDP dans un thread qui vient alimenter la pile. Il reçoit, il place dans la pile et continue son boulot le plus rapidement possible. Le programme principal peu créer autant que Consumer que nécessaire qui sont en fait des threads qui traitent chaque trame dans la pile à leur vitesse suivant la complexité des calculs à faire et se mettent en pause dès que la pile est vide.

J'ai fais un bon départ avec ça mais ça s'est vachement compliqué quand j'ai eu besoin d'interagir avec ce flux UDP à partir de l'interface web...

Vu que l'interface est externe au programme, il faut arriver à communiquer avec pour lui envoyer une trame et attendre un résultat en effectuant toute une série de contrôles comme le fait actuellement Domocan CE4. J'ai eu des résultats en me bricolant une interface UDP en PHP qui se connecte directement sur la LandTiger pour envoyer une trame via l'interface web et lire le résultat mais le problème c'est qu'il y a déjà mon programme qui utilise l'ip/port et c'est pas trop naturel de forcer ça avec des options. Je me suis donc lancé à ajouter un serveur TCP/IP dans mon programme interface pour le "piloter" via un client TCP PHP mais je me suis perdu dans mes threads mutex et conditions et du coup ça marche plus.

Avec C#, j'ai une bien meilleur gestion des évènements et je trouve plus facile d'intégrer différentes interfaces dans un même programme sous la forme de plugins. Je me retrouve avec le même problème, il me faut communiquer entre l'interface web et le programme C#. J'étais partis sur l'idée de refaire mon serveur TCP sous la forme d'un plugin mais en faisant des essais, je me suis rendu compte que communiquer entre l'interface web et le programme se faisait plutôt du coté "client" que "serveur". J'en étais arrivé à transformer mon client PHP en service Symfony et j'y faisais des appel via JQuery. Tout bien réfléchis, j'essaye autre chose et j'ai remplacé mon serveur TCP par un serveur WebSocket. Le service Symfony n'existe plus et maintenant c'est javascript qui vient se connecter sur le serveur WebSocket quand la page est chargée et ça te permet de piloter l'ensemble mais aussi de faire réagir ton interface à des évènements provenant du serveur.

Un exemple : au lieu d'utiliser dans ta page web un timer qui toutes les secondes fait une requête vers un script pour afficher une valeur à l'utilisateur "en temps réel", avec websocket tu as un évènement javascript sur ta page à chaque fois que le serveur t'envoi quelque chose. Il te reste plus qu'à faire quelques tests pour identifier ce que le serveur te raconte et tu mets à jour la valeur.

Je sais pas si c'est très clair ^^

A bientôt
Tant que vous avez des dents, croquez des pommes !  (^_^) ♪♫  ♪
Répondre
#4
Koala,

Juste pour ton info, mon framework, basé sur PHP (et bridge en C pour remplacer EZL ainsi que de lmancer des commandes PHP qui vont analyser les retours CAN et les traduire en actions compréhensibles par l'utilisateur) n'est pas obligé de reloader les pages pour afficher les changements d'états. On utilise un serveur NGINX avec module NCHAN qui permet d'implémenter un serveur de type COMET. Ceci permet, avec JQUERY sur la page utilisateur et un channel qui reçoit les retours d'informations ouvert en permanence (changement d'états, de température, etc) de réagir à ces stimuli ...et par exemple passer une lampe de l'icone éteinte vers allumée ... sans un reload! ;-)

En plus, cela permet (AJAX) de lancer des commandes, à travers le browser, via le serveur ... aussi sans reload/post!

Ce qui fait que quand un utilisateur clicke sur une lampe pour la changer d'état, pas de reload, la commande est passée au serveur à travers une fonction AJAX déclarée, qui la traduit en action complexe (programmée en PHP ... configs en DB MySQL), qui lance la commande CAN pour inverser la lampe. La GRAD16 reçoit la commande, agit sur le triac, et renvoi le statu sur le bus CAN. Le bridge en C, intercepte la trame DomoCAN (directement sur bus CAN ou via EZL/Landtiger sur UDP 1470 dépendant de ta config HW), lance le script PHP de décodage qui va faire passer le message dans le channel COMET. Comme un script sur la page user écoute sur ce channel et décode les message qui la concerne, la lampe va changer d'état (icone)... CQFD.

... Only my 2 €uro Cents, Henry
Répondre
#5
... ce qu'il nous manque, il me semble, c'est la partie automate programmable ... à mon avis, l'idéal serait en Blockly qui permet de façon visuelle de programmer et donc diminue la connaissance minimum pour faire fonctionner le système et ... permet un backup/restore et échange de code!

PS: Selon moi, il y aurait même moyen de pousser une config de base dans les carte GRAD16 et IN16 afin d'assurer le flip/flop (ou autre config basic) dans les cartes et d'ajouter de l'intelligence pour le reste, via la Raspberry!?! ... j'ai une microbase sur Blockly, mais je ne suis pas loin 8-(
Répondre
#6
Salut Henry,

Il faut vraiment qu'on se contacte via une messagerie instantanée :o)

Je ne connais pas trop NCHAN et COMET, ça ressemble à ce que j'ai obtenu avec les Websockets. Il faut voir les avantages et inconvénients

On va avoir beaucoup de points communs puisque c'est presque une centrale que tu as réalisé. J'ai étudié certains passages de ton travail pour m'inspirer ou pour réfléchir notamment ton morceau de C++. J'ai finis par laisser tomber cette voie là car je n'ai pas réussis à adapter pour envoyer un programme via l'interface en mode bootloader.

Je cherche à faire la même chose que toi à quelques petites différences près. Je vais tenter de fusionner Domogest avec l'interface web. J'ai commencé un essais avec mono et un de mes premiers objectifs étaient de manipuler plusieurs interfaces tout en restant dans un même programme. Je suis trop habitué à Linq et les évènements C# pour retourner en C++ et en plus Bigonoff nous a laissé un exemple fonctionnel que je bidouille au quotidien :o) Maintenant je cherche à créer des systèmes pour renuméroter automatiquement les cartes ou des trucs dans le genre.

Après je ne crée pas mon propre framework car je cherche à m'appuyer au maximum sur de l'existant. Je cherchais surtout à organiser mon projet web tout en restant modulable et c'est exactement ce j'ai trouvé avec Symfony. Si on regarde ce qu'on a besoin coté php, ce n'est rien de plus qu'un simple site web avec une bonne gestion des process. Dans Symfony, tu as tout un standard qui te permet de manipuler facilement tout ça et c'est bien documenté. Synchrone ou asynchrone avec des méthodes proches de celles que tu trouves quand tu manipules les threads, je trouve ça facile à utiliser.

En attendant j'ai réalisé mon premier script shell pour préparer le Raspberry Pi, je cherchais à faire une installation personnalisable :

https://github.com/domocan-koala/pi-seed

J'en parlerai plus tard mais l'optique c'est d'installer l'environnement web et de télécharger la dernière version de mon projet Symfony. Une fois le site fonctionnel, il va télécharger des composants en fonction du matériel. A l'heure actuelle le site est un simple projet vide, je vais bientôt montrer un exemple pour commencer à mettre en pratique l'intégration de bundle, commencer à bien exploiter les annotations doctrine et par la même occasion, essayer de présenter ce que je vais faire avec les interfaces.

A bientôt
Tant que vous avez des dents, croquez des pommes !  (^_^) ♪♫  ♪
Répondre
#7
Video 
Hello tous Smile

Je me permet d'intervenir sur ce sujet qui nous est tous cher, Henry désolé mais je n'ai toujours pas le temps d'avancer pour partager mon framework mais je peux déjà vous donner quelques idées:

Tout d'abord, la version actuelle de mon interface tourne sur un nas depuis au moins 7 ans, sans pb majeur, c'est comme vous: développé a partir de PHP sous Apache 2 mais sans programme compilé pour l'UDP, je travail avec les socket PHP natives (donc 100% PHP).
Le problème avec PHP, c'est le temps de traitement des algos et aussi la socket, vu qu'on n'est pas en temps réel, mais que ce n'est pas critique pour notre environnement, c'est quand même un peu juste, surtout si a terme on fait tout tourner sur du PI et qu'on fait une carto complète, elle met quelques secondes de plus que sous Domogest natif.

Bref, j'ai commencé il y 3 ou 4 ans à tout re-coder en nodeJs, de part sa mis en œuvre assez simple et le langage javascript que je connais par cœur, j'y trouve mon compte, et surtout c'est que ça reste super puissant et très très très rapide à l'exécution, je vois maintenant la différence, c'est impressionnant.
Node gère sans soucis les sockets UDP ce qui permet aussi de s'affranchir de programme externe.
Mais l'avantage majeur que j'ai trouvé à cela, c'est surtout la gestion des websocket natives, ce qui rejoins vos interrogations sur les connections entre le serveur et le client: plus besoin de code client avec un timer pour rafraichir les données, le serveur fait une sorte de push, et tout est géré automatiquement avec les websockets, c'est comme des connections persistantes client/serveur du protocole http 1.1, mais qui pallie les failles de se dernier et qui est plus souple, c'est parfait pour nos applis Smile

L'interface web est responsive, donc pas de pb entre un passage d'écran de mobile, tablette ou pc, les applis android et IOS ne sont pas encore abouties mais dépannes pas mal et servent aussi à recycler de vieux portable en guise d'interrupteurs hi-teck :p

ça tourne bien mais je n'ai pas eu le temps de tout transférer et de faire une grosse recette sur mon install, c'est pourquoi les deux versions tournent sur mon reseau encore à ce jour (via des redirection de flux UDP en broadcast au niveau de la couche 1 OSI).

J'essaye de mettre quelques photos des interfaces, j'ai pour l'instant toujour une page de config auto en fonction de ce que le serveur trouve sur le Bus Can et ensuite on peut directement dans l'interface web créer ses propres pages web perso en ajoutant des sliders, boutons ou function, il me reste à gérer entierement la partie fonction des cartes (horloge surtout).
Ensuite j'ai aussi un DomogestLike version web qui permet de faire une partie du domogest actuel, il faut que je termine mais je doit être a 75% du fonctionnement total, la gestion, l'edition et l'affectations des trames fonctionne sans accros.

Pour finir ce dernier serveur tourne sur un pi (enfin sur 3 PI car installé dans 3 maisons différentes sur des installation domocan complète), ma famille est contente de ces pages web, cela convient à la plupart des utilisateurs, moi je veux aller au bout des choses et être non dépendant d'un windows avec domogest (100% web + applis android et IOS).
Il s'installe à partir d'une version fraiche de PI avec des scripts d'admin, mais depuis quelques temps les évolutions de node sont nombreuses et il faut que je reprenne mes scripts.

J'essaye de mettre quelques photos, mais une vidéo serait plus parlante, je fait ça après mes vacances (bien méritées)

Edit: j'ajoute des vidéos en pj, pour domogestweb, c'est une capture avec une simalation sous chrome d'un nexus5, l'ecran est donc un peu jute, et les fonction d'edition de trame bugs pour info, sur un navigateur sous PC ça fonctionne parfaitement

Edit bis: impossible d'ajouter des pj, je met un lien ici :
VIDEOS
Répondre
#8
Hello,

ça a l'air super bien au point ce que tu as fait !

BRAVO
Répondre
#9
Salut, oui c'est bien.

J'en profite pour vous dire qu'en ce moment c'est 5$ les 10 circuits 10/10 max 2 couches sur Seeed studio.

@ bientôt
Tant que vous avez des dents, croquez des pommes !  (^_^) ♪♫  ♪
Répondre