Fehler im Script aber Script testen geht ? ! ? ! ?

[jmaus]

Und wo genau ist das Bitte dokumentiert?

70% aller zur Verfügung stehenden Funktionen und Methoden sind nicht dokumentiert.

Die Sysntax für solche Sachen ist:
"search CCU" && ("try and fail" || "try and success")

Und wo genau hast du das gefunden oder ist das nur eine Vermutung? Die wäre allerdings doch sehr wage IMHO.

[BadenPower]

Und wo genau hast du das gefunden oder ist das nur eine Vermutung? Die wäre allerdings doch sehr wage IMHO.

Probier einfach einmal im Skript-Testen-Bereich folgenden Zeile aus:

system.CacheInfo();

und schau was bei Dir dann dort im Bereich "Cache info (IseESP::sm_cc; XY entries)" steht.
Ich vermute, dass das die Anzahl (also anstelle von XY) der momentan verwendeten (im Cache vorhandenen) Variablen ist.


.

[jmaus]

Probier einfach einmal im Skript-Testen-Bereich folgenden Zeile aus:

system.CacheInfo();

und schau was bei Dir dann dort im Bereich "Cache info (IseESP::sm_cc; XY entries)" steht.
Ich vermute, dass das die Anzahl (also anstelle von XY) der momentan verwendeten (im Cache vorhandenen) Variablen ist.

Danke. Das sieht wirklich in der Tat interessant aus. Folgende Skript-Anweisung

Code: Alles auswählen

WriteLine(system.CacheInfo());

gibt mir folgenden "sm_cc" Bereich Ausgabe:

Code: Alles auswählen

Cache info (IseESP::sm_cc; 112 entries):
...

Und das kann gut hinkommen. Die TausendEuro-Frage wäre nun allerdings ob das system.ClearCache() wirklich auch das bewirkt was man möchte? Das muss ich heute Abend mal genauer testen. Und wenn das so ist müsste man ja im Grunde "nur" am ende jedes Skriptaufrufes "system.ClearCache()" aufrufen damit der Cache gelöscht ist bevor der nächste Skript losläuft. Oder kennst du noch ein Kommando mit dem man die Cachegröße ggf. einstellen kann? Und mich würde auch interessieren wo genau du diese Info her hast? Wie bist du auf das ClearCache() bzw. CacheInfo() gekommen? Auf jedenfalls schonmal danke dafür. Wieder ein kleinen Schritt weiter.

[jmaus]

Danke. Das sieht wirklich in der Tat interessant aus. Folgende Skript-Anweisung

Code: Alles auswählen

WriteLine(system.CacheInfo());

gibt mir folgenden "sm_cc" Bereich Ausgabe:

Code: Alles auswählen

Cache info (IseESP::sm_cc; 112 entries):
...

So, hab noch ein bisschen testet und gesucht und folgende Kommandos mit Bezug auf "Cache" scheint es wohl zu geben:

Code: Alles auswählen

system.CacheInfo()
system.ClearCache()
system.CacheMode()

Das "CacheInfo()" gibt wie gesagt Infos über den Cache von ReGaHSS aus. Allerdings scheint mir das eher ein Webseitencache zu sein als ein Cache für die Skriptvariablen und damit um das Problem das wir hier sehen in irgendeinerweise zu beeinflussen. Während man mit "system.ClearCache()" den cache momentan löschen kann kann man auch folgendes Kommando ausführen um den Cache wohl komplett zu deaktivieren:

Code: Alles auswählen

system.CacheMode(0);

Danach liefert "system.CacheInfo()" immer leere Informationen, d.h. also der Cache ist dann deaktiviert. Allerdings scheint es dann trotz des deaktivierten Caches immer noch das Problem mit der Begrenzung auf 200 Scriptvariablen zu geben. Es muss also ggf. noch ein weiteren Cache/Speicherbereich geben der für die Anzahl der Scriptvariablen zuständig ist.

Leider also auch damit keine Lösung/Workaround des Problems. Trotzdem vielen Dank für den Hinweis bzgl. der Cache() Kommandos.

[papi]

Ich werde verrückt - und ich suche seit mehreren Tagen wie ein Irrer nach der Ursache meiner Probleme...

Gibt es vielleicht eine Möglichkeit, die CCU2 zu einem bestimmten Zeitpunkt automatisch neu zu starten (ohne ihr einfach den Stecker zu ziehen)?
Damit könnte ich wenigstens die Zeit überbrücken, bis die Herrschaften von EQ3 sich der Problematik irgendwann mal angenommen haben, denn nach einem Neustart kommt meine Kiste zunächst erstmal auf 52 benutzte Variablen, die dann wohl langsam anwachsen.

Mal was Anderes: Hat schon einmal jemand versucht, was denn passiert, wenn man die Variablen in allen Skripten mit dem gleichen Namen versieht?
Klar ist das nicht sonderlich elegant und auch nicht sprechend programmiert, könnte aber Variablen sparen, sofern diese nicht jeweils mit einer eigenen SysID - unabhängig ihres Namens - behandelt und gespeichert werden.

[jmaus]

Mal was Anderes: Hat schon einmal jemand versucht, was denn passiert, wenn man die Variablen in allen Skripten mit dem gleichen Namen versieht?
Klar ist das nicht sonderlich elegant und auch nicht sprechend programmiert, könnte aber Variablen sparen, sofern diese nicht jeweils mit einer eigenen SysID - unabhängig ihres Namens - behandelt und gespeichert werden.

Genau das ist das momentan einzig vorübergehende Workaround für das Variablenproblem. Siehe hier:

http://homematic-forum.de/forum/viewtop ... 26&t=27907

Dort haben einige auch bereits einige gängige Skripte mit gleichen Variablennamen konvertiert – auch wenn das unschön und unpraktisch ist. In jeden Falle solltest du allerdings das Problem bei eQ3 als offiziellen Bugreport melden damit dort die mögliche Lösung des Problems ganz nach oben auf die Prioritätenliste gesetzt wird. Eine entsprechende Vorlage für solch einen Bugreport findest du im selben Thread wie aufgelistet (http://homematic-forum.de/forum/viewtop ... 20#p256487).

[papi]

Ja, ich bin schon ein pfiffiges Kerlchen.

Ok, ich werde mal eine Meckermail absetzen, aber ist das wirklich so sinnvoll, dass Alle aus nur einem Rohr schießen?
Stattdessen formuliere ich lieber eine eigene Variante, damit auch deutlich wird, dass ich mich nicht einfach der Petition anhänge, sondern stinksauer und enttäuscht über die bei ELV/EQ3 vertriebene Qualität bin.

Danke!

Edit:
Ist ja lustig - es wurde ja bereits erwähnt, dass EQ3 und ELV die gleiche Postadresse haben, aber sie verwenden wohl auch den gleichen Mailserver.
Hier die Empfangsbestätigung meiner Mail an EQ3:

Code: Alles auswählen

This is the Mail-Delivery-Service.

Your message was sccessfully delivered:

	To: support@eq-3.de
	Subject: Plötzlich auftretende Überläufe der CCU2

phoenix.elv.de[217.7.137.155] reply 250 2.0.0 u1K8IYRN012065 Message accepted for delivery

[nash1970]

ich ich bin in diesen Bug reingelaufen. Sehr ärgerlich, aber ist nun mal so.

Damit ich den Erfolg meiner Bemühungen, lokale Variablen zu vermeiden oder zumindest wiederzuverwenden, verfolgen kann, habe ich mir eine kleine Überwachung geschrieben. Jetzt kann ich wenigsten die Variablenverbraucher identifizieren und mich benachrichtigen lassen, wann ich an oder über die 200er Grenze komme.

Code: Alles auswählen

! Einfach eine Systemvariable mit dem Namen "VARIABLES" als Typ Zahl mit dem Wertebereich 0 bis 1000 (oder höher) anlegen

!verständliche Variante mit lokalen Variablen
!var temp = system.CacheInfo();
!var i = temp.Find("Cache info (IseESP::sm_cc; ");   !Suchstring ist 27 Zeichen lang
!var j = temp.Find("entries):");
!dom.GetObject("VARIABLES").State(temp.Substr(i+27,j-(i+27)));

!unverständliche Variante ohne lokale Variablen
dom.GetObject("VARIABLES").State(system.CacheInfo().Substr(system.CacheInfo().Find("Cache info (IseESP::sm_cc; ")+27,system.CacheInfo().Find("entries):")-(system.CacheInfo().Find("Cache info (IseESP::sm_cc; ")+27)));

[papi]

Ich durchschaue Dein Skript zwar nicht, aber kann es sein, dass bei dieser Vorgehensweise gleichnamige Variablen mehrfach gezählt werden?
Ich komme mit Deinem Skript nämlich auf 329 Variablen, obwohl ich nur ca. 70 verwende und da bin ich mir sehr sicher.

[koppenho]

Damit ich den Erfolg meiner Bemühungen, lokale Variablen zu vermeiden oder zumindest wiederzuverwenden, verfolgen kann, habe ich mir eine kleine Überwachung geschrieben. Jetzt kann ich wenigsten die Variablenverbraucher identifizieren und mich benachrichtigen lassen, wann ich an oder über die 200er Grenze komme.

Klasse! Danke für den Code. Hab's sofort ausprobiert.
Mein Wert: 176.
Das Ergebnis dürfte bei mir stimmen.