Edomi und WLED Json/API

[saegefisch]

Hi Micha,
ja, ich weiß, dass Du damit auch Recht hast... für mich selber kann ich mir die Löterei auch vorstellen, aber bei Bekannten möchte ich lieber was (fast) Fertiges einbauen. Und wie gesagt: Bei adressierbaren Strips ist "fliegend" auch durchaus denkbar, weil man die Ströme sauber direkt in die Strips bringen kann. Den Pegelwandler kann ich mir bei 5V für viele ESP8266 sogar auch noch sparen (z.B. wie hier), wenn er für 5V gebaut ist.

Ergänzende Info zum verlinkten Shield oben: Das Shield hat noch eine Sicherung und ein Relais wegen des Standby-Verbrauchs - siehe hier.

Aber guter Hinweis auf den Strip, danke! Die Daten des Strips lesen sich gut. Hatte noch gar nicht auf dem Schirm, dass es auch adressierbare RGW gibt, dachte nur RGB. Leider fehlt die Angabe eins CRI-Werts (W natürlich nur ) und der Lichtmenge/Meter (oder hab's überlesen). Und es läppert sich der Preis über die Meter auch gegenüber "herkömmlichen".

Adressierbare LEDs sind für mich gerade auch eher nachrangig (bzw. wie bei Dir für mich erst mal leicht lösbar), eine HW-Lösung für herkömmlichen PWM-Strips treibt mich derzeit viel mehr um.

[vento66]

Ich halt das ganz simpel ESP32 -> 3 Drähte anlöten, und ab ins Gehäuse. Maximal noch einen Pegelwandler dazwischen, und fertig. Nur ist mir bis jetzt 1 mal der Pegelwandler abgeraucht, ohne gehts aber auch. Ich hab aber SK6812 RGBWW Stripes mit 5V am laufen.

[saegefisch]

Zu WLED:
Ausblick: Ich arbeite derzeit an einer ordentliche Integrationen in die edomi-Szenen, weil ich die vielfältig einsetze und WLED zukunftsfähig finde für die variable Ergänzung fester Beleuchtung. Dies gilt für RGB(W), aber ich möchte das auch für adressierbare LEDs erreichen. W/WW, RGB(W) soll sich damit technisch wie ein fest verbauter Strip (KNX, DALI) verhalten/nutzbar sein. Bei den adressierbaren soll zumindest der per WLED-App/GUI eingestellte Stand gespeichert werden können. Ein wenig Spielen damit wird sicher auch gehen (z.B. durchschalten Effekte oder auf "solid" setzen) und Anzeige von aktiver Pallette/Effekt als Text wird definitiv gehen (selbst, wenn sie seitens WLED sich mal ändern), aber wie schon geschrieben: Es ergibt mMn keinen Sinn, die App nach zu programmieren - weil WLED wird ja auch weiter entwickelt. Das will man nicht immer nachziehen müssen.

Parallel treibt mich die Hardware dazu um. Das ist zwar etwas OT aber vielleicht interessiert es auch andere, weil WLED schon spannend ist. Derzeit baue ich per Steckbrett - klappt wunderbar für WSxxx, aber auch RGB(W). Infos zur Verkabelung auf der WLED-Seite hier, hier und hier. Aber auch im WWW z.B. für RGB(W) hier und viele weitere. Um der Frage zuvor zu kommen, warum man nicht alles in WSxxx macht? Für Akzentlicht valide, aber wenn es um hohe Lichtmengen geht und/oder hohe CRI-Werte, sind nur "herkömmliche"Strips sinnvoll. Fehlt ein Bedarf für Adressierbarkeit, sind sie bei größen Längen auch spürbar günstiger.

Für eine dauerhafte Nutzung ist Steckbrett aber nix - finde ich. Für WSxxx geht es vielleicht noch (irgendwie), aber für RGB(W) mit den nötigen MOSFETs ist dies wegen der erforderlichen Querschnitte bei langen Strips mit den größeren Strömen auch ein Risiko. Auch wenn ich da immer mit 24V arbeite, um die Ströme klein zu halten. Daher die Frage an die Runde, die vielleicht schon weiter damit sind:

Gibt es empfehlenswerte ESP8266-Shields oder fertige Geräte, die man mit der aktuellen WLED-Firmware betreiben kann?

• Für adressierbare LEDs (WSxxxx) bin ich auf das hier gestoßen und sieht für mich gut aus. ESP flashen und drauf, in Gehäuse einbauen, Netzteil dran und Strip. Fertig. Kennt das schon jemand? Empfehlenswert? Alternativen?
• Was mich besonders umtreibt: Kennt jemand etwas vergleichbares für RGB(W) und 24V? Als ESP8266-Shield oder fertiges Geräte, dass mit WLED flashbar ist.

[saegefisch]

...ich musste da erst mal drüber schlafen, Dein Argument ist ja auch richtig. Irgendwie...
Mein Gedanke: Wenn das Device nicht mehr antwortet, wird es vermutlich aus sein (oder man hat eine fragile (W)LAN-Infrastruktur). Dann ist der letzte Stand vermutlich inhaltlich falscher, als ein leerer Zustand. Zumindest bei WLED. Bei einem Sensor oder anderen Devices (ist ja ein generischer LBS) hingegen wäre es wohl wie "retained" und daher besser als zu leeren. Und natürlich kann man auch selber über den A4 = Error code und/oder A3 = "{error:...}" reagieren und aktiv Werte gewünscht setzen.

Daher: Für WLED würde ich denken, leeren wäre besser, für einen generischen LBS ist Dein Argument völlig richtig und es bleibt besser, wie es ist.

[jonofe]

Wäre es nicht sinnvoll, die dann zu leeren? Mir schient es logischer, aber vielleicht gibt es dazu auch andere Meinungen.

Für die Liveansicht gebe ich dir vielleicht Recht, allerdings durch den Event-gesteuerten Ansatz von EDOMI würde ein einfaches Rücksetzen der Ausgänge natürlich auch wieder die nachfolgenden Logiken triggern, was natürlich keinen Sinn macht, da ja an A1-A3 eigentlich nix passiert ist. Daher bevorzuge ich eigentlich immer Ausgänge nur dann zu setzen, wenn es auch neue Informationen für den Ausgang gibt. Ein Leeren ohne Triggern der Nachfolge Logiken gibt es ja leider nicht.

[saegefisch]

Zwei Gründe:
* WLED macht kein MQTTS, nur non-secured MQTT - was ich für mich persönlich nicht möchte, weil wichtigeres darüber läuft, als ein paar LEDs und den Sicherheitslevel nicht für WLED absenken möchte (=PW im Klartext im WLAN). Ja, ich nutze auch ACL und könnte es damit abschirmen mit getrennten Usern, aber es erhöht das Risiko von Fehlern, daher habe ich bei mir Port 1883 gar nicht aktiv, nutze also nur MQTTS, nicht aber MQTT parallel.
* Bei Bekannten möchte ich nicht auf ewig der admin bleiben, also die Komplexität so niedrig wie möglich: Mit ordentlicher KNX-Doku kann ein Eli helfen, mit edomi dieses Forum bzw. im Notfall einer Neuinstallation die Anleitung von Christian. Bei Menschen, die keinerlei Linux können, ist edomi schon Grenzerfahrung (kommen aber gut damit klar und sind sehr glücklich damit im Betrieb und kleinen Änderungen), aber MQTT liegt jenseits dessen.

Daher finde ich dafür HTTP-POST ganz wunderbar. Wenn MQTTS gehen sollte, würde ich MQTT auch bevorzugen, es bleibt die Sache mit der Komplexität bei Bekannten. Daher ist der LBS klasse - zumal generisch für viele andere HTTP-Zwecke ein Schweizer Messer.

[vento66]

MQTT läuft bei mir auf der EDOMi Büchse, ich sehe also keinen Grund, warum es kein MQTT geben sollte

[saegefisch]

Der LBS ist echt klasse und hilft mir wirklich sehr für edomi-Lösungen bei Freunden - weil eben kein MQTT. Und für mich jetzt auch erst mal, weil WLED derzeit noch kein MQTTS kann und unsecure MQTT ich in meinem LAN eigentlich nicht möchte. Da laufen auch wichtigere Dinge drüber, als ein paar LEDs. Und wenn man dem WLED-Issues auf GitHub folgt, wird es für ESP8266 auch kein MQTTS geben mangels Leistung. Obwohl ESPhome es kann auf ESP8266. Aber WLED hat wegen der Effekte mit x LEDs auch andere Anforderungen... Daher wird mir Dein LBS vermutlich wohl dauerhaft WLED anbinden.

Nachtrag: Wenn nach einem erfolgreichen Lauf das WLED-Device ausschaltet, liefert der nächste Aufruf nach der timeout-Zeitspanne zwar korrekt einen Fehler an A4 und A5, aber die anderen Ausgänge A1 bis A3 bleiben unverändert. Wäre es nicht sinnvoll, die dann zu leeren? Mir schient es logischer, aber vielleicht gibt es dazu auch andere Meinungen.

[saegefisch]

Prima, danke für die Info zu E9/E10.
V0.3: Geht alles. Auch E17 als Trigger funktioniert auch wunderbar. Danke! Du bist echt klasse, André! Ein kühles Kölsch (oder Alt? Ist ja ein Minenfeld diese Frage... je nach Ortschaft...) auf Dich! Oder beides... Damit ist edomi wieder ein Stück generisch-universeller geworden.

Und WLED ist damit nun via HTTP ebenso wie mit MQTT nutzbar. Das zu liefernde JSON ist exakt gleich.

Info für WLED-Nutzer. Wenn man an E17 im JSON ein "v":true ergänzt, liefert A3 danach auch wieder den gesamten STATE nach Änderung, um damit seine Visu zu aktualisieren. Ohne den Parameter kommt an A3 sonst nur {"success":true}

[jonofe]

v0.3 ist jetzt online.

EDIT: Habe es jetzt mit deinen Einstellungen getestet, nur als URL habe ich http://httpbin.org/post verwendet.
Das funktioniert. E9 und E10 kannst du auf Default=1 lassen, die werden nur bei URLs mit "https://" berücksichtigt.

[jonofe]

Use of undefined constant CURLOPT_HTTPHEADERS

Okay, guter Hinweis. Da ist ein S zu viel. Muss CURLOPT_HTTPHEADER heißen. Das ändere ich noch kurz ab.
Kommt dann gleich die v0.3.

[jonofe]

Wäre es nicht sinnvoll, wenn E17 auch zusätzlicher Trigger wäre?

Ja, das wäre sinnvoll und daher jetzt auch in v0.2 enthalten. Außerdem war noch ein Fehler in der Schreibweise in CURLOPT_POSTFIELDS, welcher dazu geführt hat, dass POST data (E17) nicht berücksichtigt wurde. Das Problem sollte jetzt auch behoben sein.

[saegefisch]

Dank' Dir, André! Du bist immer wieder eine Wundertüte...

Werde mir den LBS nachher mal installieren und testen und berichten. Aber schon vorab: Wäre es nicht sinnvoll, wenn E17 auch zusätzlicher Trigger wäre? Weil wenn ich neuen payload produziere, soll er normalerweise auch raus. Dann spare ich mir, aus dem non-numeric (JSON-)Daten noch irgendwie eine 1 für E1 produzieren zu müssen.

Nachtrag: Ich musste es doch gleich probieren... mit E4 bis E13 alles default belassen, außer E9 = 0 und E10 = 0.

• Mit GET und E2 = "http://192.168.xxx.yyy/json/state" bekomme ich (wie erwartet) sofort das gleiche an A3, wie mit dem edomi-eigenen GET und an A2

HTTP/1.1 200 OK
Content-Length: 391
Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: *
Access-Control-Allow-Headers: *
Connection: close
Accept-Ranges: none

• Ändere ich auf POST mit E14 = "application/json" und E17 = "{"on":true,"bri":10}" (alles andere unverändert), bekomme ich zurück A2

HTTP/1.1 400 Bad Request
Content-Length: 0
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: *
Access-Control-Allow-Headers: *
Connection: close
Accept-Ranges: none

im Error-Log:

Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19002326.php | Fehlercode: 2 | Zeile: 132 | Use of undefined constant CURLOPT_HTTPHEADERS - assumed 'CURLOPT_HTTPHEADERS' (this will throw an Error in a future version of PHP)
Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19002326.php | Fehlercode: 2 | Zeile: 132 | curl_setopt() expects parameter 2 to be int, string given
Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19002326.php | Fehlercode: 2 | Zeile: 141 | Use of undefined constant CURLOPT_POST_FIELDS - assumed 'CURLOPT_POST_FIELDS' (this will throw an Error in a future version of PHP)
Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19002326.php | Fehlercode: 2 | Zeile: 141 | curl_setopt() expects parameter 2 to be int, string given

WLED2.jpg

Nachtrag 2: bei CURLOPT_HTTPHEADERS muss vermutlich nur das S weg
Nachtrag 2: bei CURLOPT_POST_FIELDS muss vermutlich nur der Unterstrich weg
Danach funktioniert es und WLED akzeptiert/verarbeitet die gesetzten Werte...

[jonofe]

Habe jetzt mal einen generischen HTTP-Request LBS (19002326) hochgeladen.
Dieser unterstützt GET, POST, PUT, DELETE, PATCH und auch SSL, Basic Auth, Digest Auth.
Der LBS ist noch nicht dokumentiert.

Für die Anforderung aus diesem Thread sind folgende Eingänge gegenüber den Default-Werten zu ändern:

E2: richtige URL eintragen
E3: POST
E14: application/json
E17: <WLED JSON API String>

Danach sollte ein Triggern von E1 mit einer 1 den Request ausführen und an A3 sollte die Antwort erscheinen. A2 zeigt die Header, A1 den Response-Code.
Über E18 kann man steuern, ob bei einer Response mit mehr als 10.000 Zeichen (Limit der EDOMI iKOs) das Ergebnis in ein File geschrieben werden soll.
Wenn an E18 ein gültiger Filename angegeben wird, dann passiert dies automatisch. Der Erfolg wird dann über A6 und A7 signalisiert.

Mögliche Erweiterungen des LBS:
Cookies
Custom-Headers
Custom-Options

[saegefisch]

oh ja,...
ich hatte die ganze Zeit nur die JSON API angeschaut, weil ich einfach immer versuche JSON und/oder MQTT zu denken. Das andere hatte ich mir beim ersten WLED-Kontakt mal überflogen, aber dort steht auch "While this API is not deprecated, it is highly recommended to use the JSON API instead of the HTTP API for new integrations, as it is structured in a better way and allows efficient use of newer features like segments, presets, and playlists." und habe den Weg daher später nicht mehr auf GET/POST hin geprüft

Ich denke daher weiterhin, dass JSON via HTTP-POST der bessere Weg ist - wenn kein MQTT verfügbar ist