Gira X1

[hyman]

Ich schrieb ja schon (mit Bild), dass die Web-Oberfläche erst ewig am Rad dreht und dann irgendwann sagt, der X1 sei nicht erreichbar. Obwohl natürlich alles andere außer dieser neumodischen Bug-Oberfläche tut.

Genau genommen ist das Mono unter der Logikengine weg, wie die Fehlermeldung sagt. Ich hab das gelegentlich schon daran sehen können, dass meine Heizungregelung die maximale Vorlauftemperatur plötzlich springen lässt. Die wird von einer 6h-Durchschnittstemperatur abgeleitet, die dann wohl ihre Vorgeschichte vergisst:

SprüngeDurchNeustart.png

Gemeint sind die Sprünge um kurz vor 8:00 und kurz nach 9:00 Uhr. Passiert immer nur, wenn ich das neue Webinterface benutze. (Die Ausschaltung kurz nach 15:30 und Wiedereinschaltung kurz nach 22:30 Uhr ist so gewollt.)

Erde an Gira: Bitte baut Eure neue Web-Oberfläche so, dass sie auch tut. Und entkoppelt sie so von der Logikengine, dass sie nicht alles mit in den Abgrund reißen kann. Und packt nicht alle Logikblätter auf eine Seite sondern gebt mir für jedes Blatt eine eigene Seite. Oder noch besser: Zeigt den Zustand direkt in den Logikblättern im GPA an.

Und wenn Ihr das alles nicht tut, dann lasst bitte, bitte die alte Weboberfläche drin. Die ist zwar auch gruselig, aber tut wenigstens stabil.

Grüße von Horst

[EinBjoern]

Sieht man den Absturz auch in der Weboberfläche, oder ist nur die Logikengine weg?

[hyman]

Mit der Firmware 2.5.353.0 hat Gira das Webinterface komplett umgestellt.

Nachtrag dazu. Anscheinend ist das neue Webinterface auch für Out-of-Memory-Exceptions zuständig, die zum Neustart der Logikengine führen. Auszug aus dem Logfile:

2020-05-23 08:43:42.460 | Warning | mono: {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:42.488 | Warning | mono: Unhandled Exception: {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:42.488 | Warning | mono: OutOfMemoryException {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.778 | Warning | mono: [ERROR] FATAL UNHANDLED EXCEPTION: System.OutOfMemoryException: Out of memory {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.813 | Warning | mono: at (wrapper managed-to-native) object:__icall_wr {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.820 | Warning | mono: apper_mono_gc_alloc_vector (intptr,intptr,intptr) {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.820 | Warning | mono: at (wrapper alloc) object:AllocVector (intptr,intptr) {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.820 | Warning | mono: at System.Collection {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.855 | Warning | mono: s.Generic.List`1[System.Byte].set_Capacity (Int32 value) [0x00000] in <filename unknown>:0 {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.855 | Warning | mono: at System.Collections.Generic.List {operator()} [ProcessRunner.cpp (76)] 2020-05-23 08:43:43.855 | Warning | mono: `1[System.Byte].EnsureCapacity (Int32 min) [0x00000] in <filename unknown>:0 {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.855 | Warning | mono: at System.Collections.Generic.List`1[System.Byte {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.856 | Warning | mono: ].Insert (Int32 index, Byte item) [0x00000] in <filename unknown>:0 {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.856 | Warning | mono: at System.Collections.Generic.List`1[System.Byte].InsertR {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.856 | Warning | mono: ange (Int32 index, IEnumerable`1 collection) [0x00000] in <filename unknown>:0 {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.856 | Warning | mono: at System.Collections.Generic.List`1[System.By {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.856 | Warning | mono: te].AddRange (IEnumerable`1 collection) [0x00000] in <filename unknown>:0 {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.856 | Warning | mono: at Fleck.WebSocketConnection+<>c__DisplayClass70_0. {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.857 | Warning | mono: <StartReceiving>b__0 () [0x00000] in <filename unknown>:0 {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.857 | Warning | mono: at System.Threading.Thread.StartInternal () [0x00000] in <filename {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.857 | Warning | mono: unknown>:0 {operator()} [ProcessRunner.cpp (76)]
2020-05-23 08:43:43.857 | Error | Process mono died with exit code 1 {operator()} [ProcessRunner.cpp (372)]

Bis auf Weiteres kann man das neue Interface also wohl in der Pfeife rauchen und verwendet besser das Alte unter https://<ip-adresse>:4433/discovery/presentation/

Grüße von Horst

[hyman]

Ja, das habe ich inzwischen dank Robby auch begriffen. Zähler und Grundrechenart -- beides Logikbausteine aus dem Gira-Arsenal -- sollten dafür reichen, oder nicht?

Außer natürlich, Du willst so was wie Regenmenge in der letzten Stunde, Tag, Woche, ... also "rolling", dann hilft Dir ein einzelner Zähler nicht mehr. Das Thema hatten wir neulich schon mal in unterschiedlichen Variationen ... keine von denen finde ich aber so richtig passend.

Vielleicht einfach zwei Zähler, von denen einer die Impuls-Telegramme mit einer Verzögerung von einer Stunde, einem Tag oder einer Woche bekommt. Die Differenz der beiden Zählerstände wäre dann der gesuchte Zählerzuwachs für den entsprechenden Zeitraum. Oder man überlässt das alles doch einem Hager TXE771 (1 Kanal) bzw. TXE773 (3 Kanäle)...

[KLT16a]

Ich bin selbst noch nicht sehr fit, vielleicht liegt es daran, aber... ich verstehe Deine Frage nicht. Eine Tasterschnittstelle kann noch nur 0/1 (an/aus, offen/geschlossen etc.) liefern. Wie willst Du denn da eine Regenmesser auslesen oder was soll da dann eine Formel berechnen? Aber vielleicht stehe ich auch nur auf dem Schlauch und Du kennst es mir erklären, bzw. die Frage klarer formulieren?

Hallo,

ich muss doch zählen und rechnen können wie oft der Regenmesser sich auskippt und dieser Wert in der Stunde bzw. pro Tag um dann sagen zu können wieviel Regen ist gefallen.

[hyman]

Ahsoja, dann macht das auf einmal Sinn: Jede 1, die vorbei kommt, sind dann soundso viele mm Regenmenge. Das kann man mit einem Zähler machen. Dessen Zählerstand dann mit der Impulswertigkeit multiplizieren. Würd ich immer noch ohne Formelberechnung machen ...

[Robby]

Geht mir genau so. Klar kann man einen Regenmesser mit an/aus auslesen, mehr liefern die Regenmesser in den nativen KNX-Wetterstationen letztlich auch nicht. Aber wozu man da eine Formell braucht ...

Er meint wohl einen Regenmesser mit Wippe der die Regenmenge misst.

[hyman]

ich verstehe Deine Frage nicht. Eine Tasterschnittstelle kann noch nur 0/1 (an/aus, offen/geschlossen etc.) liefern. Wie willst Du denn da eine Regenmesser auslesen oder was soll da dann eine Formel berechnen?

Geht mir genau so. Klar kann man einen Regenmesser mit an/aus auslesen, mehr liefern die Regenmesser in den nativen KNX-Wetterstationen letztlich auch nicht. Aber wozu man da eine Formel braucht ...

[alorenzen]

Ausführen:
Wenn auf diesen Datenpunkt eine Szenennummer geschrieben wird, wird diese Szene ausgeführt.

Edit:
Kurz gesagt heißt das für dich, dass du zum externen Ansteuern der Schaltzeituhr die Szenennummer auf den Ausführen Datenpunkt schreiben musst

So - mir ist eine einfache Umsetzung der Feiertagsfunktion eingefallen.
Ich scheitere aber schon an den Basics, nämlich dem Ausführen der Zeitschaltuhr von extern.
Erstmal einfachster Aufbau. Es soll extern EINE GA mit entsprechender Szenennr. auf die entsprechende Zeitschaltuhr des X1 gesendet werden, also genau ein Schaltindex auf einer Zeitschaltuhr ausführen, mehr nicht. Aber ich kriege die Zeitschaltuhr nicht zum Ausführen des entsprechenden Index.

1. Die ersten 10 Zeitschaltuhren sind in der ETS aktiviert.
2. Auf der entsprechend Zeitschaltuhr ist eine GA auf dem KO "Index der Schaltuhr" zugewiesen. Flag Schreiben auf der dem sendenden KO ist aktiviert, Lesen auf X1 Seite
3. DPT ist 17.001
4. Der Gruppenmonitor zeigt die GA mit dem erwarteten Wert für die Szenennr. auf dem Bus


Aber der X1 tut nix. Ich habe extra eine existierende Zeitschaltuhr benutzt, die definitiv funktioniert. Ich habe auf dem Gerätedatenpunkt für die Zeitschaltuhr mit und ohne KNX-Integration versucht. Wie gesagt wird die GA mit korrektem Inhalt auf den Bus gesendet.
Was mach ich falsch?

Bildschirmfoto 2020-05-22 um 14.10.52.png
Bildschirmfoto 2020-05-22 um 14.14.03.png
Bildschirmfoto 2020-05-22 um 14.13.07.png
Bildschirmfoto 2020-05-22 um 14.12.11.png

[martiko]

Hallo,

ich benötige mal wieder Hilfe. Ich möchte einen Regenmesser mittels einer Tasterschnittstelle auslesen. Gibt es bereits fertige Formeln für den X1 oder wenigstens Lösungsansätze?

Ich bin selbst noch nicht sehr fit, vielleicht liegt es daran, aber... ich verstehe Deine Frage nicht. Eine Tasterschnittstelle kann noch nur 0/1 (an/aus, offen/geschlossen etc.) liefern. Wie willst Du denn da eine Regenmesser auslesen oder was soll da dann eine Formel berechnen? Aber vielleicht stehe ich auch nur auf dem Schlauch und Du kennst es mir erklären, bzw. die Frage klarer formulieren?

[KLT16a]

Hallo,

ich benötige mal wieder Hilfe. Ich möchte einen Regenmesser mittels einer Tasterschnittstelle auslesen. Gibt es bereits fertige Formeln für den X1 oder wenigstens Lösungsansätze?

Danke schon mal.

[KLT16a]

Prüfe mal folgendes:

• "Typ des Ausgangs" bei beiden Ausgängen der Formelberechnung auf NUMBER eingestellt?
• Typ des Datenpunkts "gefühlte Temperatur" ist Dezimalzahl?

Wenn das beides stimmt, dann nimm mal die Verbindung zwischen Formelberechnung und Ausgang weg und zieh die neu.

Grüße von Horst

Hallo Horst,

jetzt funkioniert es. Danke noch einmal.

[martiko]

alorenzen
Sowas in der Art würde ich mir auch sehr wünschen und zwar für unterschiedlicheste Anwendungen. Sei es wie Du vorgeschlagen hast anhand von Feiertage etc. (die über KNX als Status kommen) aktiv oder inaktiv zu setzen, könnte man damit auch sehr leicht eine Option "Manuell" einbauen, die Pauschalt alle Zeitschaltuhren deaktiviert etc...
Generell sind die Zeitschaltuhren, die über App (bzw. G1) konfiguriert werden können zwar schon echt gut... aber mit ein bisschen mehr KNX-Integration könnte man diese noch viel flexibler gestalten.

[alorenzen]

Na ja, die Zeitschaltuhr einfach mal die Option Aktiv/Inaktiv zu geben, wäre jetzt nicht kompliziert nutzbar.
Lieber mal so Kleinigkeiten sukzessive pflegen, als die große Lösung, die dann erst kommt, wenn sich das Ding überlebt hat.

Mir ist übrigens eine für Gira noch einfacher umzusetzende Variante eingefallen. Wenn man die Gültigkeit und den zugehörigen Wert als Gerätedatenpunkte zur Verfügung stellen würde, müsste Gira überhaupt nix in der Logik ändern, sondern nur diese Variablen beschreibbar machen. Damit kann man dann einfach unterschiedliche Uhren für Wochentags und Feier-/Sonn-/Samstags nehmen. Aber die Logik und der Aufwand würde unendlich viel einfacher. Keine doppelten Variablen.
In der Logik müsste nur um 0:00 Uhr ein Vergleicher auf So/Sa/Feiertag(Feiertag von extern oder Excel Kalender) gemacht werden und dann das Gültigkeitsdatum "von" entsprechend verschoben werden.

[hyman]

Mit der Firmware 2.5.353.0 hat Gira das Webinterface komplett umgestellt. Leider bekomme ich jetzt ziemlich häufig minutenlang das drehende Rad:

X1DrehtAmRad.png

gefolgt von der Meldung das Gerät sei nicht erreichbar. Die Webseite selber lädt recht schnell, der X1 reagiert auf ping innerhalb von weniger als 10ms, die App funktioniert, ich sehe aktualisierte Daten im Datenpunktmonitor. Auch das alte Webinterface (das Gira dankenswerterweise unter https://<ip-adresse>:4433/discovery/presentation/ weiterhin anbietet) funktioniert problemlos. Also ist "das Gerät" natürlich erreichbar, nur wahrscheinlich nicht der Service, den das neue Webinterface gern benutzen würde.

Hat einer von Euch schon das Gleiche beobachtet?

Grüße von Horst