Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
KNXWEB : état des widget correct à l'affichage
#1
Bonsoir à tous,

J'ai avancé un peu depuis mon dernier message, et je vous remercie encore pour votre aide.

J'ai réussi à paramétrer une visualisation simple mais complète de l'état de mes éclairages dans l'ensemble de ma maison, en consacrant une demie-heure par-ci par-là au paramétrage de cette visualisation sur linknx/knxweb2, tournant sur mon RaspberryPi, et j'allais m'intéresser à la représentation de l'état de mes volets roulants, quand j'ai eu besoin d'arrêter et relancer mon RaspberryPi.

Première mauvaise surprise : autant j'ai sauvegardé régulièrement mon design, autant j'ai totalement oublié de sauvegarder la définition de mes objets dans le fichier linknx.xml. J'ai perdu les 2/3 de mon travail. J'en apprends donc un peu plus sur le fonctionnement de l'interface et ne me ferait plus avoir comme ça !

Deuxième surprise : pour les objets qui sont restés, plus rien ne fonctionne. Enfin si, si je teste mon design, j'arrive en général à allumer une lampe depuis le design, mais son état sur ce dernier ne se met plus à jour, et plus moyen de l'éteindre donc !

J'avais paramétré mon design avec, pour chaque éclairage :
- un objet ecl_<xxx> de type EIS 1.001, correspondant à la GA du retour d'état de la commande d'éclairage de la lampe xxx. La valeur initiale de cet objet était récupérée du stockage persistant, j'ai paramétré une historisation de chaque changement de valeur de cet objet et les flags sont restés ceux par défaut (CWTU).
- un objet on_off_<xxx> de type EIS 1.001, correspondant à la GA de commande d'allumage de la lampe xxx. Paramétrage en tout point identique à l'objet ci-dessus, à ceci près que j'avais paramétré un listener dans cet objet, pointant vers le GA du retour d'état de la commande, et que j'avais coché "lire".

Bon, j'étais arrivé à ce paramétrage un peu par hasard, en tâtonnant, et tant que mon RaspberryPi était en vie, cela fonctionnait à merveille. Je pouvais me connecter de n'importe où (iPad, PC, etc ...) j'avais accès à l'état exact de mes éclairages et je pouvais les modifier par cette interface. Un seul bémol, un petit temps de latence entre l'action faite sur l'interface, et l'état de l'objet après l'action. Ceci était sans doute du au fait que le feedback-object du bouton ne pointait pas sur l'objet de commande mais sur l'objet d'état.

Constatant donc que ma façon de paramétrer ma visualisation pouvait ne pas fonctionner dès la première coupure de courant, j'ai décidé de revoir tout ça et trouver le fonctionnement qui marchera à tous les coups avant de redévelopper totalement ma visualisation.

J'ai lu dans l'historique du forum EIBD/Linknx/knweb2 sur Google groups que je ne suis pas le seul à ne pas bien comprendre la notion de listener. J'ai lu également que je n'étais pas obligé d'utiliser deux objets pour gérer mon éclairage. J'ai donc essayé de reparamétrer ma visualisation ainsi :
- un seul objet déclaré dans linknx concernant mon éclairage.
- sa GA correspond à la commande d'éclairage
- les flags restent inchangés (CWTU)
- sa valeur initiale est théoriquement mise à jour par requête sur le bus
- historisation à chaque changement de valeur
- listener sur la GA correspondant au retour d'état de la commande, case lire cochée.
En clair :
Code :
<object type="1.001" id="on_off_bureau" gad="1/0/9" init="request" log="true">Eclairage bureau
            <listener gad="1/1/9" read="true" />
</object>

Sur le principe, lorsque je teste mon design, l'état réel de mon éclairage n'est pris en compte qu'après le premier clic sur mon bouton représentant l'éclairage, lequel est paramétré comme suit :
Code :
<control type="button" picture="32x32_lightOff2.png" picture-active="32x32_lightOn2.png" display-picture="no" text="Bureau" size="12" color="#000000" align="" text-padding="0" text-padding-left="0" confirm="no" feedback-object="on_off_bureau" feedback-compare="eq" feedback-value="on" inactive-goto="" inactive-action="" active-goto="" active-action="" x="808" y="545" width="32" height="32" desc="Eclairage du bureau">
        <actionlist id="inactive-action">
                     <action type="set-value" id="on_off_bureau" value="on"/>
        </actionlist>
        <actionlist id="active-action">
                     <action type="set-value" id="on_off_bureau" value="off"/>
        </actionlist>
</control>

Par contre, plus de temps de latence, ça réagit immédiatement. On ne peut pas perdre sur tous les tableaux !

Un peu d'aide pour m'expliquer comment traiter mon problème ?

Je précise que du point de vue fonctionnement, tous mes BP se comportent à merveille, en simple point comme en multi-point.

Merci de votre aide.

Cordialement.
Répondre
#2
Bonjour,

c'est bien documenté, il ne reste plus qu'à tester Smile

Voilà ce que je ferais:
1) Démarrer un surveillant de bus (Group Monitor d'ETS ou groupsocketlisten en ligne de commande)
2) Redémarrer linknx
3) Vérifier qu'il y a bien une demande de lecture (Read request) addressée à 1/1/9.
4) Vérifier qu'il y a bien une réponse (et une seule) (Read response) diffusée sur 1/1/9
5) Vérifier qu'il n'y a pas de lecture ni de réponse sur 1/0/9

Bonne recherche !
Répondre
#3
Bonsoir Sphinkx,

Tout d'abord, merci pour ton aide.

Voici ce que je peux voir défiler lorsque je mets en application ton mode opératoire :
Code :
Read from 0.0.0 to 1/1/9
Response from 1.0.9 to 1/1/9: 01
Read from 0.0.0 to 1/1/0
Response from 1.0.6 to 1/1/0: 00
Read from 0.0.0 to 1/1/2
Response from 1.0.6 to 1/1/2: 00
Read from 0.0.0 to 1/1/4
Response from 1.0.6 to 1/1/4: 00
Read from 0.0.0 to 1/1/3
Response from 1.0.6 to 1/1/3: 00
Read from 0.0.0 to 1/1/1
Response from 1.0.6 to 1/1/1: 00
Read from 0.0.0 to 1/1/5
Response from 1.0.6 to 1/1/5: 00
Read from 0.0.0 to 1/1/10
Response from 1.0.8 to 1/1/10: 00
Read from 0.0.0 to 1/1/7
Response from 1.0.11 to 1/1/7: 00

Donc à priori, le résultat est conforme à tous les points de ton mode opératoire.

Dans la liste ci-dessus, le retour d'état lié à mon éclairage du bureau est bien positionné à "on". Pour autant, l'état de ma lampe sur ma visualisation reste à "éteint". Si je clique une première fois sur le bouton alors que la lampe est allumée, l'image active du bouton remplace la précédente, la lampe ne change pas d'état. Le clic suivant (et tous les autres) fait (font) ce qu'on attend de lui (d'eux).

Je me demande, d'après ce que tu écris, si je ne fais pas fausse piste avec une seule GA pour gérer l'état de mon bouton. En effet, dans le paramétrage du bouton, le feedback-object correspond à l'objet on_off_bureau (1/0/9) et en théorie, il devrait donc y avoir un read dessus à la construction de la page. Ai-je bien compris ?

Merci de ta réponse.
Répondre
#4
Pas mal !
Ca à l'air de bien marcher au niveau KNX et de la demande de valeur initiale par linknx.

Maintenant, on peut vérifier ce que linknx a effectivement compris.

Donc refaire la manip précédente puis se connecter à linkx en direct pour l'intérroger.
Les adresses et ports pour la connection sont dans le fichier config XML de linknx.

Pas très convivial d'entrer du XML en direct, sans trop de fautes de frappe, mais soit...
Chez moi ça marche comme cela en utilisant telnet et ma config:

telnet 192.168.1.102 1028
Trying 192.168.1.102...
Connected to 192.168.1.102.
Escape character is '^]'.
<read><object id="AmiPlaStaLsnr"/></read>
ne pas oublier le retour à la ligne et puis Ctrl-D
et la réponse arrive

<read status='success'>off</read>

... après avoir allumé avec un bouton poussoir, c'est différent...
<read><object id="AmiPlaStaLsnr"/></read>
<read status='success'>on</read>

A essayer pour vérifier que ce que linknx pense de l'état de "on_off_bureau" dans ton installation.

Bien sûr, après redémarrage de linknx, je rafraîchis la visu knxweb2 (fermer la page ou bouton reload this page) et ca marche tout seul du premier coup.

L'autre alternative est de définir deux objects dans la config linknx, un pour le retour d'état, l'autre pour la commande et de modifier la définition du bouton dans knxweb2 en conséquence. Dans ce cas, il ne faut pas demander de lire la valeur initiale de l'object de commande...

A suivre ?

Répondre
#5
Salut,

ta config semble bonne en effet pas besoin de 2 object il seul suffit avec le ou les listener qui vont bien pour le retour d'état

@sphinkx bonnes idées mais,

il est possible de lire les données linknx de façon beaucoup plus "simplement" via knxweb par exemple la section "object" va afficher la liste des objects et aussi dans e tableau pour chacun d'eux afficher la valeur interne de linknx
ou le faire de façon unitaire aussi sur avec la fonction "Lire/ecrire un object"
ou encore le script linknx_cmd.php à la racine du dossier knxweb qui va te permet d'envoyer les requetes xml directement à linknx (comme celle que propose sphinkx )

sinon pour ton problème si je pense que si cela ne met pas ajour le status dans knxweb cela viens peut-être d'un object qui n'existe plus dans linknx et qui peut être utilisé dans knxweb

tu peux voir avec la console dans chrome ou avec firebug dans firefox, les requetes passées entre knxweb et linknx et voir les éventuelles erreur
sinon voir les valeurs retournée par linknx

après il y a de la config knxweb également dipso dans la partie "admin" je te conseil de ne pas utiliser pour le moment "useEventSource" ni "useJavaIfAvailable"
qui ne doivent donc pas être "coché" dans la "configuration knxweb" (techniquement c'est le fichier knxweb
/inlcude/config.xml )

en espérant que cela aide

@+
Anthony.
Knxweb : http://www.knxweb.fr/
Dépot des sources : https://github.com/linknx/knxweb
Version de démo de Knxweb : http://www.knxweb.fr/demo/setup.php
Script install du trio : https://github.com/linknx/install
Export ETS génère le linknx.xml : http://www.knxweb.fr/ETS/index.php
Répondre
#6
Bonjour à tous,

@Energy01 je sais que j'ai activé les options useEventSource et useJavaIfAvailable dans mon fichier de configuration knxweb. Dès que je repasse devant mon RaspberryPi (demain soir en fait), je mets à jour ma config et je reteste.

Si pas mieux, je regarderai également la console de Chromium.

Merci également pour votre disponibilité et les pistes que vous me donnez.

Stay tuned.

Cordialement.
Répondre
#7
Bonjour à tous,

Je confirme les pistes données par @Energy01, et suis en train de reconstruire ma supervision, en prenant bien soin de sauvegarder régulièrement les modifications de mon paramétrage.

Je vous remercie tous d'avoir accordé un peu d'intérêt à mon problème.

Bonnes fêtes de fin d'année à tous.

Cordialement.
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)