Hallo,
ich habe mich nun an den ESP8266 gewagt, leider zeigt der DS18b20 keine Temperatur an und ich weiss nicht wo ich ansetzten soll:
ESP8266: NodeMCU v.3
Firmware: ESPeasy_R147_RC8
Data vom DS18b20 an GPIO2 (D4)
Data und 3.3V mit 4k7Ohm Widerstand verbunden
Weboberfläche des ESP über wifi erreichbar.
Das Temerature-DS18b20 Device hat eine Port-Nr erhalten, heisst das dass mein Data-Pin richtig ausgelesen wird?
ImAnhang Bilder der Einstellung
Das sieht erst Mal gut aus. Ich sehe keinen Fehler. Er findet ja einen. Stelle die delay Zeit von 60 am Anfang Mal auf 5 evtl braucht der sonst zu lange. Und du siehst schnell ein Ergebnis
Gesendet von meinem MI 8 mit Tapatalk
das heisst wenn bei Port eine Art MAC Adresse erscheint bin ich sicher dass der DS18B20 richtig verkabelt ist?
Zitat von: jumperger am 13 Januar 2020, 15:31:10
das heisst wenn bei Port eine Art MAC Adresse erscheint bin ich sicher dass der DS18B20 richtig verkabelt ist?
Sobald bei dem entsprechenden Sensor eine ROM ID erscheint, kann ESPEasy zumindest die ID auslesen, dann sollte die Verkabelung i.O. sein.
Gruß Peter
Danke für die Klarstellung, dobald ich zuhause bin werde ich nach dem Delay sehen.
Leider bringt das Umstellen des Delay auf von 60 auf 5 nicht den gewünschten Erfolg.
Unter Temperature steht immer noch 0.00 auf grünem Grund.
Hallo jumperger,
sehr merkwürdiges Verhalten. Gibt es einen Grund, warum du so eine alte Firmware benutzt? Das sollte zwar kein Grund sein, warum es nicht geht, aber wer weiß.
Ich würde dir raten eine aktuelle ESPEasy MEGA firmware bei github runterzuladen und diese zu flashen.
Alternativ wäre auch noch Tasmota anzuraten; diese Software erkennt von selbst, welche Sensoren angesteckt sind.
Wenn dort nichts auftaucht, dann liegt es mit hoher Wahrsheinlichkeit an der Sensorseite und nicht an der Software.
Ich würde es an deiner Stelle mal mit Tasmota versuchen.
Viele Grüße Gisbert
Ich bin neu beim ESP8266 deshalb habe ich eine stable Version gewählt da ich nichts davon kenne und mir gedacht habe ein einfacher DS18b20 würde wohl auch von einer älteren Version erkannt.
Auf github wusste ich dann auch nicht richtig was ich nehmen muss da bei der letzten Version 4 Dateien mit Grössenangabe alle blank heissen und mir der blank_4mb mein esp gar nichts machte ( logisch im Nachhinein bei dem Namen). Die einzige .bin nicht blank habe ich auch probiert (Name enthielt keine Grösse für den ESP), aber damit hat der ESP kein ESP_0 Wifi gemacht sondern EB... irgendwas und ich konnte mich nicht einloggen.
Ich bin für jeden Link zu einer aktuellen funktionierenden firmware dankbar, ich habe auf github alle history Seiten durchgescrollt aber keine stable gefunden.
Ihr seit euch dicher dass wenn der ds18b20 eine id schickt dass es dann nicht an meiner Verkabelung mit 4k7Ohm liegen kann? Und dass GPIO 2 (D4) nicht falsch sind?
ZitatIhr seit euch dicher dass wenn der ds18b20 eine id schickt dass es dann nicht an meiner Verkabelung mit 4k7Ohm liegen kann? Und dass GPIO 2 (D4) nicht falsch sind?
Dazu müsstest du eine Skizze liefern.
Tasmota: lade die tasmota.bin runter und flashe sie auf den ESP, https://github.com/arendst/Tasmota/releases/tag/v8.1.0 (https://github.com/arendst/Tasmota/releases/tag/v8.1.0)
Viele Grüße Gisbert
Zitat von: jumperger am 13 Januar 2020, 21:09:29
Ich bin neu beim ESP8266 deshalb habe ich eine stable Version gewählt da ich nichts davon kenne und mir gedacht habe ein einfacher DS18b20 würde wohl auch von einer älteren Version erkannt.
Auf github wusste ich dann auch nicht richtig was ich nehmen muss da bei der letzten Version 4 Dateien mit Grössenangabe alle blank heissen und mir der blank_4mb mein esp gar nichts machte ( logisch im Nachhinein bei dem Namen). Die einzige .bin nicht blank habe ich auch probiert (Name enthielt keine Grösse für den ESP), aber damit hat der ESP kein ESP_0 Wifi gemacht sondern EB... irgendwas und ich konnte mich nicht einloggen.
Ich bin für jeden Link zu einer aktuellen funktionierenden firmware dankbar, ich habe auf github alle history Seiten durchgescrollt aber keine stable gefunden.
Die blank_x.bin-Dateien sind einzig dazu da, den kompletten Speicher zu überschreiben, was manchmal hilfreich ist, wenn ein ESP vorher schon eine Firmware drauf hatte oder das Flashen aus anderen unerfindlichen Gründen fehlschlägt.
Vergiss das mit der "stable"-Firmware. Meine sämtlichen NodeMCUs, Sonoffs und OBI-Wlansteckdosen laufen alle mit verschiedenen Releases vom Github und ich hatte noch nie Probleme damit.
Mit Tasmota konnte ich mich noch nie anfreunden... ;-)
Die aktuelle ESPEasy auf Github gibts hier: https://github.com/letscontrolit/ESPEasy/releases/download/mega-20191208/ESPEasy_mega-20191208.zip
Aus diesem Paket nimmst Du für eine "normale" NodeMCU am besten mal die ESP_Easy_mega-20191208_normal_ESP8266_4M1M.bin und flashst sie drauf.
Und dann schau mer mal... ;-)
Vielen Dank an alle für eure Unterstützung, aller Anfang ist schwer, was würde ich ohne euch machen !?
@ howy-1
mit der von dir verlinkten firmware hat es auf Anhieb geklapt. Jetzt sind 21,00 Grad in meinem Büro anstatt der vorherigen 0,00 Grad , mir ist auch gleich viel wärmer.
Ich hatte die gleiche Firmware schon heruntergeladen hat waren nur nicht die gleichen .bin Files im .zip Archiv.
Der Unterschied liegt im Detail:
von mir heruntergeladen: ESPEasy-mega-20191208.zip
von dir verlinkt: ESPEasy_mega-20191208 und das auf der gleichen Seite.
Ich hab immer gleich oben neben dem Release auf mega-20191208 geklickt anstatt unten auf "Assets", man lernt eben immer dazu.
@Gisbert,
ich hab die Tasmota nun nicht versucht da die ESPeasy geklappt hat und ich mich hier schon etwas eingelesen hatte, falls dann mal wieder Schwierigkeiten auftreten sollten dann weiss ich zumindest dass ich auch dort nach einer Lösung suchen kann.
Dann werde ich nun versuchen mich einzulesen um den ESP mitsamt DS18b20 in FHEM zu integrieren.
Auf jedenfall vielen Dank für die Hilfe.
Nachdem ich jetzt in das Webinterface des ESPeasy hineingeschaut habe stelle ich fest dass es dort tausende Einstellungen gibt welche ich meistens nicht im Wiki finde.
- Gibt es irgendwo Erklärungen dazu
- In der Main Page habe ich eine rote Fehlermeldung: "No system time source" wo kann ich diesen Fehler beheben?
- In der GPIO Tabelle sind einigem mit einem Dreieck und ! gekennzeichnet. Was heist das sollte ich lieber ein anderes als dasvon mir genutzte GPIO2 auf D4 benutzen?
- Welches der MQTT Protokolle sollte ich auswählen?Ich hab schon 2 shellys über MQTT eingebunden.
Danke abermals für die Hilfe.
Die Einstellung zum NTP-Server findest Du unter Tools -> Advanced -> NTP Settings.
Hinsichtlich der Symbole bei den einzelnene GPIOs sind das nur Hinweise auf mögliche Probleme bzw. Vorbelegungen, z.B. interne Pull-Up, I2C, SPI etc.
So ist z.B. beim D1 Mini GPIO-2 imho mit der internen LED gekoppelt und deswegen nicht unbedingt nutzbar.
ZitatNachdem ich jetzt in das Webinterface des ESPeasy hineingeschaut habe stelle ich fest dass es dort tausende Einstellungen gibt
Auch hier ist Tasmota viel User-freundlicher, da es viele Einstellungen von selbst erledigt.
Tasmota ist generell besser geeignet bei Relais und wenig Sensoren, während ESPEasy besser bei vielen, verschiedenen Sensoren ist.
Viele Grüße Gisbert
Zitat von: jumperger am 14 Januar 2020, 01:28:48
- Welches der MQTT Protokolle sollte ich auswählen?Ich hab schon 2 shellys über MQTT eingebunden.
Danke abermals für die Hilfe.
Für die Verbindung ESPEasy und FHEM brauchst Du doch überhaupt kein MQTT, das ist ja grad das Gute daran. Ich muss mich nicht auch noch mit MQTT-Programmierung befassen und muss auch keinen MQTT-Broker betreiben ;D
Ich sehe es bei ESPEasy als Vorteil, dass man alles selbst einstellen kann. So kann man jeden Port belegen und nutzen wie man möchte. Es gibt doch im Netz etliche Beschreibungen zu ESPEasy, wo die Einstellungen erklärt werden, dazu noch HowTos, wie z.B. für ESPEasy und Sonoff-Geräte.
Aber wie @Gisbert schon schrieb, Tasmota soll wohl mehr für die ganzen Steckdosen und andere Geräte gut sein, ESPEasy eben für Leute, die mehr als nur schalten wollen.
Ist vllt. auch eine Glaubensfrage , ähnlich Windows vs. Linux :D
Grüße...
Zitat von: howy-1 am 14 Januar 2020, 20:37:40
Für die Verbindung ESPEasy und FHEM brauchst Du doch überhaupt kein MQTT, das ist ja grad das Gute daran. Ich muss mich nicht auch noch mit MQTT-Programmierung befassen und muss auch keinen MQTT-Broker betreiben ;D
Vermutlich hat howy-1 recht, dass es für ESPEasy einfacher ist, die speziellen Module zu verwenden.
Trotzdem eine Anmerkung zu MQTT:
Mit MQTT2_SERVER ist es völlig stressfrei, einen MQTT-Broker zu betreiben, man braucht keine zusätzlichen Perl-Module und keine externen Dienste.
Was "MQTT-Programmierung" sein soll, weiß ich nicht, aber das Konfigurieren von MQTT2_DEVICE-Geräten ist sehr flexibel und es gibt zwischenzeitlich so viele Beispiele, dass die größte Kunst die ist, rauszufinden, was denn grade für ein neues Gerät die richtige Kombination ist...
MQTT hat afaik gg. reinen HTTP-Lösungen einen Vorteil: es ist asynchron ausgelegt (es muß also nicht zwangsweise sowohl der sendende Client, der Broker und der empfangende Client gleichzeitig "am Netz hängen"), man kann es daher auch gg. kurzfristige Ausfälle "härten".
Ich bin auf die MQTT Idee gekommen da in meinem FHEM schon MQTT2-SERVER läuft und ich damit 2 shellys ganz stressfrei eingebunden habe.
Den NodeMCU habe ich hauptsächlich angeschafft um Temperaturfühler (DS18b20) an meinem Schwimmteich an FHEM zu übermitteln um dann hoffentlich die Pumpen entsprechend zu schalten.
Im Sommer sollen Solarmatten entsprechend der Temperaturfühler in den Filterkreis eingebunden werden.
Als Einstiegsprojekt möchte ich nun im Winter die Filterpumpe nur einschalten wenn die Aussentemperatur am Teich gegen 0 geht um ein Gefrieren der Pumpe zu verhindern ohne dass die Pumpe dafür 24/24 eingeschaltet sein muss.
Als MQTT-Protokoll habe ich aktuell PiDome MQTT eingestellt, ich weiss aber nicht ob dies das richtige/beste Protokoll ist.
Es wurde automatisch ein MQTT2-Device angelegt namens ESPClient_MAC-Adresse welches ein Reading namens PoolWaterTemp enhält. Dies wurde in ESPeasy konfiguriert.
Klingt doch gut...Jetzt ist auch klar, was mit "Protokoll" gemeint war. FHEM ist da afaik nicht wählerisch, wenn da ist, was da sein soll, ist das ok., und wenn du sowieso MQTT2_SERVER schon am laufen hast, musst du auch nichts anderes nehmen.
Zitat von: Beta-User am 17 Januar 2020, 05:19:29
Klingt doch gut...Jetzt ist auch klar, was mit "Protokoll" gemeint war. FHEM ist da afaik nicht wählerisch, wenn da ist, was da sein soll, ist das ok., und wenn du sowieso MQTT2_SERVER schon am laufen hast, musst du auch nichts anderes nehmen.
Bei ESPEasy hatte ich bisher immer Openhab MQTT eingestellt, weil ich einer Anleitung vor Jahren gefolgt bin, unter der irrigen Annahme, dass es nur damit in Zusammenarbeit mit Fhem geht.
Gut zu wissen, dass andere Einstellungen auch funktionieren, mit OpenhabMQTT geht es auch.
Viele Grüße Gisbert
Hmm, MQTT ist ein generisches Protokoll, spannend ist eigentlich immer "nur", ob
- JSON verwendet wird (finde ich zwischenzeitlich@MQTT2_DEVICE ganz praktisch, weil das in der Regel die subscribe-Liste verkürzt, aber ohne JSON geht's auch)
- irgendeine LWT-Info gesendet wird (wenn es unterstützt wird, ist es vermutlich egal, welches "Protokoll" man wählt), und
- ob diese "autodiscovery"-Geschichte für OpenHAB (?) gesendet wird (das finde ich wirklich lästig, da für FHEM völlig unnötig...)
Kurz: FHEM (und vor allem MQTT2_DEVICE) kommt mit "fast allem" klar, der Rest ist eine Frage der persönlichen Vorlieben ;) .
Übrigens: Vor kurzem kam hier im Forum die Frage auf, ob ESPEasy (also die FHEM-Module) mit "wandernden" Devices klarkommt, also solchen, die sich zwischendurch mit anderen AP's verbinden und dann eine neue IP bekommen. Antwort war: bislang nicht.
Für die MQTT-Implementierungen dürfte das kein Problem sein, solange das Device den Broker wiederfindet, um sich neu anzumelden...