Hallo,
ich weiß, das was ich hier fordere bzw. vorschlage ist sicher unpopulär. Aber es würde eine dicke Lücke in der programmtechnischen Verwaltung des Systems schließen, die ansonsten stundenlange und fehlerträchtige manuelle Routine-Klickerei an letztlich hunderten von Objekten erfordert.
Die Aufgabe:
In meinen Initial- und Systemwartungs-Routinen werden u.a. Sekundär-Variablen generiert und bestimmten Objekten zuweisen, z.B. Min-/Max-Werte, Zeitstempel als darstellbarer String usw., dabei ggf. anlegen/zuweisen
- Variablen selbst, Initialwerte
- Variablenprofil
- den Inhalt generierende Events
- Datenbankaufzeichnung
- Sichtbarkeit
usw.
Als zweite Stufe laufen dann Initialscripts für Erzeugung und Zuordnung der Objekte für Visualisierungen (Dummy-Instanzen bzw. Links) bzw. zur Zuweisung in diverse Schalt-, Filter- und Regel-Matrix-Scripts.
Soweit alles prima und läuft bestens, sogar auch hersteller-/modulabhängige Unterschiede beachtend und quasi Fehler selbstreparierend. ABER:
Das Problem:
Es gibt eine dicke „missink link“ in diesem ansonsten per PHP steuerbaren Initial- bzw. Pflegeprozess:
Die Daten der primären Variablen müssen einmal „angefasst“, also geändert werden (können), damit die per Event angekoppelten Scripts initial noch fehlende Variablen überhaupt generieren, bevor diese dann in Visualisierungsbereiche oder an Matrix-Scripten zugewiesen werden können.
Dazu muß man initial einmalig einen auslösenden Wechsel des Zustandes am Primärwert (z.B. Batterie, STATE, Temperatur, Humidity…) erzwingen, damit die Sekundärvariablen wie „Stand“, „Minimum“… durch die angekoppelten Eventscripts überhaupt erstmalig erzeugt werden. Erst wenn diese existieren, können die Scripts der zweiten Stufe sie greifen und als Link in Visualisierungen oder an die Matrix-Scripts zuweisen.
Wenn man nun nicht bis zum St. Nimmerleinstag warten will, dass auch der letzte Sensor einmal eine leere Batterie hatte oder ein Wasserschaden auftrat usw, bevor man die Zuweisungsscripte endlich komplett laufen lassen kann, sollte das natürlich besser „simulierend“ bedarfsweise ausgelöst erfolgen können.
Manuell ist das machbar nach Sicherheitsabfrage durch Klick auf den Inhalt der Variable in der Verwaltungskonsole. Was fehlt, ist aber eine Script-steuerbare Version dieses manuell zum Glück noch möglichen „testweisen/simulierten“ Ändern von RO-Variableninhalten, die ich hiermit vorschlage.
Nachtrag:
Natürlich wäre es möglich, jedesmal „Seit“, „Min“, Max" usw. gleich bei jedem einzelnen Objekt initial dediziert mit einzupflegen und damit das o.g. Problem zu umgehen. Das widerspricht aber allen Top-Down-Überlegungen, die z.B. am eventgekoppelten Script zentralisiert und nebenbei auch noch gleich automatisch fehlerkorrigierend evtl. fehlende Variablen und Zuweisungen wieder ergänzen. Als Ziel sehe ich bzw. habe ich (bis auf diese Lücke realisiert) ein selbstüberwachendes robustes System, das sogar ggf. anwenderseitig „aus versehen gelöschte/zerspielte“ Bereiche beim nächsten Event automatisch repariert.
Außerdem zentralisiert sich damit der Pflegeaufwand bei zu ändernder oder zu erweiternder Funktionalität auf genau eine, sowieso die spezifische Funktion beinhaltende Stelle im System. Weiterhin automatisieren sich damit alle Ergänzungen um weitere funktionsgleiche Objekte (weiterer Sensor, weitere Heizung…) auf pures Anlegen der Primär-Instanzdaten und einmaliger Bestands-Eintrag im zyklisch arbeitenden Wartungsscript. Alles andere passiert dann von alleine. Zwischendurch hier reingehen zu müssen und „per Hand alle Variablem mal wackeln zu lassen“ ist da einfach irgendwie anachroistisch.
Sorry, dass ich schon wieder so viel geschrieben habe, aber ich wollte lieber gleich nachvollziehbar begründen, warum ich an dieser neuralgischen Stelle (schreiben in RO-Variablen?) eine Änderung vorschlage.
Als Alternative zum Schreiben in RO-Variablen könnte ich mir ein simuliertes Feuern von Events vorstellen, also PHP-seitiges Auslösen „als wenn das Event eingetreten wäre“, was das Problem ebenso lösen könnte.
Wie ist Eure Meinung dazu?
Gruß Gerd