les variables javascript sont communes à tous les équipements d'un même connecteur ??

[tilleul]

Je viens de me rendre compte d'un truc vraiment bizarre: il semblerait que deux équipements génériques liés au même connecteur ont leurs variables javascript en commun !

Pour s'en rendre compte, il suffit de créer deux équipements génériques liés au même connecteur (apparemment il n'y a pas de souci si les connecteurs sont différents) avec chacun une variable X (string par ex.), créer une commande JS dans l'un des deux équipements du genre "X='bonjour';", puis dans le DS, créer deux widgets affichant chacun le contenu de chaque variable X. Dès qu'on exécute la commande les deux widgets affichent "bonjour" ...

Est-ce normal ou est-ce que ma LD disjoncte ?

Personnellement ca ne me semble pas très logique: il me semble que chaque équipement doit pouvoir avoir des variables de même nom (variables qui en plus sont considérées comme des "états" !) sans nécessairement les partager avec ses copains qui utilisent le même connecteur. Sinon quel est l'intérêt d'avoir plusieurs équipements sur ce connecteur ?

:confused:

[tilleul]

Est-ce que quelqu'un de l'équipe LD peut confirmer que le message précédent a été lu et pris en compte ?
En effet, en poussant mes tests un peu plus loin, je peux carrément avoir deux équipements contenant un même nom de variable mais de type différent ! Par ex, équipement1 possède une variable X de type STRING et équipement2 possède une variable appelée également X mais de type DOUBLE. Autant dire que l'affichage dans le DS de ces deux états génère une erreur (widget en rouge) dans l'équipement2 lorsque équipement1 attribue une chaine de caractère à "sa" variable X ...[ATTACH=CONFIG]308[/ATTACH]

Peut-on espérer une correction rapide de ce problème ou au moins une explication sur le pourquoi du comment et une information sur un planning possible de résolution de la chose ... merci ...

[laurent]

Bonsoir,

personnellement, je ne suis pas très étonné par ce fonctionnement.
Les variables javascript peuvent en effet être renseignées à partir d'un script Javascript lié au connecteur en décodant les trames qu'il reçoit. A ce stade, le script n'est lié aucunement à un équipement. Du coup, il est logique que la variable soit mise à jour dans l'ensemble des connecteurs qui la compose.

Laurent

[tilleul]

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.

[laurent]

C'est sur que la gestion du Javascript est largement perfectible, mais je trouve (tout comme toi semble-t-il) ce quid st déjà possible énorme.
A titre d'exemple, j'ai pu redévelopper from scratch une interface en RS232 avec mon alarme grâce à ça en allant jusqu'à introduire une autre façon de construire / gérer les trames reçues que celles proposées en standard. C'est énorme de pouvoir faire ça dans une box domotique.
Autre exemple, lorsque j'étais bloqué par un processus d'authentification non géré par LD, j'ai pu passer par un serveur apache tiers pour contourner le soucis. C'était possible.
On peut déjà, en l'état, quasiment tout faire.
Maintenant, je suis d'accord qu'un axe de progrès serait vers la facilité à le faire. Je crois que l'équipe LD avance à grands pas sur le sujet et prends vraiment en compte les remarques des uns et des autres.

Bonne soirée,
Laurent

[tilleul]

laurent a écrit :On peut déjà, en l'état, quasiment tout faire.

C'est tout à fait vrai. Parfois de manière fort tordue, mais c'est vrai.

Repensant à ce que tu disais sur le fait que les variables peuvent être déclarées dans le script du connecteur, j'ai déclaré une fonction dans ce même script, espérant qu'elle serait disponible pour tous les équipements du connecteur. Malheureusement ca n'a pas l'air d'être le cas. Dommage car cela aurait pu être bien pratique.

Par contre, dans l'état actuel, le fait de pouvoir modifier une variable appartenant à un autre équipement du même connecteur pourrait en définitive avoir un intérêt mais sincèrement je préfèrerais pouvoir interagir directement sur un autre équipement depuis du code JS.

D'ailleurs voici une liste de choses (non-exhaustive) qu'il serait bon d'améliorer pour le moteur JS de LD:

1) chaque équipement JS d'un même connecteur doit pouvoir avoir des variables/états qui lui sont propres, quitte à utiliser le terme de "privé" et "public" comme cela a été fait pour les variables des modules logiques

2) avoir de nouveaux types de variables/états, notamment "booléen" et, si possible, array. Bien entendu intégrer le support ces types dans le WISEE/WIDO et les automates

3) pouvoir accéder aux éléments des variables/états de type "liste" depuis le WISEE/WIDO et les automates. Ce type de variable est un peu tordu à gérer (ce n'est pas un vrai "array") mais je l'ai déjà détourné des dizaines de fois de son utilité primaire de "gestion de liste de lecture" pour y stocker (et afficher !) 1000 infos différentes (qui n'ont rien à voir avec de l'audio). Le principal problème étant l'exploitation d'un élément particulier de la variable "liste".

Tiens à propos du widget "liste", un truc qui serait vraiment bien c'est que lorsqu'on change d'écran et que le nouvel écran contient un widget liste, la ligne sélectionnée dans ce widget soit directement visible (par ex si c'est la ligne 18 sur 40 et que le widget n'affiche que 10 lignes à la fois, le widget "scrolle tout seul" jusque la ligne 18 de manière à l'afficher en première position).

4) trouver un moyen pour pouvoir piloter un équipement depuis un autre équipement, donc accéder à ses commandes, mais aussi pouvoir lire ses états, à travers du code JS. L'idéal serait qu'on puisse le faire quel que soit le type d'équipement (JS ou pur KNX !) mais si c'est juste pour les équipements JS ce sera déjà un GRAND bond :). Pour l'instant je le fais en faisant du "ping-pong" entre le JS et les modules logiques mais ce serait bien de pouvoir éviter ca.

5) Avoir la possibilité d'ajouter du code et des états JS même pour un équipement classique, notamment KNX. Cela permettrait de coder des comportements complexes sans passer par le module logique.

6) Intégrer des déclencheurs dans le moteur JS (ceci afin de ne plus devoir le faire dans le module logique). Non, je n'ai rien contre le module logique en soi :) mais le champ des possibilités est beaucoup plus grand en JS.

7) le moteur JS devrait au mieux être réellement multitâche (ce qu'il n'a pas l'air d'être d'après les quelques tests que j'ai pu faire) et à défaut utiliser une file d'attente d'exécution (ce qu'il a l'air de faire pour le moment du moins pour les événements très rapprochés).

8) Avoir la possibilité d'utiliser des "librairies" de fonctions ou au moins une "réserve" de fonctions communes faites maison sans devoir les recopier dans chaque commande d'équipement.

9) Avoir un éditeur de code JS digne de ce nom, avec au minimum une police de caractères de taille fixe (genre Lucida Console ou Courier) et une zone d'édition plus grande l'actuelle (plein écran ou presque ?). Le fin du fin serait du "syntax highlighting" bien sur, mais sincèrement ce n'est pas nécessaire à ce stade.

10) Permettre un copier/coller d'équipements JS qui copie les scripts de commande et les variables

Je sais ca fait beaucoup ... :D

Mais apparemment je ne suis pas le seul à deviner la puissance que le JS pourrait libérer. A l'instar d'un Home Center de Fibaro (qui utilise du Lua) ou d'un EibPort de Babtec (qui utilise Java), la Lifedomus aurait (enfin ?) un moteur de programmation évolué.