Gira X1

[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]

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

[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]

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

[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

[EinBjoern]

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

[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

[martiko]

hyman
Hast Du den (Riesen-)Fehler schon direkt bei Gira gemeldet? Ich bin nicht sicher, wie aktiv die hier mitlesen...

inhaltlich stimme ich Dir absolut zu!

[intelligente Haustechnik]

Ich bin nicht sicher, wie aktiv die hier mitlesen...

Keine Sorge, da liest nicht nur einer mit...

[jb1]

Bitte mal den Ball flach halten...

Ich frage mich, wie du zu einem out of memory auf dem X1 gekommen bist. Du wirst vermutlich irgendwelche eigenen Logikbausteine oder welche von Drittanbietern haben, die ein Speicherleck haben.

Eine Übersicht zum aktuellen Speicherverbrauch auf dem X1 kannst du dir auf der neuen oder alten Webseite angucken (Diagnose -> Prozesse bzw. "view more information" -> System Overview).

Die neue genau wie die alte Webseite macht nur beim Aufruf der Unterseite für die Logik einen API Aufruf an die LogicEngine, um eine Übersicht der geladenen Bausteine/Blätter und deren Werte zu bekommen.

Ich kann hier bei der neuen Webseite allerdings feststellen, dass scheinbar ein Timeout beim Abrufen des Logik-Status fehlt. Wenn ich den mono Prozess manuell beende und gleichzeitig den Status abrufe, geht der Abruf wie erwartet ins Leere.
Daraufhin startet wie erwartet die LogicEngine automatisch neu, die Webservice-API der neue Webseite wartet aber immer noch und blockiert somit die Webseite.
Diesen Fehler werde ich mal eintragen.

[hyman]

Ja, ich habe natürlich haufenweise

eigenen Logikbausteine oder welche von Drittanbietern

in meinem Projekt.

Aber die laufen seit Monaten stabil. Und wie ich schon schrieb: Das Problem ...

Passiert immer nur, wenn ich das neue Webinterface benutze.

Wenn es also mit den Fremdbausteinen zu tun hat, muss es irgend was geben, was das neue Web-Interface mit denen anders macht als das alte.

Und warum weigert sich das neue Webinterface, mir auch nur den Login-Screen zu zeigen, während alles andere übers Netzwerk (ping, altes Web-Interface, Datenpunkt-Monitor) gleichzeitig tut?

[jb1]

Wenn es also mit den Fremdbausteinen zu tun hat, muss es irgend was geben, was das neue Web-Interface mit denen anders macht als das alte.

Kommst du denn auch in diesen Zustand, wenn du nicht die Logik-Seite öffnest, sondern nur die normale Seite? Denn so wie ich das sehe, sollte das nur passieren, wenn du die Logikseite öffnest und beim Sammeln der Logikdaten der Prozess durch ein out-of-memory sich beendet.

Und warum weigert sich das neue Webinterface, mir auch nur den Login-Screen zu zeigen, während alles andere übers Netzwerk (ping, altes Web-Interface, Datenpunkt-Monitor) gleichzeitig tut?

Die neue Webseite macht über JavaScript Anfragen an die interne Webservice-API. Beim Aufruf der Logikseite macht diese API dann wiederum einen Aufruf an die LogicEngine, um die Logik-Informationen zu bekommen. Diese Anfrage ist jedoch exakt die gleiche auf der alten Webseite.
Hier ist nur der Unterschied, dass für die alte Webseite das HTML der kompletten Seite immer selbst zusammengebaut wird, bei neuen Webseite dies aber dynamisch über API Aufrufe nachgeladen wird.

Da hier der Webservice ja scheinbar beim Abrufen der Logikinformationen blockierend in einer Endlosschleife stecken bleibt, können auch keine anderen Unterseiten mehr aufgerufen werden.


Aber da ja der gleiche API Aufruf zum Sammeln der Logikinformationen gemacht wird, sollte ebenfalls bei der Verwendung der alten Webseite noch manchmal der mono-Prozess abstürzen. Da der Prozess aber automatisch wieder neu gestartet wirst, bekommst du davon nur vielleicht nichts mit.

[jb1]

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?

Die KOs der Zeitschaltuhren in der ETS kann man nicht beschreiben. Über diese KOs wird nur ein Wert rausgesendet, wenn die Uhr ausgelöst hat (Ausgelöst) und welche Schaltzeit augelöst wurde (Index der Schaltzeit).

Zum manuellen Auslösen musst du auf den Ausführen Datenpunkt schreiben, den du schon im Bild markiert hast.
Zum einfachen Testen kannst du auch einfach mal über den GPA Datenpunktmonitor die Szenennummer auf den Datenpunkt schreiben.

Wenn du dies in der Logik oder über eine Visu-Funktion machen möchtest, kannst du dort einfach diesen Datenpunkt auswählen.
Wenn du das aber über KNX machen möchtest, musst du die KNX-Integration für diesen Datenpunkt aktivieren. Bei "Senden" kommt die Gruppenadresse rein, auf die von außen die Szenennummer geschrieben wird. Status/Rückmeldung kannst du verbinden, musst du aber nicht.

x1-timer-1.png
x1-timer-2.png
x1-timer-3.png

[alorenzen]

Die KOs der Zeitschaltuhren in der ETS kann man nicht beschreiben. Über diese KOs wird nur ein Wert rausgesendet, wenn die Uhr ausgelöst hat (Ausgelöst) und welche Schaltzeit augelöst wurde (Index der Schaltzeit).

Danke, das konnte ich leider am Wochenende auch schon eruieren. Schönere wäre es natürlich, wenn dieser sich wie "Ausführen" verhalten würde. Das würde das Ganze einfach besser lesbar machen, als die versteckete "KNX Integration"

Zum manuellen Auslösen musst du auf den Ausführen Datenpunkt schreiben, den du schon im Bild markiert hast.
Zum einfachen Testen kannst du auch einfach mal über den GPA Datenpunktmonitor die Szenennummer auf den Datenpunkt schreiben.

Auch das konnte ich am Wochenende zum Laufen bringen, hatte ich noch eine Fehler drin. Funzt.

[alorenzen]

Ich habe dann noch mal etwas Gehirnschmalz inverstiert um eine "Feiertags"-Lösung OHNE Logik und OHNE komplette Dopplung der DPs umzusetzen.
Sowas finde ich immer extrem unübersichtlich, schlecht lesbar und nach ner Weile hat man wieder vergessen, wie es funktioniert.
Traurig/enttäuschend, dass sowas im X1 nicht direkt mit drin ist. So ist die Basis der Lösung eine MDT Bedienzentrale, die eigentlich ausschließlich für diesen Zweck angschafft wurde.
Die eigentliche Steuerung, die eigentlichen Zeitschaltuhren sind auf dem X1. Die sind einfach viel eleganter, da ich nicht mit Szenen arbeiten muss und nicht bei den Aktoren auf die Funktionen angewiesen bin, die die Hersteller für Szenen vorgesehen haben. Ich kann direkt in der Zeitschaltuhr sehen, was und wo angesteuert wird und muss dann nicht noch auf den Aktor gehen.
Um das Ganze übersichtlich zu gestalten, bin ich von funktions-orientierten Zeitschaltuhren zu ereignisorientierten Zeitschaltuhren gewechselt.
Vorher hatte ich Zeitschaltuhren für beispielsweise Kaffeemaschine, Bachlauf, etc.
Jetzt gibt es nur noch 6 Zeitschaltuhren:

Zeitschaltuhr Wochentags EIN (extern angesteuert)
Zeitschaltuhr Wochentags AUS (extern angesteuert)
Zeitschaltuhr Wochenende EIN (extern angesteuert)
Zeitschaltuhr Wochenende AUS (extern angesteuert)
Alle Tage EIN
Alle Tage AUS

Logischerweise brauchen nun die Zeitschaltuhren alle DPs die angesteuert werden müssen. Das ist praktisch kein Problem, da hier ja 50 erlaubt sind, es macht es eher im Gegenteil etwas unübersichtlicher, da alle DPs immer über alle Schaltzeiten mitgeschleppt werden.
Wenn die Schaltzeiten einer Uhr nicht ausreichen, muss man dann halt noch mehr Uhren anlegen.
Für mich reicht das problemlos. Wochentags EIN hat bei mir nur 4 Schaltzeiten 06:00, 06:30, 07:00, 15:00.

Tip 1 - Wenn man mit der MDT BZ arbeitet, sollte man das Ganze auf 6 Schaltzeiten begrenzen, da die BZ nur 6 Zeiten bei einer Schaltuhr kann.

Tip 2 - Wenn hier jemand sowas wie "Sonnenaufgang" vermisst - das sind überlicherweise Schaltzeiten die nicht zwischen Wochentag und -ende unterschieden werden müssen. Deswegen die Uhren "Alle Tage" ohne externe Ansteuerung.

Das externe Ausführen der Zeitschaltuhr geschieht über den Geräte-DP der jeweiligen Schaltuhr. Auch hier 2 Tips:

Tip 3 - Startet die Benennung der Zeitschaltuhren mit "Zeitschaltuhr". Die Geräte-DPs haben keine Struktur sondern sind eine einfach Liste. So sind sie leichter wiederzufinden.

Tip 4 - Richtet die einzelnen Schaltzeiten so ein, als ob sie wirklich so aufgeführt würden. Dies ist eigentlich nicht notwendig, da nur der externe "Ausführen" DP greift. Es hält das Ganze aber besser lesbar.

Der Einzige kleine Trick ist jetzt den Wert "Gültigkeit von" auf ein Datum weit in der Zukunft zu setzen. Ich habe beispielsweise 2050 gewählt. Sprich die Schaltzeituhr wird nie ausgeführt.
Für alle angelegten Zeitschaltuhren findet man nun in den Datenpunkten unter Geräte-Datenpunkte jeweils 5 Einträge. Wir brauchen nur "Ausführen". Hier die "KNX Integration" aktivieren und unter "Senden" eine hierfür angelegte GA aus der ETS eintragen. Das Ganze funktioniert jetzt wie eine Szene. Der in der GA übertragene Wert muss der auszuführenden Schaltzeit entsprechen. in meinem Beispiel:

(1) 06:00
(2) 06:30
(3) 07:00
(4) 15:00

Entsprechend ist die Konfig in der MDT Bedienzentrale nun extrem einfach. Jeweils eine Zeitschaltuhr anlegen. Typ "Wert senden" "Szene". In der Tabelle die Wochentage markieren, die entsprechend Ausführzeit eintragen und als Szenennr. den passenden Zeitschaltindex.
Hier gibt es nun einen kleinen Trick. Die Feiertag-Steuerung bei der MDT BZ erfolgt nach dem Motto "wie Sonntag" und das Ganze funktioniert nur innerhalb einer Zeitschaltuhr. Damit also im Feiertagsfall eine "Sonntags" Zeit geschaltet würde, müsste eine solche auch vorhanden sein.
Ist aber kein Problem. Man aktiviert die Feiertagsbehandlung sowohl für die Uhren "Wochentags", wie Wochenende. Die Wochentags hat keinen Sonntag, was im Feiertagsfall einer Deaktivierung entspricht. Die "Wochenende" ist dann im Feiertagsfall aktiv, egal, dass gar keine Wochentag-Einstellung vorhanden ist.
Somit gelten die Zeiten der MDT BZ, die dann im Prinzip eine Szene aufführen, die einer Schaltzeit im X1 entspricht. Es gelten also nur die Zeiten der BZ.

Hier mal eine großes Lob an die MDT Leute. Wie gut/einfach die Konfig in der ETS umgesetzt wurde. Und auch wie umfangreich die Feiertagsfunktion umgesetzt wurde.
Die hört nämlich bei weitem nicht bei dem einfachen Datenbankabgleich auf:

- man kann in die Datenbank eigene "Feiertage" eintragen, wie z.B. Brückentage
- Man kann einzelne Tage durch Aktivierung des "Feiertag" Schalters am Vortag aktvieren. Sowohl an der MDT BZ selbst, aber auch von Extern. Spricht man kann es auch auf einen beliebigen andern Schalter legen. Also z.B. Auch für nen Brückentag, wenn man keine Lust hat in fest einzutragen, einfach am Vorabend aktvieren..
- Es gibt noch on Top eine Urlaubsfunktion.

Mir fällt zur Zeit keine Lösung mit geringerem Aufwand ein für/mit X1 ein. Hier dann auch ein Lob an die Gira Mitarbeiter für den grundsätzlich tollen X1 und viel Verständnis dafür, dass die Armen offensichtlich alle Feiertage durcharbeiten.