Fhem

@lex · 14 Novembre 2015

J'ai un device EIB qui comprend 4 entrées, qui détectent un front montant.
J'ai raccordé deux de ces entrées sur des détecteurs de mouvement (une sur chaque).
Chaque entrée est dans un group address (1/2/0 et 1/2/1).
Quand le détecteur détecte, je vois passer le group address dans linknx, donc ça marche.
Mais l'autocreate de FHEM ne l'a pas trouvé.
Je l'ai créé manuellement (avec un define sans rien de spécial), mais ça ne marche pas: FHEM ne le voit pas, aucun log créé.

J'aimerais utiliser FHEM pour allumer des lampes à l'extérieur, avec des temps d'allumage différents si c'est l'un ou l'autre détecteur qui a été activé.
Je pensais donc au notify, mais rien ne marche.

Dans la config actuelle, l'actionneur de mes lampes extérieures n'est pas activé par le group address du device EIB (d'entrée) qui détecte le signal des détecteurs. C'est peut-être ça le problème ?
Du coup, je pense utiliser FHEM uniquement pour éteindre les lampes, après un temps que je choisis, ce serait un workaround (je n'ai pas testé), je pourrais choisir un temps différent pour chaque group address.

Mais je me demande quand même s'il est possible que FHEM fasse tout le boulot (allumage pendant un temps qui dépend du détecteur qui aura détecté), ou bien s'il faut qu'il y ait le group address de mon device d'entrée dans la sortie de l'actionneur.

Merci.

jcoenen · 14 Novembre 2015

@lex;1054333 a dit:
J'ai un device EIB qui comprend 4 entrées, qui détectent un front montant.
J'ai raccordé deux de ces entrées sur des détecteurs de mouvement (une sur chaque).
Chaque entrée est dans un group address (1/2/0 et 1/2/1).
Quand le détecteur détecte, je vois passer le group address dans linknx, donc ça marche.
Mais l'autocreate de FHEM ne l'a pas trouvé.
Je l'ai créé manuellement (avec un define sans rien de spécial), mais ça ne marche pas: FHEM ne le voit pas, aucun log créé.

J'aimerais utiliser FHEM pour allumer des lampes à l'extérieur, avec des temps d'allumage différents si c'est l'un ou l'autre détecteur qui a été activé.
Je pensais donc au notify, mais rien ne marche.

Dans la config actuelle, l'actionneur de mes lampes extérieures n'est pas activé par le group address du device EIB (d'entrée) qui détecte le signal des détecteurs. C'est peut-être ça le problème ?
Du coup, je pense utiliser FHEM uniquement pour éteindre les lampes, après un temps que je choisis, ce serait un workaround (je n'ai pas testé), je pourrais choisir un temps différent pour chaque group address.

Mais je me demande quand même s'il est possible que FHEM fasse tout le boulot (allumage pendant un temps qui dépend du détecteur qui aura détecté), ou bien s'il faut qu'il y ait le group address de mon device d'entrée dans la sortie de l'actionneur.

Merci.

Et quand tu fais un grouplisten ip:addresse_du_eibd 1/2/0

Que vois tu revenir lorsque le detecteur est en action ?

@lex · 14 Novembre 2015

Le problème vient d'ailleurs: j'ai (par erreur) arrêté mon autre pi sur lequel tournait encore EIBD auquel FHEM se raccordait.
J'ai tenté de mettre le TUL vers l'EIBD de mon Pi2 (sur lequel il y a FHEM), mais ça ne marche pas. Je pensais que c'était à cause de linknx qui s'y connecte déjà, j'ai donc redémarré mon ancien pi et je tente de recréer un nouveau TUL pour s'y connecter, mais ça ne marche plus...

Le TUL est en "initialized"

Mon TUL actuel:

AckLineDef

Clients
:EIB:
DEF eibd:172.19.3.52 15.15.251

DevType
EIBD
DeviceAddress
fffb
DeviceName
eibd:172.19.3.52
FD
85
NAME
tul
NR
168
PARTIAL

STATE
Initialized
TYPE
TUL

L'autre pi tourne, et EIBD est actif:

~ $ ps ax |grep eib
2232 ? Ss 0:00 /usr/local/bin/eibd --daemon=/var/log/eibd.log --pid-file=/var/run/eibd.pid -D -S -T --listen-tcp ipt:172.19.3.50

jcoenen · 14 Novembre 2015

@lex;1054370 a dit:
Le problème vient d'ailleurs: j'ai (par erreur) arrêté mon autre pi sur lequel tournait encore EIBD auquel FHEM se raccordait.
J'ai tenté de mettre le TUL vers l'EIBD de mon Pi2 (sur lequel il y a FHEM), mais ça ne marche pas. Je pensais que c'était à cause de linknx qui s'y connecte déjà, j'ai donc redémarré mon ancien pi et je tente de recréer un nouveau TUL pour s'y connecter, mais ça ne marche plus...

Le TUL est en "initialized"

Mon TUL actuel:

AckLineDef

Clients
:EIB:
DEF eibd:172.19.3.52 15.15.251

DevType
EIBD
DeviceAddress
fffb
DeviceName
eibd:172.19.3.52
FD
85
NAME
tul
NR
168
PARTIAL

STATE
Initialized
TYPE
TUL

L'autre pi tourne, et EIBD est actif:

~ $ ps ax |grep eib
2232 ? Ss 0:00 /usr/local/bin/eibd --daemon=/var/log/eibd.log --pid-file=/var/run/eibd.pid -D -S -T --listen-tcp ipt:172.19.3.50

As tu fait un delete TUL avant de le redéfinir ?

Sinon tu peux toujours le redéfinir dans /opt/fhem/fhem.cfg

Cherches la ligne def tul TUL ... et changes l'adress du daemon eibd.
Sauve le fichier et redémarre fhem ou rereadcfg.

Normalement eibd permet a plusieurs client de se connecter (donc fhem, linknx, et les groupread/write ...)

Voila l'explication pour les détecteurs non détectés (c'est un comble ça).

Une fois détecté et reconnu, un notify et l'affaire est réglée.

Tu peux aussi visionner la page Event Monitor et faire une détection, le message de détection devrait apparaitre dans les events.

@lex · 14 Novembre 2015

J'ai fait un delete du TUL.

Je viens d'essayer avec une modif directement dans le fichier fhem.cfg: ça ne marche pas après un rereadcfg.

Par contre, le comportement est bizarre: FHEM voit ce qui se passe sur le bus, mais ne peut pas y écrire.
Je vois qu'on allume une lampe, mais je ne peux pas l'éteindre depuis FHEM.

J'ai même redémarré mon Pi (t'imagines mon niveau de désespoir ;(), mais ça n'a évidemment rien changé.

J'ai le même comportement avec l'EIBD de l'autre pi et avec l'EIBD du Pi sur lequel tourne FHEM (j'ai essayé les deux configs pour le TUL)

Vraiment strange...

jcoenen · 14 Novembre 2015

@lex;1054376 a dit:
J'ai fait un delete du TUL.

Je viens d'essayer avec une modif directement dans le fichier fhem.cfg: ça ne marche pas après un rereadcfg.

Par contre, le comportement est bizarre: FHEM voit ce qui se passe sur le bus, mais ne peut pas y écrire.
Je vois qu'on allume une lampe, mais je ne peux pas l'éteindre depuis FHEM.

J'ai même redémarré mon Pi (t'imagines mon niveau de désespoir ;(), mais ça n'a évidemment rien changé.

J'ai le même comportement avec l'EIBD de l'autre pi et avec l'EIBD du Pi sur lequel tourne FHEM (j'ai essayé les deux configs pour le TUL)

Vraiment strange...

Donc fhem connecte bien eibd et voit les messages du bus, c'est déjà ça.

As tu démarré eibd avec les bonne options (R pour routeur si je me souviens bien).

Tu peux aussi mettre le log eibd et voir si les messages fhem sont reçu et transmis.

Aussi l'adresse knx de linknx doit être différente de celle de fhem ...

@lex · 14 Novembre 2015

- J'ai rajouté -R pour le routing: pas d'effet.
- J'ai enlevé -T (tunnel): pas d'effet.
- log eibd: le fichier log est vide (bizarre, sur les deux pi)
- adresse knx de linknx: je vois ça où ? j'ai changé l'adresse du TUL pour être sûr (1.1.251 et 1.1.249): pas d'effet.

jcoenen · 15 Novembre 2015

@lex;1054385 a dit:
- J'ai rajouté -R pour le routing: pas d'effet.
- J'ai enlevé -T (tunnel): pas d'effet.
- log eibd: le fichier log est vide (bizarre, sur les deux pi)
- adresse knx de linknx: je vois ça où ? j'ai changé l'adresse du TUL pour être sûr (1.1.251 et 1.1.249): pas d'effet.

C'est effectivement on ne peut plus curieux.

Si je comprend bien la situation précédente était:
Pi 1, eibd connecte une interface knx-IP, fhem connecte eibd. Tout fonctionnel

Nouvelle configuration:
Pi 2, eibd connecte l'interface knx-IP et fhem connecte eibd, fhem ne peux pas écrire sur le bus. De même si on tourne eibd sur le Pi 1 (mais qui connecte quoi, eibd pi2 ou KNX-IP ???).

le Pi 2 a un processeur différent du Pi 1, les programmes doivent être recompilés sur le Pi 2, une copie donnera des résultats imprévisibles, donc bcusdk et pthsem doivent être recompilés.

Concernant le Pi 1 dont eibd ne semble plus fonctionner, d'une part si eibd connecte l'interface knx-IP, il faut se poser la question, cette interface supporte-elle plus d'une connexion ? Comme la connexion est elle réalisée, UDP ? TCP ?
D'autre part si eibd se connecte via le eibd du Pi 2, comme fhem ne peut écrire, on peut s'attendre a ce que d'autre clients ne puisse écrire sur le bus.

Concernant linknx, l'adresse de connexion est spécifiée dans le fichier de config de linknx, section services, knxconnection url="ip:127.0.0.1"

Par contre linknx peut très bien utiliser un mode de communication différent avec eibd (différent de celui utilisé par fhem) et que celui-ci soit fonctionnel ...

Apparemment un nouveau fork de eibd est disponible je vais essayer ça un de ces jours, il semble apporter quelques améliorations.

@lex · 15 Novembre 2015

Situation précédente:

- Pi1 (un vieux modèle B): tourne linknx & EIBD (qui connecte vers le gateway KNX - cf plus bas). Linknx ne fait plus rien, EIBD toujours fonctionnel

- Pi2 (un quad-core): tourne linknx, EIBD (qui connecte vers le gateway KNX - cf plus bas), knxweb & FHEM. Linknx se connecte au EIBD de Pi2, FHEM se connecte au EIBD de Pi1: tout fonctionne.

Par erreur, j'ai éteint Pi1 (j'avais oublié que son EIBD était encore en production

)
FHEM n'a plus fonctionné (normal).

J'ai reconfiguré le TUL pour qu'il se connecte sur le Pi2: ça ne marche pas.
J'ai rallumé Pi1 et reconfiguré le TUL pour qu'il se connecte sur le Pi1: ça ne marche plus.
Depuis, je n'arrive plus à avoir une connexion du TUL vers un des deux EIBD.
Le linknx du Pi2 fonctionne parfaitement (via son propre EIBD).

La config de Pi2: linknx: knxconnection url="ip:127.0.0.1"

Le gateway IP/KNX est un Siemens N148/22, je viens de découvrir qu'il supporte jusqu'à 5 KNX tunneling connexions (ce qui explique que la config de départ avec 2 EIBD différents qui s'y connectent fonctionnait).

Je ne pense pas qu'il faille une recompilation puisque tout marchait avant...

J'ai même tenté une install de eibnetmux hier, mais il manque des paquets pour Jessie et je ne m'y connais pas assez pour chipoter là-dedans, j'ai donc abandonné.

EIBD peut-il se connecter avec plusieurs clients ? Le problème vient peut-être de là: en rallumant le pi1, linknx a redémarré (je l'avais peut-être arrêté à l'époque, je ne sais plus), et donc je ne peux plus me connecter à EIBD sur le Pi1, et je ne peux pas me connecter sur le Pi2 car il a déjà une connexion de son propre linknx. (mais est-ce que ce sont des connexions permanentes ?).
Je continue à chercher (il faut que ça marche ! 8-|).

@lex · 15 Novembre 2015

J'ai essayé en redémarrant Pi1 et en ne tournant que EIBD dessus, et en définissant le TUL pour qu'il s'y connecte.
Ca ne marche pas.

Au démarrage de FHEM, il ne voit pas d'I/O, j'ai donc plein de messages du style:
No I/O device found for 0_LivingAppliqueTV

J'ai ça pour chaque group address, mais je suppose que c'est un symptôme du fait que le TUL ne se connecte pas correctement.

Le mystère reste entier.

J'ai aussi des messages de ce style dans le log de FHEM, après un redémarrage:
2015.11.15 16:39:50 1: Including ./log/fhem.save 2015.11.15 16:39:50 1: statefile: Undefined value 0c6f Undefined value f02333 Undefined value 0f0b0f

Là aussi, je suppose que c'est lié au problème du TUL.

jcoenen · 15 Novembre 2015

oui tant que la connexion ne sera pas active tu auras des messages du genre, attention que le gateway knx doit faire un Time Out avant de pouvoir reconnecter sur un autre eibd

jcoenen · 15 Novembre 2015

jcoenen;1054500 a dit:
oui tant que la connexion ne sera pas active tu auras des messages du genre, attention que le gateway knx doit faire un Time Out avant de pouvoir reconnecter sur un autre eibd

Vérifies aussi que eibd ou eibnetmux que doit connecter FHEM est bien démarré, s'il n'est pas présent tu n'auras pas de messages d'erreur sur FHEM juste TUL non initialized.

@lex · 15 Novembre 2015

Je viens de vérifier EIBD avec la commande groupswrite.

Les 2 EIBD fonctionnent, chacun depuis leur propre Pi et depuis l'autre Pi.

Donc en command line, tout roule.

J'ai fait un update de FHEM, ça n'a rien changé.

J'ai ça dans le fhem.cfg:
define tul TUL eibd:localhost 15.15.251

Le TUL est en mode "initialized".

Ca ne fonctionne toujours pas.

jcoenen · 15 Novembre 2015

@lex;1054624 a dit:
Je viens de vérifier EIBD avec la commande groupswrite.

Les 2 EIBD fonctionnent, chacun depuis leur propre Pi et depuis l'autre Pi.

Donc en command line, tout roule.

J'ai fait un update de FHEM, ça n'a rien changé.

J'ai ça dans le fhem.cfg:
define tul TUL eibd:localhost 15.15.251

Le TUL est en mode "initialized".

Ca ne fonctionne toujours pas.

J'ai la même configuration pour mon TUL, mais j'utilise eibnetmux.

Tu n'a qu'un fhem qui tourne je suppose. Jai beau chercher, si tu a la lecture, pour quelle raison l'écriture serait-elle bloquée ...

jcoenen · 15 Novembre 2015

je viens de trouver un truc qui concerne Jessie, les routes vers le multicast sont ajoutée à la main, ces adresses multicast sont utilisées par eibd, mais si la lecture est bonne ...

post-up route add -net 224.0.23.12 netmask 255.255.255.255 eth0
pre-down route del -net 224.0.23.12 netmask 255.255.255.255 eth0

Les 2 pi sont en Jessie ou le Pi 1 est-il en wheezy ?

@lex · 16 Novembre 2015

Le Pi1 est en wheezy, le Pi2 est en Jessie.

Dans les deux pi, j'ai cette même route:
Destination Gateway Genmask Flags Metric Ref Use Iface
224.0.23.12 * 255.255.255.255 UH 0 0 0 eth0

Je dois quand même faire ta modif ?

Le spectre de Berryboot réapparait:
/etc/network $ more interfaces
# Static network configuration handled by Berryboot
iface eth0 inet manual

auto lo
iface lo inet loopback

Ca voudrait dire que c'est Berryboot qui se charge des routes ?

jcoenen · 16 Novembre 2015

@lex;1054714 a dit:
Le Pi1 est en wheezy, le Pi2 est en Jessie.

Dans les deux pi, j'ai cette même route:
Destination Gateway Genmask Flags Metric Ref Use Iface
224.0.23.12 * 255.255.255.255 UH 0 0 0 eth0

Je dois quand même faire ta modif ?

Le spectre de Berryboot réapparait:
/etc/network $ more interfaces
# Static network configuration handled by Berryboot
iface eth0 inet manual

auto lo
iface lo inet loopback

Ca voudrait dire que c'est Berryboot qui se charge des routes ?

ecoutes, c'est très curieux de voir les messages du bus et de ne pas pouvoir écrire sur le bus les connexions réseau étant bidirectionnelles. Les connexions knx utilisent plusieurs mode (udp tcp et multicast) il faudrait savoir quelle type est utilisé avant de déduire quoi que ce soit. J'ai vu ce post sur un blog qui parlait de jessie qui semble être différent de wheezy à plusieurs points de vue, d'après ce que j'ai vu berryboot est un programme d'aide à l'installation, ce qui met une couche supplémentaire à l'install de base et donc que fait-il de plus ???

les routes IPv4 devraient être bonnes mais le multicast c'est moins sûr et c'est par exemple ce que Ets utilise pour certaines interfaces.

jcoenen · 17 Novembre 2015

Bon le point sur la situation.

Je viens d'installer knxd sur un raspberry pi 2 (au Pays-Bas) sur lequel tourne JESSIE.

De la même manière j'ai installé fhem via debian et apt-get.

knxd est démarré et se connecte via un VPN sur un eibnetmux qui tourne en Belgique.

knxd -e 10.10.25 -t 255 -D -i -R -T -S -b ipt:192.168.1.132

Avec l'option -t on peut voir le traffic et les connections.

Les deux démons knx se connectent (send suivit de receive).

En suite j'ai fait un def du TUL sur fhem (que j'ai vu se connecter sur knxd)

Et les messages du bus sont apparus.

Esuite j'ai essayé une commutation, les messages passent bien via knxd et je vois sur le fhem et knxweb2 en belgique que les lampes s'allument (par contre je n'ai pas de retour visuel 8-|)

Il semblerait donc que knxd soit nettement plus performant que eibd ...
De plus il est compatible avec Jessie, la configuration de systemd étant inclue.
Sur github il mentionnent la compatibilité avec ETS5, que j'essayerai ce soir (via le tunnel).

Avec eibd et eibnetmux je ne suis jamais arrivé a interconnecter des machines via le VPN au niveau EIB/KNX. Avec knxd c'est chose faite.

@lex · 19 Novembre 2015

Il semblerait donc que knxd soit nettement plus performant que eibd ...
De plus il est compatible avec Jessie, la configuration de systemd étant inclue.
Sur github il mentionnent la compatibilité avec ETS5, que j'essayerai ce soir (via le tunnel).

Toujours content de knxd ?

moustic999 · 19 Novembre 2015

bon j'ai reinstallé fhem
je suis occupé avec l'install de knxd
j'ai deja galéré dans fhem pour réussir a faire fonctionner mon oceanpi avec mon softremote
j'arrive a allumer / eteindre un lampe dummy

maintenant je vais essayer d'avoir knxd fonctionnel et l'utiliser dans fhem

Rechercher

Rechercher

Fhem

@lex

jcoenen

@lex

jcoenen

@lex

jcoenen

@lex

jcoenen

@lex

@lex

jcoenen

jcoenen

@lex

jcoenen

jcoenen

@lex

jcoenen

jcoenen

@lex

moustic999

Sujet semblables

Nos articles

On a aimé dans le forum