Hallo zusammen,
ich habe hier mein erstes Modul des RGBWW-ESP-Moduls liegen und scheitere ein bisschen an der Erst-Integration in FHEM. Ich habe versucht, mich an die Hinweise hier zu halten: https://forum.fhem.de/index.php/topic,70738.0.html (https://forum.fhem.de/index.php/topic,70738.0.html)
Status:
- das Hardware funktioniert und ist erreichbar, d.h. ich kann über http die Konfiguration vornehmen, Farben ändern etc.
- Firmware laut Web-Frontend ist vbs35 (RGBWW version 0.8.1-vbs5, SMING Version 3.5.1), beim Update-Check wird mir als verfügbare OTA-Version 0.3.1-vbs35 angezeigt (auch nach Durchführung des Updates)
- das FHEM-Modul wurde installiert und das Device "ESPtest" erstellt
- MQTT-Server läuft und kriegt auch Daten vom ESP-Modul, wenn man über webapp Farben ändert etc. (sollte ja aber für's direkte Schalten über FHEM erstmal keine Rolle spielen, oder?)
Für mich sieht das alles soweit gut aus, und nach meinem Verständnis müsste ich jetzt doch eigentlich z.B. über
set RGBtest rgb 008080 (bzw. über den Color-Picker) die Farbe ändern können - geht aber nicht. Die LEDs reagieren nur auf das, was über das Web-Frontend des Moduls (webapp) direkt gewählt wird.
Im Logfile taucht immer wieder
ESPtest: error http://192.168.1.51/config?: empty answer received retrieving config auf.
Also irgendwas stimmt da nicht mit der Kommunikation :-(
So sieht das Device bei mir aus, wie im Anhang...
Ich wäre dankbar für sachdienliche Hinweise und entschuldige mich schon mal, falls noch wichtige Infos fehlen sollten - das ist noch komplettes Neuland für mich.
CU,Matze
Gib das bitte mal in deinen Browser ein und gucke, was da kommt:
http://192.168.1.51/config
Hi,
da kriege ich ein wunderschönes JSON-File angezeigt:
Hm, sieht super aus. Kannst du das gleiche nochmal auf dem Rechner machen, auf dem FHEM läuft? Also ggf. per Kommandozeile:
curl http://192.168.2.53/config
Hab momentan keine gute Idee/keinen Ansatz. Kannst du mal bitte verbose auf 5 stellen und dann nochmal ein "get config" auslösen?
Hallo Matze,
hiermal meine Definition
defmod LED_Stripe01 EspLedController 192.168.178.20
attr LED_Stripe01 devStateIcon {Color_devStateIcon(ReadingsVal($name,"rgb","000000"))}
attr LED_Stripe01 webCmd on:off:rgb:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffff00
attr LED_Stripe01 widgetOverride rgb:colorpicker,rgb
Dann sollte es so aussehen wie in dem Screenshot.
Gruß
Markus
Hi,
Zitat von: vbs am 02 Januar 2019, 13:31:29
Hm, sieht super aus. Kannst du das gleiche nochmal auf dem Rechner machen, auf dem FHEM läuft? Also ggf. per Kommandozeile:
curl http://192.168.2.53/config
Hab momentan keine gute Idee/keinen Ansatz. Kannst du mal bitte verbose auf 5 stellen und dann nochmal ein "get config" auslösen?
mit curl direkt vom Raspi bekomme ich ebenfalls problemlos ein JSON-File.
Ich hab gerade mal verbose auf 5 gestellt (s. Anhang, ab ca. 19:11)
Hallo Markus,
Zitat von: Markus. am 02 Januar 2019, 18:25:44
hiermal meine Definition
Dann sollte es so aussehen wie in dem Screenshot.
Genau so (natürlich mit meinen Adressen) sieht's aus - es reagiert aber nix, egal was ich mache.
... noch ein kleiner Nachtrag:
Wenn ich über webapp die Farbe ändere, dann kommen die entsprechenden Readings auch im FHEM-Modul an. Es funktioniert also "nur" der Weg FHEM->ESP nicht
Hm, also vorweg: ich hab nach wie vor leider kein Idee.
Aber: er sagt ja immer "empty answer received" bei jedem HTTP-Request. Ich kenne das Problem, dass diese Meldung auch immer einmalig bei jedem Neustart von FHEM (wenn das ESP-Modul initial den Status abruft) erscheint. Passiert bei mir. Ich hab aber nie rausfinden können warum. Ich halte es für ein FHEM-Problem, kann es aber nicht beweisen. Komisch eben, dass es nur einmalig beim Neustart passiert. Vielleicht führt das gleiche Problem dazu, dass es bei dir (warum auch immer) ständig passiert.
Hast du schonmal FHEM neu gestartet? Hilft das evtl.?
Ansonsten probier mal bitte eine Minimal-Config für FHEM zu bauen, wo nur dieses eine Gerät drin ist. Mal gucken, ob das was ändert.
Zum Nachtrag:
Ja, der Event-Server funktioniert. "Nur" die HTTP-Requests wollen nicht.
Hallo zusammen,
das mit der Mini-Konfig probier ich noch. Ich hab jetzt mal auf dem Raspberry (auf dem FHEM läuft) einen tcpdump gemacht um zu sehen, was da eigentlich so passiert (s. Anhang):
- zuerst läuft da ne schöne TCP-Unterhaltung zwischen Raspberry (192.168.1.11) und ESP-Controller (192.168.1.51)
- FHEM sendet das JSON-Paket per HTTP POST an den Controller
- und jetzt kommt's: der setzt die Verbindung zurück (RST)
Wenn ich das richtig sehe, dürfte das Problem also am Controller liegen, oder?
(Beide momentan vorhandenen Controller verhalten sich übrigens identisch)
Wäre die Frage, warum es mit allen anderen Clients geht, die nicht FHEM sind, oder?
Kannst du mal von dem FHEM-PC (z.B. per curl) ein HTTP-GET auf /config mitschneiden und einmal das aus FHEM ausgelöste "get config"? Sollte beides den gleiche HTTP-Request auslösen.
Hi,
ich glaub, es liegt wohl doch irgendwo an FHEM - ich hab jetzt eine Minimal-Konfig gemacht, damit funktioniert das alles bestens :-[ Hier ein tcpdump...
Jetzt ist wieder die Original-Konfig drin.
Wenn ich http://192.168.1.51/config per curl abfrage, sehe ich ein HTTP GET und krieg das JSON auch zurück.
Über get xxx config sieht das alles deutlich anders aus (s. Anlage); hier reichen meine Wireshark-Kenntnisse dann nicht mehr aus :-\, aber es endet wieder mit einem RST
18:35:08: curl
18:35:13: get xxx config
So, Problem gefunden 8)
Durch das autocreate hatte ich jede Menge KNX-Devices in meiner Konfig (die war ca. 122kB groß). Die habe ich jetzt einfach mal alle entfernt (noch 11kB), und schon fluppt das mit den LEDs und auch die restliche Bedienung von FHEM ist deutlich angenehmer geworden!
Es ist also definitiv (?) ein FHEM- bzw. Performance-Problem. Dein Modul und alles drumherum scheint nun wunderbar zu funktionieren.
Vielen Dank für die Unterstützung bei der Ursachenforschung....
Na gern, immerhin einen Schritt weiter. Ist generell eine wertvolle Erkenntnis, dass es offenbar ein Performanceproblem ist. Das erklärt mMn auch das Verhalten, welches ich bei mir beim Starten von FHEM beobachte.
Ich kann das auch im tcpdump nachvollziehen:
Es wird der TCP-3-Wegehandshake durchgeführt und der ist dann zum Zeitpunkt 5.128 abgeschlossen. Jetzt könnte FHEM Daten senden, tut es aber nicht. Dann um 6.52 wird die Verbindung vom Controller geschlossen (FIN-Flag), vermutlich ein Timeout. Bei deinem ersten Beispiel war es dann so, dass FHEM dann nach einer knappen weiteren Sekunde doch noch Daten geschickt hat (den HTTP-POST). Da aber aus Sicht des Controllers die TCP-Verbindung schon nicht mehr bestand, wurden diese Pakete dann mit RST quittiert.
Bei deinem Gut-Fall kann man sehen, dass curl innerhalb von Millisekunden Daten schickt, nachdem die Verbindung aufgebaut wurde.
Ich war etwas überrascht zu sehen, dass die Verbindung nach ca. 1,5 Sek. vom Controller wieder geschlossen wird, wenn dann nicht augenblicklich Daten nachkommen. Evtl. kann man da im TCP-Stack des Controllers ein paar Timeouts laxer einstellen, um das zu entschärfen.
Also der Default-Wert ist relativ knapp bemessen in SMING. 8)
int keepAliveSeconds = 0; // << the default seconds to keep the connection alive before closing it
Wenn ich das erhöhe und damit eine neue Firmware baue, könntest du das dann nochmal testen gegen deinen Fehler-Zustand? Also könntest du den nochmal herstellen?
Ich hab mal eine vbs36b gemacht, welche die HTTP-Verbindung 5 Sek. offen hält. Freue mich über jeden Test(er):
set myRgbCtrl fwUpdate http://rgbww.dronezone.de/testing/version.json
Hi,
dummerweise hab ich keine Kopie der alten fhem.cfg - aber ein komplettes Image des Raspi 8)
Ich hol mir das gerade mal aus der Sicherung und versuch's damit nochmal:
- Test mit jetziger Firmware (Fehler rekonstruieren)
- Firmware-Update
- erneuter Test
dauert aber noch ein paar Minuten :)
Schön, wenn ich als Anfänger hier endlich mal was dazu beitragen kann!
So, hier das Ergebnis:
"leider" kann ich mit der fhem.cfg aus meinem letzten Backup (vom 30.12.) den Fehler nicht nachstellen; diese ist auch "nur" 88kB groß (die fehlerhafte hatte 122kB) - da muss in den letzten paar Tagen also einiges dazugekommen sein.
Auf jeden Fall funktioniert's mit der alten fhem.cfg nun auch ohne Firmware-Anpassung. Aber vielleicht kann das ja jemand anders nachvollziehen ::)
Ok, macht nix. Bin mir jetzt eigentlich recht sicher, das Problem verstanden zu haben. Hadere aber noch ein bisschen mit mir über den konkret Timeout-Wert am Ende.
Also vielen Dank an dich, hat sehr geholfen diesem Problem, welches ich da schon länger vermutet habe, auf die Schliche zu kommen!