openHAB-Geister im Haus (undefinierte Actions)

[J-N-K]

Hast Du VSCode die ganze Zeit laufen?

[int5749]

In der Regel nicht, da ich den Windows Rechner mit VSCode Nachts ausschalte. Heute lief der mal mit, weil ich das Log von openHAB offen hatte. Ich meine aber VSC war geschlossen. (eine Hand lege ich dafür nicht in Feuernähe)

[udo1toni]

Die NullPointerException scheint mit einem Scheduler zu tun zu haben, da müsste man aber mehr als nur den kurzen Ausschnitt aus dem log sehen. Ich bin da auch nicht sonderlich gut drin so was anhand des Traces zu identifizieren.

Was das GA-Gemecker betrifft, so versuchst Du, den Status von GA zu erfragen (mit dem < vor der GA) aber die entsprechende GA antwortet nicht, was ein starkes Indiz dafür ist, dass entweder kein KO auf lesbar konfiguriert ist, oder (schlimmer) mehrere KO lesbar konfiguriert sind oder (noch schlimmer) die angefragte GA nicht als Haupt-GA im lesbaren KO eingetragen ist. Dann antwortet das KO nämlich auf einer anderen GA als auf der anfragenden GA. (das wäre quasi so wie in meiner kleinen Geschichte von oben)

Was etwas seltsam scheint: Die Meldung Loading model 'h47.items' deutet darauf hin, dass entweder eine Änderung an der Datei vorgenommen wurde (oder zumindest der Zeitstempel geändert wurde) oder alternativ openHAB neu gestartet hat, dann würden aber andere Einträge fehlen.

[int5749]

Die NullPointerException scheint mit einem Scheduler zu tun zu haben, da müsste man aber mehr als nur den kurzen Ausschnitt aus dem log sehen. Ich bin da auch nicht sonderlich gut drin so was anhand des Traces zu identifizieren.

Viel mehr ist da aber nicht im log davor läuft alles wie ein Uhrwerk (obwohl ich hier weit von der Schweiz entfernt wohne).

Was das GA-Gemecker betrifft, so versuchst Du, den Status von GA zu erfragen (mit dem < vor der GA) aber die entsprechende GA antwortet nicht, was ein starkes Indiz dafür ist, dass entweder kein KO auf lesbar konfiguriert ist, oder (schlimmer) mehrere KO lesbar konfiguriert sind oder (noch schlimmer) die angefragte GA nicht als Haupt-GA im lesbaren KO eingetragen ist. Dann antwortet das KO nämlich auf einer anderen GA als auf der anfragenden GA. (das wäre quasi so wie in meiner kleinen Geschichte von oben)

Ich habe jetzt einfach mal alle Aktoren und Sensoren neu programmiert (kann ja auch nicht schaden) und eine Liste der Mecker-GAs erstellt und diese geprüft. Echt seltsam. Eine GA ist der Lichtschalter an meinem Bett. Dieser ist ausser spiegelbildlicher Tasten analog konfiguriert zu dem auf der Seite meiner Frau. Meine GA (also eine davon, denn der Schalter hat 6 Tasten) wird angemeckert und bei meiner Frau nix. OK, ist ja meistens der Mann, der die Mecker bekommt, aber schon seltsam. Es handelt sich um 5 GAs mit "negative confirmation" und nochmals 5 GAs mit "giving up reading datapoint". Bei dem "giving...." würde ich einen eigenen Thread aufmachen, das riecht schon nach einem Fehler

Was etwas seltsam scheint: Die Meldung Loading model 'h47.items' deutet darauf hin, dass entweder eine Änderung an der Datei vorgenommen wurde (oder zumindest der Zeitstempel geändert wurde) oder alternativ openHAB neu gestartet hat, dann würden aber andere Einträge fehlen.

Die hatte ich tatsächlich bearbeitet, da ich eine Gruppe zum persistieren diverser Items angelegt und diese entsprechend befüllt hatte. Dann aber gesehen, dass alle Items schon einzeln in der persist-Datei sind und dennoch kommen beim Start falsche Werte (zumindest nach dem Geisterstart vor 2 Tagen)

[udo1toni]

Eine GA ist der Lichtschalter an meinem Bett. Dieser ist ausser spiegelbildlicher Tasten analog konfiguriert zu dem auf der Seite meiner Frau. Meine GA (also eine davon, denn der Schalter hat 6 Tasten) wird angemeckert und bei meiner Frau nix. OK, ist ja meistens der Mann, der die Mecker bekommt, aber schon seltsam. Es handelt sich um 5 GAs mit "negative confirmation" und nochmals 5 GAs mit "giving up reading datapoint".

Schaltest Du denn mit den Schaltern unterschiedliche Dinge? Eventuell ist Dein knx System nicht so konfiguriert, wie man das macht...

Also, ich habe z.B. drei "Standorte" mit Tastern im Schlafzimmer. Einmal Tür, einmal linke Bettseite, einmal rechte Bettseite. Die Taster steuern jeweils zwei Dimmer, einen Rollladen und ein Fenster. Die Tastergruppe an der Tür steuert zusätzlich noch Steckdose und Beleuchtung des Balkons. Aber was die Dimmer betrifft, so sind alle drei Tastergruppen identisch parametriert, es ist jeweils die selbe GA für Senden und die selbe GA für Rückmeldung hinterlegt. Ich kann so zwar nicht unterscheiden, welcher Taster zum Schalten des Lichts verwendet wurde, das ist aber auch eine Information, die mich nicht interessiert. Wichtiger ist für mich, dass es funktioniert

Taster sind per Definition niemals "Eigentümer" eines Status, sie sollten also auch nicht lesbar sein. Am einfachsten entfernst Du also die Abfrage für die GA, das ist eh falsch.

Die hatte ich tatsächlich bearbeitet, da ich eine Gruppe zum persistieren diverser Items angelegt und diese entsprechend befüllt hatte. Dann aber gesehen, dass alle Items schon einzeln in der persist-Datei sind und dennoch kommen beim Start falsche Werte (zumindest nach dem Geisterstart vor 2 Tagen)

Du solltest eigentlich keine Zustände aus der Persistence auslesen, wenn das nicht zwingend notwendig ist. knx betreffend sollten z.B. alle Zustände vom Bus erfragt werden. Solche Items sollten keinesfalls auf restoreOnStartup konfiguriert sein, das macht nur Durcheinander.

[int5749]

Schaltest Du denn mit den Schaltern unterschiedliche Dinge? Eventuell ist Dein knx System nicht so konfiguriert, wie man das macht...

Nein, die beiden Taster am Bett sind "identisch" und doch etwas anders
Also Identisch, weil beide Taster die gleichen Funktionen schalten.
Aber bei meiner Bett-Seite ist mein Nachttischlicht auf Taste 2 (1. Wippe rechte Seite) und das Nachttischlicht meiner Frau auf Taste 1 (1. Wippe linke Seite)
Bei der Bett-Seite meiner Frau ist ihr Nachttischlicht auf Taste 1 (1. Wippe linke Seite) und mein Nachttisch auf Taste 2 (1. Wippe rechte Seite)

Somit kommt jeder einfach an sein Licht und ihr wisst nun wie rum wir im Bett liegen

Du solltest eigentlich keine Zustände aus der Persistence auslesen, wenn das nicht zwingend notwendig ist. knx betreffend sollten z.B. alle Zustände vom Bus erfragt werden. Solche Items sollten keinesfalls auf restoreOnStartup konfiguriert sein, das macht nur Durcheinander.

Oha, GROße Baustelle, bösen Anfängerfehler die ganze Zeit mitgeschleppt => bei mir ist FAST alles persisiert

Da wird wohl jemand aufräumen müssen und nähert sich nach Jahren einem aufgeräumteren System.

[int5749]

Andere Frage in dem Zusammenhang: Warum klappt es bei einem Kanal, aber nicht beim zweiten.

Code: Alles auswählen

Type switch	: ch6		"Nachttisch 1"			[ ga="1/2/1+<0/4/1" ]
Type switch	: ch7		"Nachttisch 2"			[ ga="1/2/2+<0/4/2" ]

Beide Kanäle sind in der ETS identisch als lesend konfiguriert.

[udo1toni]

Also Identisch, weil beide Taster die gleichen Funktionen schalten.

Um mehr geht es nicht. Nehmen wir an, Du hast zwei Aktoren für die beiden Nachttischlampen, dann gibt es in beiden Aktorkanälen zwei wichtige KO, das ist zum einen das KO, mit dem der Kanal geschaltet wird, zum anderen das KO, welches die aktuelle Schaltstellung zurück meldet.
Der Einfachheit halber:

Code: Alles auswählen

Ch Command Rückmeldung
 1  0/0/1   0/0/11
 2  0/0/2   0/0/12

Dann ist auf der einen Bettseite Taster eins mit 0/0/1,0/0/11 und Taster zwei mit 0/0/2,0/0/12 parametriert. Auf der anderen Bettseite ist es genauso, nur dass Taster eins und zwei vertauscht sind. Du hast also insgesamt vier GA. Soll das Nachttischlicht auch noch zusätzlich über Zentral aus ausgeschaltet werden, so kommt (ausschließlich im Aktor) noch jeweils die Zentral Aus GA als sekundäre GA zum Command KO dazu.

Auf openHAB-Seite bildest Du nun nicht die Taster ab, sondern die Aktor-Channel, und zwar genauso

Code: Alles auswählen

Type switch : ch1 "Nachttischlampe links" [ga="0/0/1+<0/0/11"]
Type switch : ch2 "Nachttischlampe rechts" [ga="0/0/2+<0/0/12"]

das Rückmelde-KO hat gewöhnlich das Flag für Lesen gesetzt.

Wie erwähnt gibt es nur wenige Fehlerquellen, aber natürlich können auch mehrere Fehler gleichzeitig vorliegen.
Punkt 1: Die abgefragte GA ist keinem KO zugeordnet, bei dem das L-Flag gesetzt ist. Alternativ ist bei mehreren mit der GA verknüpften KO das L-Flag gesetzt (das sollte eigentlich nur zu doppelten Antworten führen, es kann aber dadurch zu Störungen auf dem Bus kommen)
Punkt 2: Die abgefragte GA ist nicht als Haupt- (d.h. die erste in der Liste) GA mit dem KO verknüpft, bei dem das L-Flag gesetzt ist. knx sendet ausschließlich auf der ersten verknüpften GA, egal, auf welcher GA ein Read Request empfangen wird.
Punkt 3: Die Topologie des Busses verhindert die Abfrage (beispielsweise, weil ein knx Router die GA filtert)
Punkt 4: in openHAB wird ein *-control Channel verwendet. Dort wird niemals ein Read Request erzeugt, da openHAB per Definition selbst "Eigner" des Status ist.
Punkt 5: in openHAB ist kein < angegeben.
Punkt 6: es wird der falsche DPT verwendet.

Die Punkte 4 - 6 sind nur der Vollständigkeit halber und Punkt 3 würde im Zweifel die gesamte Kommunikation, diese GA betreffend stören.

[int5749]

Die bestätigt ja genau meine Konfiguration. Somit scheint diese zumindest richtig zu sein.
Ich werde dieses spezielle Problem mal versuchen zu beobachten, denn es tritt auch nicht immer und bei jedem Start von openHAB auf.
Dies macht es herausfordernd bis unmöglich, dahinter zu kommen warum der Status manchmal nicht gelesen werden kann.

Zum ursprünglichen Problem. Die heutige Nacht war wieder ruhhig, keine seltsamen Schaltvorgänge
Um 2023-02-26 03:33:22.738 (fast schon eine seltsame Zeit) gabe es für 2 Minuten Kommunikationsprobleme bei 1 von 3 Wechselrichtern über ModBus, was schon eher in Richtung Netzwerk zeigt
Werde evtl. heute Abend mal den Switch booten, das habe ich bei all den Aktionen in den letzten Tagen noch nicht vorgenommen.

Alle anderen Aktionen habe eher das Boot-Up Log bereinigt, als das es Probleme behoben hat, was natürlich ein schöner Nebeneffekt neben der Lernkurve ist.