Fhem

( dans

» Electricité » Domotique

)
Chercher:    

Fhem

- Page 3
Page 3 sur 11 Page precedente 12 3 45 Page suivante Dernière page - Résultats 201 à 211 sur 211


14/11/2015 Vieux  
  42 ans, Namur
 
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.
14/11/2015 Vieux  
 
  56 ans, Liège
 
Citation:
Posté par @lex Voir le message
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 ?

14/11/2015 Vieux  
  42 ans, Namur
 
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
14/11/2015 Vieux  
 
  56 ans, Liège
 
Citation:
Posté par @lex Voir le message
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.

Dernière modification par jcoenen 15/11/2015 à 00h00.
15/11/2015 Vieux  
  42 ans, Namur
 
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...
15/11/2015 Vieux  
 
  56 ans, Liège
 
Citation:
Posté par @lex Voir le message
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 ...
15/11/2015 Vieux  
  42 ans, Namur
 
- 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.
15/11/2015 Vieux  
 
  56 ans, Liège
 
Citation:
Posté par @lex Voir le message
- 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.
15/11/2015 Vieux  
  42 ans, Namur
 
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 ! ).
15/11/2015 Vieux  
  42 ans, Namur
 
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.
15/11/2015 Vieux  
 
  56 ans, Liège
 
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
15/11/2015 Vieux  
 
  56 ans, Liège
 
Citation:
Posté par jcoenen Voir le message
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.
15/11/2015 Vieux  
  42 ans, Namur
 
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.
15/11/2015 Vieux  
 
  56 ans, Liège
 
Citation:
Posté par @lex Voir le message
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 ...
15/11/2015 Vieux  
 
  56 ans, Liège
 
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 ?
16/11/2015 Vieux  
  42 ans, Namur
 
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 ?
16/11/2015 Vieux  
 
  56 ans, Liège
 
Citation:
Posté par @lex Voir le message
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.
17/11/2015 Vieux  
 
  56 ans, Liège
 
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 )

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.
19/11/2015 Vieux  
  42 ans, Namur
 
Citation:
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 ?
19/11/2015 Vieux  
  38 ans, Hainaut
 
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
Page 3 sur 11 Page precedente 12 3 45 Page suivante Dernière page - Résultats 201 à 211 sur 211



Forum Domotique : Voir ce forum, Nouveautés, Actifs, Sans rép
Tout BricoZone : Page de garde, Dernieres 24h

Photos au hasard
Voir toutes nos photos


Pas encore membre de BricoZone ?!
Attention Pour participer, poser une Question ou Répondre : inscrivez vous !
Ceci vous permettra également de recevoir un email lors des réponses.
Mais même si vous ne voulez rien écrire : vous pourrez surveiller les forums et leurs nouveaux messages, et obtenir une vue rapide de tous les nouveaux messages depuis votre dernière visite !
Tout ceci est évidemment gratuit et rapide.

Visitez aussi : BricoZone France, nos Blogs. On aime Astel, JardiZone et InternetVista.
 
Connexion!
Identifiant
Mot de passe

Inscription - Oublié ?

Annuaire Pro

Maisons Blavier s.a.

Blavier construit des maisons clé-sur-porte en mettant l’accent sur l'accompagnement et le budget


Maisons Baijot

Entreprise générale de construction Maison basse énergie Construction traditionnelle de qualit


SIBOMAT sa

Leader de la construction à ossature bois en Belgique depuis plus de 30 ans.


AlarmeMaison.biz

Pour nous la sécurité de votre maison n'est pas un vain mot.. Alarmes en KIT de bricolage!!

Ajoutez votre société