[gelöst] Attribute von Datenpunkten im Trigger lesen

[Sascha 0]

Hallo Zusammen,

ich versuche in einem Trigger die Attribute des auslösenden Datenpunktes zu lesen:

Leider erfolglos. Ich habe schon rausbekommen, dass ich folgendes benötige:

getObject('ID auswählen');

Doch wie bekomme ich das Objekt mit der Variable Objekt ID aus dem Trigger?

Dass ich das ganze in eine "echte" JavaScript Funktion packen kann, weiß ich. Ich versuche das aber immer zu vermeiden, da der Code dadurch für mich als Laie nach langer Zeit nicht "lesbarer" wird. Blockly ist da für mich als "nicht-Programmierer" ein Segen.

Danke & Gruß
Sascha

[Codierknecht]

@Sascha-0

Dass ich das ganze in eine "echte" JavaScript Funktion packen kann, weiß ich. Ich versuche das aber immer zu vermeiden, da der Code dadurch für mich als Laie nach langer Zeit nicht "lesbarer" wird. Blockly ist da für mich als "nicht-Programmierer" ein Segen.

Da wirst Du nicht drumherum kommen.

@haus-automatisierung kann das sicher besser erklären und mich ggf. korrigieren. Aber AFAIK sind das statische Eigenschaften eines Objektes, an die Du aktuell mit Blockly nicht herankommst.
Es sei denn, Du bettest in Blockly eine kleine JS-Funktion ein. Die kannst Du ja umfassend kommentieren, damit Du später noch weißt was da passiert.

let obj = getObject(ObjectID); // statisches Objekt lesen
return obj.common.write; // Wert der Property "write" zurückgeben (ist beschreibbar ja/nein)

[haus-automatisierung]

@sascha-0 sagte in Attribute von Datenpunkten im Trigger lesen:

Doch wie bekomme ich das Objekt mit der Variable Objekt ID aus dem Trigger?

Momentan gibt es keinen Block, welcher dynamisch eine Objekt ID bekommen kann, um das Objekt zu bekommen.

In welchem Fall interessiert Dich denn common.write? Man weiß doch eigentlich, ob die Zustände steuerbar sind, auf welche man den Trigger registriert hat.

[haus-automatisierung]

@codierknecht sagte in Attribute von Datenpunkten im Trigger lesen:

Aber AFAIK sind das statische Eigenschaften eines Objektes, an die Du aktuell mit Blockly nicht herankommst.

Doch, da kommst Du schon dran. Einfach mit "Attribut von Objekt". Nur kann man aktuell die Objekt ID nicht dynamisch in den Block reinreichen, welcher das komplette Objekt zurückliefert. Das war ja die Frage.

[Sascha 0]

@haus-automatisierung said in Attribute von Datenpunkten im Trigger lesen:

In welchem Fall interessiert Dich denn common.write? Man weiß doch eigentlich, ob die Zustände steuerbar sind, auf welche man den Trigger registriert hat.

Ich nutze das ganze um meinen Heizkessel per RestAPI zu steuern. Die Leseseite steht mittlerweile. Jetzt wollte die Datenpunkte, die der Heizkessel auch als Schreibtelegramm annimmt in einem Skript abhandeln.

Mein Ziel ist es, den gesamten Code in einem Trigger abzuhandeln und je nach Attribut der auslösenden Datenpunkte meine Schreibaktionen machen. Somit muss ich nicht für jeden Datenpunkt ein eigenes Skript machen, sondern kann dynamisch über Bedingungen in einem Trigger reagieren.
Das common.write ist nur ein Beispiel, abhängig vom Typ muss ich z. B. Umrechnungen machen: z. B. boolean wird ein Interger mit Faktor und Offset

Die ganzen Hardcode Objektdefinitionen sind da immer ein Graus: z. B.

Sowas hier ist immer Suboptimal:

Das hier ist ist perfekt:

Jetzt braucht es noch dafür etwas dynamisches:

So ist es übrigens auch mit diesem Baustein:

Hier den Datenpunkt dynamisch anzugeben, wäre ein Traum! Den Datenpunkt immer dynamisch zu haben, wäre perfekt!

Danke & Gruß
Sascha

[paul53]

@sascha-0

[Codierknecht]

@paul53
Godfather of Blockly hat wieder zugeschlagen

@Sascha-0
Falls Du das suchen solltest:

[Sascha 0]

@paul53

Jaaaaaaa! Das ist es!! Danke!!
Jetzt muss ich mir noch etwas für meine selbst erstellten Attribute überlegen. Da kann ich aber mit Javascript statt Blockly leben.

Trotzdem bleibt mein Faturewusch, alle Objekte auch dynamisch angeben zu können.

[haus-automatisierung]

@sascha-0 sagte in [gelöst] Attribute von Datenpunkten im Trigger lesen:

Trotzdem bleibt mein Faturewusch, alle Objekte auch dynamisch angeben zu können.

Ja, gab es an andere Stelle schon (und ich glaube auch als GitHub Issue).
Mir fehlen momentan die Ressourcen um das auch noch einzubauen. Zumal die Zielgruppe davon sehr klein ist.