Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[legro]

Beim Versuch, in einem Skript auf Änderungen zu reagieren, probierte ich folgende Optionen aus.

Die erste Version funktioniert wie gewünscht, die zweite liefert einen Fehler unsubscribe: invalid type of id - object

Schaut man sich den JavaScript-Code an, wird sogar mir als Anfänger schnell klar, woran das liegt ..

Im ersten Beispiel wird der Datenpunkt selbst im Objektbaum referenziert, im zweiten Beispiel wird dessen Wert (Inhalt) referenziert.

Was ich nicht verstehe ..

Eigentlich will ich doch einen Trigger, der die Änderung des Wertes in dem Datenpunkt registriert. Für mich wäre es logisch, wenn das erste Beispiel nicht (der Datenpunkt ändert sich doch gar nicht) und nur das zweite (bei dem sich der Wert/Inhalt ändert) das richtige Verhalten liefern würde.

Irgendwie stehe ich nach wie vor auf Kriegsfuß mit der Implementierung von JavaScript bzw. Blockly.

PS:

Was ich glaube verstanden zu haben ..

Im ersten Beispiel wird der String [].concat(..) als Parameter dem Trigger on übergeben. Im zweiten Beispiel wird der Inhalt getObject(..) des Datenpunktes übergeben. Referenziert der String [].concat(..) einen Datenpunkt, so liefert getObject(..) natürlich nur einen Wert (hier true/false), was natürlich zu einem Fehler führt.

[paul53]

@legro sagte: das erste Beispiel nicht (der Datenpunkt ändert sich doch gar nicht)

Die ID ist eine Konstante, aber auch das statische Objekt des Datenpunktes:

nur das zweite (bei dem sich der Wert/Inhalt ändert) das richtige Verhalten liefern würde.

Getriggert wird auf eine Änderung des Zustandes des Datenpunktes, der per ID adressiert wird. Den Zustand erhält man nicht mit getObject(id), sondern mit getState(id).

[legro]

@paul53 sagte in Verständnisproblem: Object versus ObjectID:

@legro sagte: das erste Beispiel nicht (der Datenpunkt ändert sich doch gar nicht)
.. Den Zustand erhält man nicht mit getObject(id), sondern mit getState(id).

Danke für deine Antwort. In der Tat habe ich fälschlicherweise getObject mit getState verwechselt.

Leider verstehe ich's dennoch nicht ganz. Was liefert denn getObject, wenn nicht die ObjectID? Oder anders gefragt, was unterscheidet die beiden Blöcke Object ID (erste Option) und Object (zweite Option)? Naiv, wie ich bin, ging ich davon aus, dass die beiden Blöcke identisch sein sollten (was sie offensichtlich nicht sind).

Welchen Block gibt es unter System in Blockly, den man in diesem Trigger einsetzen kann?

[Homoran]

@legro Du musst dir Objekt wie eine Kiste vorstellen. Darin befinden sich die states!

Trigger finden tatsächlich auf ObjectID statt, auch wenn sich der Wert von Objekt ändert.

[paul53]

@legro sagte: Was liefert denn getObject, wenn nicht die ObjectID?

Zum Beispiel dieses statische Objekt:

{
  "common": {
    "name": "Taupunkt außen",
    "desc": "Manuell erzeugt",
    "role": "value.dewpoint",
    "type": "number",
    "read": true,
    "write": false,
    "unit": "°C",
    "def": 0,
    "min": -20,
    "max": 35
  },
  "native": {},
  "type": "state",
  "_id": "0_userdata.0.Aussen.Klima.Taupunkt",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  },
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1659369399962
}

@legro sagte in Verständnisproblem: Object versus ObjectID:

Welchen Block gibt es unter System in Blockly, den man in diesem Trigger einsetzen kann?

Der untere ist allerdings ein Text-Block, in dem die ID eingetragen wurde.

[legro]

@paul53

Vielen Dank. Dank deiner detaillierten Erläuterungen habe ich jetzt endlich das Ganze verstanden.

Ich versuch's mal zusammenzufassen.

Die Eingänge in den beiden Blöcken ..

.. erwarten die Adresse des Datenpunktes im Objektbaum als String. Darauf muss man als (immer noch) Anfänger erst einmal kommen. Der Block Object liefert das Objekt mit allen seinen Feldern ..

javascript.0 (2171) script.js.Rollladen._ObjectsTest: { common: { name: 'Grp01_Ins', desc: 'Manuell erzeugt', role: 'state', type: 'boolean', read: true, write: true, def: false }, type: 'state', native: {}, from: 'system.adapter.admin.0', user: 'system.user.admin', ts: 1714825235822, _id: '0_userdata.0.Rollladen.Grp01_Ins', acl: { object: 1636, state: 1636, owner: 'system.user.admin', ownerGroup: 'system.group.administrator' } }

[paul53]

@legro sagte: erwarten die Adresse des Datenpunktes im Objektbaum als String.

Ja, wobei sich durch einen Klick auf "Object ID" bzw. "default" ein Selektionsfenster zur Auswahl des Datenpunktes öffnet. Blockly zeigt nach erfolgter Auswahl nicht die ID, sondern den Namen an.

[legro]

@paul53 sagte in Verständnisproblem: Object versus ObjectID:

Ja, wobei sich durch einen Klick auf "Object ID" bzw. "default" ein Selektionsfenster zur Auswahl des Datenpunktes öffnet. Blockly zeigt nach erfolgter Auswahl nicht die ID, sondern den Namen an.

Statt Kritik an Blockly gibt's nun freudige Begeisterung. Diese beiden Trigger-Bausteine ermöglichen auf unterschiedlichste Kriterien zu testen, wie die nachfolgende Abbildung zeigt.

Tolle Sache, wenn man's mal verstanden hat. Aber Dank deiner Unterstützung konnte ich's im Detail (endlich) verstehen.