04-02-2014, 09:18 PM
Bonsoir Laurent
tu as raison, remis en perpective, c'est probablement la raison historique de ce fonctionnement. Je le comprends et je l'accepte.
Mais je persiste à croire que cela doit être changé, à moins qu'on ne considère pas Lifedomus comme un superviseur indépendant du protocole utilisé par les équipements.
L'ouverture vers le monde TCP et HTTP (et dans une moindre mesure RS232) permet justement à la Lifedomus de se lier à des systèmes divers et variés, parfois simples mais également parfois complexes.
Pour moi les connecteurs TCP/HTTP et le JS doivent permettre la communication vers par exemple des automates programmables (Wago, Beckhoff, etc.) mais également pourquoi pas vers une autre LD ou un autre système multi-protocole. Dans le cas des automates programmables, ce que ces machines sont capables de gérer dépasse complètement le stade KNX/ZWave/Enocean et Netatmo/Sonos/IRTrans/Gadgets ... on parle de matériel DALI, DMX, CANOpen, etc ou "strictement" électriques (relais dans le sens le plus pur du terme, pilotés directement). On parle d'éclairages, mais aussi de pompes, de vannes, de systèmes de ventilation, de chauffage, d'ascenseurs, etc. Bref de la gestion technique de bâtiment. Avoir une gestion d'équipement JS telle que LD le propose actuellement avec des variables communes à tous les équipements rend caduc voire impossible (mais au minimum très lourd) tout espoir de communication vers ce monde. En effet, tout comme pour une Lifedomus, une adresse IP (généralement) gère et fait office de passerelle vers des dizaines, voire des centaines d'équipements, sur plusieurs protocoles différents. Si on veut que Lifedomus puisse servir de supervision pour ces équipements, le modèle "Equipement JS" intégré actuellement DOIT évoluer.
En outre, cela fait maintenant plusieurs semaines que je triture le modèle JS de la Lifedomus dans tous les sens. Je SAIS que je suis en train de pousser la LD dans ses derniers retranchements (à ce niveau) et je pense que cela n'a encore été réalisé par personne et peut-être même pas envisagé par l'équipe LD. Je suis en train de réaliser des choses, avec une facilité (une fois que c'est mis en place quand même :) ) que je n'aurais pas imaginée il y a seulement quelques semaines. En effet, à présent les "automates LD" servent presque strictement au déclenchement d'événements dont le traitement est en réalité repris à 70% par du code JS, beaucoup plus flexible (malgré quelques restrictions et les nombreux obstacles de l'interface du CS à ce niveau). Je suis en train de revoir complètement la manière de gérer un projet de A-Z, à la fois pour moi et mes clients. Les nombreuses fonctionnalités "manquantes" dont se "plaignent" (à ne pas prendre péjorativement) certaines membres du forum sont en réalité réalisables dans 90% des cas en utilisant des équipements JS.
C'est encore loin d'être parfait, cela peut paraître parfois plus lourd à mettre en place mais en réalité je gagne énormément de temps: rien de plus facile que de faire du copier/coller de code et/ou de la recherche dans du texte pour remplacer un nom de variable par un autre. A comparer avec le temps que cela prend de "tirer des liens" entre les différents blocs des modules logiques de la LD ou remplacer dans ces mêmes blocs une variable ou un état d'équipement par un(e) autre.
C'est également pour cela que je pense que la gestion du Javascript avec LD doit évoluer vers un mieux.
tu as raison, remis en perpective, c'est probablement la raison historique de ce fonctionnement. Je le comprends et je l'accepte.
Mais je persiste à croire que cela doit être changé, à moins qu'on ne considère pas Lifedomus comme un superviseur indépendant du protocole utilisé par les équipements.
L'ouverture vers le monde TCP et HTTP (et dans une moindre mesure RS232) permet justement à la Lifedomus de se lier à des systèmes divers et variés, parfois simples mais également parfois complexes.
Pour moi les connecteurs TCP/HTTP et le JS doivent permettre la communication vers par exemple des automates programmables (Wago, Beckhoff, etc.) mais également pourquoi pas vers une autre LD ou un autre système multi-protocole. Dans le cas des automates programmables, ce que ces machines sont capables de gérer dépasse complètement le stade KNX/ZWave/Enocean et Netatmo/Sonos/IRTrans/Gadgets ... on parle de matériel DALI, DMX, CANOpen, etc ou "strictement" électriques (relais dans le sens le plus pur du terme, pilotés directement). On parle d'éclairages, mais aussi de pompes, de vannes, de systèmes de ventilation, de chauffage, d'ascenseurs, etc. Bref de la gestion technique de bâtiment. Avoir une gestion d'équipement JS telle que LD le propose actuellement avec des variables communes à tous les équipements rend caduc voire impossible (mais au minimum très lourd) tout espoir de communication vers ce monde. En effet, tout comme pour une Lifedomus, une adresse IP (généralement) gère et fait office de passerelle vers des dizaines, voire des centaines d'équipements, sur plusieurs protocoles différents. Si on veut que Lifedomus puisse servir de supervision pour ces équipements, le modèle "Equipement JS" intégré actuellement DOIT évoluer.
En outre, cela fait maintenant plusieurs semaines que je triture le modèle JS de la Lifedomus dans tous les sens. Je SAIS que je suis en train de pousser la LD dans ses derniers retranchements (à ce niveau) et je pense que cela n'a encore été réalisé par personne et peut-être même pas envisagé par l'équipe LD. Je suis en train de réaliser des choses, avec une facilité (une fois que c'est mis en place quand même :) ) que je n'aurais pas imaginée il y a seulement quelques semaines. En effet, à présent les "automates LD" servent presque strictement au déclenchement d'événements dont le traitement est en réalité repris à 70% par du code JS, beaucoup plus flexible (malgré quelques restrictions et les nombreux obstacles de l'interface du CS à ce niveau). Je suis en train de revoir complètement la manière de gérer un projet de A-Z, à la fois pour moi et mes clients. Les nombreuses fonctionnalités "manquantes" dont se "plaignent" (à ne pas prendre péjorativement) certaines membres du forum sont en réalité réalisables dans 90% des cas en utilisant des équipements JS.
C'est encore loin d'être parfait, cela peut paraître parfois plus lourd à mettre en place mais en réalité je gagne énormément de temps: rien de plus facile que de faire du copier/coller de code et/ou de la recherche dans du texte pour remplacer un nom de variable par un autre. A comparer avec le temps que cela prend de "tirer des liens" entre les différents blocs des modules logiques de la LD ou remplacer dans ces mêmes blocs une variable ou un état d'équipement par un(e) autre.
C'est également pour cela que je pense que la gestion du Javascript avec LD doit évoluer vers un mieux.
www.osmotiq.com, domotique, développement logiciel et web -- tests & tutoriels KNX, Lifedomus, ZWave, etc.
Twitter: osmotiq
Twitter: osmotiq