HomeMatic-Forum / FHZ-Forum

jmaus hat geschrieben: ↑

16.07.2018, 21:08

(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.

In de internen Scripten für

Energiesensor ( Strom / Gas)
HMIP-PSM
HM-MessSteckdosen
Wettersensor HMIP-swo

habe ich den String .Variable( nicht gefunden. Das kann man in einem per "Programme drucken" erzeugten pdf ganz schnell suchen.

alchy hat geschrieben: ↑

16.07.2018, 22:12

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.

Ach, das meinst du. Jetzt wird es klarer Da kannst du in der Tat Recht haben das das zwischenzeitlich vielleicht mal anders reagiert hat. Das Problem ist eben, das nach meiner initialen Änderung an der Prüfung valider/invalider Methodenaufrufen ich von eQ3 gebeten wurde das ganze wieder ein stückweit aufzuweichen weil es von gewissen internen und externen Applikationen Problemmeldungen mit der strikteren Handhabung von Methodennamen gegeben hat. Und nun müsste man erst einmal wieder rausfinden welche das genau waren und ob es in der Tat auch .Variable() betroffen hat. Alles leider nicht ganz so einfach und schnell zu beantworten.

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

Danke für die Tests. Nun müsste man auch noch wissen ob ggf. externe Applikationen wie PocketControl&Co vielleicht auf .Variable() setzen. Und wie gesagt, ich bin mir leider immer noch nicht ganz sicher ob der ursprüngliche Entwickler nicht mit Absicht .Variable() auch auf HSSDP Objekte anwendbar haben wollte oder ob das in der Tat einfach nur ein Bug ist.

Hallo Alchy!

alchy hat geschrieben: ↑

16.07.2018, 17:15

Ein kleiner Fehler in einem Script, in einer neuen APP usw. und die Geräte sind bis auf weiteres erstmal unbrauchbar.

Als interessierter Laie stellt sich mir die Frage, wie das "erstmal unbrauchbar" zu werten ist?
Was muss man tun, um die Geräte wieder zur Mitarbeit zu überzeugen?


Roland

Mit Verlaub, das ist nicht korrekt.
Was die Methode machen soll ist in der Doku, wie ich auch ganz am Anfang gepostet habe, definiert.

Wenn irgendeine Applikation die Methode falsch anwendet, dann muss die Application gefixt werden und damit ist das dann korrekt. Alles andere ist ein Rückschritt und einfach falsch.

Alchy

Roland M. hat geschrieben: ↑

16.07.2018, 22:38

Hallo Alchy!

alchy hat geschrieben: ↑

16.07.2018, 17:15

Ein kleiner Fehler in einem Script, in einer neuen APP usw. und die Geräte sind bis auf weiteres erstmal unbrauchbar.

Als interessierter Laie stellt sich mir die Frage, wie das "erstmal unbrauchbar" zu werten ist?
Was muss man tun, um die Geräte wieder zur Mitarbeit zu überzeugen?


Roland

Ich (auch als Laie) habe vorhin das Testszenario von alchy ausgeführt und musste den Aktor anschließend ab- und wieder anlernen.
Ein "drüberlernen" hat nicht gereicht.
Ob es einen Skript-Befehl gibt, der den Aktor wieder gangbar macht, ist mir jedoch nicht bekannt.

Die harte Variante ein Gerät wieder zur Mitarbeit zu bewegen, ist ein Ablernen, Rücksetzen, Anlernen.
Habe ich zig mal durch, bis ich von einem Freund per Mail auf eine viel elegantere Methode hingewiesen wurde.
Die weichere Methode ist ganz einfach mittels einem einzeilerscript zu erledigen.
Bei Bedarf kann ich morgen etwas zusammenschreiben.

Die Fehlermeldung taucht jedenfalls mehrfach im Forum auf. Ich denke schon, daß der ein oder andere User da schon in den Bug gerasselt ist, ohne es zu wissen.

Alchy

alchy hat geschrieben: ↑

16.07.2018, 22:39

Mit Verlaub, das ist nicht korrekt.
Was die Methode machen soll ist in der Doku, wie ich auch ganz am Anfang gepostet habe, definiert.

Wenn irgendeine Applikation die Methode falsch anwendet, dann muss die Application gefixt werden und damit ist das dann korrekt. Alles andere ist ein Rückschritt und einfach falsch.

Das ist, mit Verlaub, deine Meinung und faktisch nicht deine oder gar meine Entscheidung und es gibt über deine hobbymäßige Nutzung der HomeMatic auch noch andere Interessen die eQ3 verfolgt und da zählt eben auch dazu das bestehende Anwendungen weiter so funktionieren sollen wie vorher. Aber versteh mich nicht falsch bitte. Im Grunde bin ich auf deiner Seite und auch ich finde das gehört "repariert". Allerdings kannst du jetzt noch so viele offizielle eQ3 Tickets aufmachen wie du willst und auf die offizielle Doku verweisen. Im Zweifel wird das dann nur dazu führen (wenn man das nicht in diplomatischer Art und Weise und mit technischer Nüchternheit so vorbringt das das Bewusstsein geschaffen wird das diese Änderung nicht zu einer Explosion führt) das die Dokumentation einfach angepasst wird wie das bereits beim 200-Variablenproblem damals der Fall war.
Also wenn du nicht willst das demnächst die Dokumentation von .Variable() einfach entsprechend erweitert wird damit der Dokumentation gerecht geworden ist sollten wir lieber uns darauf konzentrieren rauszufinden ob es irgendwelche nennenswerten Applikationen gibt die ggf. .Variable() fälschlicherweise so einsetzen wie du das hier vorgebracht hast und dann dafür sorgen das dies beendet wird. Das du die internen Skripte der WebUI bereits danach gescannt hast ist ja bereits ein Anfang. Nun wäre rauszufinden wie es um PocketControl, Mediola&Co z.B. steht...

Tja, dann wäre es dann so. Trotzdem bleibt es falsch.

Da ich weder pocketcontrol noch mediola einsetze und bestimmt auch nicht noch diese Software kaufe um hier Support zu leisten, musst du auf meine Mitarbeit diesbezüglich verzichten.

Du hast schon bei falscher Benutzung anderer Methoden die entsprechenden, aussagekräftige Fehler ins log schreiben lassen.
Das wäre meiner Meinung nach auch hierfür die beste Methode.

Alchy

alchy hat geschrieben: ↑

16.07.2018, 22:46

Die harte Variante ein Gerät wieder zur Mitarbeit zu bewegen, ist ein Ablernen, Rücksetzen, Anlernen.
Habe ich zig mal durch, bis ich von einem Freund per Mail auf eine viel elegantere Methode hingewiesen wurde.
Die weichere Methode ist ganz einfach mittels einem einzeilerscript zu erledigen.
Bei Bedarf kann ich morgen etwas zusammenschreiben.

Die Fehlermeldung taucht jedenfalls mehrfach im Forum auf. Ich denke schon, daß der ein oder andere User da schon in den Bug gerasselt ist, ohne es zu wissen.

Alchy

Ich wäre generell immer an einem solchen Einzeilerscript interessiert!

Gruß Carsten

Es reicht wohl tatsächlich aus, mit den Datenpunkt wieder zu setzen!

Anschließend lässt sich (bei mir zumindest) der Aktor wieder schalten.

Ich hatte mir schnell mal ein Diff gezogen, um zu schauen, was bei der Ausführung des Skripts von Alchy tatsächlich passiert: