Neues Modul: ESPEasy [war: ESPEasy ohne MQTT]

Begonnen von dev0, 18 Juli 2016, 11:53:28

Vorheriges Thema - Nächstes Thema

eppi

#15
Auf meinen Wunsch und Anregung von dev0 habe ich ein zusätzliches C-Plugin für EasyESP "FHEM-TELNET" geschrieben. Die Verwendung ist identisch mit dev0 FHEM-HTTP Plugin:

Einfach die Datei _C010.ino is ESPEasy Verzeichnis kopieren und neu kompilieren. Nach dem flashen "FHEM TELNET" (Config->Main Settings->Protocol) auswählen.
In FHEM z.B. einen Dummy, mit dem Namen des ESP anlegen (Config->Main Settings->Name). Die Readingnamen werden aus den Settings "Value Name x" generiert (Devices->Edit Sensor->Optional Settings->Value Name x).

Getestet mit:
- Arduino IDE 1.6.5
- Boardmanager -> http://arduino.esp8266.com/stable/package_esp8266com_index.json -> esp8266 by ESP8266 Community version 2.3.0
- ESPEasy R108

Download: https://github.com/eppi72/Projekte/tree/master/ESP8266/ESPEasy/C-Plugin

Gruss Eppi

dev0

Selbst ist dem Mann! Find ich gut.
Jetzt müssen wir nur noch den anderen Weg einbauen: FHEM -> ESP

eppi

#17
Zitat von: dev0 am 23 Juli 2016, 09:42:58
Selbst ist dem Mann! Find ich gut.
Jetzt müssen wir nur noch den anderen Weg einbauen: FHEM -> ESP
Danke :D
Du meinst ein FHEM-Modul, dass GPIO Output schaltet?
zBsp:
http://[ESPName]|[ESPIP]/control?cmd=GPIO,[GPIO],[VALUE]

dev0

Ja, das FHEM Modul ist nicht das Problem. Ich habe aber den Mechanismus in ESPEasy noch nicht verstanden, wie die Befehle "angenommen" werden. Ist aber in Domo... http und mqtt schon implementiert. Sollte zu lösen sein, wenn man etwas Zeit investiert.

flurin

Hallo,

So habe ich es gelöst:

1. esp_http in 99_myUtils.pm einfügen:


sub
esp_http($$$)
{
  my ($ip,$gpio,$value) = @_;
   
  my $url = sprintf("http://%s/control?cmd=GPIO,%s,%s", $ip, $gpio, $value);
  #Log 1, ($url);
 
  # method: POST
  HttpUtils_NonblockingGet({
    url       =>$url,
    timeout   => 5,
    callback   =>sub($$$) {
      if ($_[1] ne "") {Log 1,"$_[0]->{name} ERR:$_[1] DATA:$_[2]";}
    }
  });
}


2. ein dummy definieren:


define esp_relay dummy
attr esp_relay setList on off
attr esp_relay userReadings http {esp_http("192.168.0.52", "4", ReadingsVal("esp_relay","state","") =~/^on/?0:1)}


In diesem Beispiel ist:
esp-ip = 192.168.0.52
GPIO = 4 (bei mir ist der GPIO-4 Ausgang mit einem Relay verbunden)

userReadings lässt sich auch bei anderen Devices anwenden.

dev0

Danke für den Hinweis, flurin.

Manchmal sieht man den Baum vor lauter Wäldern nicht ;) Habe gerade die ESPEasy Command Reference entdeckt und damit ist auch mir klar geworden, dass auf ESPEasy Seite gar nichts mehr implementiert werden muss und ich nur noch das FHEM Modul schreiben muss.

justme1968

schaut euch mal das KeyValueProtokol modul an. das sollte für die richtung sensoren -> FHEM viel besser sein als dummys. es ist sehr flexibel und wird schon für mindestens zwei andere projekte verwendet.


eine gegenrichtung würde ich da auch gerne noch einbauen und es dann mit dem esp 1wire board von hexenmeister verwenden.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

dev0

Zitat von: fh168 am 19 Juli 2016, 11:27:51
kann man auch zum ESP Daten übertragen?
Ja, siehe Modul im ersten Beitrag.

dev0

Zitat von: justme1968 am 25 Juli 2016, 17:38:03
schaut euch mal das KeyValueProtokol modul an. das sollte für die richtung sensoren -> FHEM viel besser sein als dummys.
Ich habe mir nur die command ref zum KeyValueProtocol angesehen und muß gestehen, dass sich das Bessere an dem Modul, gegenüber einem Dummy, mir nicht erschließt. Verursacht ein "setreading" via HTTP vielleicht mehr Last?

PS: In der command ref fehlt noch die Beschreibung der define Parameter <Type> und <ID> zum KeyValueProtocol. Mag sein, dass man es versteht, wenn man auch Jeelinks nutzt ;)

justme1968

man könnte genau so fragen warum ein cul nicht direkt setreading kommandos sendet :)

das bessere ist unter anderem: man muss die fhem und esp seite nicht von Hand synchron halten was device namen angeht, kann devices per rename umbenennen, es wird die 'normale' logisch/physikalisch trennung verwendet, man kann beliebig viele readings auf einen schlag aktualisieren und bekommt ein gemeinsames event, es erzeugt (etwas) weniger last, fhem baut aktiv die verbindung auf und muss nicht verbindungen akzeptieren, es wird nicht für jedes reading eine eigene verbindung auf gemacht sondern es bleibt eine einzige verbindung offen die für alle updates verwendet wird, die komplette logik bezüglich ein oder mehrer devices und ein oder mehrerer readings pro device und deren Namen liegt komplett auf einer (der esp) seite, ...

das jeelink device ist nur das iodev. alles andere wird automatisch per normalem autocreate angelegt. der arduino/esp oder was auch immer muss nur das richtige protokoll senden.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

amithlon

Hallo,

prinzipiell kann ein arduino/esp senden, was man ihm beibringt.
Ich bin zu FHEM gekommen, weil ich für vorhandene Sensoren und Aktoren eine Oberfläche gesucht habe.
Als Protokoll zwischen meinen eigenen aktuelleren Sachen nutze ich MQTT.
Meine alten 433MHz-Sensoren bedient eine Bridge mit einem ESP8266/RFM12-433MHz und macht die MQTT-Sachen draus.
Die E3000 Energiemesser waren erst über ESP8266/RFM12-868MHz als MQTT-Devices angebunden, zum Test habe ich dafür mal einen Arduino-Nano mit RFM12 als Jeelink an den Raspi gesteckt.

In FHEM ist der Unterschied letztlich nur, ob es MQTT-Devices oder Jeelink-Devices sind.
Allerdings fallen ein paar Vorteile von MQTT weg: keepAlive z.B. oder QualityOfService zwischen Sensoren, die es können.
Auch ein paar Debug-Möglichkeiten, wenn ich mir z.B. unabhängig von FHEM anschauen will, was ein Sensor sendet oder nur testen will, ob er schaltet.

Ich werde für mich also vermutlich bei dieser Lösung bleiben: Mosquitto als MQTT-Broker mit auf dem RasPi und Eigenbauten oder Fremdprotokolle mit einer MQTT-Bridge meist wohl mit ESP.
So bleibt für mich FHEM überschaubar mit seinen Devices und ein "externer" CUL auch. Ob ich einen USB-Stick ersetzen muß oder 3 Stück für alle möglichen Protokolle ranstecken muß oder 3 Bridges mit ESP irgendwo im erreichbaren Umfeld der Sensoren/Aktoren rumliegen habe, macht wenig Unterschied.
Für WLAN-Abdeckung sorgt man in seinen 4 Wänden i.a. ohnehin, dann müssen aber irgendwelche 433MHz-Sachen nicht auch noch durch 3 Wände reichen.

Gruß aus Berlin
Michael




dev0

#26
Zitat von: justme1968 am 26 Juli 2016, 11:46:49
das jeelink device ist nur das iodev
Die Vorteile liegen klar auf der Hand. Ich habe aber noch Schwierigkeiten mir das ganze Setup praktisch vorzustellen: wie würde konkret das IODev dafür aussehen? Was würde zB. ein ESP senden? Gibt es irgendwo ein Beispiel für Anbindung für's Netz?

Fragen, Fragen, ... ;)

justme1968

such mal bitte im forum. es gibt zwei oder drei threads in denen es genauer beschrieben ist.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

SpenZerX

Was ihr braucht ist denke ich ein neues Modul. 

Generell würde ich dann überlegen ob es nicht besser ist auf FHEM-Seite einen TCP-Server an einem definierten Port zu öffnen (TcpServerUtils.pm hilft da)  an dem dann die ESPs (vermutlich mehrere) flexibel andocken können - anstatt mit einzelnen festgelegten Verbindungen zu arbeiten.

Sicherlich, das parsen der Kommunikation ist dann schon ein bischen tricky, aber keine Hexerei.

Nach dem parsen könnte dann das Ergebnis an die 2. Modulstufe übergeben werden - das bringt mehr flexibilität.

MFG

amithlon

Hallo,

was sollte ein ESP senden und wie soll die Anbindung LAN -> FHEM real aussehen?
Beispiel meines Sensors im Moment:
alle 2 Minuten aufwache, einloggen ins WLAN, connect MQTT, senden der Daten und schlafen gehen.
Das dauert normalerweise unter 500ms und die würde ich wegen Batteriebetrieb ungern wesentlich verlängern.
Bei Aktoren ist es egal, das muß ohnehin ständig online sein.
Ausnahme wären Aktoren, die nciht sofort reagieren müsse, wo es z.B. auch reicht, wenn sie den Lüfter (Beispiel) erst max. 2 Minuten später einschalten.
Die können bei mir (mit MQTT) auch Batteriebetrieben sein, da kümmert sich MQTT drum.

Ich probiere das auch gern mal aus, auch mit Telnet oder HTTP, allerdings kann ich da wohl im Moment nur auf der ESP/Arduino-Seite wirklich rumspielen, FHEM ist mir da im Detail noch etwas zu unklar.

Gruß aus Berlin
Michael