Neues Modul: ESPEasy [war: ESPEasy ohne MQTT]

[dev0]

Bei den 120 Build werden die Readings richtig unter einem Device angelegt. Ist das so gewollt?

R120 wird von dem Modul nicht unterstützt. Ab der aktuellen Modulversion fange ich das auch mit einer Warnung im log ab und Devices werden nicht angelegt/aktualisiert.

Hm also beim Build 133 von ESPEasy bekomme ich pro Wert ein neues Device angelegt.

Siehe bitte in den ersten Beitrag zum Attribut uniqIDs und/oder in die commandref. Daraus sollte hervorgehen wie Werte den FHEM Devices zugeordnet werden. Wenn es nicht klar wird, dann melde dich bitte noch einmal und wir verbessern gemeinsam die Beschreibung.

[P.A.Trick]

Puh ehrlich gesagt habe ich jetzt wirklich lange gebraucht um zu kapieren wie das funktioniert.

Also erst einmal habe ich das Attribut uniqIDs bei der Bridge auf 0 gesetzt.
Danach habe ich die IDX Values bei den Devices gesetzt (>0).
Beim Device Namen habe ich dann den Namen gesetzt.
Ok, wenn man es einmal verstanden hat ist es ok, aber einfach ist das ehrlich gesagt nicht.

Naja, jetzt will ich nicht meckern sondern mich noch einmal für das tolle Modul bedanken.
Jetzt kann ich wenigstens mein OLED Display schick ansteuern. Vielen lieben Dank dafür und
allen die daran mitgearbeitet haben! Ihr seid die Besten!

[dev0]

Ich habe die Staging Verison in den master branch eingecheckt: https://github.com/ddtlabs/ESPEasy
Damit wird die Version auch automatisch aktualisiert, wenn das Repository ins Update eingebunden wurde (update add https://raw.githubusercontent.com/ddtlabs/ESPEasy/master/controls_ESPEasy.txt).

Änderungen 0.44 <-> 0.51

- eval JSON decoding in http response
- removed Authorization String from debug log
- combined internals logging
- more detailed debug log (verbose 5, child bridge)
- check for temporary bridge device in deleteFn and do no IOWrite
   see: https://forum.fhem.de/index.php/topic,55728.msg497366.html#msg497366
- added check that fhem.pl is new enough (11000/2016-03-05)
   see: https://forum.fhem.de/index.php/topic,55728.msg497094.html#msg497094
- improved generell loggin for more easy support

[dev0]

Naja, jetzt will ich nicht meckern sondern mich noch einmal für das tolle Modul bedanken.

Das hat mit mekern nix zu tun. Wenn Du es besser beschreiben kannt, dann ist ein Patch für die commandref gerne gesehen.

[P.A.Trick]

Das hat mit mekern nix zu tun. Wenn Du es besser beschreiben kannt, dann ist ein Patch für die commandref gerne gesehen.

Hm nein man muss es halt lesen und verstehen! Ich habe mir nur eben überlegt ob eine bebilderte Anleitung helfen würde.
Was hälst du von einem Wiki Eintrag?

BTW: Ich fände es noch genial, wenn die ESP Easy Version in einem Reading angezeigt werden würde!?

[P.A.Trick]

Ich habe die Staging Verison in den master branch eingecheckt: https://github.com/ddtlabs/ESPEasy
Damit wird die Version auch automatisch aktualisiert, wenn das Repository ins Update eingebunden wurde (update add https://raw.githubusercontent.com/ddtlabs/ESPEasy/master/controls_ESPEasy.txt).

Änderungen 0.44 <-> 0.51

Leider bekomme ich auch mit dieser Version eine Warnung!

Code Auswählen Erweitern

2016.10.03 12:19:41.135 4: ESPEasy espBridge_192.168.1.22_17858: child device deleted
2016.10.03 12:19:46.427 4: Connection accepted from espBridge_192.168.1.19_31419
2016.10.03 12:19:46.431 1: PERL WARNING: Use of uninitialized value in substitution (s///) at ./FHEM/34_ESPEasy.pm line 569.
2016.10.03 12:19:46.432 3: stacktrace:
2016.10.03 12:19:46.433 3:     main::__ANON__                      called by ./FHEM/34_ESPEasy.pm (569)
2016.10.03 12:19:46.434 3:     main::ESPEasy_Read                  called by fhem.pl (3221)
2016.10.03 12:19:46.435 3:     main::CallFn                        called by fhem.pl (671)
2016.10.03 12:19:46.438 5: ESPEasy espBridge_192.168.1.19_31419: received header: {'Authorization' => undef,'Connection' => 'close','Content-Length' => '214','Host' => '192.168.1.101'}
2016.10.03 12:19:46.438 5: ESPEasy espBridge_192.168.1.19_31419: received content: {"module":"ESPEasy","version":"1.02","data":{"ESP":{"name":"wemos3","unit":0,"version":9,"build":133,"sleep":0,"ip":"192.168.1.19"},"SENSOR":{"0":{"deviceName":"wemos3","valueName":"RSSI","type":1,"value":"-67"}}}}
2016.10.03 12:19:46.442 4: ESPEasy espBridge_192.168.1.19_31419: no basic authentication required
2016.10.03 12:19:46.443 4: ESPEasy espBridge_192.168.1.19_31419: send http close '200 OK'
2016.10.03 12:19:46.447 5: ESPEasy espBridge_192.168.1.19_31419: dispatch: wemos3::192.168.1.19::1::1::0::i||unit||0||0|||i||sleep||0||0|||i||build||133||0|||r||RSSI||-67||1
2016.10.03 12:19:46.448 5: espBridge dispatch wemos3::192.168.1.19::1::1::0::i||unit||0||0|||i||sleep||0||0|||i||build||133||0|||r||RSSI||-67||1
2016.10.03 12:19:46.499 4: ESPEasy espBridge_192.168.1.19_31419: child device deleted


Ok es liegt an der fehlenden User/Pass Kombi. Jetzt habe ich die mal gesetzt und die Warnung ist weg!

[dev0]

Also erst einmal habe ich das Attribut uniqIDs bei der Bridge auf 0 gesetzt.

Das Attribut 'uniqIDs' muss nur disabled werden, wenn Du Daten von mehreren ESPs in 1 FHEM Device laufen lassen möchtest. Sonst reicht es aus die 'ESP Device Namen' (nicht den 'ESP Namen'!) identisch zu benennen. Dabei muss man nur darauf auchten, dass die 'Value Namen' alle unterschiedlich sind. Wenn nicht nötig, dann sollte man das Attribut uniqIDs nicht setzen, da sonst nicht mehr eindeutig festgestellt werden kann an welches Devices z.B. ein Befehl ala 'set gpio...' gesendet werden soll. Die wahrscheinlich bessere Alternative zum uniqIDs=0 ist eine zusätzliche readingsGroup. Im Nachhinein wollte ich das im Modul aber nicht mehr ändern um Anwender nicht zuverärgern, die das Attribut bereits nutzen.

Danach habe ich die IDX Values bei den Devices gesetzt (>0).

Das ist für das Modul eigentlich uninteressant, aber es scheint ESPEasy Plugins zugeben, die keine Werte schicken, wenn der Wert auf 0 steht.

Was hälst du von einem Wiki Eintrag?

Eigentlich nichts, da viele Wiki Beiträge nach einer gewissen Zeit nicht mehr aktuell sind und es keiner merkt. Eine ausführliche commandref sollte das aber abdecken.

BTW: Ich fände es noch genial, wenn die ESP Easy Version in einem Reading angezeigt werden würde!?

Das sollte in der aktuellen Modulversion im Internal ESP_CONFIG angezeigt werden.

Leider bekomme ich auch mit dieser Version eine Warnung!

Schaue ich mir gleich an, ich vermute, dass Du keine 'basic authentication' verwendest.

[dev0]

Leider bekomme ich auch mit dieser Version eine Warnung!

Code Auswählen Erweitern


2016.10.03 12:19:46.431 1: PERL WARNING: Use of uninitialized value in substitution (s///) at ./FHEM/34_ESPEasy.pm line 569.


Habe die Version 0.52 in master branch eingecheckt, die die Warnung, zur nicht gesetzten 'basic authorization', nicht ausgibt.
Kannst Du das bitte kurz testen?

[P.A.Trick]

Habe die Version 0.52 in master branch eingecheckt, die die Warnung, zur nicht gesetzten 'basic authorization', nicht ausgibt.
Kannst Du das bitte kurz testen?

Klappt! Vielen Dank!

[dev0]

Ich habe die aktualisierte Version 0.5.3 auf Github eingecheckt: https://github.com/ddtlabs/ESPEasy

- fixed: PERL WARNING: Use of uninitialized value in substitution (s///) at ./FHEM/34_ESPEasy.pm
- fixed: PERL WARNING: Ambiguous use of -time resolved as -&time() at ./FHEM/34_ESPEasy.pm
- attr adjustValue: reading can be a regexp
- code cleanup

[mutanwulf]

Hallo,
erstmal vielen Dank für das Modul habe das mal mit meinem NodeMCU getestet und funktioniert wunderbar.

Jetzt habe ich aber ein Problem"chen" mit dem WeMOS D1:

Der übermittelt irgendwie "true" anstatt den Wert von uptime und WiFi.

Muss ich einen anderen Sketch nehmen für die WeMOS D1?

Die NodeMCU sind mit dem gleichen Sketch (nur anderes Device) geflasht und laufen direkt.
Modul Version 0.54
ESPEasy 135

[dev0]

Der übermittelt irgendwie "true" anstatt den Wert von uptime und WiFi.

Da mir nur eine Ursache dafür bekannt ist, ist es schwer zu glauben, dass Du die selbe Binärdatei benutzt: Die ArduinoJson Library ist veraltet.
Kontrolliere das bitte noch einmal. Hier gibt es ESPEasy R137 RC1 auch als fertiges Image.

[Franz Tenbrock]

Hallo
wo ist eigentlich der Unterschied zwischen Wemos und Nodemcu
hab da irgendwie nichts gescheites im Netz gefunden ....

[P.A.Trick]

Hallo
wo ist eigentlich der Unterschied zwischen Wemos und Nodemcu
hab da irgendwie nichts gescheites im Netz gefunden ....

Gute Frage! Schaue einfach mal hier rein: http://frightanic.com/iot/comparison-of-esp8266-nodemcu-development-boards/

[mutanwulf]

Da mir nur eine Ursache dafür bekannt ist, ist es schwer zu glauben, dass Du die selbe Binärdatei benutzt: Die ArduinoJson Library ist veraltet.
Kontrolliere das bitte noch einmal. Hier gibt es ESPEasy R137 RC1 auch als fertiges Image.

Ich hatte den ESPEasy bei mir kompiliert aber auf 2 verschiedenen Rechnern.
Kaum die ArduinoJson aktualisiert schon gehts

Danke

Einer der Unterschiede zwischen WeMOS und NodeMCU ist, das die WeMOS wesentlich kleiner und "stackable" ist. Für den WeMOS gibt es Relais, Temperatur, Feuchte- und Enwicklungsboard als steckbaren Aufsatz.