Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
communication entre knxweb et linknx
#1
Bonjour,

j'ai un souci déjà évoqué ici :
http://groups.google.fr/group/domotique-...749146b83b

En résumé : knxweb semble fonctionner : je peux allumer et éteindre
une lampe, mais si j'utilise un bouton poussoir, ou bien si je
recharge la page de knxweb, la lampe apparait à l'écran du navigateur
toujours éteinte, bien qu'elle puisse être allumée.

Après avoir passé plusieurs nuits à essayer plein de choses, il me
semble que le problème est que knxweb n'est pas capable de lire (read)
un état connu de linknx, alors que knxweb est bien capable d'écrire
(je peux allumer et éteindre une lampa avec knxweb).

En utilisant firefox + le plug'in firebug, je peux voir que les ordres
"write" envoyés à linknx par knxweb sont bien reçus, et bien exécutés,
mais que les ordres "read" ne reçoivent jamais de réponse.

J'utilise linknx 0.0.1.27 et knxweb 0.6.1 (prélévés sur Sourceforge).
Eibd fonctionne bien (interface IP Siemens N148/21) : les commandes
$ groupswrite ip:192.168.0.12 1/3/22 0
$ groupswrite ip:192.168.0.12 1/3/22 1
$ groupreadresponse ip:192.168.0.12 1/3/22
me permettent respectivement d'éteindre, d'allumer, et de lire l'état
de l'actionneur TOR a l'adresse de groupe 1/3/22. Le retour est alors
toujours bon.

Linknx, dans le même temps, voit bien les changements d'états demandés
par les commandes ci-dessus, et me semble donc bien savoir dans quel
état est l'actionneur (je n'utilise pas l'option -d, et je vois les
messages qui s'affichent dans la shell).

Auriez-vous des idées ?
#2
Salut,

Moi j'avais exactement le même soucis ...
Knxweb pouvais allumer/éteindre une lampe mais ne voyais pas l'état
réel de cette lampe. Du coup, si j'allumais la lampe avec un bouton
physique, la lampe restait éteinte dans Knxweb, mais allumé en réel !

Le soucis venait du fait qu'il y avait une variable dans knxweb qui
n'était pas renseignée dans linknx.xml
On peut le voir avec le plugin firebug dans l'onglet réponse.

Fait une passe sur tes variables, et tout devrait rentrer dans
l'ordre.
( N'oublie pas de relancer Linknx et eibd après modification )
#3
Merci pour ta réponse.

je viens de re-tester comme tu me l'indiques, et c'est un peu surprenant.

Test 1 : J'ai dans knxweb un design avec une seule zone, et dans cette zone
un seul objet (une lampe, enfin, un switch). Cet objet existe bien dans
linknx (il est défini dans le fichier conf/linknx.xml), et je peux
l'actionner à partir de knxweb. Par contre, impossible d'avoir son vrai état
dans knxweb. Firebug montre que les opérations imposées pas knxweb de
commutation fonctionne bien, et je peux voir leur réponse. Par contre, il
n'y a jamais de réponse de linknxw pour une interrogation en lecture de
l'état.

Test 2 : Suivant tes indications (mais en les déformant un peu ;-) ), j'ai
changé le nom de l'objet dans knxweb (j'ai mis un nom qui n'existe pas dans
linknx). Et là, j'ai un message d'erreur dans knxweb qui m'indique que
l'objet n'existe pas. En plus, firebug montre que knxweb demande toutes les
secondes l'état à linknx, et la réponse existe à chaque fois, et elle est
une erreur (l'objet n'existe pas).

Ce qui me surprend, c'est que dans le 2eme cas, knxweb et linknx arrivent à
communiquer (toutes les secondes, pour avoir l'etat des objets), mais que
dans le premier cas (quand l'objet existe), linknx n'envoie jamais l'etat...

Je pensais d'abord à un problème du cote de knxweb, mais je penche
maintenant pour un probleme de linknx. Je vais essayer de le recompiler.
#4
Salut,

Je vois plusieurs pistes pour essayer de savoir ce qui se passe.
1) Comme knxweb communique avec le script linknx.php qui à son tour se
connecte à linknx (sur le port 1028), tu pourrais lancer un analyseur
de paquets (du style wireshark) pour voir ce qui se passe entre le
scripts linknx.php et linknx (sur le port 1028 à moins que tu ne l'aie
modifié).

2) Utiliser le script php http://ouaye.net/linknx/other/linknx-cmd-php.txt
(copié sur le serveur web ou se trouve knxweb et renommé en linknx-
cmd.php) pour envoyer/recevoir toutes sortes de commandes à linknx et
voir les résultats.

3) Regarder quels sont les messages affichés par linknx (lorsque tu le
lance en ligne de commande, sans l'option -d). En particulier si des
messages sont affichés quand knxweb fait ses requètes de lecture
d'état toutes les secondes.

Que vois-tu exactement dans firebug quand knxweb essaie de lire
l'état? Peux-tu poster la requète exacte qu'il envoie. Que se passe-t-
il ensuite. Est-ce que le script linknx.php envoie immédiatement une
réponse vide? Ou une réponse contenant <read status='success"> ...</
read> mais pas la valeur de l'objet dedans? Ou bien est-ce-que la
requète reste en attente et se termine par un timeout?

Bien à toi,

Jean-François

On 28 août, 14:19, Nicolas Garnier <n.b.garn...@gmail.com> wrote:
> Merci pour ta réponse.
>
> je viens de re-tester comme tu me l'indiques, et c'est un peu surprenant.
>
> Test 1 : J'ai dans knxweb un design avec une seule zone, et dans cette zone
> un seul objet (une lampe, enfin, un switch). Cet objet existe bien dans
> linknx (il est défini dans le fichier conf/linknx.xml), et je peux
> l'actionner à partir de knxweb. Par contre, impossible d'avoir son vrai état
> dans knxweb. Firebug montre que les opérations imposées pas knxweb de
> commutation fonctionne bien, et je peux voir leur réponse. Par contre, il
> n'y a jamais de réponse de linknxw pour une interrogation en lecture de
> l'état.
>
> Test 2 : Suivant tes indications (mais en les déformant un peu ;-) ), j'ai
> changé le nom de l'objet dans knxweb (j'ai mis un nom qui n'existe pas dans
> linknx). Et là, j'ai un message d'erreur dans knxweb qui m'indique que
> l'objet n'existe pas. En plus, firebug montre que knxweb demande toutes les
> secondes l'état à linknx, et la réponse existe à chaque fois, et elle est
> une erreur (l'objet n'existe pas).
>
> Ce qui me surprend, c'est que dans le 2eme cas, knxweb et linknx arrivent à
> communiquer (toutes les secondes, pour avoir l'etat des objets), mais que
> dans le premier cas (quand l'objet existe), linknx n'envoie jamais l'etat...
>
> Je pensais d'abord à un problème du cote de knxweb, mais je penche
> maintenant pour un probleme de linknx. Je vais essayer de le recompiler.
#5
A tu pensé à mettre les variables pour l'heure et la date ?

L'idéal serait de mettrer ton Linknx.xml ainsi que ton design.xml

Je suis sur que t'as une variable non renseignée dans linknx. Et tant
qu'il y a une variable en erreur, il n'y a pas de rafraichissement !
#6
Après les conseils de DaGGer et Jef2000, voici ce que je peux dire ce
soir :

> A tu pensé à mettre les variables pour l'heure et la date ?

Je les avais enlevées de design.xml, et je les ai aussi enlevées de
Linknx.xml : idem
Je les ai remises dans les deux fichiers : idem

> 3) Regarder quels sont les messages affichés par linknx (lorsque tu le
> lance en ligne de commande, sans l'option -d). En particulier si des
> messages sont affichés quand knxweb fait ses requètes de lecture
> d'état toutes les secondes.

Après démarrage de linknx, et premier appel à knxweb, linknx affiche
dans la shell les états de tous les actionneurs pour lesquels knxweb
demande l'état. Ces valeurs sont correctes : une lampe allumée dans
l'appartement donne un message de linknx avec un état "on" :
1283027732 INFO Object : New value on for object ecl_dressing (type:
1.001)
et une lampe éteinte donne bien un message avec "off":
1283027745 INFO Object : New value off for object pc (type: 1.001)
(il y a d'autres messages, mais je veux dire ici que les états sont
lus correctement)

Par contre, knxweb n'affiche pas les valeurs correspondantes, il ne
doit pas y avoir accès.

De plus, linknx n'affiche jamais de message périodique (toutes les
secondes)...

> 2) Utiliser le script php http://ouaye.net/linknx/other/linknx-cmd-php.txt
> (copié sur le serveur web ou se trouve knxweb et renommé en linknx-
> cmd.php) pour envoyer/recevoir toutes sortes de commandes à linknx et
> voir les résultats.

Il est pratique ce script !

Mais j'observe quelques comportements étranges avec lui...

Si j'envois <read><objects/></read>
Alors linknx s'affaire et je vois dans la shell qu'il lis les valeurs
de tous les objets définis dans linknx.xml
Mais il n'y a pas de retour dans "result" du script (le navigateur
attend...)

Par contre, si j'envois <read><object id="pc"/></read>
Alors j'ai un retour : <read status='success'>on</read>
qui est correct.

Si j'envois <read><objects/></read>
ET si je tue linknx après qu'il ai lu les valeurs auprès de tous les
participants,
Alors le navigateur affiche le retour (parfaitement correct par
ailleurs) :

<read status="success">
<objects>
<object id="cur_date" value="1900-0-0" />
<object id="cur_time" value="0:0:0" />
<object id="ecl_WC_1" value="off" />
...
<object id="ecl_cuisine_1" value="on" />
<object id="pc" value="on" />
<object id="pc_1" value="off" />
<object id="pc_3" value="off" />
</objects>
</read>

Je vais continuer ces tests demain. Je commence à suspecter ma
compilation de linknx (les tests de pthsem ne fonctionnaient pas,
alors j'ai utilisé l'option -with-pth-test=no du script configure).
#7
J'ai donc essayé pas mal de choses avec le script de Jean-François
(même si je ne comprends pas tout).

Une chose récurrente, c'est que la plupart des commandes que j'envoie
ne reçoivent pas de réponse (le navigateur attend la réponse) mais si
je tue linknx, alors la réponse arrive.

Exemples :
exec : <read><status/></read>
result sans tuer linknx : rien, attente du navigateur
result (après avoir tué linknx) : <read status="success">
<status>
<timers />
<rules />
</status>
</read>

exec: <read><objects/></read>
result sans tuer linknx : rien, attente
result après avoir tué linknx : <read status="success">
<objects>
<object id="pc" value="off" />
</objects>
</read>

A noter qu'il y a un caractère (binaire ?, impossible de l'extraire de
la page web) à la fin des résultats précédents, et que ce caractère
n'est pas présent en réponse à un appel à un objet unique (situation
qui marche bien) :
<read><object id="pc"/></read>
qui donne :
<read status='success'>off</read>

... Ce caractère serait-il l'origine du problème ? Il semble bloquer
l'interprétation du XML envoyé par linknx par ce navigateur.

Si oui, d'ou viendrait ce caractère ? Je suis sur MacOS+Macports, ce
qui est un environnement unix presque traditionnel, mis à part
quelques soucis sur des librairies particulières (et je suspecte
pthsem d'être dans ce cas).

J'ai compilé la version de linknx trouvée sur le CVS de Sourceforge,
et j'ai exactement les mêmes comportements.

Merci pour vos indications,


Nicolas.
#8
A toutes fins utiles, voici les fichiers les plus simples que
j'utilise et qui reproduisent le problème :

linknx.xml :

<?xml version="1.0" ?>
<config>
<objects>
<object type="1.001" id="pc" gad="1/3/22">Stranne</object>
</objects>
<rules>
</rules>
<services>
<knxconnection url="ip:192.168.0.12" />
<xmlserver type="inet" port="1028"/>
<persistence type="file" path="/Users/ngarnier/Desktop/linknx/
persist"/>
</services>
</config>


au démarrage de linknx, j'ai :

RhoneConfusedrc ngarnier$ ./linknx -c/Users/ngarnier/Desktop/linknx-cvs/conf/
linknx.xml
1283084705 INFO XmlInetServer : Starting on port 1028
1283084705 INFO Object : Configured object 'pc': gad='2838'
1283084705 INFO main : Config file loaded: /Users/ngarnier/Desktop/
linknx-cvs/conf/linknx.xml
1283084705 INFO KnxConnection : KnxConnection: Group socket opened.
Waiting for messages.
1283084705 INFO KnxConnection : write(gad=2838, buf, len=2):
Send request
Read from 0.0.0 to 1/3/22
Response from 1.1.3 to 1/3/22: 00
1283084705 INFO Object : New value off for object pc (type: 1.001)

fichier design.xml de knxweb :

<config>
<zones>
<zone id="appart" name="appart" img="plan.gif">
<control type="switch" label="Stranne" object="pc" x="427"
y="135"/>
</zone>
</zones>
</config>

Y manque-t-il un ingrédient crucial ?

N.
#9
Bon, j'ai un peu avancé, et j'ai localisé le problème : c'est ma
compilation de linknx sur mac qui a un souci.

J'ai repris l'installation complète (eibd + linknx) sur une autre machine
(Ubuntu), en gardant knxweb sur le mac, et là, ça marche ! le linknx
d'Ubuntu parle bien avec le knxweb du mac. Par contre, c'est eibd sur Ubuntu
que j'ai foiré... il démarre, mais ne parle pas au bus.

Mais en utilisant eibd du mac, linknx d'Ubuntu, et knxweb du mac : ça marche
bien. C'est d'ailleurs "rigolo", car j'utilise donc 3 adresses ip (à une
près, c'est le cas le plus compliqué). Heureusement pour moi que
eibd/linknx/knxweb permet ce genre de gymnastique !

192.168.0.10 pour le routeur N148/1,
sur lequel se connecte eibd, qui est lui sur la machine
192.168.0.12 (MacOSX).
eibd demarre avec :
$ eibd -d -D -S -T -i ipt:192.168.0.10:3671
192.168.0.12 pour le Mac sur lequel tourne eibd,
c'est cette adresse que connaît linknx (dans linknx.xml)
192.168.0.11 pour la machine sur laquelle tourne linknx (Ubuntu)
192.168.0.12 (mais ça pourrait être n'importe quelle autre adresse) pour le
serveur web,
et donc knxweb, à qui je donne l'adresse de linknx :
192.168.0.11 dans design.xml

Je vais maintenant essayer de réparer l'installation d'eibd, de sorte à
avoir eibd et linknx sur la même machine, ce qui semble plus pertinent dans
mon cas.

Si je trouve une explication sur le problème de linknx qui insère un
caractère en plus dans ses réponses, je posterai ici.
#10
Le dimanche 29 août 2010, Nicolas Garnier a écrit :

> Si je trouve une explication sur le problème de linknx qui insère un
> caractère en plus dans ses réponses, je posterai ici.

C'est pas le caractère de fin de trame qui pose problème (manquant), des
fois ?

--
Frédéric
#11
C'est possible. Je ne sais pas, je ne peux pas dire (j'ai l'impression que
le problème est là quand il y a un caractère en trop, mais mon constat
peut-être erroné).

D'où cela peut-il venir ?


> Si je trouve une explication sur le problème de linknx qui insère un
> > caractère en plus dans ses réponses, je posterai ici.
>
> C'est pas le caractère de fin de trame qui pose problème (manquant), des
> fois ?
>
> --
> Frédéric
>
#12
Bonjour,

juste pour dire que mon problème n'apparaît pas sur Ubuntu, ni sur Debian,
mais juste MacOs + MacPorts.

J'ai tout installé sur une petite machine Debian (un Lex Light), et tout
fonctionne très bien.

Merci pour vos conseils.

Nicolas.


Atteindre :


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