Ankündigung

Einklappen
Keine Ankündigung bisher.

Edomi und WLED Json/API

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #16
    Zitat von saegefisch Beitrag anzeigen
    Für das Setzen von Werten braucht's POST. Oder ich habe die WLED-Anleitung falsch verstanden,
    Ganz ober steht doch

    Code:
    Example (AP): 192.168.4.1/win&A=255 sets the brightness to maximum
    Example (mdns): led.local/win&A=128&FX=0 sets the brightness to half and the effect to Solid
    Das sah für mich spontan nach HTTP-GET aus. Nicht?

    Wenn man per JSON ansteuert, dann ist HTTP-POST notwendig. So zumindest mein initiales Verständnis...
    Zuletzt geändert von jonofe; 11.11.2021, 19:23.

    Kommentar


      #17
      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
      Zuletzt geändert von saegefisch; 11.11.2021, 17:52.

      Kommentar


        #18
        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

        Kommentar


          #19
          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
          Code:
          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
          Code:
          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:
          Code:
          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...
          Zuletzt geändert von saegefisch; 12.11.2021, 17:47.

          Kommentar


            #20
            Zitat von saegefisch Beitrag anzeigen
            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.

            Kommentar


              #21
              Zitat von saegefisch Beitrag anzeigen
              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.

              Kommentar


                #22
                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.
                Zuletzt geändert von jonofe; 12.11.2021, 17:49.

                Kommentar


                  #23
                  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}
                  Zuletzt geändert von saegefisch; 12.11.2021, 19:08.

                  Kommentar


                    #24
                    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.
                    Zuletzt geändert von saegefisch; 12.11.2021, 19:06.

                    Kommentar


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

                      Kommentar


                        #26
                        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.
                        Zuletzt geändert von saegefisch; 12.11.2021, 21:53.

                        Kommentar


                          #27
                          Zitat von saegefisch Beitrag anzeigen
                          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.

                          Kommentar


                            #28
                            ...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.
                            Zuletzt geändert von saegefisch; 14.11.2021, 16:40.

                            Kommentar


                              #29
                              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.
                              Zuletzt geändert von saegefisch; 14.11.2021, 17:39.

                              Kommentar


                                #30
                                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.

                                Kommentar

                                Lädt...
                                X