ESP8266 mit ESPEasy in wenigen Minuten an Fhem anbinden

[chunter1]

Ich sag mal: Solange es nix saubereres unvierselle(re)s gibt, bin ich froh, daß ESPEasy existiert.
Wer's besser machen kann: Nur zu. Wir freuen uns auch bestimmt gehörig darüber...

Gut formuliert
Hoffentlich auf Eclipse... das MESH Demo des ESP8266 schaut auch sehr interessant aus!

[juppzupp]

Wer mag kann sich ja http://www.wifi-iot.ru mal anschauen.

[chunter1]

Wer mag kann sich ja http://www.wifi-iot.ru mal anschauen.

link geht nicht?

[juppzupp]

Ist wohl gerade down.

[Rince]

Naja, man könnte es forken und eine gehärtete Version draus machen. Die haben sich in den ersten Versionen wohl erstmal drauf gestürzt, alle möglichen Sensoren abfragbar zu machen.

Ich denke, dass eine Mitarbeit auf jeden Fall erst mal schlauer wäre. Es könnte ja für den Anfang reichen, erst mal ein Issue in Git zu posten und auf die entsprechenden Überläufe hinzuweisen.


Wenn sie kooperativ sind (und warum nicht? Stabilität liegt in ihrem eigenen Interesse), gewinnen alle davon.

Ein neues "Framework" mag für das ein oder andere Problem eine Lösung sein, Erfahrungsgemäß kauft man sich damit nur neuen Ärger an anderer Stelle ein. Gerade beim ESP schießen derartige Projekte wie Pilze aus dem Boden. Noch einen wachsen zu lassen, halte ich derzeit für nicht zweckdienlich.

Aber das sind nur die 2 Cent von jemand, dessen Mithilfe beim Programmieren, mangels Fähigkeit, nicht erwartet werden kann...

[chunter1]

Wer mag kann sich ja http://www.wifi-iot.ru mal anschauen.

Sehr interessant!
Vorallem wegen dem hier (obwohl auch nicht RTOS):

"The project is written in C language using the chip developer SDK. WITHOUT LUA, WITHOUT Arduino IDE. Fast, compact and stable code (compared with LUA, Arduino IDE)."

Damit ist für mich klar, dass ich vorerst eher keine Zeit mehr in ESPEasy investiere... (so lieb das Arduinospielzeug auch sein mag..)

[Bapt. Reverend Magersuppe]

Sehr interessant!
Vorallem wegen dem hier (obwohl auch nicht RTOS):
Damit ist für mich klar, dass ich vorerst eher keine Zeit mehr in ESPEasy investiere... (so lieb das Arduinospielzeug auch sein mag..)

Wenn man denn die Sprache beherrscht....

[chunter1]

Google Webpage Übersetzer ist dein Freund

[RappaSan]

Hat denn jemand noch einen Tip, wo die 2 Nachkommastellen in Code generiert werden und wie man sie wegbekommt?

[Bapt. Reverend Magersuppe]

Google Webpage Übersetzer ist dein Freund

Der Übersitzer stolpert sich ja was zusammen
So wie ich das verstehe gibt es keinen Source. Naja, einen Source den man nicht sieht kann man auch nicht schlecht reden
Für eine Pro-Version muss man sich für 2€ einen Key kaufen (sofern man die braucht) in Russland.

Vermutlich muss man noch 2-3 Monate abwarten was sich insgesamt so entwickelt oder selber irgendwo mitmachen wenn man es denn kann.
Ich bräuchte beispielsweise etwas, das per MQTT kommuniziert, ein paar Messwerte von Sensoren wie Temperatur usw durchgibt und per MQTT-subscribe GPIOs schaltet.

[hjgode]

Soweit ich weiß, kann der ESP-8266 keine echten Hardware Interrupts, weshalb wahrscheinlich viele Schleifen im ESPeasy programmiert werden mussten. Ich habe mir den Code jedoch nicht angesehen.

Abhilfe kann man hier nur schaffen, wenn man einen Arduino oder anderen Hardware-Interrupt fähigen Prozessor verwendet und den ESP nur als WLAN Schnittstelle. Dazu gibt es wahrscheinlich auch schon einige Projekte, u.a. zum Beispiel esp-link 2.0 mit MQTT und JSon Support von Jeelabs.

Das Schöne an ESPeasy ist, dass man die Sensoren und Aktoren dynamisch definiert und nicht schon im Code hinterlegen muss. Das habe ich noch bei keinem anderen ESP-8266 MQTT Projekt gesehen.

Wenn mich eine Funktion von ESPeasy stört, würde ich über Github ein issue oder einen request eröffnen. Falls dann nicht reagiert wird, kann man den Code dann immer noch forken.

Es muss jeder selbst wissen, auf welches Pferd er setzt. Statt rumzumäkeln solte man lieber aktiv werden, und wenn man nur ein issue meldet.

Hav Fun

Josef

[Pf@nne]

Vermutlich muss man noch 2-3 Monate abwarten was sich insgesamt so entwickelt oder selber irgendwo mitmachen wenn man es denn kann.
Ich bräuchte beispielsweise etwas, das per MQTT kommuniziert, ein paar Messwerte von Sensoren wie Temperatur usw durchgibt und per MQTT-subscribe GPIOs schaltet.

Ein erstes Grundgerüst findest du hier:
http://forum.fhem.de/index.php/topic,46022.msg378012.html#msg378012

[beSmart]

Hallo Forum.

Auch ich habe ESPEasy ausprobiert und ein Display angeschlossen. Lief auf Anhieb und ohne Probleme.
Jetzt ist für mich von Interesse wie man mit Fhem Texte an den ESP mit Display sendet.
Die erste Möglichkeit die mir einfällt, ist per HTTP

Code Auswählen Erweitern

( {system "wget http://192.168.178.233/control?cmd=lcd,1,1, $DEVICE offen"})
Diese Lösung finde ich aber nicht besonders elegant.........

Gibt es bessere Alternativen?

Dank und Gruß

beSmart

[schka17]

Meins Wissens noch nicht, ich würde mir auch MQTT wünschen, das ist aber noch nicht implementiert, zumindest nicht in den älteren Versionen, den aktuellen Sourcecode habe ich noch nicht angeschaut.


Sent from my iPad using Tapatalk

[MadMax-FHEM]

@   hjgode

Ich spiele auch seit längerem mit dem ESP8266 rum.

Ziel war ein Füllstandsmesser für meinen Tank auf dem Balkon.
(existierende Füllstandsmesser z.B. HomeMatic sind für meine Tankform nicht brauchbar...)

Und ein Temp/Hum Sensor auf Basis HTU21D da dieser bereits mit 3,3V läuft...
(Aktuell habe ich DHT11 im Einsatz)

"Integration" per "GET fhem/?cmd setreading..."

Folgendes habe ich probiert:

- NodeMCU mit LUA (hat mir nicht gefallen, ist aber persönlich)
- ARDUINO-IDE (bzw. eclipse Plugin) ist sehr einfach, da viele von den Libraries funktionieren bzw. ähnliche Libraries für ESP8266 (Adafruit/Sparkfun) existieren (manche Dinge laufen leider nicht so stabil, d.h. der ESP8266 "bootet" schon "einfach mal durch"...)
- native SDK (ebenfalls eclipse). Nicht ganz einfach, da das "Betriebssystem" nicht eben toll dokumentiert ist... Bin ich noch nicht so lange dran, daher kann ich wenig zur Stabilität sagen...

Äh, jetzt zum eigentlichen: der ESP hat interrupts. d.h. es ist möglich z.B. auf GPIO-Änderungen eine Interruptfunktion zu hängen. Schleifen ohne Wartepausen sind sehr schlecht, da sonst das "Betriebssystem" "austickt" und der ESP8266 ungefragt durchbootet (ist evtl. das Problem bei manchen Libraries der Arduino-IDE-Variante / habe ich aber noch nicht bis ins Deteil untersucht)...
Bin grad selber dabei z.B. den Ultraschallsensor von "pulseIn" welche (in Adruino-IDE-Variante) als Warteschleife implementiert ist auf Interrupt umzustellen...


Wo ich momentan "scheitere" ist Batteriebetrieb...

Aktuell "steuere" ich den ESP8266 per ATtiny85 und FET.
D.h. ich schalte den gesamten "Sensor" inkl. Spannungstranformation etc. ein und wieder aus.

Im Ruhezustand komme ich aktuell auf 4uA...

Schalte ihn alle 10min für ca. 4sec. ein (reicht meist [wenn mal ein Telegramm nicht kommt isses nicht so schlimm / bzw. sende ich den Füllstand {klappt praktisch immer} und die Batteriespannung {klappt nicht immer} / fixe IP, DHCP dauert nat. [deutlich] länger).
Der ESP macht die Messung, sendet die Daten und geht in DeepSleep...
Der ATtiny schaltet nach 4sec komplett aus...
...und nach 10min wieder von vorne.

Aber mit 2AA komme ich gerade mal gute 2 (knapp 3) Wochen...
...der ESP ist im "On-Betrieb" zu hungrig...
...schade...


ATtiny läuft direkt von der Batterie und schaltet (ohne Brownout [braucht auch deutlich mehr Strom]) bis zu 1,8V allerdings gibt wohl der Spannungswandler bereits vorher auf...
...eventuell muss ich da mal einen anderen nehmen.

Andere Variante statt 2AA mit einer Powerbank und 3min Wartezeit komme ich auf ca. 4 Wochen...
...besser aber auch nicht wirklich toll...

Wenn jemand Ideen bzw. Erfahrung in Richtung Batteriebetrieb hätte wäre ich sehr interessiert!!

Danke, Joachim