Gira L1 - Bug, Edelschrott oder Layer 8?

[hyman]

... und vor allem auch Antworten darauf? Und Schreibzugriffen auf die Kesselpumpen-GA? Wenn ja von woher? Wie ich vorher schon frug ...

[hubidoo]

Schon wieder sind mir Deine Schlussfolgerungen etwas zu schnell.


Bei Inbetriebnahme werden nach meiner Erfahrung sehr wohl Leseanforderungen auf den Bus geschickt. Ob die auch beantwortet werden, steht auf einem anderen Blatt. Wie sind die Flags der entsprechenden Kommunikationsobjekte gesetzt? Hast Du schon mal während einer Inbetriebnahme den ETS-Gruppenmonitor mit laufen lassen? Was hast Du ggf. dort gesehen?


Irrtum. Null sieht die UVR nie, es bedeutet einfach nur, dass seit der Inebtriebnahme noch nie ein Wert gesendet wurde. Wenn Deine Kesselpumpe bei einer Inbetriebnahme aus geht, muss es dafür eine andere Ursache geben. Auch hier: Der Gruppenmonitor ist Dein Freund...

Was null bedeutet, weiß ich schon, aber null ist nicht true oder 1, daher interpretiert die UVR das so, dass keine Kesselanforderung ansteht und schaltet die Pumpe ab.
K und S Flags sind gesetzt. Ich kucke die ganze Zeit über knxd auf den Bus. Die Ursache ist der L1 selbst, der bei Reset/Neustart aktuell keine Werte lesen kann und zwar keinen einzigen. Wenn er oben ist, bekommt er jedoch Änderungen mit. Gira meint, dass es so aussieht, dass er abfragt bevor der knx daemon geladen hat.

Das Teil ist softwaremäßig einfach kaputt nach dem Firmware-Update und das ist permanent.

[hyman]

Was null bedeutet, weiß ich schon, aber null ist nicht true oder 1, daher interpretiert die UVR das so, dass keine Kesselanforderung ansteht und schaltet die Pumpe ab.

Es gibt zwei Möglichkeiten:

• Was Du sagst ist wahr, dann hat die Anbindung der UVR einen Bug, denn null ist auch nicht false oder 0. Es dennoch so zu interpretieren (anstatt als "keine Änderung") wäre deshalb ein Bug. Unklar wäre mir in dem Fall, woher die UVR das false überhaupt zur Kenntnis bekommt...
• Die UVR ist über ganz normale Kommunikationsobjekte angebunden. Dann gilt ganz klar: Damit die Kesselpumpe abschaltet, muss auf der verknüpften GA ein false-Telegramm kommen. Von einem Ausgang im Logikmodul, der noch auf null steht kommt das sicher nicht. Also musst Du Dich dann fragen, woher es sonst kommt.

Die Ursache ist der L1 selbst, der bei Reset/Neustart aktuell keine Werte lesen kann und zwar keinen einzigen.

Was genau meinst Du mit "lesen kann"? Versucht er es gar nicht erst oder bekommt er beim Versuch keine Antwort?

Da man auch schon von knxd-Problemen gehört hat: Wo ist denn Dein Gruppenmonitor-Log einer Inbetriebnahme? Ohne den ist das hier alles Kaffeesatzleserei...

Das Teil ist softwaremäßig einfach kaputt nach dem Firmware-Update und das ist permanent.

Das kann natürlich auch sein, glaube ich aber erst, wenn ich verstanden habe, welcher Mechanismus bei null Deine Pumpe abschaltet. Dann wäre ein Factory Reset, gefolgt von erneutem Firmware-Update einen Versuch wert...

[hubidoo]

hubidoo
Bitte berichte dann mal, was dabei herausgekommen ist. Ich hatte mit dem Umstieg auf die neue Firmware mit dem alten grauen LOMO auch Probleme und hatte es nach diversen Versuchen incl. Hotline erstmal aufgegeben, weil mir der Gira-Vorschlag (Werksreset) zu vage erschient.

Die Vorgehensweise ist genau die Richtige:
Gira-Hotline => Hardware-Werksreset => Downgrade => Hardware-Werksreset => Upgrade => Inbetriebnahme => gleiches Problem? => wenn nein = Problem gelöst, wenn ja, Gira-Hotline => Hardware-Austausch, altes LOMO gegen neues L1

Ich bekomme nun ein L1 zugesendet.

[hyman]

... und das obwohl wir immer noch nicht verstanden haben, wie Deine Pumpe sich mit null ausschaltet oder was im ETS-Gruppenmonitor geloggt würde, wenn Du den mal bei einer Inbetriebnahme mit laufen lassen würdest. Naja, wie Du meinst...

[hubidoo]

Es gibt zwei Möglichkeiten:

• Was Du sagst ist wahr, dann hat die Anbindung der UVR einen Bug, denn null ist auch nicht false oder 0. Es dennoch so zu interpretieren (anstatt als "keine Änderung") wäre deshalb ein Bug. Unklar wäre mir in dem Fall, woher die UVR das false überhaupt zur Kenntnis bekommt...
• Die UVR ist über ganz normale Kommunikationsobjekte angebunden. Dann gilt ganz klar: Damit die Kesselpumpe abschaltet, muss auf der verknüpften GA ein false-Telegramm kommen. Von einem Ausgang im Logikmodul, der noch auf null steht kommt das sicher nicht. Also musst Du Dich dann fragen, woher es sonst kommt.

Was genau meinst Du mit "lesen kann"? Versucht er es gar nicht erst oder bekommt er beim Versuch keine Antwort?

Da man auch schon von knxd-Problemen gehört hat: Wo ist denn Dein Gruppenmonitor-Log einer Inbetriebnahme? Ohne den ist das hier alles Kaffeesatzleserei...


Das kann natürlich auch sein, glaube ich aber erst, wenn ich verstanden habe, welcher Mechanismus bei null Deine Pumpe abschaltet. Dann wäre ein Factory Reset, gefolgt von erneutem Firmware-Update einen Versuch wert...

Das Problem ist, dass das L1 offensichtlich eine 0 sendet auf die Gruppenadresse bei null, daher stand im CAN-Modul des UVR im KNX Eingang der Kesselanforderung "AUS". Das ist kein UVR Problem, sondern immer noch ein L1 Problem. Auf TA-Seite ist alles gut. Das L1 hat keine Initialwerte drin stehen für die entsprechenden GAs, daher interpretiert es ein false hinein, obwohl kein Wert bekannt ist. Das ist jedenfalls nicht ok. Gira hatte bestätigt, dass es bei älteren Teilen, den grauen, zu Problemen kommen kann beim Firmwareupdate. Zumindest sagte mir der Mitarbeiter, dass er schon ein paar ausgetauscht hatte.

Ähnliche Problem habe ich doch auch bei der Außenbeleuchtung. Da wird die Beleuchtungsstärke abgefragt, geht nicht, dennoch wird scheinbar ein Wert 0 angenommen, daher geht dann am Tag das Licht an, da der Vergleicher sagt, Ok., kleiner 100 und dann den Ausgang auf high setzt.

Selbiges Spiel mit den Bewegungsmeldern, deren Flag auf 1 stehen bleibt und daher nie mehr abschaltet.
Witzigerweise funktioniert das manchmal und manchmal nicht, mal bleibt das Licht aus am Tag, mal schaltet es ab in der Nacht, wie es gerade gelaunt ist. Man meint gerade, L1 hat ihre Tage...

Jetzt Trommelwirbel...
Das Teil ist jetzt völlig jungfräulich gewesen, nach Gira-Reset-Prozedur neu bestückt mit Down-/Upgrade. Unabhängig davon wird durch die Zertifikatsfehlermeldung das L1 nun sowieso getauscht, aber egal, mich interessiert, ob jetzt der Logikkram wieder normal läuft.
Habe gerade noch die physikalische Adresse neu vergeben.
Werde danach mal einen Monitor mit laufen lassen und kucken, ob da jetzt endlich nach Neustart was raus kommt. Bei bisherigen Versuchen tauchte da nichts auf.

[hyman]

Das Problem ist, dass das L1 offensichtlich eine 0 sendet auf die Gruppenadresse bei null, daher stand im CAN-Modul des UVR im KNX Eingang der Kesselanforderung "AUS".

Was genau heißt "offensichtlich"? Weil die 0 in der UVR steht? Oder hast Du das Telegramm im ETS-Gruppenmonitor gesehen? Mit dem L1 als Absender? Wenn ja, warum sagst Du das trotz mehrfacher Nachfragen nicht?

Das L1 hat keine Initialwerte drin stehen für die entsprechenden GAs, daher interpretiert es ein false hinein, obwohl kein Wert bekannt ist.

Auch diese Aussage hast Du jetzt schon mehrfach wiederholt. Sie bleibt aber unzutreffend. Den Beweis hast Du selbst schon oben in Beitrag #8 geliefert: Einer der Eingänge null, Ausgang auch null, genau so soll es sein. Null ist weder false noch true. Würde mich sehr wundern, wenn der L1 trotzdem was auf den Bus sendet. Und wenn er es tut, würde ich mich auf die Suche nach weiteren Logikausgängen machen, die auch auf diesen Datenpunkt schreiben. Erst wenn ich da nix finde, fange ich an, daran zu glauben, dass Du doch recht hast.

Ich bin seit vielen Jahren Softwareentwickler und habe schon Pferde kotzen sehen (Compilerfehler). Also ja, sowas kann vorkommen, aber äußerst selten. In den weitaus meisten Fällen (99+%) findet sich für so seltsames Verhalten eine ganz banale andere Ursache.

[hubidoo]

... und das obwohl wir immer noch nicht verstanden haben, wie Deine Pumpe sich mit null ausschaltet oder was im ETS-Gruppenmonitor geloggt würde, wenn Du den mal bei einer Inbetriebnahme mit laufen lassen würdest. Naja, wie Du meinst...

Hier ist der aktuelle Status nach dem Komplett-Reset:

Die Fehler beim Starten im logicengine.log sind geblieben:

2020-05-05 19:53:30,618 [Fleck Receive Thread] ERROR GdsClient [(null)] - Code: 120; Text: GDS client: Received error from GDS server, code: 120; text: Failed to get licenses.; hint: Crypto system failure (code 9) | request = '{"request":{"correlationId":3166,"command":"GetLicenses","domain":"logic"}}' 2020-05-05 19:53:32,932 [Fleck Receive Thread] ERROR GdsClient [(null)] - Code: 1; Text: GDS client: Received error from GDS server, code: 1; text: Get value failed.; hint: URN = urn:gds:dp:GiraLogikmodul.GILOMOKX01:KNX-GA-Channel:Brunnenwasser-Druckmelder-23569 | request = '{"request":{"correlationId":3168,"command":"GetValue","id":"150016"}}' 2020-05-05 19:53:35,236 [Fleck Receive Thread] ERROR GdsClient [(null)] - Code: 1; Text: GDS client: Received error from GDS server, code: 1; text: Get value failed.; hint: URN = urn:gds:dp:GiraLogikmodul.GILOMOKX01:KNX-GA-Channel:Bewegungsmelder140BMHofunterBalkon | request = '{"request":{"correlationId":3173,"command":"GetValue","id":"150004"}}' 2020-05-05 19:53:35,899 [Fleck Receive Thread] ERROR GdsClient [(null)] - Code: 1; Text: GDS client: Received error from GDS server, code: 1; text: Get value failed.; hint: URN = urn:gds:dp:GiraLogikmodul.GILOMOKX01:KNX-GA-Channel:Bewegungsmelder240BMHofunterBalkon | request = '{"request":{"correlationId":3175,"command":"GetValue","id":"150006"}}' 2020-05-05 19:53:36,594 [Fleck Receive Thread] ERROR GdsClient [(null)] - Code: 1; Text: GDS client: Received error from GDS server, code: 1; text: Get value failed.; hint: URN = urn:gds:dp:GiraLogikmodul.GILOMOKX01:KNX-GA-Channel:Bewegungsmelder340BMHofunterBalkon | request = '{"request":{"correlationId":3177,"command":"GetValue","id":"150032"}}' 2020-05-05 19:53:37,295 [Fleck Receive Thread] ERROR GdsClient [(null)] - Code: 1; Text: GDS client: Received error from GDS server, code: 1; text: Get value failed.; hint: URN = urn:gds:dp:GiraLogikmodul.GILOMOKX01:KNX-GA-Channel:Bewegungsmelder440BMHofunterBalkon | request = '{"request":{"correlationId":3179,"command":"GetValue","id":"150002"}}' 2020-05-05 19:53:38,272 [Fleck Receive Thread] ERROR GdsClient [(null)] - Code: 1; Text: GDS client: Received error from GDS server, code: 1; text: Get value failed.; hint: URN = urn:gds:dp:GiraLogikmodul.GILOMOKX01:KNX-GA-Channel:Bewegungsmelder140BMEDFzimmer | request = '{"request":{"correlationId":3183,"command":"GetValue","id":"150029"}}' 2020-05-05 19:53:38,968 [Fleck Receive Thread] ERROR GdsClient [(null)] - Code: 1; Text: GDS client: Received error from GDS server, code: 1; text: Get value failed.; hint: URN = urn:gds:dp:GiraLogikmodul.GILOMOKX01:KNX-GA-Channel:Bewegungsmelder240BMEDFzimmer | request = '{"request":{"correlationId":3185,"command":"GetValue","id":"150014"}}' 2020-05-05 19:53:39,623 [Fleck Receive Thread] ERROR GdsClient [(null)] - Code: 1; Text: GDS client: Received error from GDS server, code: 1; text: Get value failed.; hint: URN = urn:gds:dp:GiraLogikmodul.GILOMOKX01:KNX-GA-Channel:Bewegungsmelder340BMEDFzimmer | request = '{"request":{"correlationId":3187,"command":"GetValue","id":"150020"}}' 2020-05-05 19:53:40,293 [Fleck Receive Thread] ERROR GdsClient [(null)] - Code: 1; Text: GDS client: Received error from GDS server, code: 1; text: Get value failed.; hint: URN = urn:gds:dp:GiraLogikmodul.GILOMOKX01:KNX-GA-Channel:Bewegungsmelder440BMEDFzimmer | request = '{"request":{"correlationId":3189,"command":"GetValue","id":"150009"}}' 2020-05-05 19:53:40,938 [Fleck Receive Thread] ERROR GdsClient [(null)] - Code: 1; Text: GDS client: Received error from GDS server, code: 1; text: Get value failed.; hint: URN = urn:gds:dp:GiraLogikmodul.GILOMOKX01:KNX-GA-Channel:Bewegungsmelder140BMKFCche | request = '{"request":{"correlationId":3191,"command":"GetValue","id":"150033"}}' 2020-05-05 19:53:41,684 [Fleck Receive Thread] ERROR GdsClient [(null)] - Code: 1; Text: GDS client: Received error from GDS server, code: 1; text: Get value failed.; hint: URN = urn:gds:dp:GiraLogikmodul.GILOMOKX01:KNX-GA-Channel:Bewegungsmelder240BMKFCche | request = '{"request":{"correlationId":3193,"command":"GetValue","id":"150013"}}' 2020-05-05 19:53:42,347 [Fleck Receive Thread] ERROR GdsClient [(null)] - Code: 1; Text: GDS client: Received error from GDS server, code: 1; text: Get value failed.; hint: URN = urn:gds:dp:GiraLogikmodul.GILOMOKX01:KNX-GA-Channel:Bewegungsmelder340BMKFCche | request = '{"request":{"correlationId":3195,"command":"GetValue","id":"150024"}}' 2020-05-05 19:53:43,009 [Fleck Receive Thread] ERROR GdsClient [(null)] - Code: 1; Text: GDS client: Received error from GDS server, code: 1; text: Get value failed.; hint: URN = urn:gds:dp:GiraLogikmodul.GILOMOKX01:KNX-GA-Channel:Bewegungsmelder440BMKFCche | request = '{"request":{"correlationId":3197,"command":"GetValue","id":"150022"}}' 2020-05-05 19:53:44,912 [Fleck Receive Thread] ERROR GdsClient [(null)] - Code: 1; Text: GDS client: Received error from GDS server, code: 1; text: Get value failed.; hint: URN = urn:gds:dp:GiraLogikmodul.GILOMOKX01:KNX-GA-Channel:Pumpe4WohnhausStatus | request = '{"request":{"correlationId":3219,"command":"GetValue","id":"150015"}}'

Hier ist sind die Telegramme ab Inbetriebnahme, der L1 hat die Adresse 0.4.253 und fragt nach Reset ab und erhält auch Antwort.
Wer das komplette Log sehen möchte, darf das gerne via PM melden.

Die doppelten Telegramme kommen vom knxd, muss demnächst mal kucken, wie ich ihm das austreibe.


Auswahl_002.png



Die meisten Werte stehen nun auf true oder false, bis auf die Bewegungsmelder, die er zwar abfragt, die aber so lange auf null stehen, bis sie sich das erste mal gerührt haben.

[hubidoo]

Was genau heißt "offensichtlich"? Weil die 0 in der UVR steht? Oder hast Du das Telegramm im ETS-Gruppenmonitor gesehen? Mit dem L1 als Absender? Wenn ja, warum sagst Du das trotz mehrfacher Nachfragen nicht?


Auch diese Aussage hast Du jetzt schon mehrfach wiederholt. Sie bleibt aber unzutreffend. Den Beweis hast Du selbst schon oben in Beitrag #8 geliefert: Einer der Eingänge null, Ausgang auch null, genau so soll es sein. Null ist weder false noch true. Würde mich sehr wundern, wenn der L1 trotzdem was auf den Bus sendet. Und wenn er es tut, würde ich mich auf die Suche nach weiteren Logikausgängen machen, die auch auf diesen Datenpunkt schreiben. Erst wenn ich da nix finde, fange ich an, daran zu glauben, dass Du doch recht hast.

Ich bin seit vielen Jahren Softwareentwickler und habe schon Pferde kotzen sehen (Compilerfehler). Also ja, sowas kann vorkommen, aber äußerst selten. In den weitaus meisten Fällen (99+%) findet sich für so seltsames Verhalten eine ganz banale andere Ursache.

Sorry, war gerade beim Essen.
Grundsätzlich hast Du Recht, bei KNX habe ich jedoch mittlerweile den Eindruck, dass man keine Firmware-Updates einspielen kann, ohne nicht komplett alle betroffenen Teilnehmer zu nullen und auf Werksreset zu setzen. Hatte jetzt schon ein paar mal üble Verhaltensweisen, die sich ums verrecken nicht erklären ließen und erst nach Komplett-Reset hat sich das Teil normal verhalten. KNX-Geräte sind extrem auffällig dafür. Neulich hatte ich aber auch eine pfSense, die völlig durch gedreht war, nachdem sie einen Downgrade erhalten hatte. Der Fehler war in dem Fall, dass alle Einträge mehrfach im Config-File vorhanden waren. Das ist auch ein Bug an dem der Hersteller seit Wochen knobelt. Auch das sind Softwareentwickler und keine schlechten, dennoch passiert das eben ab und an.
Das eine Prozent erwische immer ich...dafür habe ich einen Riecher.

Kuck bitte mal oben das Log an:
Siehe Gruppenmonitorlog: Kesselpumpe => GroupValueWrite => Aus oder Ein
Er macht folgendes: Abfrage Status erste Pumpe, wenn die 0 ist, setzt er sofort die Kesselpumpe auf Aus, Abfrage nächste Pumpe, ist die 1, setzt er die Kesselpumpe auf Ein. Der Pumpenstatus ist nun nicht mehr null nach Werks-Reset. Bei den Bewegungsmeldern ist es jedoch immer noch null. Ob das normal ist, weiß ich nicht. Abfragen tut er sie und erhält auch eine Antwort. Ich kann nur sagen, dass das vorher auch so war, aber eben null statt false und die Kesselpumpe dennoch deaktiviert wurde. Du kannst doch sicher in den Code kucken, was er in den letzten Releases machte, wenn ein Wert null ist...if [ "$VALUE" = "TRUE" ] || [ "$VALUE" = "1" ] then ...mach dies... else mach das...fi. Schon ist es passiert.

Für mich sieht alles komplett richtig aus, außer dass der knxd hier nachplappert.
Die Kesselpumpe (=Heizungsanforderung) kennt momentan nur der L1, sonst keiner.

[hyman]

Kuck bitte mal oben das Log an:

0.4.253 ist der L1? In der Tat kommt daher der Befehl, die Kesselpumpe zu schalten.

Hast Du inzwischen die Eingänge des ODER-Gatters mit false vorbelegt? Wenn ja, wäre das jetzige Verhalten korrekt:

• Der erste Ausgabewert kommt, nachdem das ODER-Gatter das erste Telegramm empfangen hat.
• Und wenn sein erster Eingang ein true empfängt, schaltet es auch den Ausgang ein.

Wenn nicht: Wie sicher bist Du, dass für das Senden auf diese GA nur das ODER-Gatter in Frage kommt, das wir hier diskutieren? Kann es noch andere Logikbausteine geben, die auf diesen GA-Datenpunkt senden?

Bei den Bewegungsmeldern ist es jedoch immer noch null. Ob das normal ist, weiß ich nicht. Abfragen tut er sie und erhält auch eine Antwort.

Das sehe ich anders: Nicht alle Leseanforderungen des L1 werden auch beantwortet. Das betrifft alle Bewegungsmelder und die Pumpe 4. Antworten sehe ich nur von einem Lichtwert und von drei der vier Pumpen.

Für mich sieht alles komplett richtig aus, außer dass der knxd hier nachplappert.

Siehe oben -- für mich nicht ganz. Den knxd würde ich mal stilllegen und schauen, ob die ganzen Duplizierungen dann weg gehen.

[hyman]

Du kannst doch sicher in den Code kucken, was er in den letzten Releases machte, wenn ein Wert null ist...if [ "$VALUE" = "TRUE" ] || [ "$VALUE" = "1" ] then ...mach dies... else mach das...fi. Schon ist es passiert.

Nee, ich bin zwar Softwareentwickler, aber nicht vom/fürn L1/X1. Das war jb1...

Warum ich trotzdem nicht glaube, dass es so ist: Logikbausteine (präziser: deren Execute-Methode) werden normalerweise erst aufgerufen, wenn sie einen neuen Eingabewert bekommen UND für alle Eingänge einen Wert haben. Vorher tun sie einfach gar nix.

Deshalb glaube ich auch, dass Du

die Eingänge des ODER-Gatters mit false vorbelegt

hast...

[hubidoo]

Nee, ich bin zwar Softwareentwickler, aber nicht vom/fürn L1/X1. Das war jb1...

Warum ich trotzdem nicht glaube, dass es so ist: Logikbausteine (präziser: deren Execute-Methode) werden normalerweise erst aufgerufen, wenn sie einen neuen Eingabewert bekommen UND für alle Eingänge einen Wert haben. Vorher tun sie einfach gar nix.

Deshalb glaube ich auch, dass Du


hast...

Der L1 hat die Adresse 0.4.253.

Ich muss mal ein bischen ausholen...
Die GA "Kesselpumpe" oder besser "Heizungsanforderung" (werde das noch mal ändern) ist ausschließlich dazu da, dass die TA das mitbekommt, dass aus einem der Kreise eine Anforderung besteht.

Es gibt keinen Bedarf, diese GA von woanders zu lesen oder zu beschreiben. Beschrieben werden die vier Pumpen GAs aktuell ausschließlich vom knxd (noch), der die Logiken für die Mischersteuerung und dem 1wire-Kram hält, diese wiederum werden ausschließlich im L1 gelesen und nur der L1 schreibt auf die Kesselpumpen-GA alias "Heizungsanforderung".
Der UVR wertet das dann aus, kümmert sich um die Ventile, Kesselpumpe, Leistungssteuerung des Buderus-Brenners, etc. Es wird später noch eine "Kühlanforderung" geben für die Fußbodenheizkreise in Verbindung mit Wärmetauschern im 60.000-Liter-Kälte-Puffer.

Pumpe 4 interessiert momentan noch nicht, der Kreis ist noch nicht aktiv, die existiert zwar bereits elektrotechnisch, aber die Leitung ist noch nicht befüllt.
Daher habe ich mich darum noch nicht gekümmert. Da fehlt wahrscheinlich irgendwo noch eine Kleinigkeit.

Was seltsam ist, und da bin ich noch nicht dahinter gestiegen, weshalb die Außen-Bewegungsmelder initial keine Rückmeldung geben.
Frage ich vom knxd ab, antworten sie und zwar immer.
Das ist übrigens nur initial so. Der Rest funktioniert nun auch nach dem Reset, d,h. die Melder werden dann schon korrekt auf true/false gesetzt.
Meldung ist true, keine Meldung ist false. Sobald false durchgängig anliegt, fängt die Abschalt-Zeit an zu laufen.
Bei den B&J Meldern habe ich gar keine andere Möglichkeit, als eine Gruppe je Sektor. Es gibt nur On/Off.
Die ursprüngliche Annahme, sie melden zurück, resultierte aus der Rückmeldung vom knxd.
Warum die initial (und zwar nur initial und auch nur an den L1) immer noch nicht zurück melden? No clue...


Zur Vorbelegung: da ist eben nichts vorbelegt.

Auswahl_004.png

[hyman]

Deine Erklärung in allen Ehren, aber was tut die zur Sache? Der L1 fragt, und er bekommt bei keinem der Bewegungsmelder eine Antwort. Da der L1 danach nie wieder fragen wird (sondern nur Änderungen entgegen nimmt, die "einfach so" vorbei kommen), kannst Du gar nicht wissen, was passieren würde, früge er erneut. Daraus ergeben sich zwei Fragen:

• Ist das Nichtantworten auf die initiale Nachfrage des L1 eine ausreichende Erklärung dafür, dass nachfolgende Dinge nicht so funktionieren, wie Du willst?
• Was ist anders, wenn der knxd fragt (und auch eine Antwort bekommt)?

Zur Vorbelegung: da ist eben nichts vorbelegt.

Ich meinte das ODER-Gatter ... schau Dir da mal die Eingänge an. Auch die können mit Werten vorbelegt sein, die dann verwendet werden, bis der erste Wert empfangen wird. Und ist Pumpe 4 schon ans ODER-Gatter geführt?

[hyman]

Das ist übrigens nur initial so. Der Rest funktioniert nun auch nach dem Reset, d,h. die Melder werden dann schon korrekt auf true/false gesetzt.

Das verstehe ich nicht. Was genau ist der Unterschied zwischen "initial" und "nach dem Reset"? Ich würde erwarten, dass das Gruppenmonitor-Protokoll in beiden Fällen gleich aussieht. Wer/was setzt die Melder (ich nehme an, Du meinst ihre Datenpunkte im L1) im einen Fall "korrekt auf true/false"?

[hubidoo]

Das verstehe ich nicht. Was genau ist der Unterschied zwischen "initial" und "nach dem Reset"? Ich würde erwarten, dass das Gruppenmonitor-Protokoll in beiden Fällen gleich aussieht. Wer/was setzt die Melder (ich nehme an, Du meinst ihre Datenpunkte im L1) im einen Fall "korrekt auf true/false"?

Mit dem Reset ist der physikalische Hardware-Werks-Reset gemeint, den ich auf Ansage der Gira-Hotline durch führte.
Nach diesem Reset gibt es z.B. bei den Beteiligten des ODER-Gatters keine "null" mehr, sondern da steht nun false und zwar bei allen.

Das Verhalten hat sich geändert, d.h. für mich, dass die Aussagen der Gira-Hotline am wahrscheinlichsten sind, dass bei einem der Firmwareupdates bei den LOMO-Teilen durch Upgrade auf L1 etwas schief laufen kann, nicht vollständig ist oder was auch immer. Ob das nun aus Sicht des L1 fehlerhafte Configs sind, libs oder binaries kann ich nicht sagen, da ich noch nicht auf dem Dateisystem eines L1 drauf war. Fakt ist, dass nach dem Factory-Reset nun die primären Funktionen wieder laufen, die vor dem Update problemlos funktionierten und nach dem Update nicht mehr. Was trotzdem nicht weg ist, sind die Fehlermeldungen im Log. Da ist also immer noch etwas faul. Gira meinte, dass die LOMOs und L1 hardwareseitig nicht identisch sind. Dann gibt es noch das p12 Problem, was sich nicht lösen lässt. Ob da bei Updates bereits intern mit Zertifikaten gearbeitet wird, weiß ich nicht, ich kann es mir aber vorstellen. Als Ergebnis kann man sagen, dass es wohl insgesamt besser ist, ein LOMO nur auf L1 umzuflashen, wenn man das Teil anschließend komplett resettet und noch mal ein down- und upgrade am Ende fährt und trotzdem kann es noch Probleme geben.