[Workaround] Skript mit dom.GetObject("BidCos-RF") funktioniert nicht 3.53.30.20200919

[jmaus]

Code: Alles auswählen

ID: 1013
Type:INTERFACE

In der Tat komisch.. Und was gibt folgendes aus:

Code: Alles auswählen

object o=interfaces.Get("BidCos-RF");
WriteLine ("ID: "  # o.ID ());
WriteLine ("Type:" # o.TypeName());  

[franky1275]

In der Tat komisch.. Und was gibt folgendes aus:

Code: Alles auswählen

object o=interfaces.Get("BidCos-RF");
WriteLine ("ID: "  # o.ID ());
WriteLine ("Type:" # o.TypeName());  

führt zum gleichen Ergebnis:

Code: Alles auswählen

ID: 1013
Type:INTERFACE

Ich habe den Betreff mal mit [Workaround] markiert.
Falls das nicht passt, bitte Bescheid geben

[jmaus]

In der Tat komisch.. Und was gibt folgendes aus:

Code: Alles auswählen

object o=interfaces.Get("BidCos-RF");
WriteLine ("ID: "  # o.ID ());
WriteLine ("Type:" # o.TypeName());  

führt zum gleichen Ergebnis:

Code: Alles auswählen

ID: 1013
Type:INTERFACE

Ich habe den Betreff mal mit [Workaround] markiert.
Falls das nicht passt, bitte Bescheid geben

Hmm, das ist umso komischer. Und mit dem "dom.GetObject("BidCos-RF")" geht es wirklich nicht? Eigentlich sollte das in der Tat gehen auch wenn das "interfaces.Get()" die sauberere Lösung von beiden ist. Kann das jemand reproduzieren? Nicht das das ein negativer Nebeneffekt meiner kürzlich hinzugefügten Option in der GetObject() ist das man dort den Objecttyp nun direkt einschränken kann?!?

[Black]

Auf der Seite davor hat er es ja gemacht. Rückgabewert ist ja auch ein object, vom Typ ot-interface.

Und putparamset nimmt lt Definition ein Objekt als interfaceparam, das liefert GetAt auf das root.interfaces ja auch.

Hmm, das ist umso komischer. Und mit dem "dom.GetObject("BidCos-RF")" geht es wirklich nicht? Eigentlich sollte das in der Tat gehen auch wenn das "interfaces.Get()" die sauberere Lösung von beiden ist. Kann das jemand reproduzieren? Nicht das das ein negativer Nebeneffekt meiner kürzlich hinzugefügten Option in der GetObject() ist das man dort den Objecttyp nun direkt einschränken kann?!?

@Jens: Da müsstest du mal jetzt mal in deinen debugger schauen

Black

[Black]

Hmm, das ist umso komischer. Und mit dem "dom.GetObject("BidCos-RF")" geht es wirklich nicht? Eigentlich sollte das in der Tat gehen auch wenn das "interfaces.Get()" die sauberere Lösung von beiden ist. Kann das jemand reproduzieren? Nicht das das ein negativer Nebeneffekt meiner kürzlich hinzugefügten Option in der GetObject() ist das man dort den Objecttyp nun direkt einschränken kann?!?

Ich denke, du musst dir die Implementierung mal ansehen, jens, das kann bösartiken Seiteneffekt haben für Funktionen, wo ein Object als parameter übergeben werden kann.

Konnte erst heute testen, beruflich ein wenig eingebunden gewesen die letzten Wochen.

das ist die testreihe:

Code: Alles auswählen

!Fall 1 geht nicht!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!-xmlrpc.PutParamset(dom.GetObject("BidCos-RF"),"MEQ0330450:1","MEQ0330450:1","LONG_ON_TIME",0.6);

!-Fall 2 geht
!-xmlrpc.PutParamset(interfaces.Get (1009),"MEQ0330450:1","MEQ0330450:1","LONG_ON_TIME",0.6);

!Fall 3geht
!-xmlrpc.PutParamset(interfaces.Get ("BidCos-RF"),"MEQ0330450:1","MEQ0330450:1","LONG_ON_TIME",0.6);

!-Fall 4geht
!-xmlrpc.PutParamset(dom.GetObject("BidCos-RF",OT_INTERFACE),"MEQ0330450:1","MEQ0330450:1","LONG_ON_TIME",0.6);

!-Fall 5geht
!-xmlrpc.PutParamset((dom.GetObject("BidCos-RF")),"MEQ0330450:1","MEQ0330450:1","LONG_ON_TIME",0.6);

!-Fall 6geht
!-xmlrpc.PutParamset((dom.GetObject("BidCos-RF",OT_INTERFACE)),"MEQ0330450:1","MEQ0330450:1","LONG_ON_TIME",0.6);   

Der erste Fall, den der Kollege hatte, geht reproduzierbar nicht !. tuts aber auf Vorgängerversionen. Geklammert wie in Fall 5 geht das auch. Da musste nochmal reingucken.

Black

[jmaus]

Hmm, das ist umso komischer. Und mit dem "dom.GetObject("BidCos-RF")" geht es wirklich nicht? Eigentlich sollte das in der Tat gehen auch wenn das "interfaces.Get()" die sauberere Lösung von beiden ist. Kann das jemand reproduzieren? Nicht das das ein negativer Nebeneffekt meiner kürzlich hinzugefügten Option in der GetObject() ist das man dort den Objecttyp nun direkt einschränken kann?!?

Ich denke, du musst dir die Implementierung mal ansehen, jens, das kann bösartiken Seiteneffekt haben für Funktionen, wo ein Object als parameter übergeben werden kann.

Hmm, sehr interessant, in der Tat. Passiert das denn auch innerhalb anderer Methoden wenn man da dom.GetObject() nun direkt einsetzt? Denn der Aufschrei diesbzgl. müsste dann doch eigentlich etwas größer sein oder passiert das nur bei diesen xmlrpc.XXXX() Methodenaufrufen dann wäre der Fehler vielleicht dort irgendwie zu suchen. Oder das deutet gar auf irgendeinen komischen Parserfehler hin der genereller Natur ist und das wäre natürlich schon eher etwas für einen Supergau bzw. würde ne längere Bugsuche nach sich ziehen...

[jmaus]

Hier mal weitere Infos zu dem Problem nach etwas Analysen (kopiert aus dem GitHub Ticket):
https://github.com/jens-maus/RaspberryM ... -699671294

Nach etwas tieferen Recherchen und Tests zeigt sich das dies wohl ein tieferes Problem im Skriptparser von ReGaHss zu sein scheint. Schau dir mal folgenden Skript an:

Code: Alles auswählen

string str="XXecho hallo123";
string stdout;
string stderr;

! Funktioniert
string str2=str.Substr(2);
system.Exec(str2, &stdout, &stderr);
WriteLine(stdout);

! Funktioniert nicht
system.Exec(str.Substr(2), &stdout, &stderr);
WriteLine(stdout);

WriteLine("END");

Dieser erzeugt folgende Ausgaben:

Code: Alles auswählen

hallo123

Es sollte hier jedoch 2x das `hallo123` ausgegeben werden. Was man auch bei der Ausführung dieses Skriptes dann in `/var/log/messages` findet ist ein `ScriptRuntimeError` der darauf hindeutet das es sich hier um ein tieferes Problem zu handeln scheint.

Nach weiteren Analysen sieht es so aus, das folgende Bedingungen existieren müssen damit der Fehler austritt:

1. Die äußere Methode (hier `system.Exec()`) muss mehr als einen Parameter annehmen (d.h. 2 oder mehr)
2. Die innere Methode (hier `str.Substr()`) muss ebenfalls mehr als einen Parameter annehmen (d.h. 2 oder mehr)

Sobald diese Bedingungen gegeben sind und man verbindet die beiden Methoden in einem Aufruf wie oben gezeigt (`system.Exec(str.Substr(2), &stdout)`) kommt es zu dem hier beschriebenen Problem das der Parser fälschlicherweise das `&stdout` in der Auswertung des `str.Substr(2)` aufrufes versucht als vermeintlichen 2. Parameter der `Substr()` Funktion auszuwerten was wiederum zu dem ScriptRuntimeError führt. Entfernt man daraufhin z.B. das `&stdout` aus dem `system.Exec()` Aufruf kann er jedoch das `str.Substr(2)` korrekt auswerten und es kommt zu keinem ScriptRuntimeError und folglich zur korrekten Abarbeitung. Auch kann man z.B. einfach `str.Substr(2).ToString()` oder `(str.Substr(2))` (extra Klammerung) nutzen und der Parser löst das dann korrekt auf und auch dieser Aufruf funktioniert dann problemlos.

Wie also gesagt scheint das Problem völlig unabhängig der letzten Änderungen der `dom.GetObject()` Methode (Hinzufügen eines 2. Parameters) wohl bereits schon viel länger zu existieren und tritt jetzt eben nur bei `dom.GetObject()` zu Tage weil die Methode nun eben auch einen 2. optionalen Parameter annimmt und daher Analysen durchführt ob der zweite Parameter angegeben wurde oder nicht.

Die Frage wäre also ob frühere/frühe ReGaHss Versionen dieses Parser Problem noch nicht haben, oder ob der Parser schon immer dieses Defizit hatte und ich mir das dann gesondert anschauen müsste ob man das mit wenig Aufwand repariert bekommt. Wäre natürlich schön andere könnten hier noch weitere solche Tests durchführen und ggf. eben frühe ReGaHss Versionen einmal entsprechend durchtesten (was ich bei Gelegenheit natürlich dann auch noch machen werde).

[Black]

Ohne Anspruch auf Vollzähligkeit und Komplettheit habe ich mir gestern abend noch Methoden rausgesucht, welche ein Object in ihrer Parametrierung haben (DeleteObject, Add, Remove, MoveObject,RuleDelCondition und Derivate).

hier konnte ich ihn nicht zu Fehlern zwingen, obwohl ich dort auch Aufrufe von Getobject mit hineingesetzt hatte, nur eine Sache deckt sich mit deiner Beschreibung, das BÄNG bei einem zweiten Parameter mit dem ersten Parameter ein GetObject:

Case:

Code: Alles auswählen

!macht BÄNG
object o= dom.CreateObject(OT_ENUM,"TEST");
o.Add(dom.GetObject("Anwesenheit"));
o.Add(dom.GetObject("Anwesenheit.Black"));
WriteLine (o.EnumNames());
o.MoveObject(dom.GetObject("Anwesenheit"),1);
dom.DeleteObject(o);   

die beiden Sysvars Anwesenheit und Anwesenheit.Black gegen 2 beliebige andere Sysvars ersetzen, die es auf dem System gibt.

der oben ziierte Code rennt in einen Scriptruntimeerror

Code: Alles auswählen

Sep 27 20:58:11 homematic-ccu2 local0.err ReGaHss: ERROR: ScriptRuntimeError: object o= dom.CreateObject(OT_ENUM,"TEST");^M o.Add(dom.GetObject("Anwesenheit"));^M o.Add(dom.GetObject("Anwesenheit.Black"));^M WriteLine (o.EnumNames());^M o.MoveObject(dom.GetObject("Anwesenheit"),1);^M dom.DeleteObject(o);^M  [ExecError():iseESPexec.cpp:12885

während:

Code: Alles auswählen

!Läuft
object o= dom.CreateObject(OT_ENUM,"TEST");
o.Add(dom.GetObject("Anwesenheit"));
o.Add(dom.GetObject("Anwesenheit.Black"));
WriteLine (o.EnumNames());
o.MoveObject(dom.GetObject("Anwesenheit",OT_VARDP),1);
dom.DeleteObject(o);  

durchläuft. du siehst, Add() mit nur einem Parameter (Objectübergabe geht), MoveObject, mit 2 Parametern, 1 Object, 2 Integer macht BÄNG

ebenfalls geht:

Code: Alles auswählen

!Läuft
object o= dom.CreateObject(OT_ENUM,"TEST");
o.Add(dom.GetObject("Anwesenheit"));
o.Add(dom.GetObject("Anwesenheit.Black"));
WriteLine (o.EnumNames());
o.MoveObject(dom.GetObject (ID_SYSTEM_VARIABLES).Get("Anwesenheit"),1);
dom.DeleteObject(o);   

das das äquivalent zu dem interfaces.Get ist, was der ursprung des Issues war

und nun wirds böse, der Fehler ist nämlich neu in dieser version.
entgegen meiner sonstigen Gewohnheit hab ich das Script mal auf dem Hauptsystem laufen lassen, eine noch nicht geupdatete RMatik.. diese Bildschirmfoto

Zeigt, der code, der auf der aktuellen BÄNG macht, läuft auf der Vorgängerversion (hier nur andere Sysvarnamen weil anderes System)

Code: Alles auswählen

!Läuft auch, ist der Code, der auf der aktuellen BÄNG macht
object o= dom.CreateObject(OT_ENUM,"TEST");
o.Add(dom.GetObject("ANW.Gast"));
o.Add(dom.GetObject("ANW.Susa"));
WriteLine (o.EnumNames());
o.MoveObject(dom.GetObject ("ANW.Gast"),1);
dom.DeleteObject(o); 

Das verifiziert auch die Aussage des kollegen, das sein PutParamset auf der Vorgängerversion lief.

Black

[jmaus]

[...]
und nun wirds böse, der Fehler ist nämlich neu in dieser version.
entgegen meiner sonstigen Gewohnheit hab ich das Script mal auf dem Hauptsystem laufen lassen, eine noch nicht geupdatete RMatik.. diese Bildschirmfoto
[...]
Zeigt, der code, der auf der aktuellen BÄNG macht, läuft auf der Vorgängerversion (hier nur andere Sysvarnamen weil anderes System)
[...]

Der Fehler ist jedoch nur für die Nutzung von "dom.GetObject()" neu weil eben nur in der neuesten ReGaHss GetObject() ja nun auch zwei Parameter annehmen kann. Vorher kannte GetObject() ja nur maximal ein Parameter. Bei anderen Methoden die schon in vorherigen ReGaHss schon zwei oder mehrere Parameter annehmen tritt der Fehler auch mit diesen älteren ReGaHss versionen auf (siehe mein system.Exec()+str.Substr() Beispiel von oben).

Die aktuelle Frage wäre allerdings wann genau dieser Fehler denn in ReGaHss reingewandert ist oder ob dieser schon immer existiert hat. Nun müsste man eben mal ne alte ReGaHss Version hernehmen und mein system.Exec()+str.Substr() Beispiel zu Rate ziehen um durchzutesten ob das Problem da auch schon existiert hat und wenn nicht sich dann eben mal durch die Versionen durcharbeiten bis man die Version gefunden hat wo es das erste mal auftritt.

[jmaus]

Die aktuelle Frage wäre allerdings wann genau dieser Fehler denn in ReGaHss reingewandert ist oder ob dieser schon immer existiert hat. Nun müsste man eben mal ne alte ReGaHss Version hernehmen und mein system.Exec()+str.Substr() Beispiel zu Rate ziehen um durchzutesten ob das Problem da auch schon existiert hat und wenn nicht sich dann eben mal durch die Versionen durcharbeiten bis man die Version gefunden hat wo es das erste mal auftritt.

Also ich bin mal schnell hingegangen und bin die ReGaHss binaries im OCCU zurück bis zur "Ursprungsversion" R1.00.0388.0102 (CCU Firmware 2.15.5 von 2016) gegangen und es sieht in der Tat so aus das selbst mit dieser Version das Problem bereits schon existiert und es wohl in der Tat kein in neuester Zeit reingewandertes Problem zu sein scheint. Vielleicht kann das ja mal jemand mit ähnlichen Tests bestätigen.