Gira L1 - Bug, Edelschrott oder Layer 8?

[hubidoo]

Hallo zusammen,

hier ist wieder ein Fall aus meinem KNX-Gruselkabinett.

Einfachste Dinge klappen momentan nicht mit dem Gira L1, Firmware ist 2.4.37.0, GPA ist V.4.1.
Es treten zuerst einmal keine offensichtlichen Fehler auf, auch nicht in der Simulation (in der alles läuft), im Betrieb aber schon.

Beispiele:

Funktion: solange einer der Mischerpumpen läuft, soll auf eine Gruppenadresse für Heizungsanforderung eine 1 gegeben werden, läuft keine mehr, dann 0.
Simples Oder-Gatter:
Vier Gruppenadressen der Mischerpumpen am Eingang, am Ausgang die GA für die Kesselanforderung.
Pumpe 1 läuft, Pumpe 2 läuft, Rest der Pumpen ist aus, Ausgang ist 1, Pumpe 1 schaltet ab, Ausgang schaltet mit ab, obwohl die Pumpe 2 noch läuft.
Reproduzierbar: Alle Pumpen aus, Ausgang 0, Pumpe 1 an, Ausgang ist 1, Pumpe 2 an, Ausgang ist 1, Pumpe 2 aus, Ausgang ist 0.
Warum ist mir ein Rätsel. In der Simulation verhält es sich korrekt.

Ähnliches mit der Aussen-Beleuchtung, Oder-Verknüpfungen, an denen Bewegungsmelder hängen, geben 1 Signal über Wertetransformation 4Byte und dimmen Außenlampen hoch. Hochdimmen klappt, Ausschalten nicht. Weder über Treppenhausmodul noch über Ein-Ausschaltverzögerung, noch über zusätzlichen Watchdog auf die Schalt-GAs der Dimmer. Für mich sieht das im zweiten Fall so aus, als stürzt da intern was ab.

Manuell via ETS, knxd und/oder Bash-Skript klappt das alles hervorragend, nur nicht über den Gira L1. Es gibt keine Probleme, Werte von den GAs zu lesen oder zu schreiben.
Für mich ist das Teil irgendwie kaputt und verhält sich zudem anders als in der Doku beschrieben.

Bin gerade soweit, den Logik-Kram komplett in die UVR16x2 umzuziehen und das L1 zum Fenster raus zu werfen. Auf dem UVR laufen alle Logiken problemlos (und das sind viele) ohne solche seltsamen Dinger.

Es tauchen auch Fehlermeldung im logiclog vom L1 auf, die mir nichts sagen, außer dass es vom Entwickler als Fehler gesehen wird, dass keine Lizenz (für was auch??) bekommen wurde, weshalb es zu einem Crypto System Fehler kam, und Werte (aus der gleichen Linie) nicht abgefragt werden können, die manuell über knxd (andere Linie) aber problemlos funktionieren:

2020-05-04 19:49:57,965 [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":72931,"command":"GetL icenses","domain":"logic"}}' 2020-05-04 19:50:00,409 [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":72933,"command":"GetV alue","id":"150015"}}' 2020-05-04 19:50:02,648 [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":72938,"command":"GetV alue","id":"150004"}}' 2020-05-04 19:50:03,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:Bewegungsmelder240BMHofunterBalkon | request = '{"request":{"correlationId":72940,"command":"GetV alue","id":"150006"}}' 2020-05-04 19:50:04,033 [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":72942,"command":"GetV alue","id":"150028"}}' 2020-05-04 19:50:04,713 [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":72944,"command":"GetV alue","id":"150002"}}' 2020-05-04 19:50:05,803 [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":72948,"command":"GetV alue","id":"150025"}}' 2020-05-04 19:50:06,496 [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":72950,"command":"GetV alue","id":"150014"}}' 2020-05-04 19:50:07,254 [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":72952,"command":"GetV alue","id":"150018"}}' 2020-05-04 19:50:07,925 [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":72954,"command":"GetV alue","id":"150009"}}' 2020-05-04 19:50:08,586 [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":72956,"command":"GetV alue","id":"150029"}}' 2020-05-04 19:50:09,253 [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":72958,"command":"GetV alue","id":"150013"}}' 2020-05-04 19:50:09,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:Bewegungsmelder340BMKFCche | request = '{"request":{"correlationId":72960,"command":"GetV alue","id":"150022"}}' 2020-05-04 19:50:10,576 [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":72962,"command":"GetV alue","id":"150020"}}' 2020-05-04 19:50:11,244 [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:Pumpe128Werkstatt29 | request = '{"request":{"correlationId":72964,"command":"GetV alue","id":"150026"}}' 2020-05-04 19:50:11,905 [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:Pumpe228BFCro29 | request = '{"request":{"correlationId":72966,"command":"GetV alue","id":"150008"}}' 2020-05-04 19:50:12,566 [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:Pumpe328Scheune29 | request = '{"request":{"correlationId":72968,"command":"GetV alue","id":"150027"}}' 2020-05-04 19:50:13,230 [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:Pumpe428Wohnhaus29 | request = '{"request":{"correlationId":72970,"command":"GetV alue","id":"150003"}}' 2020-05-04 20:02:02,118 [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":73065,"command":"GetL icenses","domain":"logic"}}' 2020-05-04 20:02:04,443 [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":73067,"command":"GetV alue","id":"150015"}}' 2020-05-04 20:02:06,739 [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":73072,"command":"GetV alue","id":"150004"}}' 2020-05-04 20:02:07,444 [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":73074,"command":"GetV alue","id":"150006"}}' 2020-05-04 20:02:08,204 [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":73076,"command":"GetV alue","id":"150028"}}' 2020-05-04 20:02:08,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:Bewegungsmelder440BMHofunterBalkon | request = '{"request":{"correlationId":73078,"command":"GetV alue","id":"150002"}}' 2020-05-04 20:02:10,035 [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":73082,"command":"GetV alue","id":"150025"}}' 2020-05-04 20:02:10,716 [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":73084,"command":"GetV alue","id":"150014"}}' 2020-05-04 20:02:11,438 [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":73086,"command":"GetV alue","id":"150018"}}' 2020-05-04 20:02:12,095 [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":73088,"command":"GetV alue","id":"150009"}}' 2020-05-04 20:02:12,741 [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":73090,"command":"GetV alue","id":"150029"}}' 2020-05-04 20:02:13,409 [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":73092,"command":"GetV alue","id":"150013"}}' 2020-05-04 20:02:14,136 [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":73094,"command":"GetV alue","id":"150022"}}' 2020-05-04 20:02:14,805 [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":73096,"command":"GetV alue","id":"150020"}}' 2020-05-04 20:02:15,468 [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:Pumpe128Werkstatt29 | request = '{"request":{"correlationId":73098,"command":"GetV alue","id":"150026"}}' 2020-05-04 20:02:16,131 [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:Pumpe228BFCro29 | request = '{"request":{"correlationId":73100,"command":"GetV alue","id":"150008"}}' 2020-05-04 20:02:16,796 [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:Pumpe328Scheune29 | request = '{"request":{"correlationId":73102,"command":"GetV alue","id":"150027"}}' 2020-05-04 20:02:17,457 [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:Pumpe428Wohnhaus29 | request = '{"request":{"correlationId":73104,"command":"GetV alue","id":"150003"}}'

Hat jemand eine Idee, was hier die Ursache sein könnte, weshalb Basis-Funktionen nicht korrekt laufen?


Viele Grüße
Ralf

[jb1]

Sehr komisch. Wenn das in der Simulation klappt, sollte das auch auf dem L1 funktionieren, gerade mit solchen simplen Logikbausteinen wie Oder.

Der Ausgang vom Oder kann nur dann 0 sein, wenn alle Eingänge auf 0 stehen.

 public override void Execute()
{
  this.Output.Value = this.Inputs.Any(input => input.Value);
}

Kannst du einmal überprüfen, ob mindestens ein Datenpunkt von den Eingängen beim Oder-Baustein noch auf 1 steht? Das kannst du entweder im GPA im Datenpunktmonitor machen oder auf der Gerätewebseite vom L1 unter https://(ip-adresse):4433/discovery/logic/ direkt beim entsprechenden Baustein.
Auf der Webseite aktualisieren sich die Datenpunktwerte immer beim Aktualisieren der Seite, nicht automatisch.

Ich vermute nämlich, dass die Datenpunkte aus irgendeinem Grund wieder auf 0 zurück gesetzt werden. Vielleicht hast du die falschen Gruppenadressen bei den Datenpunkten eingetragen.


Zu dem Log:
Der Fehler mit GetLicenses und dem Error Code dabei bedeutet, dass das Gerätezertifikat zum Verifizieren der Lizenzen nicht geöffnet werden konnte... Das werde ich nochmal weiter untersuchen, bei meinem L1 Entwicklungsgerät hier hab ich das gleiche Meldung.
Heißt jedenfalls, dass du mit deinem L1 keine Logikbausteine, die eine Lizenz erfordern, benutzen kannst. Aber diese gibt es auch nur im Shop.

Die anderen GetValue Fehlermeldungen sind alles Fehler beim Lesen von KNX-Gruppenadress-Datenpunkten (ID-Bereich 150000 - 150300). Solche eine Meldung bekommst du, wenn eine Leseanfrage auf KNX rausgesendet wurde aber keiner geantwortet hat.


Und allgemein zum Log sind das Linux line endings (LF statt CR/LF), was im normalen Windows Editor als eine Zeile angezeigt wird.

[jb1]

Ich hab das mit dem Zertifikat mal weiter untersucht. Ich hab selbst eine recht altes damals noch LOMO (graues Gehäuse), was dann über Softwareupdates zum L1 wurde.
In dem Gerätezertifikat von dem Produktionsdatum fehlt das Gira Root CA, da ist nur das Gerätezertifikat selbst vorhanden.

Ich habe das mit einem aktuellen L1 (schwarzes Gehäuse) probiert, dort funktioniert das alles korrekt mit dem Abrufen der Lizenzen und das Root CA ist auch Teil vom Gerätezertifikat.

Ich gehe davon aus, dass der Gira Support dein Gerät austauschen würde, wenn du unbedingt lizenzbehaftete Logikbausteine benutzen möchtest.

[hyman]

Oder es hat gar nichts mit den Lizenzen zu tun.

Du schreibst der Ausgang des ODER-Gatters geht auf einen GA-Datenpunkt. Hört auf die entsprechende GA "draußen" überhaupt ein Kommunikationsobjekt? Wenn nicht, kommt auch keine Bestätigung vom Bus. Wenn es "unter Beobachtung" mit dem ETS-Gruppenmonitor tut (der dann auch bestätigt), dann wäre genau das meine Diagnose.

Wenn draußen nicht gebraucht, muss man Variablen-Datenpunkte nehmen. Hab ich auch auf die harte Tour gelernt...

[hubidoo]

Ich hab das mit dem Zertifikat mal weiter untersucht. Ich hab selbst eine recht altes damals noch LOMO (graues Gehäuse), was dann über Softwareupdates zum L1 wurde.
In dem Gerätezertifikat von dem Produktionsdatum fehlt das Gira Root CA, da ist nur das Gerätezertifikat selbst vorhanden.

Ich habe das mit einem aktuellen L1 (schwarzes Gehäuse) probiert, dort funktioniert das alles korrekt mit dem Abrufen der Lizenzen und das Root CA ist auch Teil vom Gerätezertifikat.

Ich gehe davon aus, dass der Gira Support dein Gerät austauschen würde, wenn du unbedingt lizenzbehaftete Logikbausteine benutzen möchtest.

Das ist ebenfalls ein graues Gehäuse.
Was mich dabei wundert: Weshalb fehlt das root CA nach Firmware-Update?
Das ein Fehler aus meiner Sicht.

[hubidoo]

Oder die Ausgänge der ODER-Gatter gehen zwar auf GA-Datenpunkte, auf die GAs hört aber "draußen" keiner, weshalb auch keine Bestätigung vom Bus kommt. Wenn es unter Beobachtung mit dem ETS-Gruppenmonitor tut, dann wäre das meine Diagnose. Wenn draußen nicht gebraucht, muss man Variablen-Datenpunkte nehmen...

Nein, das sind die GAs für die Pumpen, die auf dem Heizungsaktor terminiert sind. Jeder Raumtemperaturregler, der an dem jeweiligen Pumpenkreis hängt, fragt diese ab und zeigt das a) im Display an und b) als LED-Zustand rot/grün für an/aus.

[hubidoo]

Sehr komisch. Wenn das in der Simulation klappt, sollte das auch auf dem L1 funktionieren, gerade mit solchen simplen Logikbausteinen wie Oder.

Der Ausgang vom Oder kann nur dann 0 sein, wenn alle Eingänge auf 0 stehen.

 public override void Execute()
{
this.Output.Value = this.Inputs.Any(input => input.Value);
}

Kannst du einmal überprüfen, ob mindestens ein Datenpunkt von den Eingängen beim Oder-Baustein noch auf 1 steht? Das kannst du entweder im GPA im Datenpunktmonitor machen oder auf der Gerätewebseite vom L1 unter https://(ip-adresse):4433/discovery/logic/ direkt beim entsprechenden Baustein.
Auf der Webseite aktualisieren sich die Datenpunktwerte immer beim Aktualisieren der Seite, nicht automatisch.

Ich vermute nämlich, dass die Datenpunkte aus irgendeinem Grund wieder auf 0 zurück gesetzt werden. Vielleicht hast du die falschen Gruppenadressen bei den Datenpunkten eingetragen.


Zu dem Log:
Der Fehler mit GetLicenses und dem Error Code dabei bedeutet, dass das Gerätezertifikat zum Verifizieren der Lizenzen nicht geöffnet werden konnte... Das werde ich nochmal weiter untersuchen, bei meinem L1 Entwicklungsgerät hier hab ich das gleiche Meldung.
Heißt jedenfalls, dass du mit deinem L1 keine Logikbausteine, die eine Lizenz erfordern, benutzen kannst. Aber diese gibt es auch nur im Shop.

Die anderen GetValue Fehlermeldungen sind alles Fehler beim Lesen von KNX-Gruppenadress-Datenpunkten (ID-Bereich 150000 - 150300). Solche eine Meldung bekommst du, wenn eine Leseanfrage auf KNX rausgesendet wurde aber keiner geantwortet hat.


Und allgemein zum Log sind das Linux line endings (LF statt CR/LF), was im normalen Windows Editor als eine Zeile angezeigt wird.

Die Gruppenadressen passen. Ich habe das als erstes kontrolliert und den Zustand genauer untersucht. Via knxd sehe ich, dass die zweite Pumpe immer noch auf 1 steht. Die RTRs zeigen das ebenfalls so an.
Das Komische ist, dass alle Adressen in den Logs auftauchen, obwohl die gelesen werden können, z.B. taucht da auch der Binäreingang vom Brunnenwasserdruckschalter auf. Das funktioniert aber trotzdem, die Pumpe wird korrekt an- und ausgeschaltet.
Alle Adressen sind ganz normal abfragbar und es kommt eine ganz normale Anwort.

Zum Linefeed des logfiles:
Ich verwende Linux im Normalfall für daily doings, bei mir wird das korrekt angezeigt. Die Forensoftware geht scheinbar von DOS/Windows-Zeilenumbrüchen aus.

[hubidoo]

Das Oder-Gatter an sich funktioniert schon so, wie es sein soll.
Das Problem ist scheinbar, dass der L1 nach einer gewissen Zeit "vergisst", wie der Zustand des Eingangs ist.
Schalte ich die Pumpen an und aus, tauchen die auch wieder korrekt auf.
Bei der ersten Abfrage war nur Pumpe 1 auf true, obwohl beide liefen.
Ich sende aber nicht zyklisch, sondern nur für ein benötigtes Ereignis.
Die Frage ist, weshalb ist das so. Möglicherweise fragt der L1 beim Neustarten nach Änderungen die GAs nicht ab und wenn kein neues Event vorbei kam bleibt für den L1 der Eingang auf false?

Auswahl_001.png

[hyman]

Das Problem ist scheinbar, dass der L1 nach einer gewissen Zeit "vergisst", wie der Zustand des Eingangs ist.

Eigentlich nicht ... außer Du machst immer "nach einer gewissen Zeit" einen Neustart.

Wenn nicht alle Eingänge Werte haben (null ist nicht das GLeiche wie false!), gibt es auch keine Ausgabe (ebenfalls null). Man mag das bei einem Oder-Gatter bedauern, schließlich könnte auch ein true reichen, um auch den Ausgang true zu machen, aber so isses nu mal. Abhilfe: Alle Eingänge mit false vorbelegen, dann macht das erste true an irgend einem Eingang auch den Ausgang true. Solange allerdings gar kein Wert kommt, bleibt Dein Problem. Ich würde Werte von so essentieller Bedeutung einfach alle 30 min zyklisch senden...

Und ja,

Möglicherweise fragt der L1 beim Neustarten nach Änderungen die GAs nicht ab ...

genau so ist es, es sei denn Du trägst beim Eingang explizit ein "Beim Neustart lesen". Wenn Du das bei zu vielen Eingängen machst, erzeugst Du allerdings eine Menge Busverkehr...

... und wenn kein neues Event vorbei kam bleibt für den L1 der Eingang auf false?

Der Eingang bleibt nicht false, sondern undefiniert (null). Damit kommt auch kein Ausgabewert (null). Deine Kesselpumpe bleibt wo sie war (das kann auch an sein, wenn sie das zufällig beim Neustart gerade war).

[hubidoo]

Eigentlich nicht ... außer Du machst immer "nach einer gewissen Zeit" einen Neustart.

Wenn nicht alle Eingänge Werte haben (null ist nicht das GLeiche wie false!), gibt es auch keine Ausgabe (ebenfalls null). Man mag das bei einem Oder-Gatter bedauern, schließlich könnte auch ein true reichen, um auch den Ausgang true zu machen, aber so isses nu mal. Abhilfe: Alle Eingänge mit false vorbelegen, dann macht das erste true an irgend einem Eingang auch den Ausgang true. Solange allerdings gar kein Wert kommt, bleibt Dein Problem. Ich würde Werte von so essentieller Bedeutung einfach alle 30 min zyklisch senden...

Und ja,

genau so ist es, es sei denn Du trägst beim Eingang explizit ein "Beim Neustart lesen". Wenn Du das bei zu vielen Eingängen machst, erzeugst Du allerdings eine Menge Busverkehr...


Der Eingang bleibt nicht false, sondern undefiniert (null). Damit kommt auch kein Ausgabewert (null). Deine Kesselpumpe bleibt wo sie war (das kann auch an sein, wenn sie das zufällig beim Neustart gerade war).

Ich mache dann zwangsweise einen Neustart, wenn ich Änderungen vornehme, z.B. neue Logiken einbaue.
Dann ist der Eingang erst mal null, bis der Zustand bekannt ist, schon klar. Das Ergebnis ist aber dennoch komisch, da bei allen Eingängen per default das Flag "Lesen bei Gerätestart" gesetzt ist, was bei einer "Inbetriebnahme-Übertragung" wohl nicht der Fall zu sein scheint, wie man an "null" sieht.
Noch ein Bug? Ein Feature kann das nicht sein. Das ist einfach immer noch nicht zu 100% ausgegoren.

Zyklisches Senden ist wie pollen: nicht Smart, daher mache ich das nicht. Das muss so funktionieren, ansonsten bewegen wir uns rückwärts.

Jetzt zur Kesselpumpe: Das ist einfach eine Gruppenadresse, die via KNX-CAN-Anbindung an die Technische Alternative übergeben wird. Hier sieht die UVR bei "null", dass keine Anforderung besteht und schaltet die Kesselpumpe ab. Das ist ultrablöd, da dann der Vorlauf innerhalb kürzester Zeit auf Rücklaufniveau abfällt und dann wird es kalt.
Da das außer zyklisch senden nicht lösbar wäre, ziehe ich die Logiken zur UVR um, da klappt das wenigstens.

[hubidoo]

Ich hab das mit dem Zertifikat mal weiter untersucht. Ich hab selbst eine recht altes damals noch LOMO (graues Gehäuse), was dann über Softwareupdates zum L1 wurde.
In dem Gerätezertifikat von dem Produktionsdatum fehlt das Gira Root CA, da ist nur das Gerätezertifikat selbst vorhanden.

Ich habe das mit einem aktuellen L1 (schwarzes Gehäuse) probiert, dort funktioniert das alles korrekt mit dem Abrufen der Lizenzen und das Root CA ist auch Teil vom Gerätezertifikat.

Ich gehe davon aus, dass der Gira Support dein Gerät austauschen würde, wenn du unbedingt lizenzbehaftete Logikbausteine benutzen möchtest.

Nach Rücksprache mit Gira sieht es so aus, dass der Zertifikatsfehler nicht normal ist. Die anderen Probleme können ebenfalls damit zusammen hängen.
Man vermutet, dass das Firmware-Update unvollständig ausgerollt wurde, bzw. noch Reste aus der vorherigen Firmware vorhanden sind.
Gira sagte mir, dass der Weg nun so ist, dass zuerst ein Hardware-Werksreset durchgeführt werden muss, über Spannungsversorgung weg, Programmierknopf halten, Spannungsversorgung einschalten, warten bis LEDs ausgehen. Firmware-Downgrade auf 2.2.39, danach zurück auf 2.4.37. Danach sollten die Probleme weg sein.

Ist dem nicht so, werden sie mir einen neuen, schwarzen L1 im Austausch senden, egal wie alt das LOMO ist.
Daher würde ich das an deiner Stelle auch gleich mal testen.

[hyman]

Schon wieder sind mir Deine Schlussfolgerungen etwas zu schnell.

da bei allen Eingängen per default das Flag "Lesen bei Gerätestart" gesetzt ist, was bei einer "Inbetriebnahme-Übertragung" wohl nicht der Fall zu sein scheint, wie man an "null" sieht.

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?

Hier sieht die UVR bei "null", dass keine Anforderung besteht und schaltet die Kesselpumpe ab.

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...

[Gast1961]

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.

[hyman]

Was ist an dem Vorschlag, ein Gerät in unbekanntem Zustand erst mal auf einen Werks-Auslieferzustand zu bringen, vage?

[jb1]

Nach Rücksprache mit Gira sieht es so aus, dass der Zertifikatsfehler nicht normal ist. Die anderen Probleme können ebenfalls damit zusammen hängen.
Man vermutet, dass das Firmware-Update unvollständig ausgerollt wurde, bzw. noch Reste aus der vorherigen Firmware vorhanden sind.
Gira sagte mir, dass der Weg nun so ist, dass zuerst ein Hardware-Werksreset durchgeführt werden muss, über Spannungsversorgung weg, Programmierknopf halten, Spannungsversorgung einschalten, warten bis LEDs ausgehen. Firmware-Downgrade auf 2.2.39, danach zurück auf 2.4.37. Danach sollten die Probleme weg sein.

Ist dem nicht so, werden sie mir einen neuen, schwarzen L1 im Austausch senden, egal wie alt das LOMO ist.
Daher würde ich das an deiner Stelle auch gleich mal testen.

Ich kann dazu mehr sagen als der Support von Gira, denn ich hab den ganzen Zertifikatskrams für die LogicEngine programmiert :P

Deine Probleme haben nichts mit Zertifikaten zu tun. Dies würde nur Probleme machen, wenn du Logikbausteine benutzt, die eine Lizenz benötigen. In diesem Fall würde aber der GPA Download abgelehnt werden.

Und ein Upgrade/Downgrade wird da auch nicht helfen, da das Gerätezertifikat bei der Produktion auf das Gerät kommt und danach nie wieder angefasst wird.
Früher bei den grauen LOMOs (ich kann dir nicht genau sagen, bis zu welchem Zeitpunkt) hat dort bei der Kommissionierung das .p12 Zertifikat scheinbar nicht das Root CA enthalten sondern nur das Cert und den Private key. Auf aktuellen Geräten ist auch das CA mit drin.


Wenn du in der ETS den Gruppenmonitor startest, siehst du dann nach einem GPA-Download die Leseanfragen vom L1 auf die Gruppenadressen der Pumpen?