Felder $val$ $this$ $src$ Scripteingabe

[Andersmacher]

Also z. B. bei einem Trigger >20°C dann die auslösende Temperatur? OK, verstanden.
Danke!

[Andersmacher]

OK, ich habe nun ´mal ein wenig mit $src$ Skripte geschrieben und bin auf folgendes "Phänomen" gestoßen:

Code: Alles auswählen

object Datenpunkt = dom.GetObject("$src$");
var x = Datenpunkt.Value();
integer Kanal_ID = Datenpunkt.Channel();
object Kanal = dom.GetObject(Kanal_ID);
integer Geraete_ID = Kanal.Device();
object Geraet = dom.GetObject(Geraete_ID);
var Geraetename = Geraet.Name();

Liefert mir für einen Feuchte-/Wasserssensor HM-Sec-WDS sinnvolle/korrekte Werte:
$src$ = 4stellige Datenpunkt-ID
x = Wert des Datenpunktes bei Auslösung des Programms, in dem dieses Skript steht.
Kanal_ID = 4stellige Kanal-ID, mit der ich dann in den nächsten Zeilen ebenfalls sinnvoll/korrekt weiter arbeiten kann.

Löse ich jedoch den Trigger über einen Feuchte-/Wasserssensor HM-Sec-WDS-2 aus, so liefert
integer Kanal_ID = Datenpunkt.Channel();
eine "1", also offenbar nicht die Kanal-ID, sondern die Kanalnummer (Diese Sensoren haben ja wohl nur einen Kanal.), die ja aber jeder dieser Sensoren hat, und die somit einen Kanal nicht CCU-weit eindeutig bestimmen kann.

Die darauf folgenden Code-Zeilen liefern dadurch dann nur noch sinnlosen Quark und die Zentrale setzt eine Skriptfehlermeldung ab, was ich nachvollziehen kann, da ich ja dann wohl auf nicht vorhandene/definierte Kanäle/Geräte zugreife.

Kann das jemand erklären?

Jedesmal, wenn ich ein Programm neu speichere (egal ob ich es verändert habe oder nicht), erhält es offenbar eine neue "$this$-ID". Was passiert eigentlich, wenn man dadurch irgendwann die Grenze 65tausend_irgendwas erreicht, bis zu der der Wertebereich für $this$ wohl nur geht?

Kann mein obiges Problem irgendwie damit zusammenhängen, daß ähnlich wie bei $this$ IDs für Datenpunkte, Kanäle und / oder Geräte immer wieder geändert/neu vergeben werden, wenn man ein Gerät mal löscht und wieder neu anlernt?

[Black]

Mach mal id, die der wassermelder in $src$ erzeugt sichtbar und dann mal dazu das referenzierte objekt untersuchen. So lässt sich dazu nix sagen.

Ein Programm wird bei jedem gespeichere mit neuen IDs angelegt. Ist normal. Das führt dann zu so vergabeorgien und wohl auch ab und zu zu kaputteditierten Programmen. Aus dem Grunde gibt es auch Editoren, die Scripte direkt in der ccu ändern können ohne jedes mal Neuanlagen zu veranstalten.

65535 ist unkritisch, die Obergrenze ist 2 ^31.

Bei Geräten nach löschen und Neuanlagen gilt das gleiche.

Black

[Andersmacher]

@Black Danke für die Rückmeldung, aber was meinst Du mit

Mach mal id, die der wassermelder in $src$ erzeugt sichtbar

"?
Ich hatte mir die von $src$ referenzierte ID in eine Systemvariable schreiben lassen, nur dadurch weiß ich ja, daß sie bei dem einen Wassermelder nicht stimmen kann.

und dann mal dazu das referenzierte objekt untersuchen.

Mit Objekt meinst Du HM-Gerät, also eigentlich den Wassermelder - richtig? Genau das ist ja mein Problem: Die referenzierte Datenpunkt-ID führt unter Anwendung der Methoden und Eigenschaften des HM-Objektmodells nicht zu dem zum Datenpunkt gehörenden Gerät, sondern endet in einer Fehlermeldung / Skriptabbruch!

Es wird noch schräger:
Nachdem ich noch ein paar Programme/Skripte geändert und neu gespeichert habe, scheint es nun auch den anderen Wassermelder sowie weitere Sensoren zu betreffen. Beispielsweise referenziere ich auch Tür-/Fensterkontakte in einem Skript via $src$, um Meldungen mit dem Namen des trigernden Sensors via Email zu versenden und nicht für jeden Sensor eine eigene Regel schreiben zu müssen. Dies lief seit Jahren problemlos, nun erzeugt die CCU auch hierfür Skript-Fehlermeldungen.

wohl auch ab und zu zu kaputteditierten Programmen

Ich hatte, kurz nachdem ich mit HM begann, schon ´mal den "Verdacht", daß auf der CCU irgendetwas nicht stimmt, weil Programme plötzlich doppelt oder gar nicht mehr da waren oder "unerklärliche" Ergebnisse erzeugt wurden. Damals lag das wohl daran, daß ich mangels besseren Wissens mit mehreren Browser-Tabs gleichzeitig auf die CCU zugegriffen habe. Um das sicher zu bereinigen half damals nur komplettes Neuaufsetzen der CCU und seit dem halte ich mich penibel an genau ein Sitzungsfenster. Seit dem lief alles gut, bis ich vor kurzem nach einigen Programmanpassungen eben die Logmeldungen über die Skriptfehler bei Verwendung von $src$ entdeckte.

Neuaufsetzen würde jetzt aber noch deutlich aufwändiger werden, als damals, da ich nun deutlich mehr Geräte, Variable, Programme, ... habe.

Wenn dieses "Durcheinanderbringen" bei der CCU wirklich ein "bekanntes Problem" ist, bin ich am Überlegen, ob man das z. B. mit Umstieg auf Raspberrymatic "umgehen" kann. Kennt sich da jemand aus?

[MichaelN]

Vielleicht hilft das. Jens hat da aktuelle einen Fehler in der foreach Verarbeitung beseitigt und möglicherweise hatte dieser Bug auch seine Finger bei der magischen Programmverdopplung im Spiel. Wäre ein Versuch wert.

[Andersmacher]

@MichaelN Danke für den Hinweis, aber ich bin nicht sicher, ob ich ihn richtig verstehe bzw. ob ich mich oben richtig ausgedrückt habe:
Das mit doppelten Programmen ist "Jahre her". Jetzt aktuell habe ich "nur" Probleme mit falsch gelieferten Referenzen durch $src$.
Und das letzte Firmwareupdate ist auch schon einige Monate her (April - oder?). Da könnte sich doch dann jetzt aktuell keine Änderung auswirken - oder?

[MichaelN]

Meine Antwort bezog sich auf

Wenn dieses "Durcheinanderbringen" bei der CCU wirklich ein "bekanntes Problem" ist, bin ich am Überlegen, ob man das z. B. mit Umstieg auf Raspberrymatic "umgehen" ka