Bizzares Verhalten nach Neustart

[knxmfbp]

Hallo,

ich möchte mal mein Fehlerbild von gestern Morgen beschreiben nachdem ich den Rechner mit eibd und smarthome.py neu gestartet habe.
Nachdem der Server wieder hoch gefahren war und vermutlich eibd gestartet wurde hat so ziemlich alles gesponnen. Rolladen gingen runter, Lichter schalteten sich ein und sogar das Garagentor öffnete sich.
Hat sowas schon einmal jemand anderes erlebt? Ich vermute eibd, da smarthome.py öfters neu gestartet wird und auch beispielsweise die GA vom Garagentor überhaupt nicht kennt.
Im Logging sehe ich natürlich nicht sehr viel, da es sich um mein Produktionssystem handelt und kein Debug eingeschaltet ist.

Ich bin für jeden Tip offen, möglicherweise sollte ich diesen Thread woanders schreiben, aber ich dachte mir frag zuerst einmal in der Community die die gleichen Komponenten nutzen als du.

Danke!

[Msinn]

Hi,

zur Eingrenzung ein paar Fragen:
- ist das sonst nach einem Neutart von smarthome.py nicht passiert?
- ist das sonst nach einem Neustart des Rechners (Neustart von eibd und smarthome.py) nicht passiert?
- Hast Du bei den items die gesponnen haben enforce_updates definiert?

Viele Grüße
Martin

[knxmfbp]

Nein, bei einem Neustart von smarthome.py ist das noch nie passiert und in letzter Zeit starte ich diesen Prozess ein paar mal die Woche Neu wegen weiteren Implementierungen (Items und Logik).
Es gab mal vor etlicher Zeit einen Stromausfall wo auch so manche Sachen gesponnen habe und auch das Tor öffnete sich damals, jedoch habe ich damals nicht so viel darauf gegeben weil von allen Komponenten der Strom weg war.

Wie gesagt, das Garagentor ist inexistent in den Items, auch andere Lichter die angingen sind teilweise inexistent in den items.

[JanT]

Hallo,

das hört sich doch so an als wäre es reproduzierbar. Ich würde den Vorgang mit aktiviertem Log und Busmonitor wiederholen. Notfalls mehrfach bis es wieder auftritt.

Viele Grüße,

Jan

[knxmfbp]

Hi Jan, das sollte möglich sein, muss nur einen gelegenen Augenblick finden wo es niemanden stört.

Gibt es beim eibd besondere logging Möglichkeiten?

[mumpf]

Hi, der Hauptunterschied zwischen Rechner Neustart und sh.py Neustart ist, dass beim Rechner der eibd neu gestartet wird, da hast du recht. Beim eibd Neustart passiert erstmal nichts, aber sh.py macht natürlich für jedes Item mit einem knx_cache einen Cache-Zugriff auf den eibd. Dieser setzt jetzt einen knx_read ab, da er nichts im Cache hat. Die ganzen responses triggern jetzt möglicherweise irgendwelche Sachen im knx-system. Da würde ich bei der Suche ansetzen. Die Frage, warum dein Garagentor aufgeht, beantwortet das hier aber nicht, wenn es kein Item für die Garage in sh.py gibt. Gruß Waldemar

[JanT]

Wenn Du in plugin.conf

busmonitor = true

Für das KNX-Plugin setzt, werden alle KNX Pakete ins smarthome.log mitgeschrieben. Bist Du Dir sicher, dass keine Gruppenadressen für das Tor definiert ist? Auch nich indirekt in Form einer Szene oder Trigger. In solchen Fällen sind knx_cache "gefährlich" wie Waldemar geschrieben hat, und Du solltest - wenn smartHOME darauf reagieren soll - stattdessen knx_listen verwenden.

Viele Grüße,

Jan

[knxmfbp]

Ganz sicher ist das Tor nicht definiert, habe eben nochmal ein grep -r laufen lassen ab dem sh.py root Verzeichnis.
Werde mal busmonitor im sh.py setzen und schauen wie das ausschaut.

[knxmfbp]

Hatte soeben einen Ausfall der Busspannung und anschließend auch das gleiche Phänomen wie beim letzen mal. Natürlich hatte ich "busmonitor = True" noch immer nicht gesetzt, habe das aber soeben nachgeholt.

Eine Verständnisfrage tut sich mir auf, wieso sehe ich wenn ein Item über die sh.py gestetzt wird jeweils zwei Zeilen wie im folgenden Beispiel wo ein Temperaturwert auf den Bus gesendet wird oder einer Lampe ein- / ausgeschaltet wird:

2016-03-21 15:26:44 INFO     Main         knx: 0.0.0 set 2/1/51 to 0c38
2016-03-21 15:26:44 INFO     Main         knx: 15.15.255 set 2/1/51 to 0c38

2016-03-21 15:29:41 INFO     Main         knx: 0.0.0 set 0/1/4 to True
2016-03-21 15:29:41 INFO     Main         knx: 15.15.255 set 0/1/4 to True

2016-03-21 15:29:45 INFO     Main         knx: 0.0.0 set 0/1/4 to False
2016-03-21 15:29:45 INFO     Main         knx: 15.15.255 set 0/1/4 to False

[cmalo]

2016-03-21 15:29:45 INFO Main knx: 0.0.0 set 0/1/4 to False
2016-03-21 15:29:45 INFO Main knx: 15.15.255 set 0/1/4 to False

Das sieht so aus, als wenn die Nachricht zwei mal auf den Bus geschicht wird, einmal von 0.0.0 und dann von 15.15.255
Kann es sein, dass du mehrere eibd laufen hast?
Wie sieht deine System-Landschaft aus? Läuft sh.py nur einmal oder mehrmals? Verwendest du ein Wiregate???
Welcher Teilnehmer ist bei dir die 15.15.255 ?

Schick mal die Parameter mit den der eibd gestartet wird.

[knxmfbp]

Es läuft nur ein eibd bei mir und kein Wiregate. Der 15.15.255 ist mir an sich unbekannt, auch der 0.0.0 sollte laut meiner Befehlszeile vom eibd nicht sein:

/usr/bin/eibd -d -p /run/eibd.pid -S -R -i -t 10 -e 1.0.81 ipt:192.168.0.1

Wenn ich seitens ETS Geräteinfo lesen anstoße auf die 15.15.255 Adresse bekomme ich eine Hinweismeldung zurück dass das Gerät mit dieser Adresse nicht gefunden wurde.

[cmalo]

schau mal in die beiden Threads:
hier und hier

[knxmfbp]

Danke, ich habe noch einen Bewegungsmelder den ich noch nicht programmiert habe. Werde mich da Morgen mal ran machen, dann sollte von da aus wenigstens alles sauber sein.
Allerdings erklärt es noch nicht warum mit der Adresse 0.0.0 auf den Bus gesendet wird anstatt der 1.0.81 wie im eibd eingestellt. Auch wenn ich den Gruppen- bzw. Busmonitor starte sehe ich nur Quell-Adresse 15.15.255. Auch sehe im Monitor die Telegramme zweimal, erstens mit ROUT 7 und anschliessend 6.
Ich bin mir hier nicht ganz sicher was richtig ist, der Gira KNX/IP Router fungiert ebenfalls als Koppler wenn ich mich recht erinnere?

[knxmfbp]

Hängt allerdings davon ab von wo aus ich den Monitor starte. Vorheriges Beispiel war am USB Port, wenn ich mich jetzt mit dem Monitor über IP verbinde sehe ich wie am sh.py Monior zuerst ein Eintrag von 15.15.255 mit ROUT 7 und ein Eintrag mit ROUT 6 von 0.0.0.

[knxmfbp]

Endlich wieder besseres Wetter und somit habe ich den letzten Bewegungsmelder in Betrieb genommen, allerdings scheint dieser nicht die Fehler verursacht zu haben.
Als ich diesen Programmieren wollte bekam ich immer dir Fehlermeldung dass bereits ein Gerät im Programmiermodus wäre, was aber nicht der Fall ist/war. In der ETS habe ich dann über Diagnose - Physykalische Adressen - Programmiermodus versucht herauszufinden wer im Programmiermodus ist, was mir eine Flut an 15.15.255 Adressen gab. Kurzerhand eibd gestoppt und nochmals angestossen bekam ich keine Adresse mehr zurück. Auch konnte ich jetzt den BWM programmieren.

Ich habe anschliessend folgende Änderungen an den eibd Optionen vorgenommen:

# Alte Optionen
#EIBD_OPTS="-S -R -i -t 10 -e 1.0.81 ipt:192.168.0.1"

# Neue Optionen
EIBD_OPTS="-S -T -D -i ipt:192.168.0.1"

Wenn ich mir jetzt das Log anschaue sieht das auch besser aus, keine wiederholung mehr mir der Adresse 15.15.255:

2016-04-04 15:22:15 INFO     Main         knx: 0.0.0 set 0/1/2 to True
2016-04-04 15:22:18 INFO     Main         knx: 0.0.0 set 0/1/2 to False

Vielleicht hat jemand eine Erklärung? Ich selbst kriege es nicht ganz zusammen wodurch das Fehlerbild erzeugt wurde. An der -e 1.0.81 liegt es auf jeden Fall nicht, mit der hat es auch noch funktioniert, jedoch ist die Option -e ohne Wirkung da vom eibd aus alles mit 15.15.255 auf den Bus geht unabhängig von -e. Also kann es nur an der Routing Option liegen? Was bewirkt diese?