EibPC Zukunftsmusik

[bmx]

Diskussionen zu InitGA-Rückmeldung vielleicht besser hier weiterführen ...

[Tessi]

Genau, wenn das Terrassenlicht an bleibt, weil der eibPC nach einem Neustart mal eine entsprechende GA nicht bekommen hat, bemerkt man das im Urlaub ja sofort.

Nun, robuste Programmierung bedeutet auch, das das Licht auch dann so korrrkt als möglich definiert wieder abgeschaltet wird, wenn der Status nicht gelesen werden konnte. Ist vermutlich kein gutes Beispiel für Dein Anliegen...

Generell gibt es trotz korrekt gesetzter Flags keine absolute Sicherheit, das Anfragen immer beantwortet werden. Und was tun wenn (nicht), dafür gibt es keine einzig richtige und immer anwendbare Vorgehensweise. Also bleibt nur selbst programmieren, was einem gerade am sinnvollsten erscheint. Nicht immer hilft wiederholen, nicht immer kann man alles verzögern, bis alle Antworten da sind. Manchmal muß man uninitialisiert starten und das Beste daraus machen.

Bei sicherheitsrelevanten Dingen macht die Fehlerbehandlung den größten Teil des Codes aus. Da hilft alles nichts, das ist auch abseits von KNX so.

[makki]

Zum vorangegangenen sage ich lieber nichts, mit Robustheit hat das rein garnichts zu tun..

Aber trotzdem, eine gesammelte Ausgabe von Scan-Fehlern (im HS-sprech) im Log, also initGA's die eben nicht gelesen werden konnten hätte IMHO schon was. Gerade der Änfänger kämpft da eine Weile, bis überall die Leseflags erstmal verstanden und dann richtig gesetzt sind.. Spreche da aus Erfahrung
Zumindest für die nice-to-have-wenn-mal-langweilig-Liste als Minimal-Kompromiss: Ausgabe Anzahl der Scan-Fehler; das sollte ja eher noch einfacher sein, dann weiss/sieht man auf einen Blick wenigstens nach wieviel man suchen muss und ob welche hinzukamen.

Makki

[MatthiasS]

[ACHTUNG]Moderatorenanmerkungen[/ACHTUNG]

Ich schaue mir diesen agressiven Unterton nur noch sehr kurze Zeit an, dann gibt es "Reaktionen". Das ist ein technisches Forum. Ich erwarte, dass hier technisch = sachlich argumentiert wird. Alles "Unterschwellige" hat hier nichts verloren, ich denke es ist bekannt, dass wir hier konsequent den Riegel vorschieben.

Habe fertig.

[chg]

...mit Robustheit hat das rein garnichts zu tun..

Aber trotzdem, eine gesammelte Ausgabe von Scan-Fehlern (im HS-sprech) im Log, also initGA's die eben nicht gelesen werden konnten hätte IMHO schon was. Gerade der Änfänger kämpft da eine Weile, bis überall die Leseflags erstmal verstanden und dann richtig gesetzt sind..

...Zumindest für die nice-to-have-wenn-mal-langweilig-Liste als Minimal-Kompromiss: Ausgabe Anzahl der Scan-Fehler...

Full Ack and

[saft6luck]

Nun, robuste Programmierung bedeutet auch, das das Licht auch dann so korrrkt als möglich definiert wieder abgeschaltet wird, wenn der Status nicht gelesen werden konnte. Ist vermutlich kein gutes Beispiel für Dein Anliegen...

Robuste Programmierung benötigt die entsprechenden Möglichkeiten. Momentan existieren die einfach nicht. Wenn ein InitGA keine Antwort erhält, kann ich das nirgends programmgesteuert (darum geht es ja) erkennen.

Generell gibt es trotz korrekt gesetzter Flags keine absolute Sicherheit, das Anfragen immer beantwortet werden.

Das ist des Pudels Kern. Das InitGA wägt einen in Sicherheit, allerdings ohne Retry oder Rückmeldung. Das ist ja auch nur ein Beispiel! Es gibt leider noch mehrere solcher Punkte, die eine robuste Programmierung nicht unterstützen, z.B. kann man im Code wesentliche Konfigurationswerte nicht auslesen (Zykluszeit, ...), NTP nicht auf Funktionsfähigkeit prüfen, Eventeinträge weder auswerten noch (wenigstens) mitteilen, Probleme mit dem Bus/Schnittstelle/etc. prüfen oder melden, etc.

Und was tun wenn (nicht), dafür gibt es keine einzig richtige und immer anwendbare Vorgehensweise. Also bleibt nur selbst programmieren, was einem gerade am sinnvollsten erscheint. Nicht immer hilft wiederholen, nicht immer kann man alles verzögern, bis alle Antworten da sind. Manchmal muß man uninitialisiert starten und das Beste daraus machen.

Wie oben angesprochen fehlen die Informationen nach dem InitGA, um diese dann auszuwerten. Was der jeweilige Programmierer dann mit diesen Informationen anfangen will/muss ist jedem selbst überlassen. Eine 'Lösung' zu unterstützen ist nicht generell unmöglich, nur weil man die konkrete 'Lösung' noch nicht kennt.

Bei sicherheitsrelevanten Dingen macht die Fehlerbehandlung den größten Teil des Codes aus. Da hilft alles nichts, das ist auch abseits von KNX so.

Ein wahres Wort, leider kommt das scheinbar nirgends an.

[MatthiasS]

Ein wahres Wort, leider kommt das scheinbar nirgends an.

Das sind genau die Sätze, die ich meine. Lass das, letzte Warnung.

[saft6luck]

Das sind genau die Sätze, die ich meine. Lass das, letzte Warnung.

Gut, wenn man derart allgemein gültige Aussagen nicht mehr machen darf, ziehe ich sie natürlich zurück! Sorry.

[Jukom]

Ausgabeformat CSV

Hallo

ich hätte hier mal einen dringenden Wunsch für die nächsten Updates:

Der Datenexport (vom EibPc oder ftp-Server) in die csv-Datei sollte bitte so formatiert sein dass die Ziel GA als reine Adresse in eigener Spalte mit ausgegeben wird. Also statt
"Regenmenge.Zählerst.-0/6/35"
so...
"0/6/35", "Regenmenge.Zählerst."



damit wären Auswertungen einfacher.
Ideal wäre natürlich alle drei Gruppen in separater Spalte also
"0", "6", "35", "Regenmenge.Zählerst."
aber man wills ja nicht übertreiben mit den Wünschen

[MarkusL]

Hi Joachim,

also mit minimalen Excel-Kenntnissen kann man sich das doch leicht selber machen!

"Regenmenge.Zählerst.-0/6/35" in Zelle A1

=LINKS(A1;FINDEN("-";A1)-1) ergibt "Regenmenge.Zählerst."
=RECHTS(A1;LÄNGE(A1)-FINDEN("-";A1)) ergibt "0/6/35"

Natürlich kannst du die GA auch weiter zerlegen.

Gruß,
Markus

EDIT: Hmmm..oder willst du die csv-Datei direkt auswerten? Was ist dein Ziel?

[Jukom]

Hallo Markus,

du hast natürlich Recht und das mach ich defakto auch so aber du musst halt dann jede Datei einzeln anfassen und Formel einfügen.
Klar man könnte auch ein Makro schreiben und und und...
aber dennoch finde ich zu einer formatierten Ausgabe gehören "numerische" Daten und Text getrennt

[enertegus]

Klar man könnte auch ein Makro schreiben und und und...
aber dennoch finde ich zu einer formatierten Ausgabe gehören "numerische" Daten und Text getrennt

Ich denke, das wäre wohl relativ leicht machbar und wenn es auf allgemeine Zustimmung stößt, dann nehm ichs mal auf.

[MarkusL]

Hi Joachim

klar man könnte auch ein Makro schreiben und und und...
aber dennoch finde ich zu einer formatierten Ausgabe gehören "numerische" Daten und Text getrennt

Mit meiner Excel-Geschichte meinte ich auch nicht, dass eine Änderung im csv-Export überflüssig ist nur sich eben auch anders (aufwendiger) lösen lässt.

...aber wenn sich Michael diese Ergänzung jetzt auf die (ewig lange?!) Featureliste geschrieben hat...

Grüße,
Markus

[Jukom]

@Markus

Mit meiner Excel-Geschichte meinte ich auch nicht, dass eine Änderung im csv-Export überflüssig ist nur sich eben auch anders (aufwendiger) lösen lässt.

Verstehe ich jetzt nicht was du damit meinst.

Deine Formel

=RECHTS(A1;LÄNGE(A1)-FINDEN("-";A1)) ergibt "0/6/35"

funktioniert nicht wenn im GA Text bereits ein "-" steht. Du musst zuerst nach dem letzten Vorkommen eines "-" suchen oder
so: =RECHTS(RECHTS(D1;9);9-FINDEN("-";RECHTS(D1;9)))

[Tessi]

aber dennoch finde ich zu einer formatierten Ausgabe gehören "numerische" Daten und Text getrennt

Nur "0/6/35" ist für Excel auch nur ein Text. Numerisch interpretiert würde Excel daraus sonst 0 machen! Also muß man es entweder noch weiter in die einzelnen Zahlen trennen, oder die Adresse schlicht als Zahl wie sie codiert ist darstellen, also 0*2048+6*256+35=1571, damit kann dann Excel besser umgehen...