- √ - Werte auslesen gelegentlich nicht möglich

[gerksy]

Hallo zusammen,

lese hier schon eine ganze Weile mit und habe es endlich geschafft mich zu registrieren.

Kurze Vorstellung: Ich bin 31 Jahre alt, selbständiger Fachinformatiker der Fachrichtung Systemintegration aus Pforzheim und irgendwie in ein KNX Projekt geschlittert.

Es handelt sich um ein EFH. Die Programmierung wurde/wird von einem Elektrobetrieb vorgenommen. Ich richte on top quasi die Visualisierung für iPad / iPhone ein und kümmere mich um das IT Netzwerk.

Aufgrund diverser Ungereimtheiten habe ich vor kurzem ein Munin aufgesetzt um Werte auszulesen und grafisch aufzubereiten. Das wird mittels einem Cronjob erledigt der alle 5 Minuten mittels groupreadresponse Adressen ausliest. Ich sammle 75 Datenpunkte ein und warte zwischen jedem Request eine Sekunde um den Bus nicht zuzuballern.

Gelegentlich kommt es aber vor, dass groupreadresponse in einen 10 Sekunden Timeout läuft und die Abfrage abbricht (?). In der Munin Grafik erscheint dann ein 0-Wert, sprich die Kurve hat einen Einschnitt. Prinzipiell könnte ich das programmatisch abfangen und den Wert erneut versuchen auszulesen aber ich möchte eigentlich das das zuverlässig funktioniert?

Anbei ein paar betroffene Munin Grafiken die das ganze veranschaulichen. Jemand eine Idee woran das liegen kann oder wie ich am besten vorgehen kann um die Nummer zu debuggen? ETS4 ist vorhanden, allerdings habe ich eine nicht aktuelle Projektdatei im ETS3 Format.

Zur Umgebung:
Virtueller debian 7.4 auf ESX 5.5 Server mit eibd daemon (/usr/bin/eibd -D -T -S -i ipt:192.168.1.90). Im Hintergrund läuft ein groupsocketlisten (sh -c groupsocketlisten ip:127.0.0.1 2>&1) der den KNX Bus abhört und auf diverse Eingaben von Raumcontrollern reagiert (z.B. Musiksteuerung). Der KNX Bus selbst hat eine Last von ca 1,2 Telegrammen pro Sekunde.

Besten Dank und Grüße
Göks

[MarkusS]

Das Problem wandert, d.h. betrifft offensichtlich mehrere Gruppenadressen.

Sind die alle vom gleichen Typ (Temperatur)?

Betrifft das alles Geräte vom gleichen Typ?

RTRs senden die Temperatur normalerweise zyklisch und bei Änderung - kommen diese Telegramme regelmäßig?

Betrifft das immer eine Gruppenadressen zur Zeit oder laufen da wenn es passiert mehrere nacheinander in den Timeout?

Eine Linie, mehrere Linien, Aufbau?

ETS3-Projekt in ETS4 ist kein Problem, aus Sicht vom Busmonitor wäre das schon mal interessant, die Diagnose funktioniert auch mit einem leeren Projekt, ist dann halt nicht ganz so schön. Allerdings ist die ETS ein relativ grober Keil, da sieht man nur das was schön bzw. innerhalb der Spec ist, für die richtig ekligen Sachen braucht man andere Tools.

[gerksy]

Hallo Markus,

besten Dank für deine Antwort. Ich werde mal versuchen deine Fragen zu beantworten. Bin leider daheim am Mac und kann nur bedingt recherchieren.

Sind die alle vom gleichen Typ (Temperatur)?

Bei der Temperatur fällt es besonders auf. Die Wetterstation frage ich nach Helligkeit ab, dort konnte ich keine Unregelmäßigkeit feststellen. Bei den anderen Graphen kann man es nicht nachvollziehen da hier 0-Werte durchaus vorkommen können. (Regen, Wind, Tür- und Fensterkontakte).

Betrifft das alles Geräte vom gleichen Typ?

Bei der Temperatur handelt es sich bei allen prinzipiell um JUNG Raumcontroller vom gleichen Typ.

RTRs senden die Temperatur normalerweise zyklisch und bei Änderung - kommen diese Telegramme regelmäßig?

Kann ich leider nicht abschätzen. Temperaturen gehen gelegentlich über den Bus. Es sind aber so viele Raumcontroller involviert, dass ich nicht abschätzen kann wenn eins mal nicht senden sollte.

Betrifft das immer eine Gruppenadressen zur Zeit oder laufen da wenn es passiert mehrere nacheinander in den Timeout?

Ich habe die Graphen vergleichen und in der Regel ist es nur eine Gruppenadresse zum selben Zeitpunkt. Ich warte zwischen den Abfragen aber auch immer eine Sekunde um das ganze etwas zu entzerren.

Eine Linie, mehrere Linien, Aufbau?

Sehr gute Frage. Ich meine es sind 3 Linien. Müsste ich aber einmal im ETS am Rechner im Büro nachschauen.

Heute waren bis jetzt 8 verschiedene Gruppenadressen betroffen.
4 im EG und 4 im OG welches definitiv eine andere Linie sein müsste.

Antworten zu den Gruppenadressen kommen laut meinem Debug-Log von folgenden Geräten.

EG 1.6.1 1.6.4 1.6.26 1.6.40
OG 1.3.20 1.3.35 1.3.29

Irgendwas zuckt da doch

Grüße
Göks

[Christoph]

einfach gefragt:
lese flag bei den GA gesetzt?

[gerksy]

einfach gefragt:
lese flag bei den GA gesetzt?

Hi Christoph,
yepp klaro. Siehe auch meine Anhänge. Überwiegend funktioniert ja alles recht gut - nur gelegentlich zuckts.

Grüße

[Christoph]

sehe nix

wo sin die flags an den Komponenten ?
aus der Grafik nix zu sehen

wie sind die einzelne RTR`s programmiert ?
Zyklisch senden 30 s dann abfrage 91 s
funktioniert ohne lese flags

[gerksy]

Oh gerade noch etwas entdeckt.

In der eibd Doku (https://www.auto.tuwien.ac.at/~mkoeg...kdoc-0.0.5.pdf) auf Seite 165

groupreadresponses Send a group read telegram to a group address and display all response messages received within one second.

Eine Sekunde erscheint mir doch etwas wenig - wäre ja prinzipiell möglich, dass die Raumcontroller gelegentlich etwas länger benötigen? Eventuell auch wegen Verkehr auf dem Bus oder einfach nur beschäftigt mit irgendwelchen Dingen?

Werde den Bus einmal mitschneiden und wenn das erneut auftaucht die Zeiten vergleichen. Melde mich dann erneut.

sehe nix

wo sin die flags an den Komponenten ?
aus der Grafik nix zu sehen

wie sind die einzelne RTR`s programmiert ?
Zyklisch senden 30 s dann abfrage 91 s
funktioniert ohne lese flags

Anhand vom Beispiel der zweiten Grafik "EG Atrium". Wenn du dir die IST Kurve anschaust siehst du, dass ich 24 Stunden lang die Temperatur mehrmals auslesen konnte und ca. 6x nicht. Wenn die Gruppenadresse nicht mit dem L-Flag versehen wäre, dann wäre die IST Kurve recht flach.

Programmierung ist meine ich wie folgt:
Zyklisch senden alle 10 Minuten und senden bei Werteänderung (1K)

Grüße

[MarkusS]

Zyklisches senden der Temperatur alle 10 Minuten ist OK, bei mir steht das auf 15 Minuten und niemand muss frieren. Senden bei Temperaturänderung 1 K ist allerdings ziemlich grob, da würde ich 0.1-0.2 K erwarten.

Gibt es einen besonderen Grund warum Du auf dem Bus die Temperaturen zusätzlich auch noch pollst? Wenn die sowieso alle 10 Minuten gesendet werden kannst Du doch genau diesen Wert alle 10 Minuten ins Archiv schreiben und daraus die Diagramme generieren?

[JuMi2006]

Das würde ich generell machen bzw. mache es auch so. Alles was aufgezeichnet wird kommt auch zyklisch auf den Bus.

Alle 5 Minuten die Temperaturen, Stati der Wärmepumpe, Stromzähler und Helligkeiten.

Das spart viele Kopfschmerzen und ist leicht zu debuggen.

Grüße

[gerksy]

Zyklisches senden der Temperatur alle 10 Minuten ist OK, bei mir steht das auf 15 Minuten und niemand muss frieren. Senden bei Temperaturänderung 1 K ist allerdings ziemlich grob, da würde ich 0.1-0.2 K erwarten

Sorry, hatte das noch von der SOLL Temperatur im Kopf.
Die genauen Parameter für den IST Wert weiss ich leider nicht, da ich für die KNX Programmierung nicht selbst zuständig bin.

Gibt es einen besonderen Grund warum Du auf dem Bus die Temperaturen zusätzlich auch noch pollst? Wenn die sowieso alle 10 Minuten gesendet werden kannst Du doch genau diesen Wert alle 10 Minuten ins Archiv schreiben und daraus die Diagramme generieren?

Es wird leider nicht alles auf den Bus gesendet was ich graphisch darstellen möchte. Die Daten alle 5 Minuten zu pollen erschien mir am einfachsten und programmatisch einheitlichsten bevor ich Daten die ich nicht habe polle und die anderen abfangen und wegschreiben muss. Das Script ist da sehr simpel gehalten

Das würde ich generell machen bzw. mache es auch so. Alles was aufgezeichnet wird kommt auch zyklisch auf den Bus.

Alle 5 Minuten die Temperaturen, Stati der Wärmepumpe, Stromzähler und Helligkeiten.

Das spart viele Kopfschmerzen und ist leicht zu debuggen.

Ja da gebe ich dir Recht. Alle Daten die auf dem Bus vorbeirauschen und die für einen Interessant sind einfach wegschreiben wäre natürlich die einfachste Möglichkeit. In den Graphen würde man erkennen was einem noch fehlt und zyklischen gesendet werden muss. Ich habe die Programmierung des Bus aber leider nicht selbst in der Hands so dass ich das realisieren und immer wieder nachjustieren könnte.

Ich schneide jetzt mal den Bus-Vekehr mit und werde den nächsten Wert der nicht ausgelesen werden kann analyisieren.
Bin mir eigentlich sicher, dass groupreadresponse in den 1-Sekunde Timeout läuft.

[S. De Bruyne]

Reading 60 bus values every minutes is simply how not to do it.
KNX components normally send values on change or periodically, in which the period is typically 15 mins or possibly 10 min, not more.

For an A_GroupValue_Response-PDU, you should wait 3 s typically and at maximum 6 s.

[gerksy]

Habe mir aufgrund eurer Beiträge nochmal Gedanken gemacht. Werde die Werte vom Bus wie empfohlen wegschreiben und diese Daten dann als Basis für die Graphen verwenden.

Vorteile liegen eigentlich auf der Hand
- weniger Telegramme auf dem Bus
- jederzeit die aktuellsten Datenwerte
- graphen können genauer aufgelöst werden. z.B jede statt alle 5 Minuten

Die Werte die nicht über den Bus kommen muss ich dann weiterhin auslesen. Denke die Vorteile überwiegen aber ganz klar.

Besten Dank für den Denkanstoß!

[MarkusS]

Grundsätzlich kommt jeder Wert irgendwann über den Bus - weil wenn er nicht über den Bus kommt tut er nichts.

Ausnahme sind Datenpunkte die z.B. nur innerhalb von Logikbausteinen existieren um Stati zwischenzuspeichern oder innerhalb des Logikbausteins zu transportieren. Diese Werte sind auf dem Bus i.d.R. nicht interessant und teilweise kriegt man die auch nicht aus den Logikbausteinen raus.

Aktiv fragen tut man üblicherweise nur wenn man einem System nach dem hochfahren Initialisierungswerte geben will, z.B. Logiken oder einer Visu oder man pollt zyklisch wenn man etwas überwachen will (z.B. Ausfall- oder Sabotageerkennung).

Als ITler sollte man immer im Hinterkopf haben dass KNX auf Twisted Pair vergleichsweise schnarchlangsam ist und das auch die KNX-Komponenten eine lächerlich geringe Rechenleistung haben. Mit einfacher PC-Hardware und einem Ethernet kann man den KNX problemlos überfahren.

Wenn man so eine Log-Engine baut ist es ggf. interessanter, zu überwachen ob die Werte tatsächlich regelmäßig (von selbst) kommen, also über einen Watchdog zu prüfen ob ein Wert tatsächlich alle X Minuten kommt - und wenn nicht dann ggf. zu warnen. Analog haben diverse Geräte (z.B. Dimmer, Linienkoppler) Stör- und Statusobjekte die man im Auge behalten sollte. Bei bestimmten Ereignissen z.B. eine Email zu versenden ist denke ich für Dich nur eine kleine Fingerübung.

Bedingt eine enge Abstimmung mit demjenigen der die eigentliche Busprogrammierung macht.

[gerksy]

Yeah, vielen Dank.

Ich habe das heute morgen entsprechend umgebaut und beobachte das nun. Die Telegramme pro Sekunde sind von 1,2 runter auf 0,7. Wenn ich herausgefunden habe welche Werte zyklisch gesendet werden (finale ETS Projektdatei), werde ich einen entsprechenden Alarm bzw. Trigger aufsetzen. Momentan würde man das nur im Graphen sehen, da die Linie eine sehr auffällige Gerade bilden würde. Reicht für den Anfang.

Überwachung der KNX Komponenten ist ein heikles Thema. Sind dann doch einige und ich denke, dass würde im ersten Moment nicht sonderlich auffallen wenn eines Zicken macht.

Habe da was einfaches gescripted. Muss aber noch ausgefeilt und in irgendeine Art Überwachung eingebunden werden die dann auch Alarm schlägt.

root@eibd:/var/www/knx/testscripts# php knxcheck.php
Gerät           Spannung        Maske           Zustand         Fehler          Programmiermodus
1.0.1           38.25V          0012            1E              FF              not in programming mode
1.0.2           27.15V          091A            1E              FF              not in programming mode
1.0.3           36.9V           0701            00              ?               not in programming mode
1.0.4           28.65V          0012            2E              FF              not in programming mode
1.0.5           27V             0701            00              ?               not in programming mode
1.0.6           ?               091A            00              FF              not in programming mode
1.1.0           29.25V          0912            1E              FF              not in programming mode
1.1.1           29.1V           0701            00              ?               not in programming mode
1.1.2           28.2V           0701            00              ?               not in programming mode
1.1.3           28.95V          0701            00              ?               not in programming mode
1.1.4           28.05V          0701            00              ?               not in programming mode
1.1.5           29.1V           0701            00              ?               not in programming mode
1.1.6           29.1V           0701            00              ?               not in programming mode
1.1.7           29.85V          0701            00              ?               not in programming mode
1.1.8           28.95V          0701            00              ?               not in programming mode
[...]

Grüße und besten Dank bis hierher
Göks

[S. De Bruyne]

36,9 v?