Seite 1 von 3

.Variable() auf Datenpunkte ausführbar - Geräte dadurch unbrauchbar

Verfasst: 16.07.2018, 17:15
von alchy
Nun zu einem unter Umständen recht schwerwiegenden Fehler.

Link zur Doku:
https://www.eq-3.de/Downloads/eq3/downl ... l_V1.2.pdf
Variable_bug.jpg
Die Methode .Variable() ist laut Doku auf Systemvariablen anwendbar.
Wendet man jedoch die Methode fälschlicherweise auf einen Datenpunkt an, so wird der entsprechende Kanal / Datenpunkt unbrauchbar.


ACHTUNG soll heissen, danach ist der Kanal nicht mehr schaltbar über die Klickibunti!


Schrei nach Testcase vorauseilend beantwortet:

Hab mir eine HM-LC-Sw1-Pl Steckdose ausgesucht.
Variable_bug_steckdose.jpg
(Spielt aber nur eine untergordnete Rolle. Man kann sich auch alle Geräte mit einem Miniscript lahmlegen)
Die Steckdose funktioniert ohne Probleme und ist in meinem Arbeitszimmer unweit der CCU vorhanden, damit ideales Testgerät.

Ich führe folgendes Script aus:

Code: Alles auswählen

object oDP  = datapoints.Get("BidCos-RF.HEQ0157604:1.STATE");
if(oDP){
oDP.Variable(1);
}else{ WriteLine("Datenpunkt nicht vorhanden");}
Der Fehler liegt hierbei in der Zeile

Code: Alles auswählen

oDP.Variable(1);

da gehört

Code: Alles auswählen

oDP.State(1);
hin um die Steckdose einzuschalten.

Also mein Fehler (falls wer denkt ich wüsste dies nicht),
Ich habe nämlich in der Doku was von Variable() gelesen und schreibe grad meine ersten Scripte.
Kurzum, der Test schlägt fehl. Die Steckdose wird durch mein Script nicht geschalten.

Man fragt mich nach dem Fehlerprotokoll - da steht so was

Code: Alles auswählen

Jul 16 16:07:35 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::CallXmlrpcMethod: execute result isFault; method =getValue Params = {"1","STATE"} result= [faultCode:-2,faultString:"Unknown instance"] [iseXmlRpc.cpp:2605]
Jul 16 16:07:35 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::CallGetValue: CallXmlrpcMethod failed [iseXmlRpc.cpp:1432]
Jul 16 16:07:35 homematic-ccu2 local0.err ReGaHss: Error: IseHssDP::ReadValue: CallGetValue failed; sVal = 0 [iseDOMdpHSS.cpp:130]
Aber der kleine Fehler rächt sich anhaltend, da die falsche Methode doch etwas bewirkt hat. :shock:

Jeglicher weiterer Schaltversuch über die Klickibunti - Status und Bedienung, auch ein HM-Script oder auch Remote HMScript wird ab sofort ebenso mit dieser Fehlermeldung quittiert.
Schalte ich die Steckdose per Taster am Gerät selber, wird sie zwar ein/aus -geschalten, jedoch bekommt die CCU nichts mehr davon mit.


Das hat auch seinen Grund. :twisted: denn .Variable() hat man nicht auf einen Datenpunkt anzuwenden. Aber wieso ist dies möglich?
DAS war *IMHO* nicht immer so, die Methode .Variable() war nur auf OT_VARDP - sprich Systemvariablen zulässig.
Wann das in der RegaHss geändert wurde und warum weiß ich im Moment noch nicht, es gehört aber *IMHO* umgehend zurück geändert.
Ein kleiner Fehler in einem Script, in einer neuen APP usw. und die Geräte sind bis auf weiteres erstmal unbrauchbar.

Darauf muss man dann erstmal kommen!

Ich kann mich daran erinnern, das ich im Forum das ein oder andere Mal eine diesbezügliche Fehlerbeschreibung gelesen hätte. Auch die Fehlermeldung faultCode:-2,faultString:"Unknown instance" im Log habe ich schon gelesen.

Gibt es vielleicht den ein oder anderen Anwender der "falschen" Methode ??


Nachschauen ob man betroffen ist und Hife

Folgendes Script unter Script testen oder im xecuter oder... ausführen und Bildschirmausgaben anschauen / befolgen:

Code: Alles auswählen

!Bug .Variable() auf Datenpunkt Reparatur
!v0.1 (c) by Alchy
string svId;integer countA= 0;integer countB = 0;
foreach(svId, dom.GetObject(ID_DATAPOINTS).EnumUsedIDs()) {
var dp     = dom.GetObject(svId);
if (dp.IsTypeOf(OT_DP)) {
object ch = dom.GetObject(dp.Channel());
countB = countB +1;
string hssA = dp.HSSAddress(); 
string hssB = dp.Name().StrValueByIndex(".", 1);
if(hssA != hssB){ countA = countA+1; WriteLine("Datenpunkt: "#dp #" von Kanal: "#ch.Name() #" - weil: "#hssA #" ist ungleich: "# hssB); 
WriteLine("\tBitte folgende Zeile zur Reparatur unter Script testen ausführen:");
WriteLine("\tdom.GetObject(\""#dp.Name()#"\").HSSAddress(\""#hssB#"\");\r ");
}
}}
WriteLine("\r\t"#countA #" von "#countB #" Datenpunkten falsch\r ");

Platz für Updates:


Ticket: E72C94C5B638E erzeugt

Update Antwort 17.07.2018 - 11:05 Uhr:
Hallo Alchy,

das beschriebene Verhalten ist an die Entwicklungsabteilung weitergeleitet und wird unter der Bearbeitungsnummer EQ3_SUPPORT-1388 geführt.

Mit freundlichen Grüßen aus Leer

Ihr eQ-3 Support-Team

Update 18.07.2018 - Nachfrage nach Firmware und RegaHss Version
Antwort:
Getestet wurde das unter:
VERSION=2.35.16

Version: 2.1.369
Build: R1.00.0388.0128


Standard oder Community spielt jedoch keine Rolle.

Legacy gehört aus der Firmware entfernt, da innerhalb der internen Scripte Methoden wie z.B. .Replace() benutzt werden, welche in der Legacy NICHT enthalten sind.
Siehe auch viewtopic.php?t=44288&p=443220#p443213

Update 09.11.2018
in:

Code: Alles auswählen

VERSION=3.41.7

Version: 2.1.369
Build: R1.00.0388.0202
nicht mehr vorhanden.

Re: .Variable() auf Datenpunkte ausführbar - Geräte dadurch unbrauchbar

Verfasst: 16.07.2018, 18:06
von jmaus
alchy hat geschrieben:
16.07.2018, 17:15
Darauf muss man dann erstmal kommen!
Da hast du vollkommen Recht! Danke für deine Analysen.
Ich hab mir das mal hier in ReGa genauer angeschaut und soweit ich das sehen kann müsste das schon immer fälschlicherweise so funktioniert haben. D.h. selbst in der Legacy-Version müsste sich ReGa eigentlich so verhalten wenn ich das hier richtig deute. Ruf einfach mal ".Variable()" und ".HSSAddress()" ohne Argument auf einen Datenpunkt auf und du solltest sehen das die beiden Methoden exakt das selbe ausgeben ergo mit Argument dann auch das selbe machen. Und das sollte bei der Legacy nicht anders sein. Die Frage ist nun, ob es ggf. sogar so gewollt war/ist das zumindest ".Variable()" das selbe ausgibt wie ".HSSAddress()" (ohne Argumente) und lediglich das .Variable(1) mit Argumentangabe etwas "unglücklich" ist und folglich etwas "kaputt" macht weil man damit dann eben die HSS Adresse dieses Objektes auf 1 setzt.

Re: .Variable() auf Datenpunkte ausführbar - Geräte dadurch unbrauchbar

Verfasst: 16.07.2018, 18:52
von alchy
jmaus hat geschrieben:
16.07.2018, 18:06
D.h. selbst in der Legacy-Version müsste sich ReGa eigentlich so verhalten wenn ich das hier richtig deute.


Ich geb dir mal einen gut gemeinten Tipp: ReGaHss 0109
Schau dir die mal an.

Alchy

Re: .Variable() auf Datenpunkte ausführbar - Geräte dadurch unbrauchbar

Verfasst: 16.07.2018, 18:56
von jmaus
Fang bitte nicht wieder an in Rätseln zu sprechen und Tipps zu vergeben sondern mach uns allen das Leben leichter und führe aus was du genau meinst ;)

Re: .Variable() auf Datenpunkte ausführbar - Geräte dadurch unbrauchbar

Verfasst: 16.07.2018, 20:15
von alchy
#### BETA9-2017-05-18 (8d2e2bb) Release #####################################

2017-05-18 Jens Maus <mail@jens-maus.de>

* fixed all problems with function name clashes. E.g. the use of
o.ToInteger() and o.BuildLabel() on a valid object 'o' returned the
same 'string' result even though ToInteger() isn't a valid/accepted
function of an object. Something like this was possible at many
places resulting in unwanted side effects. Now a proper
ScriptRuntimeError is issued instead so that script authors can
correct these errors.
Ich bin doch nicht dazu da dir das Leben zu erleichtern, auch wenn ich es wahrscheinlich wieder mache.
Ich habe dir einen Fehler gemeldet, ihn lang und breit beschrieben, dir ein Testcase zur Verfügung gestellt usw.

Jetzt versuche ich meine CCU wieder in Ordnung zu bringen und mich um andere Sachen zu kümmern.
Im Gegensatz zu vielen anderen teste ich auf keiner TestCCU.

Alchy

Re: .Variable() auf Datenpunkte ausführbar - Geräte dadurch unbrauchbar

Verfasst: 16.07.2018, 20:20
von jmaus
alchy hat geschrieben:
16.07.2018, 20:15
#### BETA9-2017-05-18 (8d2e2bb) Release #####################################

2017-05-18 Jens Maus <mail@jens-maus.de>

* fixed all problems with function name clashes. E.g. the use of
o.ToInteger() and o.BuildLabel() on a valid object 'o' returned the
same 'string' result even though ToInteger() isn't a valid/accepted
function of an object. Something like this was possible at many
places resulting in unwanted side effects. Now a proper
ScriptRuntimeError is issued instead so that script authors can
correct these errors.
Ok, das meinst du. Danke. Aber hattest du es jetzt mal mit der Legacy ReGaHss getestet? Oder mit der Standard Version, die hat diese Änderung nämlich nicht mit drin. Wie gesagt, ich hatte mir den Quellcode bereits angeschaut und zumindest entdeckt das im Grunde mit den älteren ReGaHss Versionen (auch Legacy) das selbe passieren sollte und das kein neuer Effekt (auch nicht seit der oben zitierten Änderung) sein sollte.

Re: .Variable() auf Datenpunkte ausführbar - Geräte dadurch unbrauchbar

Verfasst: 16.07.2018, 20:59
von alchy
aktuelle Legacy und Standard - hatte ich beide getestet letzte Nacht (soweit ich mich erinnere)
Beide führten zum Verlust des Gerätes wie oben beschrieben.
Nochmals testen verkneif ich mir im Moment. Kann ich aber gerne tun, wenn es gefixt ist.


Der Wiedereinbau sollte dann vielleicht hiermit

Code: Alles auswählen

#### BETA10-2017-05-22 (334e81f) Release ####################################

2017-05-22 Jens Maus <mail@jens-maus.de>

  * fixed a regression bug which caused that obj.HssType() was not working
    properly anymore in a generic case. This resulted in incorrectly displaying
    temperatures in the WebUI with wind directions.

2017-05-21 Jens Maus <mail@jens-maus.de>

  * fixed system.Exec() function to be able to be executed without any
    parameters without interrupting a script execution.
  * fixed typo of "ID_GW_CHANNEL" constant

2017-05-19 Jens Maus <mail@jens-maus.de>

  * added a workaround for a commonly but incorrectly use of .AlDestMapDP() on
    an AlTriggerDP() acquired object so that only a warning is issued without
    stopping script execution. In future, however, we should and will remove
    this workaround again.
  * fixed a regression bug with .Variable() not having worked anymore after
    the recent opcode fixes.
erfolgt sein. Wenn nicht, dann woanders oder war es doch schon immer so.
Ob du hier oder da irgendetwas einbaust, nicht einbaust, wieder einbaust oder raus baust, kannst doch nur du wissen.
Zu einem kleinen Teil vielleicht noch die Leute die etwas testen und davon gibt es ja nicht viele.
Die 100 Leute die hier bisher reingeklickt haben, werden wahrscheinlich nicht die Muse, den Mut,den Ehrgeiz oder was auch immer haben,
auch nur einen Teil davon zu testen, zu bestätigen zu dementieren oder zu kommentieren. Aber wehe dem.....

Schlussendlich ist in der aktuellen Version ein Fehler, welcher da *IMHO* nicht hingehört.
Du weißt es, ich weiß es, ein offizielles EQ-3 Ticket ist auch erzeugt. Also warten wir ab.

Alchy

Re: .Variable() auf Datenpunkte ausführbar - Geräte dadurch unbrauchbar

Verfasst: 16.07.2018, 21:08
von jmaus
alchy hat geschrieben:
16.07.2018, 20:59
aktuelle Legacy und Standard - hatte ich beide getestet letzte Nacht (soweit ich mich erinnere)
Beide führten zum Verlust des Gerätes wie oben beschrieben.
Nochmals testen verkneif ich mir im Moment. Kann ich aber gerne tun, wenn es gefixt ist.
Ok danke für die Bestätigung. D.h. also das dieses Verhalten im Grunde schon immer da war. So dachte ich mir das bereits.
alchy hat geschrieben:
16.07.2018, 20:59
Schlussendlich ist in der aktuellen Version ein Fehler, welcher da *IMHO* nicht hingehört.
Es ist aber leider eben nicht ganz so einfach zu wissen ob das wirklich ein Bug oder ein Feature ist. Da hilft auch kein einfacher Blick in eine vermeintliche Dokumentation denn die Personen die die Dokumentation schreiben sind nicht die selben gewesen die das entwickelt haben. Und dann kommt noch dazu das man mitunter nicht einfach Dinge in ReGa rausnehmen/ändern kann und vorher sichergehen muss das niemand (wenn auch fälschlicherweise) das momentane Verhalten (z.B. Nutzung von .Variable() OHNE Parameter) verwenden. So kann es gut sein das interne Skripte .Variable() verwenden und man erst sichergehen muss warum die das tun un ob man das ersatzlos streichen kann. Hilfreich wäre dabei wenn da jemand anderes (Du?) da auch noch mit zwei Augen drüberguck'n könnte. Das würde das ganze ungemein beschleunigen.
alchy hat geschrieben:
16.07.2018, 20:59
Du weißt es, ich weiß es, ein offizielles EQ-3 Ticket ist auch erzeugt. Also warten wir ab.
Wir beiden sollen abwarten? Dann wird da auch nichts passieren. Denn defacto bin ich der Einzige der an ReGaHss etwas macht - daran ändert auch dein "offizielles EQ-3 Ticket" nichts. ;)

Re: .Variable() auf Datenpunkte ausführbar - Geräte dadurch unbrauchbar

Verfasst: 16.07.2018, 22:01
von jp112sdl
jmaus hat geschrieben:
16.07.2018, 21:08
Denn defacto bin ich der Einzige der an ReGaHss etwas macht - daran ändert auch dein "offizielles EQ-3 Ticket" nichts. ;)
Der Einzige, der etwas dran macht oder der Einzige (& letzte Verbliebene), der überhaupt noch was dran machen kann? :shock:
alchy hat geschrieben:
16.07.2018, 20:59
Die 100 Leute die hier bisher reingeklickt haben, werden wahrscheinlich nicht die Muse, den Mut,den Ehrgeiz oder was auch immer haben,
auch nur einen Teil davon zu testen, zu bestätigen zu dementieren oder zu kommentieren. Aber wehe dem.....
Ich habs auf der aktuellen RaspberryMatic getestet und genau so nachvollzogen.
Auf der originalen CCU2 mit Legacy ReGa kann ich den Test morgen auch gern noch mal durchführen, um es zu bestätigen.

Re: .Variable() auf Datenpunkte ausführbar - Geräte dadurch unbrauchbar

Verfasst: 16.07.2018, 22:12
von alchy
jmaus hat geschrieben:
16.07.2018, 21:08
Ok danke für die Bestätigung. D.h. also das dieses Verhalten im Grunde schon immer da war. So dachte ich mir das bereits.
Ach darauf willst du raus. Na dann klären wir das Missverständnis vielleicht mal auf.
Schon immer da stimmt eben nicht.
Wenn du damit aber ausdrücken willst, das der Fehler schon vor dir da war, dann gebe ich dir mal Recht.
Mit der 0109 hast du dann korrekterweise beim Zugriff auf ein HSSDP-Objekt ein ScriptRuntimeError erzeugt.
Die inkorrekten Reaktivierung geschah in Beta0110, Beta0111 und Beta0112, wie auch *IMHO* bei anderen Methoden.
An die leider wenig fruchtbaren Diskussionen wirst du dich doch erinnern.

Ich habe bei einem Schnellscan kein internes Vorkommnis von .Variable() gefunden.

Alchy