NEWS
Anleitung Blockly für DAU
-
Und muß ich für "Wert" definieren? also da den Datenpunkt normals aufgreifen, oder ist Ihm das klar?
-
@gluecksmann
Der ist aus der Rubrik der Trigger (steht default aber auf "Objekt ID") und bezieht sich auf das Objekt welches im Trigger angegeben wurde, also weiß er was gemeint ist -
OK, habe es jetzt mal mit dem Datenpunkt für CO2 versucht, da die Luftfeuchtigkeit gerade nicht über 50% wollte..
Klappt aber nicht...
-
@gluecksmann
Also so wie es aufgebaut ist funktioniert es, wenn Du jetzt im DP CO2 ein Wert von kleiner 1354 rein schreibst.
Dann kannst auch mal testen, ob Alex was spricht, wenn Du in den DP "speak" was reinschreibst. Könnte auch einfach auf sehr leise stehenDann kann auch mal den DP CO2 als RAW und ein Screenshot aus den Objekten posten.
Eingeschaltet ist das Script aber?
-
-
@gluecksmann
steht im Post oben -
@jan1 was mich irretiert...
Der test hat wie gesagt funktioniert...aber da steht doch das die Lautstärke null sein soll, oder?
-
@jan1 was ist RAW ?
-
@gluecksmann
Nein, da steht (null) und das bedeute, dass da noch nie was eingetragen wurde und das gemacht wird, was am Dot eingestellt ist.für RAW einfach bei dem DP hinten auf den Bleistift, dann wird gezeigt , wie der DP definiert wurde.
Edit:
Da Du Anfänger bist, vergesse ich auch oft, dass hier die Grundlagen komplett fehlen, somit können da auch noch ganz grundlegende Fehler drin sein und dazu gehört auch, wo wurde das Script angelegt und ist es eingeschaltet. Deshalb bitte mal ein Screenshot der in etwas so aussieht:
-
{ "common": { "role": "media.tts", "type": "string", "read": true, "write": true, "name": "speak" }, "type": "state", "native": {}, "from": "system.adapter.alexa2.0", "user": "system.user.admin", "ts": 1637915256597, "_id": "alexa2.0.Echo-Devices.db670fafbbfc4ff5b16223f5d7b07624.Commands.speak", "acl": { "object": 1636, "state": 1636, "file": 1632, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }
MOD-Edit: Code in code-tags gesetzt!
-
@gluecksmann
Das passt schon mal, wobei ich den RAW von CO2 wollte nicht den von "speak" und das auch immer schön in Code Tags (5. Symbol beim Posten oben) packen, weil es dann einfach zu lesen gehtWarum machst die Updates der vielen Adapter eigentlich nicht?
-
Da hab ich quasi nix verstanden... Updates... gibt es da ne schöne Möglichkeit die einfach alle auf einmal anzustoßen? gefühlt kommen da jeden tag neue
-
@gluecksmann sagte in Anleitung Blockly für DAU:
gibt es da ne schöne Möglichkeit die einfach alle auf einmal anzustoßen?
hab ich dir verlinkt!
oder hier:
https://www.iobroker.net/#de/documentation/admin/adapter.md?4adaptermitupdatesanzeigen
(ist noch für admin v4 - bei v5 aber ähnlich) -
- falscher RAW, Du hast den Bleistift bei Speak geklickt ich wollte den bei CO2
- hat Homoran in Deinem Post schon geändert
- Link von Homoran
Das Script sollte so wie es ist funktionieren, wenn der DP CO2 sich ändert und unter 1354. Das kann man alles manuell mal prüfen und um es auch zu sehen, gibts die debug Blöcke. Die packst einfach im Script da hin, wo was passieren sollte und wenn es das tatsächlich auf tut, wird der Text im Log unten ausgegeben
So siehst, wo was im Script arbeitet und wo es stockt.
-
{ "type": "state", "common": { "name": "CO2", "type": "number", "role": "level.co2", "read": true, "write": false, "unit": "ppm" }, "from": "system.adapter.netatmo.0", "user": "system.user.admin", "ts": 1632055717642, "_id": "netatmo.0.Wetter-(Indoor).Indoor.CO2.CO2", "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }
MOD-EDIT: Code in code-tags gesetzt!
-
@gluecksmann sagte in Anleitung Blockly für DAU:
"type": "number",
Das war wichtig und das stimmt auch, somit gibts kein Grund warum das Script nicht funktionieren sollte.
-
diese Debug Blöcke.... was hat es damit auf sich?
-
@gluecksmann sagte in Anleitung Blockly für DAU:
diese Debug Blöcke.... was hat es damit auf sich?
damit kann man Zwischenergebnisse ausgeben um zu sehen was da gerade passiert.
zum debuggen halt -
@gluecksmann
Die sorgen einfach für eine Ausgabe im Log, damit man sieht ob was funktioniert hat, oder eben nicht.
Ein Beispiel, wenn Du ein debug Block direkt nach dem Trigger einbaust und dem den Text "Trigger hat funktioniert" gibst, dann wird im Log irgendwo "Trigger hat funktioniert" stehen und Du weißt somit genau, dass das schon mal läuft -
Was sagt mir das denn?