Ich nutze das hier:
Etagenlicht
Kann man natürlich auch zum einschalten nutzen…muss man nur leicht modifizieren.
Michael
ok, danke, das schaue ich mir auch.
Mein anderer Gedanke den ich noch habe ist, ob man grundlegend immer mit einem Dummy Modul arbeiten sollte.
Weil, letzten Endes macht man doch folgendes. Man legt einen Aktor/Sensor etc. an.
Jetzt erweitert man doch dieses eine Geräte mit neuen Eigenschaften, ich versuche das ein wenig zu vergleichen mit
dem ableiten einer Basis Klasse, kann man das so sagen?
Um diese Basis (z.B. Aktor) erweitert man doch um neue Variablen, Codefragmente.
Vom Prinzip her hab ich indirekt über das Dummy Module in Anführungsstriche eine neue bzw. eine erweiterte Dummy Instanz.
Kann man das so sehen, ist das aus meiner Sicht richtig erklärt?
Gruß
Ich wollte nochmal hören was ihr zu dem Post zuvor sagt…
Ich denke, du interpretierst da zuviel hinein. In der Doku steht:
Das Dummy Modul ist eine Instanz, die keine eigenen Funktion oder Status Variablen beinhaltet. Das Modul kann nur als Platzhalter verwendet werden, um als Gerät in der Visualisierung dargestellt zu werden.
Es ist nur ein Gliederungselement im WebFront. Mehr nicht.
Gruß
Burkhard
Also ich kann der Methode ein include Konstantenscript anzulegen, mit Definitionen, nur anschließen. Das mache ich seit Jahren so und es hat sich bewährt.
Man kann komplexe Arrays perfekt in Schleifen verarbeiten und so ganze Gruppen schalten.
Hier ein Auszug aus meinem Konstanten Script:
// array(Aktor Name, Aktor Instanz ID, Aktor Bezeichnung, Aktor Status ID, bei Haus aus ja/nein)
$FS20[] = array($EG_Au_Steckdose_Webcam = 19772,'Erdgeschoß Steckdose WebCam Eingangsbereich',38737,false);
$EATON[] = array($KG_Ga_Schalter_Deckenlicht = 14038,'Kellergeschoß Garage Schalter Deckenlicht',52026,false);
das weis ich, nur rein theoretisch. Ich möchte auf das hinaus das ich mir indirekt eine Gruppe mit seinen neuen bestimmten Eigenschaften zusammen baue. Dazu nutze ich das Dummy Modul so zusagen als neue Instanz/Speicher/Objekt wie auch immer man das nennen möchte.
Zu einem habe ich meiner Meinung nach folgendes erschlagen.
Scripte, Variable Ereignisse etc… liegen direkt unter dem Dummy und man hat auch noch die Verbindung zum WebFront und kann alles ausblenden was nicht im WebFront sichtbar sein soll.
Dann wäre ich lös gelöst von Scripten worin fest vorgegebene IDs von irgendwas haben.
Dazu baue ich mir ein Script was mir die Struktur unterhalb vom Dummy Modul der diversen Variablen (Eigenschaften) ermittelt wie Helligkeit, EinAus, Instanzen etc.
Heißt ich hätte alle meine Variablen die eine Eigenschaft sein können, z.B. „EinAus“. In dem EinAus Actionscript
werden dann noch weitere diverse Scripte aufgerufen die den Strukturaufbau ermitteln und dann den Aktor bzw. die Gruppe ansteuert.
Entweder verlinke ich meine Aktoren unter die Gruppe oder ich suche die mir anderweitig zusammen.
Aber das lasse ich erstmal aus.
das mit den festen IDs möchte ich grundlegend nicht, ich würde gerne ein Script erstellen und das handelt alles ab und
von aus dann nur noch im IPS BAum arbeiten und zuweisen und verlinken …
Gruß
Ok, warum nicht. Wenn es deinem Ordnungsprinzip gerecht wird. Aber genauso gut könntest du eine Kategorie wählen.
Die Verbindung zum Webfront sehe ich eher weniger. Denn es gibt - zumindest meistens - nicht nur ein Webfront. Oft hat man ein ‚WebFront Administrator‘ und z.B. ein ‚WebFront Familie‘. Hinzu kommt noch eine Sicht für die Mobile App.
Also tut man gut daran, bei den Webfronts nur mit Links zu arbeiten.
Ich weiß ja ncht warum Du Dich gegen ein Script mit festen IDs so sträubst, der große Nachteil Deiner Variante ist m.E. der viel zu aufwendige Aufbau des Ojektbaums. Im Prinzip schon die Anlage der vielen Objekte mit unsichtbar machen etc. würde mich nerven.
Zum anderen ist die Möglichkeit eine Eigenschaft zu löschen oder hinzuzufügen in einer Gruppe von IDs in einem array viel schneller.
Der PHP Editor ist da ein mächtiges Tool, wenn es um ersetzen, finden und Referenzierung geht. Mal abgesehen das Deine Scripte ohne IDs sehr abstrakt werden und sich bei Änderungen in so etwas jedes mal wieder hinein zu verstzen fällt schwer. Ich habe das bei mir nach 2 Jahren IPS Abstinenz gemerkt…
ja mein Ordnungsprinzip möchte das auch so :D:D:D, Ordnung ist das halbe leben … und beim Programmieren ein Muss egal in welcher Umgebung … Natürlich wird in Richtung WebFront nur mit Links gearbeitet, entweder das ganze Dummy Modul verlinken und oder auch nur dann vereinzelte Elemente …
Daher blieben Kategorien bei mir auch einfach nur zur Strukturierung meines IPS Baums.
Mich würde sehr gerne interessieren was andere dazu sagen bzw. es bei sich strukturieren …
Ist das halt ein guter Ansatz, total daneben oder ja ist ein relativ guter Weg von tausenden …
Das ist für mich persönlich entscheidend.
Ich versuche eine gute Wartbarkeit zu erreichen und am besten so, das man eigentlich wenn es neue oder defekte Aktoren gibt das dann nur noch über den IPS Baum zu arbeiten, ohne das man nachher in die Scripte muss und IDs ändern.
Das geht meiner Meinung nach ganz schnell in die Hose, zu suchen zu ändern etc …
Ein Konstrukt habe ich mir ja schon im IPS gebaut, ändere ich das ganze möchte ich schon gerne Meinungen vorab von euch hören weil das ja schon viel Arbeit ist und man sich sehr schnell in was verrennen kann, ich mach das halt leider nicht so zwischen Frau und Kinder und andere Hobbies …
Gruß
weil es in meinen Augen nicht wartbar ist …feste Verknüpfungen sind nicht dynamisch. Wir versuchen doch alle so dynamisch wie möglich zu sein. Ob jetzt mehr oder minder gut oder schlecht egal. Das ist aber doch eigentlich auch das was es ausmacht. Am liebsten läuft alles von alleine oder? Das klappt nicht weil dann würden wir ja nicht ständig an der Kiste hängen und damit rumspielen und ständige Änderungen und Verbesserungen durchführen.
Ich sage immer zum IPS, das ist die neumodische Märklin Bahn …
warum aufwendig? Dummy anlegen, dann darunter alle Variabel anlegen die eine Eigenschaft oder Aktion
beschreiben was mit den Aktoren gemacht werden soll, allgemein gültige Scripte die unabhängig von irgendwas laufen können …
Wie du dann deinen IPS Baum grundlegend organisierst und so aufbaust das man alles schnell finden kann obliegt ja jedem selber. Also das bleibt eigentlich überhaupt nicht aus, ich denke das jeder seine Aktoren und sonstiges Kategorisiert.
also anlegen und was machen muss man immer. Die Objekte sichtbar/unsichtbar machen kann auch automatisiert laufen.
Sowas mache ich nicht von Hand
ich denke nicht das es wirklich schneller ist, wenn du ein Script hast was dir dein Dummy Modul einliest und schaut was alles darunter liegt welche Eigenschaften der Aktor haben kann.
Man muss ishc natürlich für das Script überlegen wie sammel bzw. erkenne ich meine Eigenschaften.
z.B. EinAus -> gebe ich der Variabel den Namen EinAus und muss sie finden.
Das der Editor ok ist, ist ja nicht die Frage.
ja da gebe ich dir Recht, aber das ist halt das Los jedes Entwickler. Dokumentieren Dokumentieren Dokumentieren.
Wenn ich irgendwann meinen eigenen Quellcode oder Konstrukt nicht mehr verstehe, dann ist grundlegend was falsch gelaufen.
Ich weis wie es läuft, es macht keiner zu 100% und selbst dann muss man sich immer wieder neu rein denken.
Wenn man aber sich was geschaffen hat, das „Eigentlich“ keinen wirklichen Eingriffe mehr benötigt, dann ist doch erstmal gut. Wenn dann doch Änderungen aus was für Gründe sich auf tun, ja dann muss man sich wieder rein arbeiten.
Aber das ist nun mal das womit man grundlegend zu tun hat …
[/QUOTE]
Gruß
Hi,
hab mal meine erste Auswertung in einem Screenshot zusammen gefasst.
In der ersten Array Ebene „GRP“, „INST“, „VARS“ etc. sind meine Eigenschaften die ich eingesammelt habe.
„GRP“ ist was spezielles, da überlege ich mir ob ich die Instanzen in die Gruppe verlinke oder ob ich mir mein bestehendes Konstrukt verwende um meine Aktor zu finden. Das mal außen vor lassen.
Alles andere weiß ich über die Namen, die muss man nun mal „einmal“ definieren. So nun kann ich mit meinem Dummy Objekt arbeiten, hab alles was ich brauche, Scripte, Zustände Variabel etc .
So für das erste…
