Entwicklung: Sensor mit dem ESP8266 WLAN-Funkmodul

Begonnen von locutus, 09 November 2014, 19:30:06

Vorheriges Thema - Nächstes Thema

Samsi

Zitat von: Prof. Dr. Peter Henning am 26 Februar 2015, 20:23:29
Erstens kann dabei von "Echtzeit" nicht die Rede sein - dafür sind weder TCP noch UDP geeignet.

pah

Für meine Anforderung ist das Echtzeit genug. Ich brauche mein Licht etc. nicht im Mikrosekundenbereich geschaltet zu haben. Und ich habe in FHEM mehrere ports offen z.B. port 8083
FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

matthias soll

@Samsi genau das denke ich auch.
HTTP Request klingt für mich am besten, wie kann ich in fhem HTTP Requests empfangen bzw. verarbeiten?
Hast du das schonmal umgesetzt?
Gruß
Matthias

Samsi

Hi,

ja, hab ich schon mal testweise gemacht, allerdings mit einem Arduino. Ist aber mit dem ESP nicht anders.  Man erstellt einfach ein dummy device in FHEM und schickt einen HTTP Get Request:

      client.print("GET /fhem?cmd=set%20ArduinoIR%20");
      client.print(code,HEX);
      client.println(" HTTP/1.0");
      client.println("Host: 192.168.0.6");
      client.println("Connection: close");
      client.println();
      client.stop();

Wenn Du den Passwortschutz (web basic auth) aktiviert hast, musst du natürlich noch das  Passwort übergeben:
client.println("Authorization   Basic ZdbfgthjToyMjU1");
http://de.wikipedia.org/wiki/HTTP-Authentifizierung

Ich öffne lieber einen port auf dem ESP und erstelle ein ECMD device das sich dann zum ESP verbindet. Hat den Vorteil, das Du eine dauerhafte Verbindung hast und so auch jederzeit vom ESP etwas anfordern kannst oder am ESP angeschlossene Relais etc. steuern kannst.

Hier ist ein Bsp. für nodemcu:

https://github.com/nodemcu/nodemcu-firmware/blob/master/lua_examples/telnet2.lua
FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

matthias soll

Hi,
ich hatte gedacht dass der request von dem esp ausgeht (ausgehen soll) damit der danach wieder in den sleep modus gehen kann, um vielleicht einen batteriebetrieb zu ermöglichen.
Oder dauert das dann zu lange bis er wieder eine Verbindung hat?

Prof. Dr. Peter Henning

@Samsi: Wer im Bereich Automatisierung von "Echtzeit" spricht, sollte das auch meinen - und das ist hier nicht der Fall. Also wäre es zur Vermeidung von Begriffsverwirrung sinnvoll, den Begriff "Echtzeit" hier zu vermeiden. Auch betreffend die "offenen Ports" sollte man bitte etwas präziser argumentieren. Die gibt es nämlich eben nicht in Fhem, sondern  nur in den einzelnen Devices - und genau das ist das Problem bei der Anbindung zeitkritischer Vorgänge.

LG

pah

matthias soll

Hallo, tut mir leid den Begriff Echtzeit habe ich ins Spiel gebracht. Was bedeutet den Zeit kritisch? Sekunden Minuten Stunden? Wie gesagt die Reaktionszeit bei fs20 Tastern ist auch sehr unterschiedlich.
Gruß
Matthias

Prof. Dr. Peter Henning

Die "Reaktionszeit" ergibt sich erstens dadurch, dass die Funksignale erstens vom CUL aufgefangen werden müssen - und dabei mit anderen Signalen konkurrieren. Eventuell wird also erst das dritte Aussenden detektiert.

Zweitens muss die zentrale Schleife von Fhem, die sequenziell alle anstehenden Aufgaben abarbeitet, an dem Device des CUL "vorbeischauen". Daran kann sie durch andere wichtige Aufgaben beliebig lange gehindert werden.

LG

pah

Samsi

@Prof. Dr. Peter Henning

danke, dass Sie jetzt etwas "präziser"argumentieren, woran Sie sich gestört haben. Denn mit der Kurzform:

ZitatErstens kann dabei von "Echtzeit" nicht die Rede sein - dafür sind weder TCP noch UDP geeignet.
Zweitens gibt es in Fhem auch keine "offenen Ports".

war sicher niemandem geholfen. Man kann  auch argumentieren das weder FHEM noch die Devices und Module keine offenen Ports haben. Diese mögen die Ports zwar geöffnet haben, der offene Port wird aber von außen betrachtet dem Prozess 'perl' zugeordnet.

Und über die Definition von Echtzeit kann sich ja jeder selbst informieren: http://de.wikipedia.org/wiki/Echtzeit

Viele Grüße


FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM


Prof. Dr. Peter Henning

Nun, wer Definitionen in der Wikipedia nachsieht, wird sicher keine sachdienlichen Hinweise mehr benötigen...

LG

pah

matthias soll

Ich wollte hier niemanden verärgern und auch keinen Streit provozieren.

BTT
Ich würde mir nur gerne Batteriebetriebene lichtschalter auf Basis des esp8266 bauen.
Es sollte doch relativ einfach möglich sein mit dem esp bei einen tastendruck am GPIO ein z.B.:  wget -q 'http://192.168.1.1/?f7=0'   
zu senden oder?  Oder irgendetwas mit dem fhem etwas anfangen kann?
Wie könnte man fhem seitig soetwas umsetzen?

Gruß
Matthias


Prof. Dr. Peter Henning

Mein Tipp: Finger weg.

Viel zu aufwändig, fehleranfällig wg. WLAN; unbekannte Latenzzeit,

Für batteriebetriebene Lichtschalter empfehle ich FS20, HomeMatic (beide direkt mit dem Schaltaktor zu paaren) oder PanStamps (wenn es denn unbedingt über Fhem laufen soll).

LG

pah

matthias soll

OK danke für den Tip.
Momentan nutze ich auch die 6 Kanal FS20 schaltsender aber komplett indirekt mit einem firmata als schaltserver
(arduino Mega mit knapp 70 ausgängen).
Ich hätte nur gerne alles über lan bzw. wlan realisiert aber wenn das dafür total ungeeignet ist lasse ich alles wie es ist.
Danke
Gruß
Matthias

SpenZerX

Zitat von: matthias soll am 27 Februar 2015, 18:37:10

Ich hätte nur gerne alles über lan bzw. wlan realisiert aber wenn das dafür total ungeeignet ist lasse ich alles wie es ist.


Lass dir doch keinen Blödsinn erzählen. ESP und aufwendig? Soll ich mal lachen.. Da kann man direkt 8er Relais-Boards oder SSR Boards anschließen. Fehleranfällig? Wird man zumindest merken wenn der Response-Code ausbleibt. Auch wenn die SDK auf dem ESP noch sehr buggy ist, der Watchdog tut seinen Dienst perfekt. Die schlechte Reaktionszeit liegt nur am Perl-FHEM. Batteriebetrieb? Die technischen Daten sind bekannt. Ist mit zu vielen Einschränkungen verbunden ...

Die nächste Generation ESP wird kommen.
Muss jeder selbst wissen ob er sich mit dem Thema IoT beschäftigt. Die Programme die jetzt erstellt werden (Nutzung SDK in C), werden auch auf der nächsten Generation laufen.

Gibt es Alternativen mit Wireless Lan die so einfach aufgebaut sind? (SoC+Flash512KB) für 2,50 Euro ?



Samsi

Also ich bin mit dem ESP bisher auch zufrieden. Muss man halt mal sehen wie Stabil der Läuft.
Momentan bastel ich gerade ein RGB WLAN Modul für RGB Stripes für ca. 6€ inklusive Gehäuse (so ähnlich wie den LD 382/Magic Ufo). Ich habe den Prototypen schon fertig und kann ihn auch schon per Telnet über WLAN steuern.
Ich werde den Protoypen in den nächsten Tagen in einem eigenen Beitrag vorstellen. Später will ich da dann noch ein PIR Sensor mit dran machen (das ist das was mir beim LD382 noch fehlt )

Der LD382 Funktioniert bei mir auch super zuverlässig über WLAN. Wenn die ESP Firmware nicht noch gravierende Fehler hat, sehe ich keinen Grund warum der ESP nicht auch gehen sollte.  Aber das werde ich erst im Langzeittest sehen.




FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM