Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[apollon77]

Das Problem ist sehr einfach: Zu viel und zu schnell.
Amazon hat "rate Limits" definiert - bedeutet das nur eine definierte Anzahl an Kommandos in einer bestimmten Zeit durch gehen ... sonst gibt es einen Fehler.

Du sendest 11 Kommandos quasi zur gleichen zeit raus ... das ist zuviel. Versuch mal ob Dir gruppen helfen.

[padrino]

@bananajoe
Ja, das mit der App weiß ich, das selbe kann man ja auch in Routinen einstellen.
In der App im "alten" Design (bis vor kurzem) blieb der Wert optisch auch wie eingestellt, im "neuen" Design sieht man den Slider von alleine auf den runden Wert hüpfen (Android).
Nein, habe kein Skript laufen, habe jetzt sogar zum Test extra die komplette JavaScript Instanz angehalten.

@apollon77
Wo Du grad mitliest
a) magst Du den "OT" Teil absplitten?
b) gibt es ein offizielles Limit in Zahlen?

[Ahnungsbefreit]

@n3ucr0n Ich würde statt der vielen Datenpunkte mit Listen arbeiten: 1 Liste mit den zu steuernden Alexa-DPs, je eine mit der Lautstärke für laut/leise/nachts. Dann kannst Du in einer Schleife über die Liste iterieren und die Verzögerung gleich mit hoch zählen. Das wäre deutlich kompakter und einfacher zu ändern...

[dslraser]

@n3ucr0n sagte in Alexa Lautstärkesteuerung via Blockly sehr unzuverlässig:

@padrino

Das hier ist einer der DP:

{
  "_id": "0_userdata.0.Lautstärke.Esszimmer_Laut",
  "type": "state",
  "common": {
    "name": "Esszimmer Laut",
    "role": "",
    "type": "number",
    "min": 0,
    "max": 100,
    "read": true,
    "write": true
  },
  "native": {},
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1604914774298,
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  }
}

Beschrieben habe ich die Datenpunkte händisch. Aktuell werden die auch nicht gesteuert bzw. verändert sondern sind starr.

mach mal eine passende role rein.
z.B.
"role": "level.volume",

[n3ucr0n]

@ahnungsbefreit
Hast Du ein (einfaches) Beispiel für mich, an dem ich mir den Gedanken mal näher führen kann?

@dslraser
Gute Idee! Werde ich testen! Das Thema mit der Verzögerung hat leider noch keinen Erfolg gebracht. Die Theorie dahinter leuchtet mir ein, daher werde ich die Verzögerung auch drin lassen, aber es werden noch immer die Lautstärken unzuverlässig geschaltet. Die Idee mit der Rolle wird heute noch umgesetzt.

[apollon77]

@padrino sagte in Alexa Lautstärkesteuerung via Blockly sehr unzuverlässig:

b) gibt es ein offizielles Limit in Zahlen?

Nicht wirklich ... experimentieren

[n3ucr0n]

@apollon77 said in Alexa Lautstärkesteuerung via Blockly sehr unzuverlässig:

Das Problem ist sehr einfach: Zu viel und zu schnell.
Amazon hat "rate Limits" definiert - bedeutet das nur eine definierte Anzahl an Kommandos in einer bestimmten Zeit durch gehen ... sonst gibt es einen Fehler.

Du sendest 11 Kommandos quasi zur gleichen zeit raus ... das ist zuviel. Versuch mal ob Dir gruppen helfen.

Oh hatte Deinen Beitrag oben überlesen, bitte entschuldigung.

Funktioniert der Workaround mit dem Setzen von Verzögerunden (jeder Block 1 Sekunde nach dem Vorherigen) oder ist das nicht zielführend?

Den Tipp mit den Gruppen werde ich testen.

[Ahnungsbefreit]

@n3ucr0n Ungetestet und nur ein Teil der Logik aus Deinem Script, sollte aber reichen, um das Prinzip zu verdeutlichen:

Wenn Du dann noch Gruppen verwendest, um alle Echos, die gleich gesteuert werden, zusammenzufassen, wird das sehr übersichtlich...

[BananaJoe]

@ahnungsbefreit

Ich meine das Skript ist so nicht richtig. Er wird die beiden Echos setzen und bei jedem das delay warten.

Wenn er in der Liste 10 Stück hat wir der die Befehle für die 10 hintereinander abfeuern , die werden den Delay warten dann aber trotzdem alle quasi zu gleichen zeit ausgeführt. Denn das Skript warten bei einem Delay nicht auf diesen sondern macht sofort weiter, der Schreibe Befehl macht das warten dann im Hintergrund.
Ich nehme deshalb "pause" um die Zeit zwischen 2 Zugriffen zu bremsen

[Ahnungsbefreit]

@bananajoe Ich denke, da liegst Du falsch. Genau für solche Zwecke gibt es den Parameter "Verzögerung in ms" . Damit wird der Wert eben genau nach Ablauf der Verzögerung gesetzt.

"Pause" sollte man wirklich nur im absoluten Notfall verwenden, ich habe in allen meinen Scripten keine einzige Pause drin und es funktioniert.

[BananaJoe]

@ahnungsbefreit sagte in Alexa Lautstärkesteuerung via Blockly sehr unzuverlässig:

@bananajoe Ich denke, da liegst Du falsch. Genau für solche Zwecke gibt es den Parameter "Verzögerung in ms" . Damit wird der Wert eben genau nach Ablauf der Verzögerung gesetzt.

"Pause" sollte man wirklich nur im absoluten Notfall verwenden, ich habe in allen meinen Scripten keine einzige Pause drin und es funktioniert.

Dann erkläre mir mal das:

:

Die müssten dann ja im Abstand von 1 Sekunde an-- und ausgehen, und nicht alle auf einmal.

[Ahnungsbefreit]

@bananajoe Nein, denn Du hast ja überall 1000 ms Verzögerung drin. In meinem Script zähle in jedem Schleifendurchgang die Verzögerung um 500 ms hoch. Also

1. mit 0 ms,
2. mit 500 ms,
3. mit 1000 ms und so weiter.

[BananaJoe]

@ahnungsbefreit jetzt habe ich deine Methode verstanden. In der Tat elegant, das Script ist schnell fertig und bereit für den nächsten Aufruf.

Wäre jetzt interessant wie en Befehlen setStateDelayed und await wait die Verzögerung umgesetzt wurde um zu sehen was die Folgen/Unterschiede sind.
Gibt es die Quellen dazu irgendwo? Mein erster Googleversuch war nicht erfolgreich

[Ahnungsbefreit]

@bananajoe Guckst Du hier: (https://gist.github.com/AlCalzone/d14b854b69ce5e8a03718336cc650a95#)