EibPC Zukunftsmusik

[enertegus]

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

Wobei es dann schwer zu lesen ist - die GAs ist man schon so gewohnt. Man muss dann doch die Zellen wieder als Text formatieren.
Also so noch nicht ausgoren. Vielleicht mit " damit Excel besser zurecht kommt (wobei der Diamond CVSViewer ohnehin das gut kann)??

[Jukom]

Also ich wäre mit "0/6/35" schon zufrieden. Wie energetus sagt, ist es gut lesbar und Excel kann prima sortieren und filtern - also alles was ich im Moment brauche

[Tessi]

Wobei Excel "0/6/35" beim Sortieren aber als kleiner als "0/6/9" ansehen würde...
Ansonsten stimme ich zu, einfach als Text "0/6/35" wäre wohl ein guter Kompromis.

[makki]

Na wenn, gehört die GA/PA als int16 in ein Feld
Weil das ist sie nunmal, auch wenn ich persönlich wenig von 2 oder mehr als 3stufigen GA halte und auch selbst ausschliesslich 3stufige GA umsetze, so stehts im KNX-Standard: Es ist ein 15Bit int (seit ETS4 16bit, warum auch immer) und dann sollte man es auch mittelfristig so ablegen..
(ich bin jetzt zu faul die Windows-VM zu starten aber das kann man trotzdem leicht mit Excel in 1/2/3 umwandeln - leichter als rechts(rechts(rechts jedenfalls )

Makki

[saft6luck]

Mir wäre auch an der Ausgabe des Integer Wertes gelegen.

Könnte man nicht beide Formate ausgeben, um sowohl richtig zu sortieren als auch ein lesbares Format zu erhalten?

[chg]

Könnte man nicht beide Formate ausgeben, um sowohl richtig zu sortieren als auch ein lesbares Format zu erhalten?

Finde ich auch die beste Lösung!

[Tessi]

Mir wäre auch an der Ausgabe des Integer Wertes gelegen.

Könnte man nicht beide Formate ausgeben, um sowohl richtig zu sortieren als auch ein lesbares Format zu erhalten?

Jetzt stehen drei Versionen zur Wahl, die alte 2stufige, die 3stufige (beide als Text) und 16Bit Integer. Da würde ich mir wünschen, das man beim Export angeben kann, welche man davon haben möchte, wobei dann auch Mehrfachwahl ganz angenehm wäre...

Nachtrag zu einem früheren Punkt:

Wenn ein InitGA keine Antwort erhält, kann ich das nirgends programmgesteuert (darum geht es ja) erkennen.

Nun, für alle interessierenden GAs könnte man Flags anlegen, die gesetzt werden, wenn die jeweilige GA erstmals schreibend empfangen wird und zusätzlich noch welche, die gesetzt werden, wenn für die jeweilige GA erstmals eine Antwort empfangen wird. Das sollte schon heute mit den Bordmitteln machbar sein - auch wenn es je nach Zahl der so zu überwachenden GAs schon einigen Aufwand bedeutet.

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.

Nun, als Analyzer war der EibPC wohl bislang nicht gedacht, ich kenne jetzt auch keine anderen Geräte, die über derart weitreichende Bus- und Eigendiagnosemöglichkeiten verfügen.
Angenehm wären solche Möglichkeiten schon, in wie weit man sie zwingend braucht und vor allem, wie viele Anwender das tatsächlich auch nutzen würden vermag ich aber noch nicht vorherzusagen.
Für mich wirklich wichtig ist die sichere Erkennung, ob seit dem letzten Reset die Zeit gültig gesetzt worden ist, ob nun per NTP, EibStudio oder Bus ist dabei zweitrangig, ich muß es aber irgendwie feststellen können. Außer per Bus - da kann ich das Event erkennen und mir merken - wüßte ich nun nicht, wie das geht.

[Uwe!]

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

Zustimmung!

[saft6luck]

Nun, für alle interessierenden GAs könnte man Flags anlegen, die gesetzt werden, wenn die jeweilige GA erstmals schreibend empfangen wird und zusätzlich noch welche, die gesetzt werden, wenn für die jeweilige GA erstmals eine Antwort empfangen wird. Das sollte schon heute mit den Bordmitteln machbar sein - auch wenn es je nach Zahl der so zu überwachenden GAs schon einigen Aufwand bedeutet.

Den Königsweg kenne ich natürlich auch nicht. Ich würde allerdings keinen Schritt zurück machen wollen. Der Großteil (read senden, Timeout überwachen, System erst nach der Abarbeitung starten) ist ja schon gemacht.

Lösungen aus anderen Bereichen wären z.B.
1. Callback (man trägt eine Funktion ein, die im Fehlerfall aufgerufen wird). Vorteil: Aktionen können sofort abgeleitet werden; (wer nicht will, braucht ja keinen eintragen) - scheidet im eibPC konzeptionell aus
2. Flags, die man später auswerten kann. Vorteil: diese Informationen sollten im eibPC bereits vorhanden sein - Nachteil: späte Auswertung -> Systemstart?
3. Automatisierte Behandlung - z.B. einstellbare Anzahl an Versuchen, im Notfall Eintrag im Fehlerspeicher
4. Es gibt bestimmt noch weitere Möglichkeiten

IMHO würde zumindest 3. Sinn machen, am liebsten zusätzlich noch 2., wobei 2. ja auch ohne InitGA Sinn macht.

Nun, als Analyzer war der EibPC wohl bislang nicht gedacht, ich kenne jetzt auch keine anderen Geräte, die über derart weitreichende Bus- und Eigendiagnosemöglichkeiten verfügen.
Angenehm wären solche Möglichkeiten schon, in wie weit man sie zwingend braucht und vor allem, wie viele Anwender das tatsächlich auch nutzen würden vermag ich aber noch nicht vorherzusagen.

Für mich geht es da ja nicht um einen Analyzer, sondern eher um das Überwachen der eigenen Funktionalität. Der eibPC kann eben nicht nur über den Bus kommunizieren, sondern auch Emails verschicken. Ein einfaches ISDN Modul von Siemens schickt mir SMS/Emails, ruft mich an oder sendet Telegramme wenn der Bus tot ist bzw. war. Wenn ich Emails wirklich brauche ist es zur Mitteilung von Problemen.

[salixer]

3. Automatisierte Behandlung - z.B. einstellbare Anzahl an Versuchen, im Notfall Eintrag im Fehlerspeicher

Der Bus muss auch bei einer Anfrage eine Antwort liefern. Dafür sind die unteren Layer verantwortlich. Falls da keine Antwort kommt, hat dein Bus ein Problem.

[Tessi]

Der Bus muss auch bei einer Anfrage eine Antwort liefern. Dafür sind die unteren Layer verantwortlich. Falls da keine Antwort kommt, hat dein Bus ein Problem.

Nein, nicht immer! Bei mir hat ein Aktor ganz offenbar Probleme, wenn mehrere Anfragen nacheinander kommen, dann beantwortet er die ein oder andere einfach mal nicht, welche, das wechselt und ist für mich nicht vorhersehbar. Offenbar ist sein Verhalten hier nicht konstant ohne das ich etwas daran ändern kann.
Dafür kann der Bus nichts, die Flags sind alle OK und die "unteren" Layer kümmern sich darum nicht. Das anfragende Gerät muß da ggf. noch einmal fragen.

Ganz generell fehlt daher auch mir eine Möglichkeit, festzustellen, ob eine GA oder auch davon abhängende Variablen seit einem Reset des EibPCs überhaupt schon mal mit einem Wert vom Bus belegt worden sind.
Schön wäre dabei auch noch die Unterscheidung, ob dies durch eine Antwort auf eine Anfrage oder durch ein direktes Schreibkomando erfolgt ist. Nice to have könnte noch die Möglichkeit sein, das Alter dieser Änderungen zu kennen - auch das kann eine Aussage zur Gültigkeit enthalten.
An sich sollte der EibPC das alles schon zur Verfügung haben, es fehlt eigentlich doch nur noch die Möglichkeit, das im Programm auch auswerten zu können.

[enertegus]

Ganz generell fehlt daher auch mir eine Möglichkeit, festzustellen, ob eine GA oder auch davon abhängende Variablen seit einem Reset des EibPCs überhaupt schon mal mit einem Wert vom Bus belegt worden sind.

Du willst
[highlight=epc]
Checktime=chtime(20,00,00)
Responses=0u16

MyResponse=AUS
// Initalisiere eine Anfrage
if Checktime then {
read("GA-Test");
MyResponse=EIN
} endif
// Antwort kommt
if eventresponse("GA-Test") and MyResponse then Responses=Responses+1u16 endif
if after(Checktime,1000u16) and MyResponse then MyResponse=AUS endif
endif
[/highlight]

Schön wäre dabei auch noch die Unterscheidung, ob dies durch eine Antwort auf eine Anfrage oder durch ein direktes Schreibkomando erfolgt ist.

Da rate ich mal das Handbuch zum Kapitel eventwrite anzuschauen.
(Den Code konnte ich von hier nicht testen - bin unterwegs...)

[makki]

Nein, nicht immer! Bei mir hat ein Aktor ganz offenbar Probleme, wenn mehrere Anfragen nacheinander kommen, dann beantwortet er die ein oder andere einfach mal nicht, welche, das wechselt und ist für mich nicht vorhersehbar.

Mit Verlaub, wenn das Leseflag richtig gesetzt ist, ist das ein ein Problem des Aktors oder eben der Installation (Topologie, Spannungsversorgung, ...)
Ich weiss was Du meinst, aber das Problem liegt hier bei A, G, I oder S

KNX hat keine gescheite Fehlerbehandlung wie man das von z.B. TCP gewohnt ist (auch wenn mich jetzt zum 10. mal jemand verkloppt: TCP/IP ist Männertechnik, KNX dagegen alpha mit Hoffnungsfaktor - nochmal mit Verlaub, ist halt so: das ist ein Fire&Forget-Schönwetter-protokoll): wenn nicht alles perfektes Schönwetter ist, gibts halt nix und das kann man hinterher auch nur schwierig ausbügeln.
Also muss man dafür sorgen, das eben gutes Wetter herrscht
Im Zweifelsfall eher durch solch sehr zweifelhafte Massnahmen wie eine "Telegrammratenbegrenzung", für Anwender 0,00 nachvollziehbar aber es hilft eben problematische Geräte trotzdem dann noch aus der Schusslinie zu bekommen (bzw. hilft das dem privaten eh nichts, weil er die Dinger nun hat und ich glaube genau zu wissen welche zwei Aktoren da infrage kommen..)

Aber wiegesagt: eine "summary" von Scan-Fehlern macht IMHO schon Sinn, u.a. deswegen und nur zur Problemanalyse..

Makki

[saft6luck]

Der Bus muss auch bei einer Anfrage eine Antwort liefern. Dafür sind die unteren Layer verantwortlich. Falls da keine Antwort kommt, hat dein Bus ein Problem.

Man kann gerne darauf pochen, nur ist der KNX Bus nun einmal 1. nur das Medium und 2. eingeschränkt für eine Fehlerbehandlung zuständig/ausgelegt. Genauso wie bei anderen Übertragungsmedien auch, sind die höheren Schichten zusätzlich für die Absicherung der 'Datenübertragung' verantwortlich. (Beispiel: Licht geht nicht an -> Anwender drückt noch einmal)

Im Beispiel KNX kann man sicherlich versuchen, für schön Wetter (wie es Makki schon beschreibt) zu sorgen. Das reduziert dann die Häufigkeit des Auftretens von Fehlern auch mal gegen 0, nur hängt das von vielen Faktoren ab und garantiert nicht(!), dass nicht doch einmal ein Problem auftritt. Zu diesen Problemen zählt eben eine hohe Buslast (-> zu kleine Puffer?) genauso wie Aktoren, die nicht antworten oder Koppler und Medienkonverter (auch Router auf IP) oder das verwendete Medium an sich, wie Powernet oder Funk, etc.

-> einen Retry vorzusehen erscheint mir auch dann sehr sinnvoll, wenn man nicht mit Fehlern rechnet, denn was nutzt mir die tollste Logik, wenn die Daten nicht stimmen, oder?

[Tessi]

@enertegus:

Ja, für GAs kann ich Code schreiben, der diese Überwachung erledigt. Ggf. läßt sich das sogar in ein Makro fassen. Aber das ergibt je nach Zahl der zu überwachenden GAs schon eine Menge Code, ist nicht so einfach auf Variablen anzuwenden und überwacht nur GAs für die ich das auch vorsehe.
Da der EibPC ja letztlich alle GAs speichert, die irgendwo einmal verwendet werden wünsche ich mir halt, das ich an der Stelle der Verwendung einfach kurz prüfen kann, welchen Status diese GA hat, ohne dafür anderswo noch Überwachungs-Code zu benötigen. Halt so wie man bei z.B. PERL fragen kann, ob eine Variable definiert ist - was hier bedeutet, das ihr schon einmal etwas zugewiesen wurde. Das hat dabei nichts damit zu tun das PERL bei Verwendung einer solchen undefinierten Variablen dann ersatzhalber einen Defaultwert verwendet statt einen Fehler zu generieren. Das der EibPC alles mit 0 vorbesetzt bedeutet für mich daher nicht, das man nicht trotzdem auf Anfrage als Status undefiniert zurückgeben kann - eben wie dies auch PERL macht, und das dieser Status automatisch im Hintergrund ohne Zutun des Programmierers ermittelt und aktuell gehalten wird.
Wenn man dann noch das Validierungsschema so konfigurieren könnte, das es Ausdrücke nur dann auswertet, wenn alle beteiligten Werte gültig sind - der Preis dafür wäre dann, das man explizit Variablen auf 0 setzen muß statt auf ihren Defaultwert zu vertrauen - dann wäre in meinen Augen das System schon um einiges sicherer ohne das man umfangreiche Verrenkungen im Code machen muß.

Wie gesagt, für bekannte GAs kann man das mit viel Code nachbauen, aber ob die Systemzeit irgendwie mal seit einem Reset gestellt wurde, kann ich so nicht ermitteln, außer es erfolgte über eine GA.

Daher stelle ich zur Diskussion obigen Wunsch nach Statusabfrage für alle GAs/Variablen und ggf. - konfigurierbar um kompatibel zu bleiben - Anpassung des Validierungsschemas, so das Ausdrücke mit undefinierten Werten eben nicht ausgewertet werden, ich denke da vor allem an uhrzeitgesteuerte Operationen, die automatisch so lange warten, bis die Uhr gestellt wurde...


@makki:
Das Problem ist der Aktor, er antwortet trotz gesetzter Flags eben manchmal nicht, und das kann ich jetzt nicht ändern.
Von den "dummen" Aktoren und Sensoren darf ich bezüglich Fehlermanagement nicht zu viel erwarten, also muß ich die Fehlerbehandlung leider den "intelligenteren" Geräten aufbürden - z.B. eben meinem EibPC.
Daher meine Wünsche, dafür entsprechende Mittel und Möglichkeiten an die Hand zu bekommen.
Scan-Fehler zu loggen hilft mir die Ursache zu finden, aber kann ich das Verhalten dann nicht ändern muß ich dennoch hin und wieder auftretende Fehler irgendwie behandeln - hoffen und ignorieren ist da keine wirkliche Alternative.