KNX Probleme nach Neustart

[rspecht]

Hallo Leute,

ich habe da ein seltsames Problem:
Mein FHEM auf einem RPI3 ist die "gute Seele" in einem KNX Netzwerk

Hier als Beispiel meine Definition fürs Licht im Büro:

Code Auswählen Erweitern

defmod Beleuchtung_EG_Buero KNX 0/0/6:dpt1
attr Beleuchtung_EG_Buero room Beleuchtung,Büro,KNX

setstate Beleuchtung_EG_Buero off
setstate Beleuchtung_EG_Buero 2017-11-02 14:07:04 getG1 off
setstate Beleuchtung_EG_Buero 2017-11-02 14:07:04 last-sender 1/1/53
setstate Beleuchtung_EG_Buero 2017-11-02 14:19:37 setG1 off
setstate Beleuchtung_EG_Buero 2017-11-02 14:19:37 state off

Nun habe ich FHEM neugestartet und kann die Lampe nicht mehr bedienen. Klicke ich auf "DEF" und dann auf "Modify" (ohne speichern) geht alles wieder.... sehr merkwürdig.

Habt Ihr hierfür eine Erklärung?

VG

[mani]

Hallo rspecht,
habe das gleiche Problem.... habe auch den Tul als I0Dev gesetzt, jedoch wenn ich die Gruppenadresse mit einem Taster beschreibe wird es in FHEM erkannt nur das schreiben von FHEM aus geht nach dem neustart nicht mehr

woran kann das liegen ..?

MFG Mani

[mani]

Hallo ok hab das Problem bei mir gelöst in dem ich beim Define die Physikalische Adresse des Gerätes als Namen genutzt habe.....dann klappt es auch nach einem reboot

MFG Mani

[docm]

Hallo rspecht,
gibt es einen besonderen Grund, warum du defmod verwendest und nicht define?
Hast du dein TUL als IO-Device gesetzt, z.B. mit attr?
Die setstate Kommandos verstehe ich nicht. Was willst du konkret erreichen?
Kannst du mal aus der fhem.cfg alle Zeilen, die sich auf Beleuchtung_EG_Buero beziehen, extrahieren und posten?
Für dein Problem kann es viele Gründe geben.
Kannst du nach dem Boot einige Devices nicht mehr bedienen, oder geht mit knx gar nichts mehr?
Was meinst du konkret mit "bedienen"? Aus der Weboberfläche heraus steuern?
Bei mir haben knx Schaltaktoren mindestens zwei Gruppenadressen pro Kanal. Eine für Steuern, eine für Status. Nehme an, in deiner Installation ist es auch so.
Mit ein paar zusätzlichen Details kann ich dir vielleicht helfen.
Viele Grüße

[Eichsfelder]

Guten Morgen!

Ich habe das selbe Problem wie Rspecht:

Ich habe vergangene Woche den Pi neu aufgesetzt und Fhem nochmals installiert.
KNXD installiert, weil ich mit einem IP Interface auf den Bus zugreife.

Jetzt werden meine Lampen, bzw rollos, im Interface erkannt wenn ich vom KNX Schalter schalte, aber von fhem heraus, kann ich nichts schalten,

Nach Betätigung von DEF und Modify kann ich wieder schalten, nach sudo reboot, geht's nicht mehr.

Habt ihr mittlerweile eine Lösung dafür?

Gruss Eichsfelder

[docm]

Hallo Eichsfelder,

bitte beschreibe das Problem genauer. Im Moment verstehe ich nicht, was bei dir passiert.

Jetzt werden meine Lampen, bzw rollos, im Interface erkannt

Was heißt das? Kommen die Informationen im FHEM an und werden in den Readings der KNX Devices richtig angezeigt?

Ich habe vergangene Woche den Pi neu aufgesetzt

Hat davor alles funktioniert? Gab es irgendwelche Hardwareänderungen, z.B. anderes IP Interface? Was war der Grund für das Neuaufsetzen? Macht man ja normal nicht ohne Not (Never change a running system). Funktioniert es bei einem Rollback wieder, d.h. wenn du die alte SD-Karte wieder in den PI schiebst?

Funktioniert es, wenn du über KNXTOOL von der PI Kommandozeile aus auf den KNX Befehle sendest?
Viele Grüße
Andreas

[Eichsfelder]

Hallo docm,

FHEM lief ca. 6 Monate mit einem TPU-Art USB module von Busware, aber immer nach sudo reboot, hat PI den TPU Art nicht mehr gefunden.
Daraufhin habe ich mir einen WEINZIERL 731 KNX IP Interface Schnittstelle geholt und diese Parametriert!
KNXD installiert.

die Alte fhem.cfg wieder eingelesen. jetzt kommen alle Readings vom KNX-Bus rein, Temperaturen, Helligkeitswerte, bzw auch Rückmeldungen vom Aktor, wenn eine lampe von Bus -taster geschaltet wird.

Nur vom Fhem aus geht es nicht, wenn ich vom PI aus schalte (vom terminal) gehts.

Wenn ich nun auf eine lampe gehe (im interface) dann auf DEF und modify drücke, kann ich die lampe so lange schalten, bis ich den nächsten sudo reboot durchführe.

Danach gehts leider nicht mehr.

Hättest du eine idee?

[docm]

Poste bitte mal deine /etc/knxd.conf

Laufen FHEM und knxd auf demselben PI?

Wie ist das Weinzierl 731 in ETS konfiguriert?

Was mich etwas wundert ist, dass dein altes Problem und dein neues irgendwie ähnlich sind. Nach Reboot funktioniert es nicht mehr richtig.

Poste bitte den Output von

Code Auswählen Erweitern


sudo systemctl status knxd

und

Code Auswählen Erweitern


sudo systemctl status knxd.socket


So wie ich dich verstanden habe, funktioniert das Senden mittels KNXTOOL auf dem PI?
Wieviele TUL Devices hast du in FHEM definiert? Ich vermute mal 1.
Bitte poste die Raw Definition deines TUL Devices.
Wie ist der STATE deines TUL Devices nach dem Boot? Sollte auf "Initialized" stehen.
Wie ist nach dem Boot der Wert von IODev bei deinen KNX Devices?
Wenn du dann ein Device mit DEF/Defmod neu angelegt hast, verändert sich dadurch etwas an irgendeinem der Internals?

Mir ist es schon bei Änderungen passiert, dass in der fhem.cfg Probleme entstanden sind.
Z.B. sollte das TUL Device vor den KNX Devices definiert sein.

Viele Grüße
Andreas

[Eichsfelder]

hallo docm:

hier meine daten:
# configuration for knxd.service
KNXD_OPTS="-e 0.0.1 -E 0.0.2:9 -D -T -S -b ipt:192.168.2.122"
START_KNXD=YES

FHEM und KNXD laufen auf dem selben PI,

Wie ist das Weinzierl 731 in ETS konfiguriert?
Gruppenadresse zum Programmieren mit der ETS4 1.1.80 und mit dem Weinzierls 1.1.81

sudo systemctl status knxd:
knxd.service - KNX Daemon
   Loaded: loaded (/lib/systemd/system/knxd.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2017-12-26 20:18:12 CET; 7min ago
Main PID: 499 (knxd)
   CGroup: /system.slice/knxd.service
           └─499 /usr/bin/knxd -e 0.0.1 -E 0.0.2:9 -D -T -S -b ipt:192.168.2.122

Dec 26 20:18:12 raspberrypi systemd[1]: Starting KNX Daemon...
Dec 26 20:18:12 raspberrypi systemd[1]: Started KNX Daemon.

sudo systemctl status knxd.socket:
knxd.socket - KNX Daemon (socket)
   Loaded: loaded (/lib/systemd/system/knxd.socket; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2017-12-26 20:18:02 CET; 8min ago
   Listen: /var/run/knx (Stream)
           [::6720 (Stream)

Dec 26 20:18:02 raspberrypi systemd[1]: Listening on KNX Daemon (socket).

Das senden mittels KNXTOOL auf dem PI funktioniert

TUL: Initialized, def: eibd:localhost 1.1.81

Wenn ich attr IODev  KNX setze und speichere kann ich schalten, nach dem reboot ist das attr IODev aber weider weg und es ist kein schalten mehr möglich.

Vielen dank schon mal für dein Bemühen

Gruß Frank

[docm]

Soweit klar. Das Problem ist das IODev.

beim knxd sieht alles gut aus.

Ich verwende ein anderes define
def knxd:localhost 1.1.81

knxd ist neuer als eibd. Aber ich glaube nicht, dass das das eigentliche Problem ist. Also lass es erstmal so.

Meine Vermutung: Könnte sein, dass in deiner fhem.cfg Datei KNX Devices definiert werden, bevor das TUL Device definiert wird. Dann findet das KNX Device beim Erstellen kein TUL Device, mit dem es sich binden kann.

Du solltest das manuell prüfen können, indem du die fhem.cfg in den Editor lädst. Aber Vorsicht beim Verändern. Am besten zuvor eine Sicherungskopie anlegen. Datei befindet sich in /opt/fhem/fhem.cfg
Die Definition des TUL muss vor der ersten Definition eines KNX Devices sein.
Gib mal Bescheid, ob das das Problem löst.

Wenn nicht, schauen wir weiter...

Viele Grüße
Andreas

[Eichsfelder]

Guten Morgen!

das wars,

Das TUL stand in der cfg zu weit hinten, ich habe es oben hin kopiert, bevor das erste define kommt.
Übrigens in meiner alten cfg mit TPU ART USB module stand das TUL auch weit oben.,

Vielen dank für die hilfe!

[rspecht]

Besser spät als nie - hier gehts auch
Ich hab die KNX definition ganz nach oben gepackt.

Im Winter hat man halt zeit zum softwerken.
Sorry nochmal das ich erst ein Jahr später schreibe - aber FEHM steht ganz hinten bei der Renovierung.

Winterliche Grüße