Befehle und Skripte wirken nicht

Warum wird der Ein/Aus-Datenpunkt nicht aktualisiert?

Dieser Abschnitt wird noch geschrieben.

Warum setzt mein Skript ps oder on nicht, oder WLED ignoriert die Befehle?

Kurz: Meist liegt es an einer von fünf Ursachen: Der Wert wurde als Bestätigung (ack=true) statt als Steuerbefehl geschrieben, das Gerät war für den Adapter gerade offline, dasselbe Preset war schon aktiv, der Datentyp stimmt nicht, oder es kamen zu viele Befehle zu schnell hintereinander. Die Checkliste unten führt dich der Reihe nach durch.

So kommt ein Befehl beim Gerät an: Der Adapter reagiert nur auf Schreibzugriffe mit ack=false. Er baut daraus einen JSON-Befehl, zum Beispiel {"ps":3} oder {"on":true}, und schickt ihn sofort ab: über die WebSocket-Verbindung, wenn sie steht, sonst per HTTP an http://192.168.x.y/json. Es gibt keine Warteschlange und keine Wiederholung.

Checkliste

1. Steuern statt aktualisieren. In Blockly muss der Block „steuere“ sein, nicht „aktualisiere“. In JavaScript schreibst du setState(id, wert) ohne true als drittes Argument. Ein Wert mit ack=true gilt als Rückmeldung vom Gerät und wird nicht gesendet.

2. Von Hand testen. Schreib denselben Wert im Objektbaum des Admins in den Datenpunkt. Reagiert WLED darauf, liegt der Fehler im Skript, zum Beispiel an verschachtelten Auslösern oder einer falschen Objekt-ID. Die IDs der Geräte sind ihre MAC-Adressen, sie ändern sich nicht, wenn du das Gerät umbenennst.

3. Ist das Gerät online? Schau auf wled.0.<MAC>._info._online. Befehle an ein Gerät, das nicht erreichbar ist, gehen verloren. Der Adapter puffert nichts und wiederholt nichts.
   • Bis v0.9.2: Im Log steht ein Fehler „Sending command to WLED device … failed with error …“. Ist das Gerät dem Adapter gerade gar nicht bekannt, steht dort stattdessen ein TypeError, der auch an Sentry gemeldet wird.
   • Ab v0.9.3: Der Adapter verwirft den Befehl mit der Warnung Device <MAC> (192.168.x.y) is offline, command for … discarded (#904).

4. Zu schnell nach dem Einschalten? Bekommt WLED gerade erst Strom, zum Beispiel über eine Zwischensteckdose, ist es erst nach einigen Sekunden im WLAN erreichbar. Befehle davor gehen verloren.
   • Ab v0.9.3 kommt hinzu: Der Adapter sendet nur an Geräte, die er als verbunden kennt (#904). Dass ein Gerät wieder da ist, merkt er erst bei der nächsten Prüfung. Die läuft standardmäßig alle 30 Sekunden („Intervall in Sekunden“). War das Gerät länger aus, prüft er seltener: Die Abstände verdoppeln sich bis höchstens 10 Minuten, und nach 5 Fehlversuchen („Maximale Wiederholungsversuche“) nur noch einmal pro Stunde. Bis dahin verwirft er Befehle.
   • Lass dein Skript deshalb warten, bis wled.0.<MAC>._info._online auf true geht, und schick den Befehl erst dann.

5. Dasselbe Preset schon aktiv? Zeigt ps bereits die Nummer, die du schreibst, lädt WLED das Preset nicht noch einmal. Das passiert auch, wenn du das Licht zwischendurch über on ausgeschaltet hast. Schick dann {"on":true,"ps":3} an wled.0.<MAC>.action.

6. Passt der Datentyp? on erwartet true oder false, ps eine Zahl. Schreibst du on als Text, macht WLED etwas anderes als gedacht: Ein Text, der mit t beginnt (also auch "true"), schaltet um, und "false" als Text bewirkt gar nichts. ioBroker meldet einen falschen Datentyp zusätzlich als Warnung im Log.

7. Zu viele Befehle hintereinander? Jeder geänderte Datenpunkt ist ein eigener Befehl. Schreibt dein Skript on, bri, Farbe und ps direkt nacheinander, kann WLED Befehle verlieren oder mit Zeitüberschreitung antworten. Fass zusammengehörende Werte in einem JSON-Befehl über action zusammen, zum Beispiel {"on":true,"bri":128,"ps":3}, oder leg sie gleich in einem Preset ab und setz nur ps. Wenn es einzelne Befehle sein müssen, lass zwischen ihnen eine kurze Pause.

8. Rückmeldung über WebSocket. Läuft die Verbindung über WebSocket, setzt der Adapter bis v0.9.2 selbst kein ack=true und meldet auch keinen Sendefehler. Das ack kommt erst, wenn WLED seinen neuen Zustand meldet. Bleibt ein Wert auf ack=false, ist der Befehl wahrscheinlich nicht angekommen. Ab v0.9.3: Der Adapter setzt ack=true, sobald der Befehl gesendet ist, und schreibt eine Warnung „Sending command for … failed“ ins Log, wenn das Senden scheitert (#904).

9. Segment-Befehle. Setzt du einen Wert in einem Segment, etwa wled.0.<MAC>.seg.0.fx, geht der Befehl nur an dieses Segment. Prüf, ob du das richtige Segment erwischt hast und ob es eingeschaltet ist.

10. Debug-Log ansehen. Stell die Instanz auf Log-Stufe „debug“. Bei jedem Befehl erscheint dann „Sending state change by websocket …“ oder „Sending state change by http-API …“ mit dem gesendeten JSON. Fehlt die Zeile, ist der Befehl gar nicht beim Adapter angekommen.

NOTE

Liest dein Skript on, beachte: Bis v0.9.2 setzt der Adapter on auf false und bri auf 0, wenn ein Gerät offline geht, und beim Adapterstart. Ab v0.9.3: Beide behalten ihren letzten Wert, die echten Werte kommen beim Wiederverbinden vom Gerät (#899).

Siehe auch: Presets per Datenpunkt ps schalten · Kompletten JSON-Befehl senden · Mehrere Befehle führen zu ETIMEDOUT · Woran sehe ich, ob ein Gerät online ist · Wiederholungen bei Offline-Geräten · Warnungen zum falschen Datentyp

Warum führen mehrere Befehle kurz hintereinander zu ETIMEDOUT?

Dieser Abschnitt wird noch geschrieben.

Warum springt ps auf -1 oder zeigt nicht das gewählte Preset?

Dieser Abschnitt wird noch geschrieben.

Warum bleiben nach dem Ausschalten einige LEDs an?

Dieser Abschnitt wird noch geschrieben.

Warum hat der Datenpunkt cct keine Wirkung?

Dieser Abschnitt wird noch geschrieben.