Bus-Profi Forum

Etwas Theorie vorweg:
Da man die LCN-Module (noch?) nicht richtig programmieren kann, wie wäre es dann wenigstens mit einer "objektorientieren Parametrierung" ? Ein Prinzip der objektorientierten Programmierung ist ja, das nur jedes Objekt selber über seine Internas Bescheid wissen soll und von aussen (von anderen Objekten) nur über wohl definierte Interfaces (Methoden/Funktionen) angesprochen wird. Auf LCN übertrage ich das so, daß jedes Busmodul (UPP, SH, LU, ..) nur selber weiss, ob und wie es seine beiden Ausgänge nutzt und ob Relais (und welche Verbraucher/Aktoren) angeschlossen sind. (Gleiches für Sensoren ...)
Andererseits sollten alle Module (Objekte) bestimmte Funktionen (Methoden) ausführen können oder sie zumindest verstehen. Ich denke dabei an Funktionen/Zustände" wie "Alles ausschalten", "Es ist Nacht/dunkel" / "Es ist Tag/hell", "Es ist niemand zu Hause" / "Es ist jemand zu Hause" usw. Bestimmte, spezielle Funktionen/Zutände sind vielleicht nur für eine Teilmenge (eine Teilklasse) von Modulen relevant. "Es ist sehr windig" oder "die Sonne scheint in die Ostfenster / Südfenster / Westfenster".interessiert wahrscheinlich nur Module mit Rolladen, Jalousien oder Markisenanschluss. Eine gewisse Art von Objektverwandschaft (Objekt-vererbung kann man das wohl noch nicht nennen) haben LCN-Module durch die LCN-Gruppenbildung. Diese erlaubt sogar eine "multiple Verwandschaft", da ein Modul mehreren Gruppen angehören kann und somit dann jeweils deren gemeisame Funktionen unterstützen sollte.
Der Interfaceumfang eines Moduls besteht im wesentlichen aus den verschiedenen Tastenaufrufen. Einige werden durch Bewohner direkt ausgelöst (Taste A1-A8 kurz/lang/los) oder per Infrarot (A,B oder C Tasten) oder sonstige Sensoren/Ereignisse (B, C, D). Die Module untereinander können ebenfalls diese Funktionen/Methoden (Tasten) aufrufen. (Man könnte Kurz,Lang und Los als Parameter zu einem Funktions/Methoden-aufruf ansehen oder eben als 3 unterschiedliche Funktionen/Methoden.)
Dann gibt es wohl noch einen Haufen von Status- und Programmierfunktionen, die die LCN-Module verstehen, aber die nicht alle öffentlich dokumentiert sind und meist auch nicht "parametriert" werden können. (Ein Beispiel wäre sonst: "Modul X, sende mir bitte Deinen aktuellen Temperaturmesswert"). Ein bischen Rechen-/Regel-werte verschicken, das geht anscheinend schon.

Da die Tastenfelder A, B,C viel von anderen Sachen benutzt werden, kann man am ehesten im D-Tastenfeld eigene Funktionen/Methoden definieren, denn es gibt leider noch keine weiteren freien Tasten, die man mit "Sende Taste ,,," aufrufen kann.

Praktische Frage:
Gibt es Empfehlungen oder Konventionen, nach der man die D-Tasten mit bestimmten allgemeinen Funktionen belegt. (Z.B. Taste "D4 Kurz" für die Funktion "Alles ausschalten" ? Jedes Modul (in der Gruppe) muss dann bei "D4-Kurz" intern hinterlegen, was es denn alles bei sich selbst "ausschalten" will.

Theoretische Hoffnung:
Wenn man dieses objektorientierte Prinzip bei LCN durchhalten möchte, brauchte man für die vielleicht praktisch vorkommenden 20-40 allgemeinen Funktionen schon je eine eigene Tastenfunktion. Dazu noch die vielen speziellen Funktionen, die bestimmte Module (z.B. Rolladen) noch zusätzlich verstehen können sollen. Da reichen dann die A-D Tastentabelle auch nicht mehr aus und am liebsten möchte ich die Funktionen/Methoden auch mit Ihrer Bedeutung benennen können = also Funktion "Alles ausschalten" statt "D4 kurz". Allein für diese Zwecke könnte man schon mal 100 benambare Tasten/Funktionen/Methoden in LCN gebrauchen und so auch eine bessere Programm-Übersicht behalten statt der festen Kurznamen, die heute aus Platzmangel sicher auch mal in anderen Modulen mit anderer Bedeutung belegt werden müssen. (Naja, solche Programmierfreiheiten brauchten dann auch einen Compiler oder Interpreter).
---
Puuhhhh - hat wirklich jemand bis hierher gelesen ? = Danke

Hallo Martin,
das ist wie "ist schon wieder Weihnachten" - ein Wunschzettel

Daß das meiste funzt (nur nicht so "komfortabel", wie du es gerne hättest), ist dir schon klar, oder(?)

2/3 deiner Wünsche würde ich glatt unterstützen, 1/3 ist "IT-Spleen" - was nicht "sinnlos" heißen soll.

Wir werden in ein paar Jahren mal schauen, was sich da bewegt hat.

Nun denn, LCN-Fee ... (Wunsch ist Wunsch);-)

Uwe

Hallo Martin

Ist ein guter Ansatz... aber nur wenn man LCN mit einer entsprechenden SW programmieren kann. Die einzelnen LCN Module werden wohl auch in naher Zukunft sich nicht mit objektorientierter SW rumschlagen können (kann übrigens der normale PC auch nicht). Da wir mit LCNP oder LCNPro recht "systemnah" programmieren, werden wir mit diesen Konventionen weiterarbeiten müssen.

Hingegen kann es sinnvoll sein, einen Wrapper zu schreiben, der OO Code in LCN Commands umsetzt. In meinem Web-Interface wird automatisch für jedes neue LCN Modul, dass sich mit einem Command oder Status auf dem Bus meldet ein LCN Object im Memory generiert. Als properties besitzt dies den aktuellen Wert (wird natürlich nachgeführt); dann gibt es Unterobjekte, welche die verschiedenen Ausprägungen von LCN Modulen repräsentiert. D.h. ein normales LCN Power Object mit ein/aus/dimmen oder ein Temp. Modul mit Temperatur Wert in Grad sowie einer Methode zum Statusabfragen etc. etc. Ich generiere aus all den verhältnismässig kryptischen LCN Messages XML Streams, welche dann von den LCN Objekten (die auf einem anderen Rechner liegen können) gelesen werden können. Jedes LCN Objekt kann sich serialisieren; d.h. mit einer Methode "toString" liefert das Objekt einen XML Code der dann genau den aktuellen Stand repräsentiert, per Netzwerk versendet werden kann oder einer DB gespeichert werden kann. Bei Bedarf kann man zu einem späteren Zeitpunkt das LCN Objekt wieder zum Leben erwecken mittels der genauen XML Definition.

Hm... aber wie gesagt, dem Otto-Normal-LCN Programmierer bringt dies wenig, sofern er nicht diese oder eine ähnliche Anwendung in Betrieb hat.

Uwe sagt schon richt => mit etwas Schweiss bringt man das von Dir vorgeschlagene auch "traditional" oder "classic" oder "old school" hin!

Schöne Grüsse, Florian

Florian:[zitat]Ich generiere aus all den verhältnismässig kryptischen LCN Messages XML Streams, welche dann von den LCN Objekten gelesen werden können. Jedes LCN Objekt kann sich serialisieren ...[/zitat]
Hmmm, das geht ja runter wie warme Butter ...
SEHR SCHÖN !
Damit hast Du ja die wesentlichen Bausteile zusammen, um ein neues \"LCN-Pro\" zu programmieren, das sich dann objektorientierter darstellt. Auf Knopfdruck könnte dann eine LCN-Parametrierung generiert werden, die mit den wenigen physikalisch vorhandenen LCN-Resourcen (Tasten) auskommen muss. Sonst gibt\"s Fehlermeldungen, dass die Programmierung zu komplex ist für die (heutige oder bisherige) LCN-Hardware.
---
Nur weil ich noch nicht durch eine LCN-Schulung eingenordet wurde, erlaube ich mir solche Wunschzettel aufzuschreiben.
Florian, hast Du schon eine Schulung durchgemacht ???

---
Uwe,
ich habe ja auch eine Praxisfrage in meinem Wunschzettel versteckt:
Gibt es Empfehlungen oder Konventionen, nach der man die D-Tasten mit bestimmten allgemeinen Funktionen belegt. (Z.B. Taste \"D4 Kurz\" für die Funktion \"Alles ausschalten\" ?

=> Macht das jeder so wie er will, oder gibt es in der Schulung Teil 3 eine Empfehlung wie: \" immer bei Taste D4 LANG hinterlegen\" und \" immer bei Taste D4 KURZ hinterlegen\". ... und Aktionen die bei starkem Wind nötig werden auf Taste D1 LANG legen usw. ..

Gruss, Martin
PS: Gibt es keine symbolischen Namen, brauchen wir eben Konventionen !!

Hmm, und irgendwie kann ich nicht mal jeder Taste einen eigenen Kommentar verpassen, in dem ich die Bedeutung dokumentieren könnte. - schon wieder was für einen Wunschzettel ??
Soll ich denn die LCN Parametrierung etwa extern auf Papier dokumentieren ??? Auch nicht sehr \"objektorientiert\" - alles, was zum Objekt gehört, auch Kommentar sollte auch dort abgelegt werden.

Hallo Martin,
deine Praxisfrage kann ich noch beantworten: "NEIN", es gibt keine Richtlinie. Hier kannst du (ich) jeder Anlage(Objekt) deine "persönliche Note" verpassen. Die älteren Module haben ja tw. auch nicht alle Tastentabellen.
Die Empfehlung ist nur (sinnvollerweise, für uns "logisch") in einer Anlage möglichst in allen Modulen die selbe Taste für gleiche zentrale Funktionen zu nutzen.

In den "alten" Modulen (Prozessor) ist der Speicherplatz begrenzt. Man(n) hat ihn dann lieber für Funktionen statt für Kommentare genutzt (100 Lichtszenen sind "mehr wert" als Tastenkommentare ). Wie das bei den "neuen" ist (oder werden kann) - ???

Im übrigen möchte (eigentlich) jeder Kunde bei Fertigstellung der Anlage eine Dokumentation in Papierform (Ausnahme IT"ler, die das auch "lesen" können, was da raus kommt ).
Es gibt eben Dinge, die erst mit einem Fetzen Papier ein voller Erfolg werden

Uwe

Um Himmels Willen, meiner Meinung nach ein eindeutiges Nein!

Was schreibt ihr da?

"verhältnismässig kryptischen LCN Messages" die ihr zu "XML Streams" verwursten wollt? Mache aus 3byte mehrere k Overhead?

"Da wir mit LCNP oder LCNPro recht "systemnah" programmieren" - wie programmieren? Das hin - und hergeschiebe mit der Maus (LCNPRo) ist programmieren? Und was ist daran Systemnah?

Soll aus einem Installationsbus so etwas werden, wo sich gerade der ehemalige html Teil des Internets bewegt? Plugins, Sessions-IDs (die deep links unmöglich machen), Scripte etc.pp., die aus Information langsame, uninteressante Buntheit machen (wenn es nicht Laufzeitfehler, bockende Scriptfilter, oder nicht verfügbare Breitbandanschlüsse den Unfug vorher stoppen)

Ich würde es sehr begrüßen LCN Module systemnaher bzw überhaupt erst einmal programmieren zu können, das jetzige Geklimper bezeichne ich i.d.R. als Parametrieren. Eine mehrfache logische Verknüpfung und zwei bedingte Verzweigungen sind 5 oder 6 Zeilen Quelltext in <5min geschrieben, mit LCNPro 1/2h oder 1h? Und man verbruzelt sinnlos Schwellwerte und C-Tastenbelegungen. (der Gelegenheitsinstallateur macht das gar nicht, verkauft solche Funktionen also auch nicht)

Entweder in einem C oder Basic oder was auch immer Dialekt, wo man an dieses ganze ABCD Tabellen Gewurschtel und Tastensperren/Treppenhauslicht Timeraufteilung nicht mehr gebunden ist, sondern die Ressourcen so aufteilt, wie man sie braucht. 100 Lichtszenen, aber man kann nicht mal die Speicher der Positionierung abfragen - lachhaft!
Der Quelltext muß vor laden in ein Modul natürlich vorher compiliert werden (so ähnlich macht das z.B. Conrad mit seinen C-Control Baureihen - deutlich flexibler!)

Alternativ gleich mit dem RISC Befehlssatz in Assembler, wobei das sicher für den Alltag nicht tauglich nicht. (in einem SH+ habe ich einen Motorola MC68HC705C9ACFN gesehen, was in den neuen HU drin ist weiß ich nicht, lt. Uwe irgendwas mit Flash)

Für letzteres müßte Hr. Issendorff allerdings von seiner Geheimniskrämerstategie abweichen und Protokoll und Schaltung veröffentlichen... wohl eher unwahrscheinlich.

Man kann es wahrscheinlich nur Elektriker-, oder Ingenieur- oder Informatikergerecht machen.
Die Lösung für den Elektriker haben wir jetzt, der Informatiker möchte Objektorientierung, mir wär Assembler am liebsten... ein Basic- oder C-Dialekt (wo man im Quelltext endlich ordentliche Kommentare reinschreiben kann und sinnbehaftete Variablennamen vergeben kann u.v.a.m.) wäre wahrscheinlich der beste Kompromiss. Und man würde das sinnlose hin- und her gehüpfe mit "sende Tasten" über mehrere Module nicht mehr benötigen. Die z.Zt. mögliche Parametrierung würde durch eine leichtere Programmierung ergänzt. Wenn man alle Befehle, die via LCN Protokoll an andere Knoten gesendet werden auf einen standardisierten Befehlssatz beschränkt (wie jetzt, nur noch ein paar Befehle mehr ) wären beide Welten sogar kompatibel!

Hr. Issendorff lesen sie mit? Schauen sie mal zum Wettbewerber seebacher.de - die Textbasierende Programmierung/Parametrierung für ISYGLT (ProgrammDesigner) scheint mir auch für LCN einen Gedanken wert zu sein, oder ein Blick zur C-Control II mit ihrem C-Dialekt.

Viele Grüße - Thomas Einzel

Hallo Thomas

Wie ich schon weiter vorne im Thread geschrieben haben => das solche HW Module "objekt-orientiert" programmiert werden können, macht nicht wirklich Sinn und ist sicher auch nicht möglich.

Ich stimme Dir absolut bei, dass es eigentlich ein parametrisieren und nicht programmieren ist und dieses hin- und her gehüpfe nervt mich auch sehr !!

Ich arbeite in einer Welt, in der Banken Ihre geschäftskritischen Applikationen auch in Browser-Anwendungen betreiben => Wenn das dort geht, denke ich, dass man die gleichen Ansätze auch für eine private Lichtsteuerung verwenden kann.

Hier trennen sich die Geister => aber eins ist klar: Eine Offenlegung der Spezifikation wäre für alle Assembler/C/Pascal/Java/VisualBasic Programmierer unter uns eine grosse Erleichterung und würde schneller neue Innovationen rund um die LCN Technologie zu Tage bringen. EIB ist beispielsweise offengelegt; jedoch ist dort die Busansteuerung ziemlich tricky...

Schöne Grüsse
Florian