Ansatz.
Man hat ein WebUI programm geschrieben und möchte dieses nun testen in Realumgebung, also mit den Geräten etc. Wenn man nun Dinge testen möchte wie z.B helligkeiten, temperaturen, Luftfeuchtigkeiten und vieles mehr war oft der weg, entweder warten bis sich einentsprechendes Scenario einstellt, den geräten mit feuchtigkeit, Heissluftfön etc zu Leibe rücken, sämtliche Wete über Systevariablen zwischenkoppeln (so die allgemein üblcihen Lösungswege)
Es gibt noch einen anderen, eigentlich ist dieser sogar von EQ3 dokumentiert (offizielle xmlrpc Dokumentation, Kapitel 5.1 methoden der Logigschicht - event. also keine Geheimnisse, an die man nur mit einem Disassembler kommt oder die man hüten müsste wie die Abschusscodes von Atomraketen
über diese Logigschicht methode teilen die Schnittstellenprozesse der Rega änderungen ihrer Zustände mit. Und das ist dann der Punkt an dem sich der SDV auch einklinkt.Anwender des SDV kannten ja schon die Möglichkeiten Datenpunkte oder Systemvariablen mit der Eigenschaft operation_write mit dem SDV zu verändern.
Eigentlich ein kleines WebUI programm nun, um dies zu demonstrieren.
Nun wollen wir allerdings die Funktion dieses Programmes prüfen. Dazu müssen wir den Humidity Datenpunkte ändern. Der Datenpunkt Humidity ist allerdings einoperation_read, operation_event, also kein Datenpunkt, den wir mit state oder value irgendwie geändert bekommen. trotzdem lässt sich im SDV nun dieser Datenpunkt bei Value anwählen und editieren:
wir wollen testen, also stellen wir anstatt der gemessenen 42% nun mal 84% ein und sagen Wert übernehmen. Die Funktion Des SDv erkennt selbsständig, ob dieses ein Datenunkt ist der sich normal über .State () oder .Value () umschreibenlässt, oder aber ob der etwas brutalere weg über xmlrpc.event zu nehmen ist.
ein Blick in die WebUi verrät uns: die rega hatte die zwangsweise untergeschobenen Daten übernommen
wir konnten sehen, das programm hatte getriggert:
der Zustand bleibt natürlich so lange bestehen bis... logischerweise der xmlrpc process über den gleichen Weg der rega ein neues messergebnis mitteilt. es ist ja der gleiche Weg. Allerdings lassen sich so sämtliche Datenpunkte der rega setzen bzw verbiegen. Auch zum testen von Systemmeldungen auf dem Channel:0 funktioniert diese Vorhehensweise. Wenn einer beospielsweise Scripte für Kommunikationsstörungen etc schreibt, so kann man auf dem Wege zum testen Störungen setzen und auch wieder wegnehmen.
Logischerweise hier der Einwurf:
Das ist kein Spielzeug um irgendwelche Störungen wegzuklicken (geht) oder wahllos irgendwelche Daten zu setzen (geht auch) sondern um Sinnvoll mit der CCU zu arbeiten bzw programme zu testen oder fehler zu suchen und zu simulieren. Aus dem Grunde war diese Funktion früher auch höhereren leveln vorbehalten.
und: ein zwangsumschreiben der rega auf dem weg wirkt sich nicht auf den xmlrpc aus, ein IObroker z.b. bekommt von der IchÄnderEinenDatapointperEvent nix mit, da IOBroker direkt auf den RPC prozess aufsetzz und von diesem die direkten daten geliefert bekommt.
Black
