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

[Jan1]

@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 stehen ;)

Dann kann auch mal den DP CO2 als RAW und ein Screenshot aus den Objekten posten.

Eingeschaltet ist das Script aber?

[gluecksmann]

@jan1

Also Alexa spricht wenn ich was in den "Speak" schreibe...

Was soll ich noch machen?

[Jan1]

@gluecksmann
steht im Post oben ;)

[gluecksmann]

@jan1 was mich irretiert...

Der test hat wie gesagt funktioniert...aber da steht doch das die Lautstärke null sein soll, oder?

[gluecksmann]

@jan1 was ist RAW ?

[Jan1]

@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:

[gluecksmann]

@jan1

{
  "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!

[Jan1]

@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 geht ;)

Warum machst die Updates der vielen Adapter eigentlich nicht?

[gluecksmann]

@jan1

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

[Homoran]

@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)

[Jan1]

@gluecksmann

1. falscher RAW, Du hast den Bleistift bei Speak geklickt ich wollte den bei CO2
2. hat Homoran in Deinem Post schon geändert
3. 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.

[gluecksmann]

@jan1

{
  "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!

[Jan1]

@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.

[gluecksmann]

@jan1

diese Debug Blöcke.... was hat es damit auf sich?

[Homoran]

@gluecksmann sagte in Anleitung Blockly für DAU:

@jan1

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

[Jan1]

@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 ;)

[gluecksmann]

@jan1

Was sagt mir das denn?

[Homoran]

@gluecksmann sagte in Anleitung Blockly für DAU:

Was sagt mir das denn?

als Text in Code-Tags kopieren macht es vielleicht lesbar

[gluecksmann]

@homoran

   script.js.common.Lueften: setForeignState(id=alexa2.0.Echo-Devices.db670fafbbfc4ff5b16223f5d7b07624.Commands.speak, state={"val":"Fenster kann zu","ack":false,"c":"script.js.common.Lueften"}) - wurde nicht ausgeführt, während der Debug-Modus aktiv ist

[Jan1]

@gluecksmann
Gute Frage, wobei das erst mal "nur" ne Warnung ist und kein Fehler.
Die Ausgabe der Debug Blöcke hast übrigens direkt unterm Blockly Editor.