Sonnenaufgang/untergang, ein mal täglich

[emax]

Ähm, bevor die Diskussion in einen Streit umschlägt:

Makki hat schon Recht, der Bus als zentrale Entität einer knx-Installation ist tatsächlich der richtige Platz für alle knx-relevanten Werte. Aber er ist eben nicht als Speichermedium oder als Cache geeignet, und ich glaube auch nicht, dass er das damit gemeint hat.

Sofern Daten via Bus zeitnah verarbeitet werden können, sollte man sie auch da drauf schreiben. Für alle anderen Fälle, z.B. HS & Co., wäre es aus meiner Sicht aber der bessere Weg (z.B. via Plugin), ausgewählte Werte aus %plugin_info auf eine einfache, wiregate-unabhängige Schnittstelle zu schicken.

Mir würde es z.B. gar nicht gefallen, wenn ich für einen Plugin-Wert, den ich ja direkt via %plugin_info verwalten kann, extra eine Gruppenadresse opfern müsste. Da kommt nämlich auf Dauer durchaus was zusammen.

Es ist keine große Sache, ein Plugin zu schreiben, welches bestimmte Informationen aus %plugin_info ausliest und entweder in eine Datei, oder von mir aus auch direkt auf den Bus schreibt. Dann hätte wenigstens jeder die Wahl, ob er dafür eine GA bereitstellen und außerdem Buslast in Kauf nehmen möchte.

Das ist natürlich alles immer nur Kleinvieh. Aber das macht ja bekanntlich auch Mist.

[emax]

Und noch ein klärendes Statement zur Frage der Bus-Rolle.

Es ist ein bisschen schwierig, die genaue Abgrenzung zu finden. Wenn ich über die Idee eines Busses als alles verbindendes Element nachdenke, finde ich da durchaus Gründe, das so zu tun. Deshalb ist die 'Krücke', wie ich das weiter oben genannt habe, etwas genauer zu definieren, denn nicht alles ist daran wäre falsch.

Das wichtige Wörtchen ist 'zeitnah', ich ergänze es durch 'Ereignis'. Besonders Letzteres unterscheidet sich erheblich von 'Zustand'. Da liegt aus meiner Sicht nämlich der Hase im Pfeffer.

Das hier vorgestellte Sonnauf/Untergangs-Plugin ist dafür ein gutes Beispiel: Es 'tut' ja nichts im eigentlichen knx-Sinne. Es wird nichts geschaltet, es impliziert keine knx-Logik. Es werden lediglich zwei Werte bereitgestellt, und jeder von Ihnen in zwei verschiedenen Notationen, zusammen drei Datenfelder je Wert. Schon dafür bräuchte man übrigens bereits sechs GA ...

Diese Werte dienen anderen Scripten nur als Information, sie sind statisch, und das 24 Stunden lang. Es gibt also zum ersten schon mal gar keine knx-Verwendung dafür.

Und wenn nur der EibD aus Laufzeitanforderungen heraus einen Algorithmus durchläuft, der seinen Cache zeitlich verkürzt (wer weiß denn schon wie viele Stunden Cache bei höher werdender Buslast garantiert sind?), sind die Werte schlicht weg. Der wesentliche Unterschied zwischen (z.B.) einem 'Ein' Telegramm und einem statischen Wert wie die Sonnenaufgangszeit ist eben der, dass das Ein-Telegramm zu einer Aktion führt, der statische Wert hingegen nicht. man kann es mit 'Flanke' und 'Pegel' vergleichen: Der Bus ist ereignisorientiert, reagiert also auf Flanken. Eine Zustandsabfrage dagegen setzt immer ein KNX-Gerät voraus, das diesen Zustand gespeichert hat und es gestattet, ihn auch abzufragen, oder - eben den EibD-Cache, auf den man sich aus meiner Sicht aber nicht verlassen kann, was seine Caching-Zeitdauer anbelangt.

Ich bin nicht sicher, ob der wiregated einen eigenen Cache verwaltet. Das wäre dann noch eine Möglichkeit, die aber im Grunde nur eine grundsätzliche Eigenschaft des Busses kaschiert: Seine 'Nicht-Speicherfähigkeit'.

Langfristig zu erhaltende Werte wie die Uhrzeiten, Maximal- oder Minimalwerte etc. sind daher wie ich finde in %plugin_info am besten aufgehoben.

[emax]

So, das Plugin steht jetzt im svn.

Wie immer gilt: Erst mal bitte testen, man kann beim Einstellen ins svn immer mal was übersehen.

[haegar80]

Hilfe, was hab ich da angerichtet...

Ich wollte doch nur mal meine Bedenken in den Raum stellen. Nicht daß jetzt alle die Plugins nur noch ins Wiregate schreiben lassen und wir uns so langsam eine Insel bauen, auf der wir nicht mehr runter kommen.

Meine Bedenken, sind aber mit euren posts ausgeräumt. Wollen wir mal hoffen, daß die Comet Visu die Wiregate Variablen ausgeben kann.
Sonnenauf-/-untergang ist ja z. B. ein nettes Gimmick auf der Startseite

Danke für die vielen Postings
Sascha

[greentux]

Man wird doch hier mal diskutieren können
Da ist nix "angerichtet".

Ich bin halt der Meinung, das man selbst mit dem WG nicht alles erschlagen kann/erschlagen sollte... Das wird spätestens jeder mal erfahren, wenn das WG mal nicht mehr geht
Dann läuft der linknx auf der Fritzbox immer noch...
Naja, seis drum, die Sonnenzeiten werden auch mir nutzen.

[emax]

Hilfe, was hab ich da angerichtet...

Nene, lass mal, das ist schon in Ordnung so. Gerade solche Diskussionen machen transparent, warum manche Dinge so entschieden wurden, wie sie entschieden wurden. Dann stehen die Leute auch dahinter.

Und vor allem ergibt sich ja immer auch die Chance, das eine Sache ja vielleicht tatsächlich besser anders gemacht werden sollte. Mir zum Beispiel ist durch Deinen Beitrag überhaupt erst bewusst geworden, dass andere Methoden ja auch Vorteile für andere Systeme haben könnten, auch wenn das speziell beim hier vorgestellten Plugin m.E. nicht der Fall ist.

Passt schon. :-)

[makki]

Ich darf meine Meinung noch etwas konkretisieren, da es bei dieser Sache IMHO um ganz eminentes Grundverständniss geht

Im Schnelldurchlauf: KNX ist eventgetrieben, dezentral. Das hat so natürlich auch irgendwie Einfluss aufs WireGate genommen..

Also jeder Teilnehmer kennt "seinen" Zustand, gibt diesen aus und kann - so gesetzt - auch gelesen werden. So hat sich IMHO jeder KNX-TLN zu verhalten, fertig; Geräte die im KNX hängen und davon nichts wissen wollen sind fehl am Platz.
Also im Prinzip gilt das also auch für HS,WG&Co wenn sie denn da dranhängen (tun sie ja auch beide so)


Mit einer mehr oder minder zentralen Logik kommt man da aber nun ganz leicht in die Bredouille; es gibt viel mehr Stati, Variablen als GAs, notwendige Persistenz etc.

Mein Grundprinzip, mit dem ich übrigens auch sehr gut fahre: wichtige Werte, die anderswo verwendet werden sollen kommen sauber (=schreibend&lesbar!) auf den Bus.
Dieser ist dabei aber keinesfalls als remanent anzusehen, auch der eibd-Cache ist eben nur ein Cache der Traffic verhindern - aber auch genauso gut gerade leer sein kann weil er - warum auch immer - gerade neu gestartet wurde.
Ergo, alle diese Werte werden zyklisch gesendet und sind im Regelfall aber auch per Lesetelegramm abrufbar. Damit kann jeder andere TLN - sei es eine Visu, HS, EibPC, ... - lokal oder anderswo - sich diese ggfs. jederzeit holen. Ob der Wert dann letztlich aus dem Cache, $plugin_info, 1-Wire, HS remanentspeicher oder .. kommt ist dem Empfänger ja egal.

Jedenfalls, wenn man das so verinnerlicht und konsequent umsetzt, kann man die Sachen dann auch schön aufteilen.

Fazit aus WG-Sicht:
- Will man sich nur etwas dauerhaft, lokal merken: $plugin_info
- Will man etwas lokal erzeugtes/gelesenes woanders verwenden, darstellen: $plugin_info + schreibende und lesbare GA
- Verwendet man einen extern bereitgestellten Wert eines anderen Gerätes: keinesfalls merken! immer lesen. (der eibd-cache tut hier dann genau das was er soll..)
Bei allem anderen, sei es linknx auf der Dreambox, HS oder sonstwas sollte man es genauso halten.

-> Ergo, Beispiel zum Thema:
- Man benötigt den Sonnenstand. lat/lon und Zeit hat man dort lokal.
- Das Ergebniss soll sowohl in Berechnungen einfliessen als auch in der Visu angezeigt werden -> Ergebniss muss auf den Bus.
- Man entscheidet sich, wer rechnen soll (Wetterstation, HS, WG, ..) -> Aber nur dort braucht man z.B. lat/lon einstellen und speichern, interessiert ja sonst keinen (ausser man will dem Nachbarn beweisen das man seinen bekannten Breitengrad in der Visu stehn hat..für mich z.B. ein klassisches Beispiel für Werte die die Welt nicht in der Visu braucht ausser zum NBF)
- Alles gut, jeder kennt den Sonnenstand.


-> Ergo2: zuwas sollte die CometVisu interne Variablen lesen können?
Klar das ginge jetzt recht einfach aber andere hätten ein Problem damit, wer sagt denn das die CV zwangsweise auf demselben WG wie das Plugin läuft ? Vielleicht gibts ein WG im Ferienhaus im Süden und eins in der schwäbischen Heimat -> Lieber von Anfang an richtig!
Im Flur läuft die HS-Visu, aufm Chumby&Co die CometVisu und auf dem nicht vorhandenen iGitt vielleicht CommanderconFusion Alle sollen funktionieren und IMHO jederzeit ersetzbar sein. Die Zeiten sind schnellebig, die Basics aber nicht..

Hoffe zumindest keine weitere Verwirrung angerichtet zu haben

Makki

[makki]

Ad2: Der Wizard..

Ich fände es ja nicht schlecht, wenn man daraus eine Webmin Oberfläche zur verfügung stellt, die nach den grundlegenden Konfigurationseingaben fragt:

Nun im Kern ist es das und schlecht fände ich das auch nicht: Der Unterschied zwischen hübsch&schön oder "nackigem" Sourcecode (bzw. einer Handvoll Parameter).

Aber jetzt muss ich doch etwas ausholen:
[Philosophie value=on]
Es ist nun leider so, das eben dieser kleine Wizard, der 3 Dinge nett abfragt (mit Fehlerkontrolle, das ein AW auch "WieWeißIchNäd" eingeben könnte - "anwenderverständlicher" Fehlermeldung etc.) gefühlt ungefähr den doppelten Zeitaufwand erfordert wie die restlichen 50 Zeilen eines wirklich komplexen Plugins.
Darf man von einem SmartHomer/SI 2011 erwarten das er Parameter in Gänsefüsschen setzen kann? Ich denke schon, weil er muss viele andere, hässlichere Dinge auch meistern.

Und die Flexibilität erheblich einschränkt, weil wenn man etwas ändert muss man danach nochmal Faktor 2 für die Anpassung des Wizards einplanen; also könnte ich niemals "mal schnell" ein Plugin für ein konkretes Problem in 10 Minuten hier abliefern sondern müsste immer Plugin/Änderung, dann sehen wie es der schöne Wizard findet, anpassen, Test, release, ...
Von anderen, vielen hier aktiven nicht zu sprechen, die darauf sicher eher noch weniger Lust haben, nachdem es läuft nochmal die doppelte Zeit zu verschwenden es nun etwas hübscher zu machen..
-> Irgendeine Kröte muss man nun schlucken, entweder schön und dauert ewig weil der Designer ja dann auch noch drüberschauen muss (ich wüsste spontan ein Beispiel, wo seit Jahren nichts voran geht, aber ich verkneife es mir)


-> Da haben wir - ganz bewusst - mit den Perl-Plugins eben einen ganz anderen Weg gewählt: es gibt zwar ein bisschen hübsch für die Basiseinstellungen des WG und eine definierte Laufzeitumgebung, die das Leben nur erleichtern soll (also das man sich z.B. nicht mit dem wie&warum von KNX oder DPT im Detail rumschlagen muss) aber ansonsten einfach ganz "echt" ist. Echte Compiler-Fehlermeldung, vielleicht manchmal anstregend, dafür aber auch alle Möglichkeiten.. Emails versenden, beliebiges parsen uvm. Manch Hersteller masst sich ja da an, "mal eben" eine eigene Programmiersprache erfinden zu wollen/müssen.. Klar, das kann man auch versuchen..
Aber dazu (Perl) gibt es ja bereits Milliarden Beispiele, Millionen Tutorials zu jeglicher Problemstellung im Netz.


Zurück zum "Wizard": der macht das alles kaputt, all die Flexibilität, das sich z.B. emax einfach überlegt, wie er die config sep. ablegt, da spricht man kurz drüber und es geht. Sonst müsste ich sagen HALT: da muss ich erst den Wizard fragen, anpassen, kann man vorab schonmal alle möglichen Variablen/Parameter liefern?.. Oder, oder..

Will man das, wo man anderswo erst den Hersteller fragen muss bevor man anfängt, ob/wie man das nun debuggen kann oder ob man Modul abc auch ohne Freigabe verwenden kann ?
Klar, man kann fragen, wir antworten auch gerne, aber der Punkt ist: man kann, muss aber eigentlich nicht! weil man die AW zu 90% auch so er-gurgeln kann.. Und geht..


Letztlich ist es ganz klar eine Philosophie-Frage; ehrlich, mit jedem anderen GA/HA System kommt man auch - wenn man mehr als ein und/oder-Gatter braucht - nun auch ganz schnell in Kontakt mit Programmiersprachen o.ä. (oder warum kenne ich sonst python )
Die Philosophie hier ist eine verbreitete Standard-Sprache (Perl) in einer wohlfühl-Umgebung bereitzustellen aber ohne unnötige Restriktionen einzubauen oder eine neue Sprache zu erfinden.
Also wird einem eine gewisse Detailkenntniss nun eh zugemutet, das ist wohl auch irgendwo notwendig, meine Prämisse ist hier: es möglichst einfach zu halten (also keinen mit obskuren Perl-Details zu nerven die mir selbst bis heute schleierhaft), eben "normal", also so das es möglichst jeder der bei einer if-Schleife nicht tot umfällt nachvollziehen kann.
[/Philosophie]


Sicher gäbe es da aus heutiger Sicht einiges zu verbessern, einiges würde man auch bestimmt anders/besser machen (vielleicht auch garnicht mit Perl aber der Zug ist nun abgefahren und dazu stehe ich dann auch!), vieles aber auch ganz genau gleich. Den Wizard dazu allerdings ehrlichgesagt: Nein!
Wenn mal 1000 Smarthomes im Monat vom unwissenden Sachbearbeiter in Gang gesetzt werden müssen (und die ETS etc. das auch hergibt), dann verhandeln wir das nochmal

Aber andererseits, ganz ehrlich: ich weiss nicht wieviele der Fragesteller hier schonmal den Genuss erlebt haben, in einem HS-Baustein eine einzige Zeile zu ändern und bereits schlappe 15 Minuten später zu erfahren, was das bewirkt hat Dafür gibts da nen Grafischen Logikeditor usw... Diese Erfahrungen haben aber sicher auch dazu beigetragen das Plugins lieber gleich&sofort sagen müssen wo denn nun das Problem sein könnte.. Für Wizards war da bisher kein Platz

Makki

[StefanW]

Bei Notfällen ist unser Support rund um die Uhr erreichbar

Guten Morgen,

Ich bin halt der Meinung, das man selbst mit dem WG nicht alles erschlagen kann/erschlagen sollte... Das wird spätestens jeder mal erfahren, wenn das WG mal nicht mehr geht Dann läuft der linknx auf der Fritzbox immer noch...

Ah ja. Danke für die Vorlage, kann ich gleich mal was dazu schreiben.

85% aller Support-Fälle zu Wiregate & Sensoren werden hier in aller Öffentlichkeit im Forum abgehndelt. Wieviele ausgefallene Wiregate Multifunktionsgateways hast Du hier mitgezählt?

Nach meiner Übersicht haben wir ernsthafte Probleme bei unter 1% der Geräte pro Jahr, in der Hälfte aller Fälle davon war die Ursache, dass die Installation / Konfig vom Anwender per root selbst "geschossen" wurde. Kleine HW-Ausfälle (einzelne Ports wie Ethernet defekt) liegen vielleicht bei 0,3%. Ich glaube einen kompletten Totalausfall wo überhaupt gar nichts mehr funktionierte wegen Ausfall der kompletten Hardware hatten wir beim Wiregate Multifunktionsgateway noch nie.

Und selbst hier: Wir sind rund um die Uhr erreichbar über unseren 24h Service. Ganz einfach per Telefon auf unserer ganz normalen Geschäftsnummer die überall veröffentlicht ist. Bitte nur im Notfall in der Nacht um drei rausklingeln bitte!

Sollte also jemandem am Sonntag um drei in der Früh sein Wiregate Multifunktionsgateway (Busmaster, Fühler usw.) abrauchen, welches das gesamte Haus steuert, dann gibt es bei uns rund um die Uhr Support und auch Ersatz. Notfalls fährt auch jemand mit dem Ersatzgerät unter dem Arm los.

Macht AVM mit der Fritzbox das auch?

[emax]

Zur flexiblen Verwendung dieses Plugins habe ich hier ein Beipiel gepostet. Damit lassen sich auch Zeiten relativ zum Sonnenauf/untergang schalten.