EibPC Zukunftsmusik

[enertegus]

eine Auswertung der Adressen zu bekommen, die mit InitGA zwar abgefragt werden sollten aber hier nicht geantwortet haben..

Sieht man doch anhand der Telegramme.

[bmx]

Sieht man doch anhand der Telegramme.

Ja. Wieviele GA hast Du? Gehst Du dann alle Pärchen mit Lesen und Antwort durch? Ich finde das einfach unnötig, weil der EibPC diese Information bereits besitzt und er mein Leben komfortabler machen soll.

Es könnte mit den GA auch leicht sein indem einfach der EibPC seine Liste durchgeht und kurz mal berichtet:
"Hallo, mir ist aufgefallen, das die Heizung beim Initialisieren nicht gesagt hat ob sie das ist und weiterhin habe ich festgestellt, das der Sensor für das Gasventil nicht geantwortet hat"

Gruß,
Bernd

[enertegus]

"Hallo, mir ist aufgefallen, das die Heizung beim Initialisieren nicht gesagt hat ob sie das ist und weiterhin habe ich festgestellt, das der Sensor für das Gasventil nicht geantwortet hat"

Das, was Du meinst, ist mit einem Makro (Funktion eventread) zu machen: Du musst zyklisch mit read abfragen und auf die Antwort warten. Auf diese Art kann man einen Aktor überwachen (Anregung redstar).

Wenn es aber um initga geht, ist die Vorgabe mit dem Telegrammmonitor m.E. ausreichend. Man macht das nur einmal pro Installation und dazu ist es mit den Monitordaten nun wirklich ok. Selbst wenn hier ein Ausbleiben einer Antwort registriert würde, ist das bei Deinem Beispiel nicht der Fall.
Daher .

[chg]

Sorry Michael aber dies sollte der EibPC direkt rückmelden, ohne dass man hierfür extra etwas mit Eventread() coden muss...

Es geht doch darum, dass man beim Coden schnell mal ne neue GA verwendet. Mit initGA kann man nun super einfach dafür sorgen, dass deren Status vor dem Systemstart vom EibPC eingelesen wird. Man müsste nun jedesmal die komplette Liste im Meldungfenster durchgehen um zu prüfen ob auf diese GA auch eine Rückmeldung kommt... Der EibPC könnte doch am Ende einfach eine Zusammenfassung mit den nicht erhaltenen Rückmeldungen ausgeben. Dann kann man die Flags in der ETS prüfen.

Wenn es für euch einfach machbar ist, dann würde es uns das Leben etwas komfortabler machen...

[enertegus]

Man müsste nun jedesmal die komplette Liste im Meldungfenster durchgehen um zu prüfen ob auf diese GA auch eine Rückmeldung kommt

Nur einmal, nicht jedesmal.
Ergänzung (man braucht natürlich auch eventresponse)

[joggele777]

Hallo Michael,

ist denn eigentlich etwas bezüglich eines eigenen Webservers auf dem EIBPC geplant? Es geht in erster Linie darum EIBPC homecontrol zu verwenden und dafür nicht einen extra Webserver auf irgendeinem System zu integrieren sondern wenn möglich dies auf/mit dem EIBPC zu handeln.

Grüsse
Jochen

[saft6luck]

Nur einmal, nicht jedesmal.

Wow, robustes Design ist dir ein Fremdwort, oder?

[Uwe!]

was hat den den Init-Prozess, der nur einmal beim Systemstart durchlaufen wird, mit robustem Design zu tun?

[SnowMaKeR]

Versteh ich auch nicht.

[saft6luck]

Mal unter uns: Wenn euer Auto mal nicht starten will, dann ist das auch ok für euch? Was hat denn der Motorlauf mit dem Motorstart zu tun????

Aber ich erkläre das gerne: Wenn ich meinen eibPC um 23:59 starte, soll er nicht die Läden fahren, weil er glaubt, dass es 17:00 ist. Genauso wenig möchte ich bei jedem Neustart dabei sitzen, damit ich sehen kann, ob alle initGAs durchgelaufen sind. InitGA ist eine nette Erleichterung, die, wie so oft, nur ansatzweise die Anforderungen abdeckt. Es wird weder ein Retry noch ein Logging, geschweige denn eine programmierbare Fehlerbehandlung angeboten.

Und bevor wieder einer schreibt "das kommt doch soooo selten vor" -> das mag sein, aber genau dann will ich es wissen, wenn es selten vorkommt!

[Tessi]

OK, aber dafür könntest Du jetzt wirklich einfach ein Makro schreiben (mußt Du für viele andere Dinge ja auch) und die Daten im Fehlerfall ja persistent ablegen. Denn wie auch immer Enertex das jetzt implementieren würde, es entspräche mit einiger Wahrscheinlichkeit nicht Deinen Wünschen.
Und wenn ein Antwort mal nicht kommt und Du das ohne Analyse der Logdaten nicht bemerkst, dann war es auch nicht ganz so wichtig.
Dein Auto beichtet Dir auch nicht alle Wehwehchen des Motors. Erst wenn der richtig auszufallen droht, etwas was Du dann ja wohl sofort und ohne Fehlerlogging bemerken wirst, dann erst meldet man auch Dir ein Problem. Aber garantiert nicht jede Kleinigkeit. Das geht so weit, das schon eingetragene Fehlermeldungen wieder gelöscht werden, wenn das Problem schon länger her ist. Dann kann Dir nicht einmal mehr die Werkstatt helfen.
Aber im Gegensatz zu Deinem Auto kannst Du hier ja selbst was programmieren - beim Auto mußt Du es nehmen, wie es ist - jedenfalls geht das den meisten von uns so.
Ich würde mir Änderungen erst einmal da wünschen, wo ich selbst nicht "nachrüsten" kann, z.B. fehlende Zeit nach einem Reset wenn auch keine anderer Zeitgeber verfügbar ist.
Oder einfacherer Berechnungen mit Zeit und Datum, ist derzeit mehr als umständlich...

[SnowMaKeR]

Ich versteh Dich immer noch nicht.
Den Vergleich mit dem Auto auch nicht.
Häää??

Wenn dein EIBPC plötzlich und unerwartet um 23:59 Uhr neu startet. Dann siehst du alles in den Logs und in der Telegrammaufzeichnung.
Wenn du Angst hast, dass eine GA mal nicht antwortet, dann nimm sie 2mal auf. Auch wenn das nicht die feine und englisch und saubere ist.

[saft6luck]

Ich versteh Dich immer noch nicht.
Den Vergleich mit dem Auto auch nicht.

Eben, aber wenn bei deiner neuen Karre mal beim Neustart die Navi nicht anläuft, dann ist die Hölle los, dann wird gemeckert und nicht verstanden, wie das sein kann ... dann bist du schnell dabei zu verstehen, warum da alles robust implementiert sein muss.

Wenn dein EIBPC plötzlich und unerwartet um 23:59 Uhr neu startet. Dann siehst du alles in den Logs und in der Telegrammaufzeichnung.
Wenn du Angst hast, dass eine GA mal nicht antwortet, dann nimm sie 2mal auf. Auch wenn das nicht die feine und englisch und saubere ist.

Den starte ich und dann will ich, dass er genauso robust anläuft, wie zu jeder anderen Zeit auch!

Das hat nichts mit einem Makro zu tun, sondern mit der Art und Weise, wie der Systemstart abläuft. Wenn die InitGAs eben einmal nicht durchlaufen kann ich nicht darauf reagieren, oder ich schreibe mir den ganzen Code selbst. Dann bin ich beim Status Quo von vor einem Jahr. Das kann man alles verdrängen für ein InitGA, nur ist diese Arbeitsweise für mich nicht zielführend.

[SnowMaKeR]

Eben, aber wenn bei deiner neuen Karre mal beim Neustart die Navi nicht anläuft, dann ist die Hölle los, dann wird gemeckert und nicht verstanden, wie das sein kann ...

Hmm, unterstellst du mir gerade, dass ich dann ausraste?
Nö Sorry. So bin ich nicht.
Den Umkehrschluss schließe ich jetzt mal nicht...

Den starte ich und dann will ich, dass er genauso robust anläuft, wie zu jeder anderen Zeit auch!
Das hat nichts mit einem Makro zu tun, sondern mit der Art und Weise, wie der Systemstart abläuft. Wenn die InitGAs eben einmal nicht durchlaufen kann ich nicht darauf reagieren

Ich bitte um Verzeihung, aber irgendwie wirkt das im Moment etwas wie "gemecker" auf mich und nicht so richtig zielführend.
Ich kann dein Anliegen jetzt zumindest ein kleinwenig nachvollziehen.
Aber irgendwie fehlt mir da der Gesamtkontext.
Unabhängig davon, dass du mit InitGA schon mal alles Abfragen kannst, dann mit Systemstart nochmal erste Überprüfungroutinen absetzen könntest, würde ich mich fragen, wenn ich es schon so robust haben möchte, warum das andere Gerät nicht auf die Leseanfrage antwortet, warum das Telegramm vielleicht nicht übertragen wurde oder what else auch immer und nicht nur Fehlerbehandlungsroutinen in einem System.
Ich bin jetzt frech und unterstelle, dass du gar nicht alle Fehlereventualitäten abprüfen kannst.

[saft6luck]

Und wenn ein Antwort mal nicht kommt und Du das ohne Analyse der Logdaten nicht bemerkst, dann war es auch nicht ganz so wichtig.

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.

Ich würde mir Änderungen erst einmal da wünschen, wo ich selbst nicht "nachrüsten" kann, z.B. fehlende Zeit nach einem Reset wenn auch keine anderer Zeitgeber verfügbar ist.
Oder einfacherer Berechnungen mit Zeit und Datum, ist derzeit mehr als umständlich...

Ich würde mir Änderungen so wünschen, dass sie zur Robustheit beitragen und nicht noch scheunentorgroße Lücken aufreißen. Aber das ist ja soo einfach.

Zuerst hat es ein Jahr gedauert, um Michael von der Notwendigkeit eines besonderen Bereiches für den Systemstart zu überzeugen und dann ist daraus eine Vereinfachung für den Init der GA-Werte geworden. Für mich bisher knapp am Ziel vorbei, aber vorbei.