Neues Modul: ESPEasy [war: ESPEasy ohne MQTT]

[justme1968]

ich denke nicht das es ein neues modul braucht. besser ist es ein vorhandenes zu erweitern. keyvalue arbeitet genau so zwei stufig.

wenn man tcp verwendet muss man eine seite fest machen. es ist eigentlich egal welche seite. fhem oder esp. für die variante esp fest gibt es schon ein modul.

für KeyValueProtocol gibt es auch schon ein udp modul. dann muss man nichts mehr fest konfigurieren.

gruss
  andre

[SpenZerX]

ich denke nicht das es ein neues modul braucht. besser ist es ein vorhandenes zu erweitern. keyvalue arbeitet genau so zwei stufig.

wenn man tcp verwendet muss man eine seite fest machen. es ist eigentlich egal welche seite. fhem oder esp. für die variante esp fest gibt es schon ein modul.

für KeyValueProtocol gibt es auch schon ein udp modul. dann muss man nichts mehr fest konfigurieren.

Das hängt natürlich von den Anforderungen ab. Mit einem eigenen Modul hat man Zugriff auf die Methode, alle URI Elemente, Headerfelder und kann on Top noch Daten in den Body packen und die Response gestalten. Alles schön HTTP konform.

Ich kenne das KeyValue Modul von FHEM aber nicht wirklich.

UDP würde ich aber definitiv nicht verwenden.

[flurin]

Zur Information:

https://github.com/ESP8266nu/ESPEasy/pull/48

Ich frage mich, ob es sich lohnt, eine Alternative zu MQTT zu entwickeln. Mit MQTT kann ich meine ESP's sowohl mit Fhem wie auch mit anderen Systemen bidirektional verbinden.

Gruss
flurin

[amithlon]

Hallo,

ich dachte schon, ich bin der einzige MQTT-Verfechter. Das Protokoll hat einfach soviele Vorteile genau für solche Verbindungen, daß man es ziemlich aufwendig wäre, eine ähnliche Funtionalität neu zu bauen.

Protokoll mit kleinen Datenmengen. Entwickelt, um auch auf unzuverlässigen Verbindungen ein Maximum an Übertragungssicherheit zu haben.
Gestaffeltes QoS, retained messages, keepAlive, LastWill, beliebiger Payload, auch binär.

Ein Bridge-System als CUL/Jeelink-Ersatz für alle möglichen Systeme mit dem ESP auf MQTT fände ich interessant, ich habe allerdings kaum Fremdsysteme im Einsatz und es wäre auch nicht richtig FHEM-spezifisch.

Gruß aus Berlin
Michael

[flurin]

Ein Bridge-System als CUL/Jeelink-Ersatz für alle möglichen Systeme mit dem ESP auf MQTT fände ich interessant, ich habe allerdings kaum Fremdsysteme im Einsatz und es wäre auch nicht richtig FHEM-spezifisch.

Ev. lässt sich ein solches Bridge mit node-red realisieren, node-red unterstützt verschiedene Protokolle (mqtt, websocket, http, ..). Beispielsweise habe ich ein ESP mit Homebridge (Homekit) via node-red (mqtt <-> websocket) verbunden.

Gruss
flurin

[amithlon]

Hallo,

ich meinte eher ESP+433MHz Receiver für Funksteckdosen und Funkthermometer usw. von/zu ESP. Genauso 868MHz z.B. für meine E3000.
Das habe ich hier ja so laufen, allerdings wegen MQTT. FHEM kam bei mir erst später dazu.
Die Sachen bekomme ich selbst auf dem ESP zusammen. Ich habe jetzt keinen Überblick, was es alles gibt, auf welchen Frequenzen und mit welchen Protokollen.

Meine IR-Geschichte ist ja auch so aufgebaut: IR-Commandos werden mitgelesen und per MQTT an FHEM übermittelt (Typ, Code, Anzahl Bits).
FHEM kann die entweder auswerten und Aktionen auslösen, z.B. per MQTT die Baumarkt-Funksteckdose schalten. Das geht an eine ESP-RFM12-Bidge, die die 433MHz Kommandos schickt.

FHEM kam deshalb "drüber" weil ich so generellen Einfluß auf das Ganze nehmen kann.
Ich habe z.B. keine Logitech, dafür eine alte Philips Prestigo SRU6000. Die ungenutzte 4. Ebene wurde mit hier ungenutzen IR-Codes programmiert und FHEM getauft. Damit kann ich jetzt auslösen, wozu ich Lust habe und was mir in FHEM einfällt.
Die Zwischenwege sind eben IR-ESP-MQTT->FHEM und von da mit MQTT-ESP- IR/433MHz oder was dranhängt.

Der Zwischenweg MQTT hat einmal den Vorteil, daß ich im Vorfeld klären kann, was ich eigentlich schicken will und sich FHEM damit nicht rumärgern muß.
Ich würde statt 5 USB-Sticks mit JeeLinks lieber 5 ESP mehr in der Gegend verteilen und denen das überlassen.

Mit WLAN und den ESP habe ich (fast*) keine Probleme, die laufen hier seit Monaten stabil ohne Hänger oder Abstürze.

* ich habe hier das "Glück", rund 20 WLAN-Netzwerke auf 2,4GHz im Umfeld zu haben, Altbau, über den Hof kommt auch noch genug.
Sa/So Abend kann es passieren, daß das WLAN hier mal für ein-zwei Stunden nahezu dicht ist. Dann nutzt auch der stabile connect zum AP nichts, die LAufzeiten werden einfach so lang, das der eine oder andere ESP mal einen Re-connect hinlegt. Dann kann eine Funkstekdose schonmal eine Sekunde spöter schalten...

Aber irgendwie wird es vermutlich ziemlich OT hier, heißt ja eigentlich ESPEasy -> FHEM (ohne MQTT) der Thread.

Gruß aus Berlin
Michael

[dev0]

Im ersten Beitrag habe ich das ESPEasy Modul aktualisiert:

- added internal timer to poll GPIO status
- added attribut interval
- added attribut pollGPIOs
- improved logging
- added esp command "status"
- added statusRequest
- commands are case insensitive
- updated command reference
- delete readings with unknown state

[chunter1]

Vielen Dank dev0 für die Arbeit!!
Hatte mir für meine 12Stk. ESP-Module schon länger eine Integration in FHEM gewünscht.
Kannst du bitte noch den "longpulse" für normale GPIOs integrieren? 

[dev0]

Welche Parameter benötig longpuls? Wie pcflongpulse?

[chunter1]

Welche Parameter benötig longpuls? Wie pcflongpulse?

soweit ich weiß ja
...cmd=LongPulse,<gpio>,<level>,<duration>

[dev0]

Yepp, Modul im ersten Beitrag ist ausgetauscht.

[chunter1]

Was mir aufgefallen ist...

Wenn man z.B. einen "longpulse 14 1 3" sendet, dann wird zwar der Wechsel des gpio14 von OFF auf ON in FHEM richtig angezeigt, allerdings fehlt der abschließende Wechsel von ON auf OFF.
Auch ein manueller GET auf den gpio liefert einen falschen Wert?

[dev0]

Ein "get ESPxx xyz" liest nur das Reading xyz aus.

Du hast drei Möglichkeiten:
- Den Status manuell updaten: "set ESPxx status gpio 14"
- Alle x Sekunden den Status abfragen lassen (pollen): Die Atrribute "pollPGIOs" und "Interval" sind dazu in der command reference beschrieben.
- Du erstellt auf dem ESP ein Device vom Typ "Switch" und erstellst, ebenfalls auf dem ESP, eine Regel, die den Status bei jeder Änderung überträgt:

Code Auswählen Erweitern


on GPIO14#Switch do
SendToHTTP <FHEM-IP>,<FHEM-PORT>,/fhem?cmd=setreading%20ESPxx%20GPIO14%20[GPIO14#Switch]
endon


[chunter1]

Ich nutze bisher die "Send Data" Option beim Typ "Switch" in ESPEasy zur automatischen Übermittlung der GPIO Status Änderung.
Wäre cool wenn das auch unterstützt werden könnte um Polling und eigene Scripts zu vermeiden.

[dev0]

 Das wäre die 4. Alternative, die ebenfalls schon funktioniert.