Das ESPEasy Modul ermöglicht Daten von einem ESP8266, mit ESPEasy R128+, zu empfangen und den ESP8266 zu steuern ohne einen zusätzlichen MQTT Broker.
Download FHEM Modul: Bestandteil von FHEM seit dem 24.02.2017
Download ESPEasy R128+: https://github.com/ESP8266nu/ESPEasy (https://github.com/ESP8266nu/ESPEasy)
Fertig compilierte ESPEasy Images für den ESP8266 gibt es hier: http://www.letscontrolit.com/wiki/index.php/ESPEasy#Loading_firmware (http://www.letscontrolit.com/wiki/index.php/ESPEasy#Loading_firmware) (mindestens R140 RC3 benutzen)
Nach dem Flashen des ESP "FHEM HTTP" in der ESPEasy WebGui auswählen und Controler IP/Port einstellen.
Danach muss, auf FHEM Seite, als erstes das Bridge Device definiert werden:
define espBridge ESPEasy bridge 8383
Ist die Bridge einmal definiert, dann werden, beim Empfang der Daten, die entsprechenden FHEM Devices automatisch angelegt.
Das automatische Anlegen von FHEM Devices und das automatische Speichern der Konfiguration wird durch die globalen FHEM Einstellungen aktiviert. Diese Einstellunegn kann man mit den Attributen autocreate/autosave überschreiben.
Die automatisch angelegten FHEM Devices können beliebig umbenannt werden, da die Zuordnung zwischen ESP Daten und FHEM Devices nicht über den FHEM Device Namen, sondern über das Internal IDENT erfolgt. Hinweis: FHEM Devices vom Typ ESPEasy nicht durch Bearbeiten der fhem.cfg umbenennen sondern den Befehl "rename" benutzen. Glaubt mir.
Will man GPIO Ports des ESP schalten, so kann man das durch eine Kombination der Attribute eventMap, stateFormat und devStateIcon vereinfachen. Dieses Beispiel für GPIO15 zeigt einen Schalter in FHEMWEB, der auch die Zustände "absent" und "hat noch keine definierten Zustand" berücksichtigt:
attr <ESP> stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"GPIO15","")}
attr <ESP> devStateIcon on:ios-on-green:off off:ios-off:on absent:10px-kreis-rot:statusRequest .*:ios-NACK:check
attr <ESP> eventMap /gpio 15 on:on/gpio 15 off:off/status gpio 15:check/
attr <ESP> webCmd :
Beispiel für den ESP internen on-for-timer. Damit kann man z.B. "set <ESP> on-for-timer 3" benutzen anstatt "set <ESP> longpulse 15 1 3" schreiben zu müssen.
attr <ESP> eventMap /longpulse 15 on:on-for-timer/longpulse 15 off:off-for-timer/
Getestete Entwicklungsumgebung:
- Arduino IDE 1.6.9
- Boardmanager -> http://arduino.esp8266.com/stable/package_esp8266com_index.json (http://arduino.esp8266.com/stable/package_esp8266com_index.json) -> esp8266 by ESP8266 Community version 2.3.0
- Libraries aus dem neusten ESPEasy Paket (z.Z R120 (http://www.esp8266.nu/downloads/ESPEasy_R120.zip))
- ab ESPEasy R109 wird die pubsubclient library 2.6+ benötigt -> https://github.com/knolleary/pubsubclient (https://github.com/knolleary/pubsubclient)
- ab ESPEasy R120 wird die ArduinoJson library 5.6.4+ benötigt -> https://github.com/bblanchon/ArduinoJson (https://github.com/bblanchon/ArduinoJson)
Edit: (24.02.2017):
- Aktualisiertes Modul v1.0 ins FHEM svn eingecheckt.
** Dieser erste Beitrag wurde grundlegend überarbeitet, da es ursprünglich in diesem Thread nur um die Entwicklung des "FHEM HTTP" ESPEasy Plugins (_C009.ino) ging.
Sehr cool! Werde ich die Tage mal testen.
Danke erst mal für die super Software.
Bis ich mal wieder Libs + IDE +ESP-Easy zusammen hatte das war leider übliche Fluchen.
Aber dann war es wirklich easy:
- dein "AddOn" einkopieren
- ein "define ESP01 dummy" #so heisst der Kerl
- und schon gibt es wie von Zauberhand neue Readings in FHEM:
ZitatHumidity 52
Temperature 26.8
Also wirklich krass einfach. Danke !
Hallo,
kann man auch zum ESP Daten übertragen?
LG
/robin
Daten werden noch nicht zum ESP übertragen. Kann ich aber bei Gelegenheit versuchen einzubauen. Testen müsstest Du das dann, da ich keine Anwendung dafür habe, ok?
klar, ich habe noch einige Witty Boards hier liegen. Da könnte ich bspw. eine RGB-Led zum leuchten bringen.
Jetzt habe ich es gerade mit MTQQ hinbekommen und jetzt gibt's wieder was neues. Echt verrückt
MQTT ist ja nichts schlechtes, ich fande es so nur einfacher... ;)
eben, man muss nicht wegen einem Sensor einen kompletten MQTT-Broker bauen. Wenn man mehrere Sensoren hat, sieht das ganze schon anders aus. Ich nutze Mosquitto auch.
Naja Mosquitto bauen muss man ja nicht unbedingt. Mit Raspbian Jessie kann man auch einen Mosquitto Broker per Docker Image nutzen. Mit Raspbian Wheezy muss man allerdings erst den Kernel neu bauen um die Docker notwendigen Optionen im Kernel zu bekommen. Aber dann geht es dort auch mit Docker.
Die Idee mit ESP Easy direkt an FHEM zu senden ist natürlich die einfachste Art.
Hallo,
Mosquitto läßt sich auf dem RasPi unter Jessie recht einfach installieren:
http://blog.wenzlaff.de/?p=6487
Gruß aus Berlin
Michael
Hallo dev0
Besten Dank für das coole Plugin! Ich habe es heute getestet und musste ein dediziertes FHEM-WEB einrichten ohne Benutzername und Passwort. Der Grund liegt darin, dass meine FHEM-WEB mit komplexen Benutzernamen und Passwörter mit einigen Sonderzeichen (basicAuth) gesichert sind und ESPeasy damit ein Problem hatte.
Besteht die Möglichkeit, dass du ein Plugin schreibst für FHEM-TELNET? Das würde mich sehr freuen.
Danke und viele Grüsse Eppi
Funktioniert basic auth denn generell oder liegt es an den Sonderzeichen? ich habs noch nicht getestet.
Telnet: habe ich nicht vor, aber Du kannst gerne einen Patch schreiben ;)
Zitat von: dev0 am 20 Juli 2016, 19:59:39
Funktioniert basic auth denn generell oder liegt es an den Sonderzeichen? ich habs noch nicht getestet.
wenn ich einen einfach user und pwd name eingebe ohne Sonderzeichen, dann scheint es zu funktionieren. Getestet habe ich es nicht, aber nach einem save im Bowser des Espeasy bleibt er korrekt stehen. Beim meinen Username und Passwort setzt er die beiden Wörter zusammen in beide Felder...
Trotzdem Danke für deine Mühe!
Wenn es generell funktioniert, dann bin ich raus. Dann müsstest du dich an den ESPEasy Autor wenden: http://www.esp8266.nu/forum/
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
Selbst ist dem Mann! Find ich gut.
Jetzt müssen wir nur noch den anderen Weg einbauen: FHEM -> ESP
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]
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.
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.
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.
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
Zitat von: fh168 am 19 Juli 2016, 11:27:51
kann man auch zum ESP Daten übertragen?
Ja, siehe Modul im ersten Beitrag.
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 ;)
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
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
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, ... ;)
such mal bitte im forum. es gibt zwei oder drei threads in denen es genauer beschrieben ist.
gruss
andre
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
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
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
Zitat von: justme1968 am 26 Juli 2016, 12:59:35
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.
Zur Information:
https://github.com/ESP8266nu/ESPEasy/pull/48
(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
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
Zitat von: amithlon am 26 Juli 2016, 16:19:20
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
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
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
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? ;)
Welche Parameter benötig longpuls? Wie pcflongpulse?
Zitat von: dev0 am 31 Juli 2016, 10:44:39
Welche Parameter benötig longpuls? Wie pcflongpulse?
soweit ich weiß ja
...cmd=LongPulse,<gpio>,<level>,<duration>
Yepp, Modul im ersten Beitrag ist ausgetauscht.
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?
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:
on GPIO14#Switch do
SendToHTTP <FHEM-IP>,<FHEM-PORT>,/fhem?cmd=setreading%20ESPxx%20GPIO14%20[GPIO14#Switch]
endon
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.
Das wäre die 4. Alternative, die ebenfalls schon funktioniert.
Hallo dev0,
habe gerade gesehen, dass Dein Branch in den Master gemerged worden ist. Somit ist Dein Link auf den Branch nur noch notwendig, wenn Du etwas änderst, dass vor der Übernahme in den Master getestet werden soll.
Grüße Jörg
Ich hatte die Mail von Github zwar aus dem Augenwinkel gesehen, aber noch gar nicht registriert, dass der Pull Request angenommen wurde. Ich hatte eher mit einer Ablehnung gerechnet ;) Den ersten Beitrag werde ich anpassen.
Danke für den Hinweis.
/Uli
- Link auf das Plugin im 1. Beitrag entfernt -> "FHEM HTTP" ist nun Bestandteil von ESPEasy.
- Das aktuelle FHEM ESPEasy Modul liegt ab jetzt auf Github: https://github.com/ddtlabs/ESPEasy
- Modulupdate via controls.txt hinzugefügt.
Ich habe eine aktualisierte Version des ESPEasy Modules auf Github eingecheckt:
https://github.com/ddtlabs/ESPEasy
Release notes:
Zitat
Version 0.1.3
- added pin mapping for Wemos D1 mini, NodeMCU,... within set commands (eg. D8 instead of GPIO 15)
- added get command "pinMap" (display pin mapping)
- added state mapping (on->1 off->0) within set commands
- added set command "clearReadings" (GPIO readings will be wiped out)
- show usage if there are too few arguments
- command reference adopted
Die vom ESP-Modul retournierten Werte werden ja ganz einfach in einen dummy geschrieben.
Ist es möglich, dass die Werte nicht im Dummy sondern im gleichnamigen ESPEasy "Device" landen?
Damit wären beide Kommuniaktionsrichtungen an einer Stelle zugänglich und viel einfacher zu warten?
Ja und ja.
Hab des ESPEasy device in FHEM so benannt wie das ESPEasy-Modul heißt.
Es kommen aber die zuvor beim dummy eingegangenen Daten nicht an.
Muss ich was beachten oder geht das ganz anders?
Haben ich auch so gemacht, funktioniert bei mir mit 2 sonoffs aber nicht mit einem nodemcu. Warum auch immer?
Gesendet von meinem SM-G930F mit Tapatalk
ESPEasy und FHEM ist es egal in welchen Devicetyp die Werte geschrieben werden, da setreading verwendet wird.
Zum Debuggen das verbose Attribut vom ESPEasy Modul und der verwendeten FHEMWEB Instanz auf 4 oder 5 setzen, dann sieht man die aufgerufenen Befehle im Log.
Hi,
I used already with the generic http plugs and bij advanced setting and by publish template I added :
fhem?cmd=setreading%20%tskname%%20%valname%%20%value%
I had dummy devices created.
Now i flashed it to 120 en choose fhem http, is this working than out of the box, because I don't get the temperatures??
another question about the module espeasy you created in them. I should be nice to have PWMFADE with it.
ex: http://192.168.180.30/control?cmd=PWMFADE,1,1000,1
I flashed espeasy on an h801 device and put an warm white led strip on it.
I can dim it with the command: http://192.168.180.30/control?cmd=PWMFADE,1,1000,1
Where pinno = 0-3 (0=r,1=g,2=b,3=w). Target 0-1023, Time 1-30 seconds.
regards Richard
Zitat von: kroonen am 11 August 2016, 22:48:35
Now i flashed it to 120 en choose fhem http, is this working than out of the box, because I don't get the temperatures??
Yes, it should work out of the box. Please check all ESP settings, especially controller ip and port (FHEMWEB oprt). You also have to configure in ESP GUI:
- Config->Main Settings->Name: This will be used for fhem device name
- Devices->Edit Sensor->Optional Settings->Value Name x: This will be used for reading names
After that you can set "attr <fhemweb> verbose 5" to see incoming commands in your fhem log.
Zitat
I should be nice to have PWMFADE with it.
Of cause, but in the completely rewritten ESPEasy module that will be released in a few days. The new version will use the 2-stage design ("zweistufig" in german) with it's own tcp socket. It can be found in the develop branch (https://github.com/ddtlabs/ESPEasy/tree/develop) at the moment.
I wonder that the PWMFADE command cannot be found in the ESP Command Reference (http://www.esp8266.nu/index.php/ESPEasy_Command_Reference). Where did you find this command? In the source code or is there another command overview?
I found it in the topic of the h801 in espeasy http://www.esp8266.nu/forum/search.php?st=0&sk=t&sd=d&sr=posts&keywords=H801
You need to compile the milight (RWBW) plug-in from espeasy playground
https://github.com/ESP8266nu/ESPEasyPluginPlayground
Ich habe gerade die aktuelle Entwicklerversion in den "developer branch" eingecheckt: https://github.com/ddtlabs/ESPEasy/tree/develop
Das Modul ist jetzt zweistufig aufgebaut und der define Aufruf hat sich geändert. Bereits angelegt Devices vor dem Update besser direkt löschen, da sie nach einem Neustart nicht mehr funktionieren werden. Sorry for that!
Ab der aktuellen Version musst zuerst ein Bridge Device angelegt werden:
define <name> ESPEasy bridge <port>
Der Port darf auf eurem System natürlich nicht bereits genutzt werden und wenn FHEM ohne root Rechte läuft (default), dann muss der Port >1024 sein. Vorschlag: 8383, da ich diesen Wert auch in ESPEasy Software demnächst vorgeben werde. Auf ESP Seite muss dieser Port ebenfalls eingestellt werden (ESP GUI -> Config -> Controller Port). Wenn Daten vom ESP auf diesem Port empfangen werden, dann werden die logischen Devices automatisch angelegt. Sollte jemand den ESP wirklich nur zum Schalten verwenden, ohne sich zumindest RSSI Werte schicken zu lassen, dann müssen die logischen Devices manuell angelegt werden. Ist in der Command reference beschrieben.
Die logischen Devices und die Bridge können nun auch beliebig (um)benannt werden. FHEM2FHEM sollte mit diesem Modul auch im raw Modus funktionieren. Habe ich aber noch nicht getestet. Sollte jemand vor dem Update in die Command Ref schauen wollen, dann auf Github gucken.
Sollte ein erfahrener FHEM Entwickler die Muße haben, mal in den Code zu gucken, wäre ich für konstruktive Kritik dankbar.
@kroonen: Do you understand some German? I released a new version on Github. Delete your defined ESPEasy devices within FHEM before you are going to update. New command reference is on Github, too.
Hi,
I get this error and fhem hangs while starting
2016.08.12 21:13:02 1: PERL WARNING: keys on reference is experimental at ./FHEM/34_ESPEasy.pm line 887, <$fh> line 353.
2016.08.12 21:13:02 2: ESPEasy Woonkamertemp2: opened as bridge -> port:8383 (v0.2.3)
Undefined subroutine &main::TcpServer_Open called at ./FHEM/34_ESPEasy.pm line 806, <$fh> line 353
I have in my config:
define Woonkamertemp2 ESPEasy bridge 8383
attr Woonkamertemp2 room Woonkamer
define Woonkameresp ESPEasy 192.168.180.71 80 Woonkamertemp2 Woonkamer-Sensor
attr Woonkameresp room Woonkamer
TcpServer_Open is a function provided by FHEM. I guess your FHEM Installation is not up to date.
Post the output of version command, in code tags, please.
Here the output
fhem> version
Latest Revision: 11952
File Rev Last Change
fhem.pl 11922 2016-08-08 14:39:02Z rudolfkoenig
90_at.pm 11342 2016-04-29 11:25:51Z rudolfkoenig
98_average.pm 10530 2016-01-16 19:27:21Z rudolfkoenig
98_cloneDummy.pm 5919 2014-05-21 05:03:48Z joachim09876
00_CUL.pm 11637 2016-06-09 18:01:20Z rudolfkoenig
09_CUL_FHTTK.pm 7529 2015-01-11 18:52:43Z matscher
14_CUL_WS.pm 10794 2016-02-11 06:26:06Z rudolfkoenig
No Id found for 71_DENON_AVR.pm
98_dewpoint.pm 6757 2014-10-12 18:58:57Z joachim09876
98_DOIF.pm 11314 2016-04-26 18:29:24Z damian-s
98_dummy.pm 11442 2016-05-15 12:43:12Z rudolfkoenig
93_FHEM2FHEM.pm 11732 2016-07-02 17:41:31Z rudolfkoenig
98_fheminfo.pm 10570 2016-01-19 06:39:23Z rudolfkoenig
01_FHEMWEB.pm 11924 2016-08-08 16:31:21Z rudolfkoenig
11_FHT8V.pm 7115 2014-12-02 06:51:20Z rudolfkoenig
92_FileLog.pm 11921 2016-08-08 08:37:09Z rudolfkoenig
10_FS20.pm 11432 2016-05-12 08:35:57Z rudolfkoenig
98_help.pm 11482 2016-05-19 19:17:31Z betateilchen
02_HTTPSRV.pm 10733 2016-02-06 09:02:02Z borisneubert
98_JsonList2.pm 11764 2016-07-08 09:27:57Z rudolfkoenig
13_KS300.pm 11620 2016-06-05 16:29:46Z rudolfkoenig
30_MilightBridge.pm 11710 2016-06-24 09:07:17Z mattwire
31_MilightDevice.pm 11177 2016-04-03 11:40:34Z markus-m
00_MQTT.pm 10418 2016-01-08 23:28:27Z ntruchsess
10_MQTT_BRIDGE.pm 6935 2014-11-09 20:35:34Z ntruchsess
10_MQTT_DEVICE.pm 6935 2014-11-09 20:35:34Z ntruchsess
91_notify.pm 11178 2016-04-03 14:20:32Z rudolfkoenig
98_PID20.pm 10722 2016-02-04 17:12:18Z john99sr
73_PRESENCE.pm 11810 2016-07-17 18:17:46Z markusbloch
# $Id: 00_SmartMeterP1 michelverbraak $
98_statistics.pm 11309 2016-04-25 17:07:12Z grompo
99_SUNRISE_EL.pm 10569 2016-01-19 06:30:28Z rudolfkoenig
98_SVG.pm 11771 2016-07-09 11:11:48Z rudolfkoenig
42_SYSMON.pm 11105 2016-03-20 19:37:02Z hexenmeister
98_telnet.pm 11789 2016-07-12 13:44:14Z rudolfkoenig
98_UbiquitiMP.pm 8516 2015-05-02 17:14:24Z wzut
98_UbiquitiOut.pm 8471 2015-04-23 17:46:01Z wzut
99_Utils.pm 10570 2016-01-19 06:39:23Z rudolfkoenig
98_version.pm 11026 2016-03-08 07:25:45Z markusbloch
59_Weather.pm 11249 2016-04-16 17:03:47Z borisneubert
Blocking.pm 11918 2016-08-07 16:51:00Z rudolfkoenig
Color.pm 11159 2016-03-30 16:08:06Z justme1968
No Id found for ConnAck.pm
No Id found for Connect.pm
No Id found for Constants.pm
DevIo.pm 11786 2016-07-12 08:44:10Z rudolfkoenig
No Id found for Disconnect.pm
GPUtils.pm 6653 2014-10-02 11:59:37Z ntruchsess
HttpUtils.pm 11935 2016-08-10 09:09:03Z rudolfkoenig
No Id found for JustMessageId.pm
No Id found for Message.pm
No Id found for PingReq.pm
No Id found for PingResp.pm
No Id found for PubAck.pm
No Id found for PubComp.pm
No Id found for Publish.pm
No Id found for PubRec.pm
No Id found for PubRel.pm
RTypes.pm 10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm 11513 2016-05-24 17:56:05Z rudolfkoenig
No Id found for SubAck.pm
No Id found for Subscribe.pm
TcpServerUtils.pm 11908 2016-08-06 15:09:55Z rudolfkoenig
No Id found for UnsubAck.pm
No Id found for Unsubscribe.pm
YahooWeatherAPI.pm 11249 2016-04-16 17:03:47Z borisneubert
Your installation seems to be ok. I have an idea what the problem is. I will fix it tomorrow morning.
I also did an debug on my test fhem installation
2016.08.12 22:15:34 4: Connection accepted from WEB_192.168.180.71_6442
2016.08.12 22:15:34 4: WEB_192.168.180.71_6442 GET /fhem?cmd=setreading%20Woonkamer-Sensor%20Temperature%2021.2%3Bsetreading%20Woonkamer-Sensor%20Humidity%2079; BUFLEN:0
2016.08.12 22:15:34 5: Cmd: >setreading Woonkamer-Sensor Temperature 21.2<
2016.08.12 22:15:34 5: Cmd: >setreading Woonkamer-Sensor Humidity 79<
2016.08.12 22:15:34 4: name: /fhem?cmd=setreading%20Woonkamer-Sensor%20Temperature%2021.2%3Bsetreading%20Woonkamer-Sensor%20Humidity%2079 / RL:3294 / text/html; charset=UTF-8 / /
2016.08.12 22:15:34 4: Connection closed for WEB_192.168.180.71_6442: EOF
I also see the issue. You take the name of the device. (mainsettings) if you have more outputs to send or more i2c device (that I have 1x bmp085 and 1 x si7021 so 2x temp 1x hum and 1 pressure), you could better take the name of the device tab and that the device name)
the setreading should look like this with %taskname%
fhem?cmd=setreading%20%tskname%%20%valname%%20%value%
regards Richard
Zitat von: kroonen am 12 August 2016, 21:18:04
Undefined subroutine &main::TcpServer_Open called at ./FHEM/34_ESPEasy.pm line 806, <$fh> line 353
Should be fixed. The new version can be found on github / develop breanch.
Zitat von: kroonen am 12 August 2016, 22:23:19
you could better take the name of the device tab and that the device name)
the setreading should look like this with %taskname%
I am aware that device name is used instead of %taskname%. I consider to make it configurable in ESP GUI in the future.
Zitat von: kroonen am 12 August 2016, 21:18:04
2016.08.12 21:13:02 1: PERL WARNING: keys on reference is experimental at ./FHEM/34_ESPEasy.pm line 887, <$fh> line 353.
Do you use a perl version >= 5.20?
However, you can ignore it at the momet. It is just a warning not an error. Edit: Should be fixed, too. Please test it.
Please, use code tags if you post logs, listings etc. Button with the hash sign (#).
Hi,
All warnings are gone, and I use perl 5.2 subversion 2 default (debian debian jessie)
It should be nice to have the %taskname% in espgui than I can use it for all mij esp's (now 16 online , and 4 of them I use inputs from more that one switches.
The PWMFADE is als working, thnx for that/. Is there a way how I can make a dimmer with slider of that. the value is from 0-1000 , so i think a slider of with 0 -100% with steps of 10. Or should i do it in the ftui gui?
regards Richard
Hi
Just another question about the new module. I have my temperature config like this
define Woonkameresp ESPEasy bridge 8383
attr Woonkameresp room Woonkamer
define Woonkamertemp ESPEasy 192.168.180.71 80 Woonkamertemp Woonkamertemp
attr Woonkamertemp IODev Woonkameresp
attr Woonkamertemp group Temperaturen
attr Woonkamertemp room Woonkamer
attr Woonkamertemp stateFormat Temp: Temperature°C Hum: Humidity
define FileLog_Woonkamertemp FileLog /var/log/fhem/Woonkamertemp-%Y.log Woonkamertemp
attr FileLog_Woonkamertemp logtype temp4hum4:Temp/Hum,text
attr FileLog_Woonkamertemp room Logfile
define weblink_Woonkamertemp SVG FileLog_Woonkamertemp:weblink_Woonkamertemp:CURRENT
attr weblink_Woonkamertemp label "Woonkamer Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_Woonkamertemp room Plots
The same esp has also a relay. Is the best way to define it than like this?
define lamp dummy
attr lamp devStateIcon on:FS20.on off:FS20.off
attr lamp eventMap on:on off:off
define relayswitchaan2 notify lamp:on set Woonkamertemp gpio 12 on
define relayswitchuit2 notify lamp:off set Woonkamertemp gpio 12 off
---------------------------------------------------------------------------------------
Or should I incoming still use the old wat on port 8083 and create for temperature / hum a dummy device, and for outgoing the module espeasy and bridge?
regards Richard
Zitat von: kroonen am 13 August 2016, 19:52:12
Or should i do it in the ftui gui?
A good idea.
Zitat von: kroonen am 13 August 2016, 21:31:24
The same esp has also a relay. Is the best way to define it than like this?
define lamp dummy
attr lamp devStateIcon on:FS20.on off:FS20.off
attr lamp eventMap on:on off:off
define relayswitchaan2 notify lamp:on set Woonkamertemp gpio 12 on
define relayswitchuit2 notify lamp:off set Woonkamertemp gpio 12 off
Or should I incoming still use the old wat on port 8083 and create for temperature / hum a dummy device, and for outgoing the module espeasy and bridge?
The old way is deprecated and can/will be removed in a future release.
You can experiment with eventMap and stateFormat to fit your needs:
attr esp eventMap /gpio 15 on:on/gpio 15 off:off/
In this example "set esp on/off" is going to switch relay on GPIO15 on/off. If you need a single device for that relay then you can use a dummy of course.
I'm serious: use "code" tags not "sup" tags. It is difficult to read on some (mobile) devices.
I'm experimenting with PWMFADE and a slider in ftui, and it looks like to work, but I wanted to read the values, but I noticed that de PWMFADE setting not are present in the Readings. GPIO are in the reading
regards Richard
Open the pwmfade url in a browser and post the output.
Hi,
How do you mean open in the browser, what show the url be?
I think this???
192.168.180.5:8083/hem?cmd=set %Ledesp%pwmfade%1%0%1
or telnet
fhem> set Ledesp pwmfade 1 0 1
fhem> l Ledesp
Internals:
DEF 192.168.180.30 80 H801_led H801_led
HOST 192.168.180.30
IDENT H801_led
IODev Woonkameresp
LASTInputDev Woonkameresp
MSGCNT 262
NAME Ledesp
NR 198
PORT 80
STATE opened
SUBTYPE device
TYPE ESPEasy
VERSION 0.2.5
Woonkameresp_MSGCNT 262
Woonkameresp_TIME 2016-08-15 11:10:18
Readings:
2016-08-14 22:16:22 GPIO1 on
2016-08-14 22:16:22 GPIO1_mode output
2016-08-14 22:16:22 _lastAction GPIO 1 Set to 1
2016-08-15 11:10:18 presence present
2016-08-14 22:15:18 state opened
Helper:
urlcmd /control?cmd=
Attributes:
IODev Woonkameresp
room Woonkamer
fhem>
Use a web browser like Firefox, IE,... and type in the URL:
http://<ESP-IP>:80/control?cmd=pwmfade,<PIN>,100,1000Replace <ESP-IP> with the IP addess of your ESP
Replace <PIN> with GPIO number
Your LEDs should do something and some data should be displayed. Show the displayed data.
http://192.168.180.30/control?cmd=pwmfade,1,0,1
result in browser
PWM fading over 1 seconds.
It doesn't give the result that pin 1 used and value 0 and fading over 1 second
The best way to get the correct status is to ask the plugin author to send the status like sensors do.
Hallo,
erstmal vielen Dank für die super Software, das macht die ESP Geschichte ja noch einfacher.
Hab am Wochenende mal die Entwicklerversion ausprobiert und nach Umstellen auf Port 1024 kamen auch die Readings.
Allerdings bin ich am Switch input verzweifelt es wurde einfach nichts übertragen. Es muß wohl ein Fehler im Plugin C_009 sein.
Ich habe jetzt unter switch input die Zeilen von SENSOR_TYPE_SINGLE eingetragen:
case SENSOR_TYPE_SWITCH:
url += F("setreading%20");
url += Settings.Name;
url += F("%20");
url += ExtraTaskSettings.TaskDeviceValueNames[0];
url += F("%20");
url += toString(UserVar[event->BaseVarIndex],ExtraTaskSettings.TaskDeviceValueDecimals[0]);
break;
und siehe da es funzt
Gruß
Mick
Ja, der Fehler ist mir heute morgen auch aufgefallen. Werde ich noch korrigieren, überlege aber noch das ganze auf Json umzustellen und alle verfügbaren Daten/Einstellungen zu übertragen, da wir dadurch auf Dauer unabhängiger sind.
Warum benutzt niemand mehr code tag?
Zitat von: dev0 am 15 August 2016, 18:49:33
Warum benutzt niemand mehr code tag?
Wieso, Kroonen macht es doch jetzt ;)
:)
Zitat von: Mick59 am 15 August 2016, 18:42:25
Allerdings bin ich am Switch input verzweifelt es wurde einfach nichts übertragen. Es muß wohl ein Fehler im Plugin C_009 sein.
Der Fix wurde in ESPEasy R122 aufgenommen.
Man bist Du schnell,
Danke 8)
Bin nun auch endlich dazu gekommen meinen SonOff mit ESPEasy und dem Fhem Modul einzubinden.
Nun meine Frage zum Modul.
Kann ich auch direkt im Fhem Device auf die Werte der Sensoren zurück greifen?
Habe einen DHT11 angebunden und die gemessenen Werte würde ich gerne direkt in dem Device als Reading haben.
Danke für die Hilfe
Ja, das ist der Sinn des "FHEM HTTP" Plugins.
Schlimm, wenn man die Frage falsch formuliert...
Nächster Versuch: Wie? ;)
Danke!
Schlimm, wenn man auf die konkrete Fragestellung antwortet...
- Für die aktuelle Version ist es hier beschrieben: https://forum.fhem.de/index.php/topic,55728.msg481087.html#msg481087 und in der Command ref.
- Für die alte Version (die ich bald entfernen werde) muß du den Namen des ESP so wählen, dass er dem FHEM Device entspricht, dass die Daten erhalten soll. Der Plugin Port muss ein FHEMWEB Port sein. Debuggen kannst Du die alte Version mit:
attr <FHEMWEB> verbose 5
Danke für den Link und die Infos.
Schlimm war an deiner Antwort ja nichts. Hast ja genau das gemacht, wonach ich gefragt habe ;)
Hätte da mal ein Problemchen...
Ich habe an meinem Sensor-Board 5x DS18B20 angebunden (alle am GPIO13).
Im ESPEasy-GUI (R120) habe ich die Sensoren konfiguriert:
Task Device Name IDX Port Value
1 DS18B20 DS18B20_00001D 1 28-f4-16-dd-06-00-00-1d 1.25
2 DS18B20 DS18B20_0000E4 2 28-22-0f-dd-06-00-00-e4 0.88
3 DS18B20 DS18B20_0000DA 3 28-e6-ac-dd-06-00-00-da 1.19
4 DS18B20 DS18B20_00009F 4 28-b3-62-dd-06-00-00-9f 0.81
5 DS18B20 DS18B20_0000C2 5 28-cf-25-dd-06-00-00-c2 0.75
(hängen grad zum Kalibrieren im Eisbad...)
Send Data ist bei allen Sensoren aktiviert.
Die unterschiedlichen IDs sowie Temperaturen sind im ESPEasy GUI sichtbar - so weit, so gut.
Mein Bridge-Device ist ebenfalls aufgesetzt. Autocreate ist aktiviert.
Ein Device wurde angelegt:
fhem> list ESPEasy_ESP_Proto_4MB
Internals:
CFGFN
DEF 192.168.254.122 80 ESPbridge ESP_Proto_4MB
ESPbridge_MSGCNT 109
ESPbridge_TIME 2016-08-19 11:10:17
HOST 192.168.254.122
IDENT ESP_Proto_4MB
IODev ESPbridge
LASTInputDev ESPbridge
MSGCNT 109
NAME ESPEasy_ESP_Proto_4MB
NR 180
PORT 80
STATE opened
SUBTYPE device
TYPE ESPEasy
VERSION 0.2.5
Helper:
Dblog:
Temperature:
Logdb:
TIME 1471597817.62393
VALUE 0.75
Presence:
Logdb:
TIME 1471597809.62333
VALUE present
State:
Logdb:
TIME 1471596593.61714
VALUE opened
Readings:
2016-08-19 11:10:17 Temperature 0.75
2016-08-19 11:10:09 presence present
2016-08-19 10:49:53 state opened
Helper:
urlcmd /control?cmd=
Attributes:
IODev ESPbridge
room ESPEasy
Allerdings erhalte ich lediglich ein Reading "Temperature", ohne Rückschluss darauf, welcher Sensor nun gelesen wurde:
2016.08.19 11:16:22 4: Connection accepted from ESPbridge_192.168.254.122_27247
2016.08.19 11:16:22 5: ESPEasy ESPbridge: accepted tcp connect <= 192.168.254.122:27247
2016.08.19 11:16:22 5: ESPEasy ESPbridge: received raw message:
GET /fhem?cmd=setreading%20ESP_Proto_4MB%20Temperature%200.81 HTTP/1.1
Host: 192.168.254.20
Connection: close
2016.08.19 11:16:22 5: ESPEasy ESPbridge: Dumper $header:
$VAR1 = {
'Host' => '192.168.254.20',
'Connection' => 'close',
'GET' => '/fhem?cmd=setreading%20ESP_Proto_4MB%20Temperature%200.81 HTTP/1.1'
};
2016.08.19 11:16:22 4: ESPEasy ESPbridge: received cmd:setreading device:ESP_Proto_4MB reading:Temperature value:0.81
2016.08.19 11:16:22 5: ESPEasy ESPbridge: autocreate is enabled
2016.08.19 11:16:22 5: ESPbridge dispatch ESP_Proto_4MB:192.168.254.122:1:1:setreading|Temperature|0.81
Wie komme ich an die Temperaturen der Einzelsensoren?
Idealerweise entweder mit der Task-ID aus ESP-Easy oder aber mit dem Name, wie er in ESPEasy definiert ist.
Ich vermute, dass Deine Value Names (ESP GUI -> Devices -> Edit -> Optional Settings -> Value Name) für alle 5 DS12B20 gleich lauten (Temperature). Nenn die mal bitte unterschiedlich und schau mal was dann passiert.
z.Z. wird das FHEM Device noch aus dem ESP Namen generiert und die die Werte in einem Reading mit dem Namen des Value Names geschrieben. Das werde ich der nächsten Version ändern. Vermutlich wird es schon reichen, statt des ESP Namen den Device Namen zu verwenden, dann kann man durch steuern ob die Werte in einem oder in mehreren Devices laufen sollen. Innerhalb eines Devices müssen die Value Names dann natürlich unterschiedlich sein.
Den Port kann man nicht dafür nutzen, da er nicht bei allen ESP Devices vorhanden ist.
Prima! Das war's.
Ich bin irrtümlich davon ausgegangen, dass der ESPEasy Device Name als Reading verwendet wird.
Hallo dev0,
könntest Du Bitte bei Gelegenheit den BME280 in das ESPEasy Plugin (_C009.ino) aufnehmen (siehe Code weiter unten *getestet), dann werden die Werte auch korrekt an FHEM übermittelt. Danke.
case SENSOR_TYPE_TEMP_HUM_BARO: // temp + hum + hum_stat + bar + bar_fore, used for BME280
// setreading #1
url += F("setreading%20");
url += Settings.Name;
url += F("%20");
url += ExtraTaskSettings.TaskDeviceValueNames[0];
url += F("%20");
url += toString(UserVar[event->BaseVarIndex], ExtraTaskSettings.TaskDeviceValueDecimals[0]);
// setreading #2
url += F("%3B");
url += F("setreading%20");
url += Settings.Name;
url += F("%20");
url += ExtraTaskSettings.TaskDeviceValueNames[1];
url += F("%20");
url += toString(UserVar[event->BaseVarIndex + 1], ExtraTaskSettings.TaskDeviceValueDecimals[1]);
// setreading #3
url += F("%3B");
url += "setreading%20";
url += Settings.Name;
url += F("%20");
url += ExtraTaskSettings.TaskDeviceValueNames[2];
url += F("%20");
url += toString(UserVar[event->BaseVarIndex + 2], ExtraTaskSettings.TaskDeviceValueDecimals[2]);
break;
Mit der neuen "_C009.ino (https://github.com/ddtlabs/ESPEasy-Fork/commit/601b5dcfceea34ea00207d983fdd03d90bcb14b0)" (Added JSON support) Version wird der Pressure-Wert des BME280's doppelt aufgeführt bzw. zweimal hintereinander- siehe auch Post von Gestern.
Der Grund ist die Zeile:
url += UserVar[event->BaseVarIndex + 2];
im Reading 3.
Wenn man die Zeile entfernt, dann wird der Wert richtig dargestellt.
Dies nur als Hinweis.
Ich habe keine BME280 zum Testen. Das heisst, es funktionierte vorher auch schon, nur mit dem Fehler, das der Wert doppelt geschrieben wurde?
Zitat von: dev0 am 23 August 2016, 18:37:26
es funktionierte vorher auch schon
Ja.
Zitat von: dev0 am 23 August 2016, 18:37:26
nur mit dem Fehler, das der Wert doppelt schrieben wurde?
Anders, nicht doppelt geschrieben sondern der Wert ist doppelt aufgeführt.
Beispiel:990.42990.42
ok, verstanden.
Testest Du bitte die aktuelle Version: https://github.com/ddtlabs/ESPEasy-Fork/blob/added-json-support/_C009.ino
Meine Sensoren funktionieren weiterhin.
Wenn alles ok ist, dann stelle ich morgen früh einen PR, damit die Änderungen ins ESPEasy übernommen werden.
Passt!
Getestet mit BME 280 und BMP180 (bzw. BMP080 - ESPEasy Device).
Die anderen Änderungen kann ich im Moment nicht bewerten/verifizieren.
Danke.
Vielen Dank fürs Testen.
Wenn die Änderungen vom ESPEasy Maintainer übernommen worden sind, dann gibt es auch eine neue Modul Version.
Hallo
Bin durch Zufall auf das Modul gestoßen und nach etwas versuchen habe ich es auch geschafft ein ESP-12E einzubinden.
Luftfeuchtigkeit und Temperatur von einem DHT 22 werden auch in FHEM angezeigt und aktualisiert.
Ein angelegter Switch an GPIO 14 wird aber nur in der Oberfläche von ESPeasy angezeigt. Der Status in FHEM steht immer auf off.
Version ist die R120
Was muss ich machen, um einen Schalter mit seinen Status in FHEM zu sehen?
Damit der Esp den Status schickt, kannst Du einen Input Switch anlegen, der sendet die Daten an FHEM.
Edit: In R122 gab es einen Fix bzgl. Switch...
ja ok den Switch habe ich angelegt.
Gibt es die R122 auch als fertige Datei? Beim selbst erstellen kommen immer unterschiedliche Fehlermeldungen.
Falls nicht muss ich noch warten.
Ich habe keine Ahnung welche kompilierten Dateien angeboten werden.
Habe es geschafft und mit Version R124 scheint es zu funktionieren.
Also Arduino 1.6.5 und ESP8266 Community 2.3.0
Schon ist der Switch zu sehen :-)
Ich nutze die Modulversion ESPEasy 0.2.5 und dazu ESPEasy in der Version 120.
Bridge habe ich angelegt, sobald das ESPEassy starte wird auch sofort ein Device mit dem Namen des ESP(=ESPTest) angelegt, jedoch scheinbar keine Werte der definierten Devices übertragen.
Ich habe derzeit keine Sensoren verbunden, sondern möchte mir lediglich die "System Info" übertragen lassen und daher den ESP entsprechend konfiguriert.
Der Internal Wert "MSGCNT" steigt ständigt und im Log erhalte ich mit Verbose 5 folgende Einträge:
2016.08.27 01:03:56 4: ESPEasy ESPEasy_ESPTest: :
Was habe ich übersehen?
Zitat von: dev0 am 18 Juli 2016, 11:53:28
Die Readingnamen werden aus den Settings "Value Name x" generiert (Devices->Edit Sensor->Optional Settings->Value Name x).
Guten Morgen
mit einem Value Name wird die Laufzeit übertragen.
Kann ich trotz deep sleep irgendwie den Status eines Eingangs übertragen? Ich möchte das ganze als Fensterkontakt nutzen.
Edit: Ich glaube Send Boot state hilft
Zitat von: dev0 am 27 August 2016, 07:21:40
Danke für den entscheidenden Hinweis! :)
Wann wird den ca. der akt. devel Branch in den stable überführt werden?
Wenn mein aktueller Pull Request vom ESPEasy Maintainer übernommen wurde, dann werde ich eine weitere Version im Develop Branch veröffentlichen. Diese Version wird dann die aktuellste ESPEasy Version benötigen, da ich ab dann die Daten zusätzlich im JSON Format übergebe und verarbeite. Wenn diese Version stabil funktioniert, dann werde ich ich sie in den Master Branch übernehmen (und später ggf. ins FHEM Update, wenn gewünscht).
Es ist zwar unschön, dass das Modul dann wieder die aktuellste ESPEasy Version benötigt, aber ohne diese Umstellung geht es nicht, wenn man auch ESP Device/Sensor Namen (nicht den ESP Namen) usw. zur FHEM Device Zuordnung verweden möchte.
Die Umstellung auf JSON hat auch den Vorteil, dass zukünftige Erweiterungen ohne diese Abhängigkeit zur ESPEasy Version umgesetzt werden können. Ältere ESPEasy Versionen haben dann ggf. nur zur Folge, dass neue Erweiterungen nicht verfügbar sind.
Im aktuellen ESPEasy (R126) ist das FHEM Plugin um Daten im JSON Format erweitert worden. Das FHEM Plugin in R126 ist weiterhin kompatibel mit älteren ESPEasy Modul Versionen. Ebenso läßt sich das FHEM Plugin R126 auch weiterhin ohne das ESPEasy Modul verwerden, indem ein FHEMWEB Port als Controller Port benutzt wird. Beide Varianten, aber natürlich mit eingeschränkten Funktionen.
Das aktuelle ESPEasy Modul v0.4 verwendet jetzt die umfangreicheren JSON Daten. Sollte mit dem Modul eine ältere ESPEasy Software eingesetzt werden, dann werden die neuen Features nicht genutzt und es wird eine Warnung ausgegeben.
Neu ist die Zuordnung von ESP Werten zu FHEM Devices. Die empfangenen Werte werden einem FHEM Device zugeordnet, dessen Name so gebildet wird:
Attribut uniqIDs == 1 (default): ESPEasy_<EspName>_<DeviceName>
Attribut uniqIDs == 0: ESPEasy_<DeviceName>
Mit "Attribut uniqIDs == 0" sollte es auch möglich sein, Daten von mehreren ESPs in ein FHEM Device laufen zu lassen, wenn die <DeviceNames> (also die eigentlichen Sensornamen) identisch sind, aber die <ValueNames> unterschiedlich sind.
Sind die Devices einmal angelegt, dann können sie beliebig umbenannt werden. Die Zuordnung geschieht über das Internal IDENT und nicht über den Namen.
Die eingebettete Command reference ist aktualisiert, ebenso das readme.md auf Github.
Sollten nach dem Lesen der command ref noch Fragen auftauchen, dann fragt ;)
Die neue Version ist jetzt im develop branch (https://github.com/ddtlabs/ESPEasy/tree/develop) auf Github verfügbar.Aus den Release Notes:
Zitat
# - process json data (ESPEasy Version R126 required)
# - added uniqIDs attribut
# - added get user/pass
# - fixed auth bug
# - state will contain a summary (see attribute setState)
# - default room for bridge is ESPEasy, too.
# - log outdated ESPEasy versions (without json) once.
# - error handling for JSON decoding
# - ESP parameter like sleep, version, ... -> Internals
# - added attribute setState (disable value mapping to state)
Hallo,
da ich jetzt etwas länger gesucht habe einen Hinweis: Der Name eines ESPEasy Device muss den FHEM Konventionen für Bezeichnungen von Readings entsprechen. Also: A-Z; a-z; 0-9; .; _
Grüße Jörg
Bei den Value Names ersetze ich ungültige Zeichen bereits durch Unterstriche. ESP Name und Device Name habe ich anscheinend noch nicht berücksichtigt. Schaue ich mir an.
Edit: @JoWiemann: Trat das mit der ESPEasy R126 oder älter auf?
Mit der aktuellen ESPEasy vom Developer-Branch und dem aktuellen FHEM-Modul vom Developer-Branch. Also alles heute frisch geholt...
Grüße Jörg
Zitat von: JoWiemann am 29 August 2016, 17:16:54
da ich jetzt etwas länger gesucht
Im Log hast Du nicht folgende Einträge vorgefunden?
2016.08.30 06:30:29.735 2: ESPEasy eb: autocreate ESPEasy_ESP02-_SI2 ESPEasy <ESP-IP> 80 eb ESP02-_SI2
2016.08.30 06:30:29.735 1: ESPEasy eb: an autocreate error occurred while creating device for ESP02-_SI2: Invalid characters in name (not A-Za-z0-9._): ESPEasy_ESP02-_SI2
2016.08.30 06:30:29.735 2: ESPEasy: Device ESPEasy_ESP02-_SI2 not defined
Aber selbst diese Hinweise können eigentlich nur dann aufgetreten sein, wenn Du eins dieser Zeichen im ESP- oder Devicenamen vergeben hattest:
- : / { } , "Richtig?
Da ich alles zunächst auf meinem Testsystem, das mit verbose 4 läuft, eingerichtet hatte, habe ich die Logeinträge zunächst übersehen gehabt. Im ESP-Devicenamen befand sich ein "-". Mein Post war auch primär als Hinweis gedacht, falls sich noch jemand wundert, wenn seine Daten nicht in Fhem ankommen.
Grüße Jörg
Gesendet von iPhone mit Tapatalk
Im Devicenamen waren noch Zeichen erlaubt, die sich zwangsläufig in einem JSON String befinden (edit: und in Readingnamen erlaubt sind). Hab es gefixed, kommt mit der nächsten Version.
Danke für den Hinweis.
Hallo,
Kann es sein dass in Zeile 139
"oledcmd" => "pcapwm <on|off|clear>",
noch ein Fehler ist?
Bei mir kommt folgende Meldung bei flascher Eingabe:
Missing argument: oledcmd needs at least 1 parameter(s)
Usage: 'set ESPEasy_nodemcu1_OLED pcapwm <on|off|clear>'
Gruß Carlos
Yepp, typischer copy paste Fehler :-[
Hat zum Glück keine Auswirkung auf die Funktion.
Danke für's Melden.
Hi
an einem ESP habe ich ein Relais angeschlossen. Dieses kann ich auch über set gpio ein und aus schalten. Wie füge ich jetzt am sinnvollsten einen Button mit on/off und einer Lampe für den Status in FHEM ein?
Hier ein Beispiel für GPIO-15 mit Icon, devStateIcon, stateFormat,...
Den on/off Text kann man optional mit dem Atrribut webCmd ausblenden.
attr <ESP> icon FS20.off
attr <ESP> stateFormat GPIO15
attr <ESP> eventMap /gpio 15 on:on/gpio 15 off:off/status gpio 15:check/
attr <ESP> devStateIcon on:ios-on-green:off off:ios-off:on .*:ios-NACK:check
#optional:
attr <ESP> webCmd :
Edit: "attr <ESP> setState 0" entfernt, da es nicht benötigt wird.
Hallo,
ich habe bisher die Daten vom Lichtsensor BH1750 mit Hilfe MQTT übertragen, jetzt habe ich den ESP auf die neueste Firmware aktualisiert und übertrage nun die Daten über das neue Modul. Die Daten werden auch problemlos empfangen und angezeigt, nur werden alle Werte auf ein vielfaches von 10 gerundet und auch keine Kommastellen übertragen.
Auf der Weboberfläche vom ESPEASY sehe ich die richtigen Daten nur in FHEM nicht. Was mache ich da falsch?
Die Werte der Sensoren werden vom Modul nicht modifiziert. Zeig mal ein list von der Bridge und vom betroffenen Device. Zusätzlich ein ein log mit attr verbose 5 und attr debug 1 (Edit: die Attribute in der Bridge und dem Device setzen). Bitte code tages verwenden (# button) sonst wird das unleserlich.
Danke für die schnelle Antwort
Internals:
CFGFN
CONNECTS 912
DEF bridge 8383
FD 23
HOST bridge
MODULE_VERSION 0.4 RC1
NAME ESPBridge
NR 193
PASS not defined yet !!!
PORT 8383
STATE initialized
SUBTYPE bridge
TYPE ESPEasy
USER not defined yet !!!
Helper:
Dblog:
State:
Logdb:
TIME 1472721883.58111
VALUE initialized
Readings:
2016-09-01 11:24:43 state initialized
Helper:
urlcmd /control?cmd=
192.168.178.154:
presence present
192.168.178.172:
presence present
Espeasy4.home.int:
presence absent
Outdated:
Uniqid:
Espeasy3_licht:
192.168.178.154:
build 126
sleep 0
unit 3
Attributes:
debug 1
group ESPEasy Bridge
room ESPEasy,Gateway
verbose 5
2016.09.01 17:25:36 4 : Connection accepted from ESPBridge_192.168.178.154_2365
2016.09.01 17:25:36 5 : ESPEasy ESPBridge: accepted tcp connect <= 192.168.178.154:2365
2016.09.01 17:25:36 5 : ESPEasy ESPBridge: received raw message: GET /fhem?cmd=setreading%20ESPEASY3%20lux%202278 HTTP/1.1 Content-Length: 234 Host: 192.168.178.176 Connection: close {"module":"ESPEasy","version":"1.0","data":{"ESP":{"name":"ESPEASY3","unit":3,"version":9,"build":126,"sleep":0,"ip":"192.168.178.154"},"SENSOR":{"v0":{"deviceName":"Licht","valueName":"lux","value":2.28e3,"type":1},"v1":{},"v2":{}}}}
2016.09.01 17:25:36 5 : ESPEasy ESPBridge: Dumper $header: $VAR1 = { 'Host' => '192.168.178.176', 'Content-Length' => '234', 'GET' => '/fhem?cmd=setreading%20ESPEASY3%20lux%202278 HTTP/1.1', 'Connection' => 'close' };
2016.09.01 17:25:36 1 : ESPEasy ESPBridge: Dumper $content: $VAR1 = '{"module":"ESPEasy","version":"1.0","data":{"ESP":{"name":"ESPEASY3","unit":3,"version":9,"build":126,"sleep":0,"ip":"192.168.178.154"},"SENSOR":{"v0":{"deviceName":"Licht","valueName":"lux","value":2.28e3,"type":1},"v1":{},"v2":{}}}}';
2016.09.01 17:25:36 5 : ESPEasy ESPBridge: no basic authentication required
2016.09.01 17:25:36 5 : ESPEasy ESPBridge: Dumper $content decoded: $VAR1 = { 'version' => '1.0', 'module' => 'ESPEasy', 'data' => { 'ESP' => { 'sleep' => 0, 'unit' => 3, 'name' => 'ESPEASY3', 'build' => 126, 'ip' => '192.168.178.154', 'version' => 9 }, 'SENSOR' => { 'v2' => {}, 'v0' => { 'deviceName' => 'Licht', 'value' => 2280, 'type' => 1, 'valueName' => 'lux' }, 'v1' => {} } } };
2016.09.01 17:25:36 5 : ESPEasy ESPBridge: dispatch: ESPEASY3_Licht:192.168.178.154:1:1:setreading|lux|2280
2016.09.01 17:25:36 5 : ESPBridge dispatch ESPEASY3_Licht:192.168.178.154:1:1:setreading|lux|2280
2016-09-01 17:25:36 ESPEasy Licht lux: 2280
2016-09-01 17:25:36 ESPEasy Licht Lux:2280
Ich denk da wird hier "value":2.28e3 das Problem liegen, also in der ESPEASY-Firmware?
Zitat von: max333 am 01 September 2016, 17:33:34
2016.09.01 17:25:36 5 : ... { 'deviceName' => 'Licht', 'value' => 2280, 'type' => 1, 'valueName' => 'lux' }...
2016.09.01 17:25:36 5 : ESPEasy ESPBridge: dispatch: ESPEASY3_Licht:192.168.178.154:1:1:setreading|lux|2280
2016-09-01 17:25:36 ESPEasy Licht lux: 2280
Ich denk da wird hier "value":2.28e3 das Problem liegen, also in der ESPEASY-Firmware?
Ja, der vom ESP gesendete Wert ist schon falsch. Um sicherzustellen, dass es beim Pull Request ins ESPEasy R126 kein Fehler auftrat habe ich mir gerade die R126 von https://github.com/ESP8266nu/ESPEasy neu runtergeladen und geflasht. Bei mir funktioniert es problemlos:
"SENSOR":{"v0":{"deviceName":"BH1750","valueName":"brightness","value":166.67,"type":1}
Hast Du die Sourcen verändert/angepasst?
Nein, ich hatte nichts angepasst.
Jetzt habe ich den BH1750 im ESPEASY gelöscht, REBOOT und neu angelegt, nun werden auch die Daten in Fhem mit Kommastelle dargestellt.
Vielleicht sind die Konfigurationsdaten mit der neuen Firmware etwas anders?
Jedenfalls vielen Dank für die schnelle Hilfe.
Danke dev0 für das Beispiel mit der Lampe.
Eine Frage habe ich jetzt noch. Kann man das Icon ändern wenn der ESP nicht mehr anwesend ist?
Im Moment reagiert der Button dann einfach nicht mehr.
In der neuesten Version des Plugins zusammen mit der Version 120 vom ESPEasy(bin noch nicht updaten gekommen) erhalte ich einige Warnungen:
2016.09.02 09:12:50 1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/34_ESPEasy.pm line 597.
2016.09.02 09:12:50 1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/34_ESPEasy.pm line 598.
2016.09.02 09:12:50 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/34_ESPEasy.pm line 599.
2016.09.02 09:12:50 1: PERL WARNING: Use of uninitialized value $host in concatenation (.) or string at ./FHEM/34_ESPEasy.pm line 815.
Zitat von: Kalli01 am 02 September 2016, 16:09:20
Kann man das Icon ändern wenn der ESP nicht mehr anwesend ist?
Ja kann man.
Das funktioniert wie bei anderen Modulen auch, die die readingFnAtrributes benutzen.
Diese Grundlagen findest Du hier:
- http://fhem.de/commandref.html#stateFormat
- http://fhem.de/commandref.html#devStateIcon
- http://fhem.de/commandref.html#perl
- http://perldoc.perl.org/perlop.html#Conditional-Operator
attr <ESP> stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"GPIO15","")}
attr <ESP> devStateIcon on:ios-on-green:off off:ios-off:on absent:10px-kreis-rot:statusRequest .*:ios-NACK:check
attr <ESP> eventMap /gpio 15 on:on/gpio 15 off:off/status gpio 15:check/
attr <ESP> it_network
attr <ESP> webCmd :
Zitat von: Pyromane am 02 September 2016, 17:42:36
In der neuesten Version des Plugins zusammen mit der Version 120 vom ESPEasy(bin noch nicht updaten gekommen) erhalte ich einige Warnungen:
2016.09.02 09:12:50 1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/34_ESPEasy.pm line 597.
Danke für den Hinweis. Diese Warnungen hatte ich Anfang der Woche auch entdeckt und behoben.
Der Fix kommt mit der nächsten Version.
Ich habe gerade das ESPEasy Modul aktualisiert und in den master branch (https://github.com/ddtlabs/ESPEasy) verschoben.
Seit dem letzten develop release gab es noch folgende Änderungen:
Zitat
- improved removing of illegal chars in device + reading names
- removed uniqID helper from bridge if device was deleted
- use peer IP instead of configured IP (could be modified by NAT/PAT)
- added http response: 400 Bad Request
- added http response: 401 Unauthorized
- fixed oledcmd cmd usage string
- improved presence detection (incoming requests)
Download hier: https://github.com/ddtlabs/ESPEasy
oder über das FHEM update falls ihr das Repository zum update hinzugefügt habt.
Die Hinweise zum letzeten development release gelten natürlich auch für diese Version: https://forum.fhem.de/index.php/topic,55728.msg485804.html#msg485804
Die Firmware des ESPEasy scheint die angegebenen Kommastellen zu ignorieren. Beim DS18B20 werden immer 2 Kommastellen übertragen, egal was in dem Feld Decimals eingetragen wurde.
Des weiteren sollte die Zeile 199 im _P004. Dallas.ino ersetzt werde, damit auch die Temperatur vom DS1825 angezeigt wird:
if ((ROM[0] == 0x28 ) || (ROM[0] == 0x3b )) //DS18B20 or DS1825
Zitat von: max333 am 03 September 2016, 22:06:59
Die Firmware des ESPEasy scheint die angegebenen Kommastellen zu ignorieren.
Stimmt! Leider kommt an der Stelle ein unerwartetes Verhalten des Compilers oder einer Library in Spiel. Mit der neusten ArduinoJson Library bekomme ich das problemlos umgesetzt, mit der alten Version und entsprechenden Konvertierungen ergeben sich noch merkwürdige Effekte... Ich hoffe, dass ich einen Weg finde, der mit der aktuell verwendeten Library funktioniert.
Zitat von: max333 am 03 September 2016, 22:06:59
Des weiteren sollte die Zeile 199 im _P004. Dallas.ino ersetzt werde, damit auch die Temperatur vom DS1825 angezeigt wird:
if ((ROM[0] == 0x28 ) || (ROM[0] == 0x3b )) //DS18B20 or DS1825
Das ist so gar nicht meine Baustelle. Vieleicht magst Du hier (https://github.com/ESP8266nu/ESPEasy) einen eigenen Pull Request stellen?
Mit welcher ArduinoJson Version funktioniert das? Ich hab die 5.6.6 und die Arduino IDE 1.6.11.
Außerdem ist mir noch aufgefallen, wenn ich mit der Firmware 126 den Hostnamen eintrage wird versucht mit der IP 0.0.0.0 eine Verbindung herzustellen. Mit der Firmware 120 funktioniert auch das noch.
Zitat von: dev0 am 04 September 2016, 13:41:44
Das ist so gar nicht meine Baustelle. Vieleicht magst Du hier (https://github.com/ESP8266nu/ESPEasy) einen eigenen Pull Request stellen?
Ich weiß, dass das nicht deine Baustelle ist, nur bin ich dort (noch) nicht registriert.
Zitat von: dev0 am 19 Juli 2016, 11:35:45
Daten werden noch nicht zum ESP übertragen. Kann ich aber bei Gelegenheit versuchen einzubauen. Testen müsstest Du das dann, da ich keine Anwendung dafür habe, ok?
Ich würde mich auch zum testen anbieten und zar mit einem Wemos OLED Display. Wäre klasse wenn man die Texte direkt senden könnte ohne über HTTP zu gehen!
Zitat von: dev0 am 01 September 2016, 07:04:05
Hier ein Beispiel für GPIO-15 mit Icon, devStateIcon, stateFormat,...
Den on/off Text kann man optional mit dem Atrribut webCmd ausblenden.
attr <ESP> icon FS20.off
attr <ESP> stateFormat GPIO15
attr <ESP> eventMap /gpio 15 on:on/gpio 15 off:off/status gpio 15:check/
attr <ESP> devStateIcon on:ios-on-green:off off:ios-off:on .*:ios-NACK:check
#optional:
attr <ESP> webCmd :
Edit: "attr <ESP> setState 0" entfernt, da es nicht benötigt wird.
Hi Zusammen,
ich hatte das selbe Problem. Dank der Anleitung kann ich nun per Schalter ein Relais schalten. Danke!
Ich habe hier aber noch eine Frage: Am Esp8266 ist noch ein Thermoeter angeschlossen, ich würde also gern in Fhem nicht nur den Schalter für das Relais zum Device anzeigen sondern noch zusätzlich die Temperatur.
Mit: stateFormat
temp ° C // Rssi dbm // GPI012
Klappt das auch schon so einigermaßen nur sobald ich das "devstateicon" analog des Beispiels einfüge ist alles kaputt.
Hat jemand einen Tip?
Gruß und Danke
Dominik
Zitat von: max333 am 04 September 2016, 14:16:13
Mit welcher ArduinoJson Version funktioniert das? Ich hab die 5.6.6 und die Arduino IDE 1.6.11.
Habe gerade gesehen, dass seit der R120 die mitgelieferte ArduinoJson Lib neu genug ist um float_with_n_digits() nutzen zu können. Kann ich mir aber erst im Laufe der nächsten Woche ansehen.
Zitat von: max333 am 04 September 2016, 14:16:13
Außerdem ist mir noch aufgefallen, wenn ich mit der Firmware 126 den Hostnamen eintrage wird versucht mit der IP 0.0.0.0 eine Verbindung herzustellen. Mit der Firmware 120 funktioniert auch das noch.
Ich werde es noch kontrollieren, aber das wird wahrscheinlich nicht an der _C009.ini liegen..
Zitat von: P.A.Trick am 04 September 2016, 14:50:27
Ich würde mich auch zum testen anbieten und zar mit einem Wemos OLED Display.
Was funktioniert denn nicht? Alle offiziellen Befehle sollten funktionieren, auch nicht offizielle über das RAW command.
Zitat von: Dominik83 am 04 September 2016, 15:54:53
Hat jemand einen Tip?
Getrennte Devices anlegen oder eine readingsGroup könnten Alternativen sein.
Mit der optimized C009.ino https://raw.githubusercontent.com/ddtlabs/ESPEasy-Fork/optimized-_c009.ino/_C009.ino funktioniert der Hostname. Aber die Kommastellen werden genau so ignoriert und die Darstellung von Werten über 1000 wird weiterhin die wissenschaftliche Notation genutzt.
Dieser PoC ist auch nicht für den produktiven Betrieb gedacht.
Du steckst bestimmt auch USB Sticks in deinen Rechner, die Du auf der Straße findest? ;) ;)
Zitat von: dev0 am 04 September 2016, 19:21:21
Du steckst bestimmt auch USB Sticks in deinen Rechner, die Du auf der Straße findest? ;) ;)
Nein natürlich nicht, erst an den Firmenrechner! ;) ;)
Zitat von: dev0 am 04 September 2016, 19:21:21
Dieser PoC ist auch nicht für den produktiven Betrieb gedacht.
Zum Testen habe ich einen 2. Odroid mit Fhem.
Hi
I tested R126 and the new plugin 0.4.1
I have a bug I think. I got a temp/humidity sensor. I have set 1 decimal, and in the interface of espeasy I get 22.9, in fhem I get 22.89. With humidity it works fine.
regards Richard
Zitat von: dev0 am 04 September 2016, 18:29:36
Habe gerade gesehen, dass seit der R120 die mitgelieferte ArduinoJson Lib neu genug ist um float_with_n_digits() nutzen zu können. Kann ich mir aber erst im Laufe der nächsten Woche ansehen.
Das Problem mit der wissenschaftlichen Notation scheint bekannt zu sein. Ich habe mit deiner _C009.ino noch mal "gespielt" und schreibe die Werte der Sensoren erst in eine String-Variable und übergebe diese dann an Json. Bei mir werden dann alle Werte wie gewünscht dargestellt.
Die Probleme bzgl. Nachkommastellen und Ungenauigkeiten durch die wissenschaftliche Notation sollten gefixed sein. Dazu wird die aktuelle Version des _C009.ino Plugin benötigt.
Update: Das Plugin ist jetzt mit R128 vefügbar.
Der Pull Request wartet z.Z. auf die Übernahme in die ESPEasy Distribution (R128?). Vorab gibt es die Version hier.Tipp: Achtet beim Compilieren darauf, dass die ArduinoJson Library aktuell ist, sonst werden alle Werte zu "1". Die ArduinoJson Version, die der ESPEasy Version R120 (http://www.esp8266.nu/downloads/ESPEasy_R120.zip) beiliegt, reicht aber aus.
Weiterhin habe ich die Konvertierung (0,1 zu on,off) beim Device Typ "Switch" in das Modul verlagert. Diese Umwandlung kann nun mit dem neuen Attribut "readingSwitchText 0" abgeschaltet werden. Ohne das Attribut ändert sich nichts.
Das aktualisierte Modul liegt hier: https://github.com/ddtlabs/ESPEasy
Zitat
v 0.4.2
- more unique dispatch separator
- moved on|off translation for device type "SWITCH" from ESPEasy Software to this module.
- new attribute readingSwitchText
@kroonen: Do you need some translation?
Hallo,
zunächst einmal vielen Dank für die hervorragende Arbeit. Alles in allem bisher für mich der beste Ansatz für ESP... und Fhem. Eine Wunsch hätte ich noch. Aus Gründen der Sicherheit würde ich es gut finden, wenn die "on/off for timer" Funktion der FS20 Aktoren in espeasy integriert würde. Hierdurch wäre sicher gestellt, dass nach x Sekunden, sofern nicht ein neuer Trigger gesetzt wird, der adressierte GPIO auf low geht.
In meinem Anwendungsfall sieht das so aus:
Fenster- und Türsensor, sowie Thermostat schalten einen elektrischen Heizkörper ein/aus. Durch "on for timer" im FS20 Aktor wird sicher gestellt, dass bei fehlendem "Aus" die Heizung auf jeden Fall nach 120 Sekunden ausgeschaltet wird.
Grüße Jörg
Hallo,
habe mir nun die aktuelle Version des Fhem-Moduls auf mein Testsystem gezogen und bekomme beim Starten von Fhem folgende Log-Einträge:
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value $ident:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value $host:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value $ac:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value $as:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value $v in split at /opt/fhem/FHEM/34_ESPEasy.pm line 893.
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value $ac in string eq at /opt/fhem/FHEM/34_ESPEasy.pm line 905.
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value in string ne at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
2016.09.06 11:54:40 2: ESPEasy ESPBridge: autocreate is disabled (ident: deletereading||GPIO.*||undef||0)
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 912.
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value $ident:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value $host:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value $ac:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value $as:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value $v in split at /opt/fhem/FHEM/34_ESPEasy.pm line 893.
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value $ac in string eq at /opt/fhem/FHEM/34_ESPEasy.pm line 905.
[Tue Sep 6 11:54:40 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value in string ne at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
2016.09.06 11:54:41 2: ESPEasy ESPBridge: autocreate is disabled (ident: setreading||presence||absent||0)
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 912.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ident:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $host:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $as:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $v in split at /opt/fhem/FHEM/34_ESPEasy.pm line 893.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac in string eq at /opt/fhem/FHEM/34_ESPEasy.pm line 905.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 912.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ident:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $host:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $as:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $v in split at /opt/fhem/FHEM/34_ESPEasy.pm line 893.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac in string eq at /opt/fhem/FHEM/34_ESPEasy.pm line 905.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 912.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ident:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $host:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $as:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $v in split at /opt/fhem/FHEM/34_ESPEasy.pm line 893.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac in string eq at /opt/fhem/FHEM/34_ESPEasy.pm line 905.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 912.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ident:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $host:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $as:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $v in split at /opt/fhem/FHEM/34_ESPEasy.pm line 893.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac in string eq at /opt/fhem/FHEM/34_ESPEasy.pm line 905.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 912.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ident:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $host:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $as:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $v in split at /opt/fhem/FHEM/34_ESPEasy.pm line 893.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac in string eq at /opt/fhem/FHEM/34_ESPEasy.pm line 905.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 912.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ident:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $host:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $as:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $v in split at /opt/fhem/FHEM/34_ESPEasy.pm line 893.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac in string eq at /opt/fhem/FHEM/34_ESPEasy.pm line 905.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 912.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ident:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $host:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $as:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $v in split at /opt/fhem/FHEM/34_ESPEasy.pm line 893.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac in string eq at /opt/fhem/FHEM/34_ESPEasy.pm line 905.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 912.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ident:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $host:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $as:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $v in split at /opt/fhem/FHEM/34_ESPEasy.pm line 893.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac in string eq at /opt/fhem/FHEM/34_ESPEasy.pm line 905.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 912.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ident:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $host:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $as:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $v in split at /opt/fhem/FHEM/34_ESPEasy.pm line 893.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac in string eq at /opt/fhem/FHEM/34_ESPEasy.pm line 905.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 912.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ident:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $host:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $as:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $v in split at /opt/fhem/FHEM/34_ESPEasy.pm line 893.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac in string eq at /opt/fhem/FHEM/34_ESPEasy.pm line 905.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 912.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ident:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $host:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $as:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $v in split at /opt/fhem/FHEM/34_ESPEasy.pm line 893.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac in string eq at /opt/fhem/FHEM/34_ESPEasy.pm line 905.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 912.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ident:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $host:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $as:: in concatenation (.) or string at /opt/fhem/FHEM/34_ESPEasy.pm line 867.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $v in split at /opt/fhem/FHEM/34_ESPEasy.pm line 893.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ac in string eq at /opt/fhem/FHEM/34_ESPEasy.pm line 905.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 910.
[Tue Sep 6 11:54:41 2016] fhem.pl: Use of uninitialized value $ip in hash element at /opt/fhem/FHEM/34_ESPEasy.pm line 912.
Ein reload liefert allerdings keine Einträge. Komisch...
Grüße Jörg
PS: Das Testsystem ist immer eine aktueller Abzug vom Fhem Repository
(on|off)-for-timer ist bereits implementiert und heißt "pulse" bzw. "longpulse". Die Syntax könnte man auch mit dem Attribut eventMap anpassen.
out-of-the-box:
set <ESP> longpulse 15 on 2 #=>switch gpio15 on for 2 secsonds
mit eventMap z.B. so:
attr GPIO15 eventMap /longpulse 15 on:on-for-timer/longpulse 15 off:off-for-timer/
set GPIO15 on-for-timer 3 #=> switch gpio15 on for 3 seconds
Wie robust die Implementierung im ESPEasy ist kann ich nicht sagen. Da bin ich raus.
Zitat von: JoWiemann am 06 September 2016, 12:02:34
habe mir nun die aktuelle Version des Fhem-Moduls auf mein Testsystem gezogen und bekomme beim Starten von Fhem folgende
FHEM hattest Du nach dem Update neu gestartet?
Kann ich im Moment leider noch nicht nachvollziehen. Bitte setze die Bridge auf verbose 5 und poste dann das Log.
Könntest Du diese Modul Version einmal testen? Ich habe die Vermutung, dass sich Deine Perl Version etwas anders verhält als ich es erwartet habe ;(
Welche Perl Version verwendest Du ?
Edit: Link zur Testversion entfernt
Hallo,
Perl ist (Wheezy): This is perl 5, version 14, subversion 2 (v5.14.2) built for arm-linux-gnueabihf-thread-multi-64int
Und die Modulversion läuft :-)
Grüße Jörg
Zitat von: dev0 am 06 September 2016, 12:03:01
(on|off)-for-timer ist bereits implementiert und heißt "pulse" bzw. "longpulse". Die Syntax könnte man auch mit dem Attribut eventMap anpassen.
out-of-the-box:
set <ESP> longpulse 15 on 2 #=>switch gpio15 on for 2 secsonds
mit eventMap z.B. so:
attr GPIO15 eventMap /longpulse 15 on:on-for-timer/longpulse 15 off:off-for-timer/
set GPIO15 on-for-timer 3 #=> switch gpio15 on for 3 seconds
Wie robust die Implementierung im ESPEasy ist kann ich nicht sagen. Da bin ich raus.
Danke für die Info, habe ich einfach in EspEasy übersehen.
Grüße Jörg
Zitat von: JoWiemann am 06 September 2016, 13:01:55
Und die Modulversion läuft :-)
Danke für's Testen!
Habe die korrigierte Version in den master branch (https://github.com/ddtlabs/ESPEasy) eingecheckt.
Hallo,
Ich hätte mal eine Frage und zwar warum werden die Readings Namen im State auf 3 Zeichen gekürzt?
Sieht bei mir so aus:
DeviceOverview
ESPEasy_Sonoff1_SysInfo VCC:-1 Fre:22500 Rss:-45 Upt:1780
Readings
VCC -1 2016-09-06 13:56:30
freeRAM 22300 2016-09-06 13:57:31
presence present 2016-09-06 13:56:30
rssi -44 2016-09-06 13:57:32
state VCC:-1 Fre:22300 Rss:-44 Upt:1780 2016-09-06 13:57:32
uptime 1780 2016-09-06 13:56:22
Könnte man da nicht den vollen Namen nehmen?
Gruß
Carlos
Zitat von: carlos am 06 September 2016, 14:05:42
Könnte man da nicht den vollen Namen nehmen?
Je nach Länge der Readingnamen und Anzahl wird das sehr unschön. Typisch für FHEM wäre sogar nur der Anfangsbuchstabe des Readings.
Ich kann mir aber vorstellen die Länge über ein Attribut konfigurierbar zu machen.
ESPEasy R128 (https://github.com/ESP8266nu/ESPEasy) beinhaltet jetzt den letzten Stand des FHEM HTTP Plugings.
Heute morgen aktualisiert (Sonoff).
Wenn man Relais oder Schaltausgänge jetzt noch in ESPEasy bzw im Modul einfach automatisiert anlegen könnte ;)
Zitat von: oli82 am 07 September 2016, 11:12:41
Heute morgen aktualisiert (Sonoff).
Wenn man Relais oder Schaltausgänge jetzt noch in ESPEasy bzw im Modul einfach automatisiert anlegen könnte ;)
Hm, woher soll das Modul das wissen?! Der GPIO hat ja keine Peripherie Intelligenz.
Grüße Jörg
Gesendet von iPad mit Tapatalk
Das stimmt. ESPEasy währe da der bessere Ansatzpunkt.
Auch da scheitert es an der fehlenden "Intelligenz". Es gibt ja verschiedene ESP... mit einer unterschiedlichen Anzahl an GPIO. Erst durch die Parametrierung als Device wird dem GPIO eine Funktion zugewiesen. Selbst bei den Sonoff, wo der GPIO12 das Relais schaltet, können weitere GPIO für andere Zwecke definiert werden. Es müsste also dann ein in ESPEasy hinterlegtes Sonoff-Profil gepflegt werden, dass als Default im Source hinterlegt, oder nach dem ersten Start ausgewählt werden kann. Im Fhem Modul müsste dann auf ein festes Keyword reagiert werden und ein Sonoff per Autocreate angelegt werden. Ich denke, zu viel Aufwand. Man kann ja jetzt schon die Konfiguration eines ESP im ESPEasy ex- und importieren. In Fhem kann man Devices kopieren.
Grüße Jörg
Gesendet von iPad mit Tapatalk
Den 1. Beitrag dieses Threads habe ich gerade generalüberholt, damit er die aktuelle Entwicklung widerspiegelt.
Hallo.
Ich habe das Modul bei mir schon im produktiven Einsatz. Ich lese damit die Impulse der Gasuhr aus. Den ESP-03 und die Stromversorgung habe ich komplett in den Sensor gestopft. ;) Funktioniert einwandfrei. Danke auch vom mir für dieses Modul.
Jetzt lese ich gerade:
ZitatDen 1. Beitrag dieses Threads habe ich gerade generalüberholt, damit er die aktuelle Entwicklung widerspiegelt.
Danke erst einmal dafür. Jetzt habe ich den 1. Beitrag für mich mal durchgearbeitet. Das mit dem Attribut uniqIDs finde ich schon mal ne gute Sache. Leider finde ich in dem Modul diese Atribut nicht in der Auswahl. Ist hier die Doku an der Entwicklung vorbei galoppiert oder wo finde ich das Attribut?
Grüße Frank
Hi Zusammen,
ich habe nun mit dem Modul meine Garagentorsteuerung realisert - klasse vielen Dank!
Am ESP in der Garage hängt neben dem Relais für die Torsteuerung noch ein Temp-Sensor sowie ein weiterer Schalter der melden Soll ob das Tor grad "auf" oder "zu" ist.
Hier habe ich auch grad noch ein Problemchen.
Der schalter hängt auf GPIO 14 und zeigt im Webinterface des ESP (definiert als Switch input) auch richtig an ob der Schalter 0 oder 1 meldet nur irgendwie kommt das bei den readings im FHEM nicht an.
Das ESP Easy Modul habe ich vorab noch auf 4.3 geupdated
Eigentlich müsste der Wert eines "Switch Input" doch auch bei den readings im FHEM erscheinen, oder? In esp-ip/json sehe ich den Wert.
Viele Grüße und Danke vorweg
Edit: Es funktioniert nun...es lag an der alten Firmware!
Zitat von: majorshark am 09 September 2016, 13:08:48
Ist hier die Doku an der Entwicklung vorbei galoppiert oder wo finde ich das Attribut?
In der aktuellen Modul Version: https://github.com/ddtlabs/ESPEasy
Zitat von: Dominik83 am 09 September 2016, 13:26:28
Eigentlich müsste der Wert eines "Switch Input" doch auch bei den readings im FHEM erscheinen, oder?
Ja, so sollte es sein.
Zitat von: Dominik83 am 09 September 2016, 13:26:28
In esp-ip/json sehe ich den Wert.
Was ist esp-ip?
Das Modul kann natürlich nur Werte verarbeiten/anzeigen, die vom ESP auch gesendet werden. Also zuerst sicherstellen, dass die Werte auch gesendet werden: Log der Bridge auf 4 oder 5 hoch drehen und in den JSON String gucken ob die Werte gesendet werden.
Sollten die Werte in dem JSON String fehlen, dann auf ESP Seite das Problem suchen.
Sollten die Werte in den Logs erscheinen, aber vom Modul nicht angezeigt werden, dann bitte den verbose 5 Logauszug und je ein list von Bridge und Device hier posten.
Hey,
mit http://ip-meines-esp/json
sehe ich mir den Json string an,
in dem steht folgendes:
{"System":{
"Build": 120,
"Unit": 1,
"Uptime": 1551,
"Free RAM": 27464
},
"Sensors":[
{
"TaskName": "temp",
"temp": 24.63
},
{
"TaskName": "UT",
"UT": 1551.00
},
{
"TaskName": "rss",
"rss": -86.00
},
{
"TaskName": "tor",
"Switch": 1.00
}
]}
Dort gibt es den task "tor" mit dem value "switch".
Ich glaube aber einen Fehler gefunden zu haben..mein esp hat noch die Version 120 - wenn ich mich nicht täusche braucht das fhem modul aber die v. 128, oder?
Hier habe ich dann direkt noch eine Frage:
Die version 128 bzw. 129 gibt es ja nicht fertig kompiliert - wenn ich nun kompiliere und per ota update "merkt" der esp sich dann meine Einstellungen? Besonders im Bezug auf meine Wifi einstellungen wäre das für mich wichtig, da ich nicht sooo einfach an den verbauten ESP zum Flashen via USB dran komme.
Grüße und ein schönes Wochenende
Du benötigst min. R128.
Wenn ein Wert auf der ESP/json Webseite angezeigt wird, dann heißt das nicht zwangsläufig, dass er auch gesendet wird.
Update sollte so funktionieren, ich hatte bisher nie ein Problem beim Update.
Ich habe eine aktualisierte Modulversion (0.4.4) auf Github eingecheckt:
- Das Attribut setState bestimmt nun auch die Anzahl der Buchstaben, die in state für die Readingnamen verwendet werden. 0 schaltet dieses Feature weiterhin ab.
- Eine Perl Warnung behoben (Use of uninitialized value in string ne at 34_ESPEasy.pm line 9xx)
- Code und Command Reference aufgeräumt.
Es wird weiterhin mindestens die ESPEasy Version R128 vorausgesetzt.
https://github.com/ddtlabs/ESPEasy
Zitat von: max333 am 03 September 2016, 22:06:59
Des weiteren sollte die Zeile 199 im _P004. Dallas.ino ersetzt werde, damit auch die Temperatur vom DS1825 angezeigt wird:
if ((ROM[0] == 0x28 ) || (ROM[0] == 0x3b )) //DS18B20 or DS1825
Dein Pull Request ist gerade gemerged worden. Toll, dass Du Dich darum gekümmert hast.
Zitat
auch wenn´s ein bisschen OT ist:
Kennt jemand ein HOW-To wie man aus den Dateien aus github eine ota-flashbare .bin Datei erstellt?
Ich möchte dich bitten dazu einen eigenständigen Thread zu öffnen und den Beitrag aus diesem Thread zu löschen. Diese oder ähnliche Fragestellungen werden bei Einsteigern immer mal wieder auftauchen und sollten mMn getrennt behandelt werden, da das Thema je nach Kenntnisstand auch umfangreicher wird...
Ich hoffe auf Dein Verständnis.
Hallo
ich wollte, wie auf http://www.fhemwiki.de/wiki/Batterie%C3%BCberwachung (http://www.fhemwiki.de/wiki/Batterie%C3%BCberwachung) beschrieben ist, eine Überwachung der ESP einrichten
Dabei ist mir aufgefallen das die Zeit beim Status aktualisiert wird, obwohl der ESP nicht mehr angeschlossen ist.
Switch off 2016-09-09 13:57:53
presence absent 2016-09-11 19:58:53
state Swi:off 2016-09-11 19:58:53
Ist das so richtig?
Ob richtig oder falsch kann man so nicht sagen. Es ist im Moment aber so ;)
Schaue ich mir bei Gelegenheit an.
OK Danke.
Ich gehe halt immer erst einmal davon aus, das es so sein soll und ich es falsch verstehe. :)
Auch Danke für deine Arbeit
Du kannst auch das Attribut setState auf 0 setzen und dich selbst, mit einem userReading, um state/STATE kümmern.
Das kann ich so direkt nicht :d
Ich habe es erst einmal so gelöst, dass jedes ESP die Wlan Signalstärke sendet und die Funktion aus dem Wiki prüft einmal am Tag ob dieses Reading älter als 1 Stunde ist.
Hallo,
espeasy scheint bei mir über json für die Temperatur nur noch true zu senden, was auch angezeigt wird.
Über HTTP wird die richtige Temperatur geholt.
Das ist mit espeasy 128-131 der Fall.
Ist vielleicht meine json Installation imRaspi falsch ?
2016.09.15 12:43:39 4: ESPEasy ESPEasy_Poolabdeckung_Wassertemperatur: presence: present
2016.09.15 12:43:39 5: ESP_B dispatch Poolabdeckung_Wassertemperatur::192.168.1.127::1::1::setreading||presence||present||0
2016.09.15 12:43:39 4: ESPEasy ESP_B: dispatch: Poolabdeckung_Wassertemperatur::192.168.1.127::1::1::setreading||presence||present||0
2016.09.15 12:43:39 4: ESPEasy ESPEasy_Poolabdeckung_Wassertemperatur: Temperature: 1
2016.09.15 12:43:39 5: ESP_B dispatch Poolabdeckung_Wassertemperatur::192.168.1.127::1::1::setreading||Temperature||1||1
2016.09.15 12:43:39 4: ESPEasy ESP_B: dispatch: Poolabdeckung_Wassertemperatur::192.168.1.127::1::1::setreading||Temperature||1||1
2016.09.15 12:43:39 5: ESPEasy ESP_B: no basic authentication required
2016.09.15 12:43:39 4: ESPEasy ESP_B: data: {"module":"ESPEasy","version":"1.02","data":{"ESP":{"name":"Poolabdeckung","unit":0,"version":9,"build":131,"sleep":0,"ip":"192.168.1.127"},"SENSOR":{"0":{"deviceName":"Wassertemperatur","valueName":"Temperature","type":1,"value":true}}}}
2016.09.15 12:43:39 5: ESPEasy ESP_B: header: {'Connection' => 'close','Content-Length' => '238','GET' => '/fhem?cmd=setreading%20Poolabdeckung%20Temperature%2023.31 HTTP/1.1','Host' => '192.168.1.111'}
2016.09.15 12:43:38 5: ESPEasy ESP_B: accepted tcp connect <= 192.168.1.127:17303
2016.09.15 12:43:38 4: Connection accepted from ESP_B_192.168.1.127_17303
hier noch die esp Seite leider etwas schlecht dargestellt:
<>
Task Device Name Port IDX/Variable GPIO Values
Edit
1 Temperature - DS18b20 Wassertemperatur 28-ff-4b-98-3e-4-0-3d 2 GPIO-5 Temperature:
23.69
Edit
2 Switch input Relay 2 GPIO-4 Switch:
0
Edit
3 Switch input Taster 3 GPIO-14 Switch:
0
Edit
4
|
Deine Library ArduinoJson ist zu alt.
Vielen Dank
jetzt geht es
huhu ! :)
Ich stelle mich glaube ich irgendwie zu blöd an -.-
Ich möchte via FHEM auf meinem NodeMCU lediglich 5 GPIO Ports schalten. Ich habe folgendes gemacht.
- NodeMCU ( ESP Dev Board ) mit dem neuesten ESPEasy geflasht ( via Arduino ).
- ESPEasy Modul in FHEM eingefügt und Update durchgeführt.
- ESP Bridge wie im ersten Beitrag beschrieben erstellt.
Irgendwas scheint aber nicht richtig zu funktionieren bzw. ich bin vielleicht zu doof den ESP zu konfigurieren.
Ich habe den ESP nur einmal kurz dazu bekommen in FHEM ein Device zu erstellen.
- Autocreate ist an !
Ich habe auf dem ESP ein Switch Device erstellt und den entsprechenden GPIO auf Masse gezogen. Dann wurde ein Device im Room ESPEasy erstellt.
Tests mit einem DHT22 blieben allerdings erfolglos. Es wurde einfach keine Temperatur angezeigt in der Weboberfläche des ESP.
Wie auch immer..
Welche ist denn nun die einfachste Vorgehensweise um einfach 4 Devices / Buttons in FHEM zu erhalten um auf dem ESP jeweils für eine Sekunde ein GPIO auf Masse zu ziehen ?
Vielen Dank!
Zitat von: somebuddy am 19 September 2016, 07:24:29
Ich möchte via FHEM auf meinem NodeMCU lediglich 5 GPIO Ports schalten.
Ich habe auf dem ESP ein Switch Device erstellt und den entsprechenden GPIO auf Masse gezogen
...
um auf dem ESP jeweils für eine Sekunde ein GPIO auf Masse zu ziehen ?
Wieso ziehst Du einen GPIO auf Masse, wenn Du ihn über FHEM schalten möchtest?
Um GPIOs für einen Zeitraum zu schalten bietet ESPEasy die Befehle Pulse und LongPulse. Wie weiter oben schon beschrieben: https://forum.fhem.de/index.php/topic,55728.msg488460.html#msg488460
Zeige bitte ein verbose 4 Log und list der Bridge, jeweils in Code-Tags.
Zitat von: dev0 am 19 September 2016, 08:11:11
Wieso ziehst Du einen GPIO auf Masse, wenn Du ihn über FHEM schalten möchtest?
Das war nur zum Testen eines eingerichteten "Switch Device" im ESP Easy.
Vielen Dank. Alles klar.. reiche ich später nach.
Hello,
I'm a newbie with ESPEasy and FHEM
ESPEasy I set fine. I have ESP-01 only. DHT11 works. GPIO-0 switches the LED (http://192.168.100.138/control?cmd=GPIO,0,1)
But I do not know how to set it up FHEM.
I have this:
define espBridge ESPEasy bridge 8383
attr espBridge group ESPEasy Bridge
attr espBridge room ESPEasy
define ESPEasy_Teplomer_Obyvak_Teplomer ESPEasy 192.168.100.138 80 espBridge Teplomer_Obyvak_Teplomer
attr ESPEasy_Teplomer_Obyvak_Teplomer IODev espBridge
attr ESPEasy_Teplomer_Obyvak_Teplomer event-on-change-reading .*
attr ESPEasy_Teplomer_Obyvak_Teplomer group ESPEasy Device
attr ESPEasy_Teplomer_Obyvak_Teplomer room ESPEasy
attr ESPEasy_Teplomer_Obyvak_Teplomer stateFormat Temp: Temperature°C Hum: Humidity
define FileLog_ESPEasy_Teplomer_Obyvak_Teplomer FileLog /opt/fhem/log/ESPEasy_Teplomer_Obyvak_Teplomer-%Y.log ESPEasy_Teplomer_Obyvak_Teplomer
attr FileLog_ESPEasy_Teplomer_Obyvak_Teplomer logtype temp4hum4:Temp/Hum,text
define weblink_ESPEasy_Teplomer_Obyvak_Teplomer SVG FileLog_ESPEasy_Teplomer_Obyvak_Teplomer:weblink_ESPEasy_Teplomer_Obyvak_Teplomer:CURRENT
attr weblink_ESPEasy_Teplomer_Obyvak_Teplomer label "ESPEasy_Teplomer_Obyvak_Teplomer Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_ESPEasy_Teplomer_Obyvak_Teplomer room Plots
Data it collects but the plots are displayed.
The log file is this:
2016-09-28_07:46:03 ESPEasy_Teplomer_Obyvak_Teplomer Hum:23.00 Tem:19.00
2016-09-28_07:50:12 ESPEasy_Teplomer_Obyvak_Teplomer Humidity: 22.00
2016-09-28_07:50:12 ESPEasy_Teplomer_Obyvak_Teplomer Hum:22.00 Tem:19.00
2016-09-28_07:50:12 ESPEasy_Teplomer_Obyvak_Teplomer Temperature: 21.00
2016-09-28_07:50:12 ESPEasy_Teplomer_Obyvak_Teplomer Hum:22.00 Tem:21.00
2016-09-28_07:51:12 ESPEasy_Teplomer_Obyvak_Teplomer Temperature: 20.00
2016-09-28_07:51:12 ESPEasy_Teplomer_Obyvak_Teplomer Hum:22.00 Tem:20.00
2016-09-28_07:51:12 ESPEasy_Teplomer_Obyvak_Teplomer Humidity: 28.00
2016-09-28_07:51:12 ESPEasy_Teplomer_Obyvak_Teplomer Hum:28.00 Tem:20.00
2016-09-28_07:52:13 ESPEasy_Teplomer_Obyvak_Teplomer Humidity: 25.00
2016-09-28_07:52:13 ESPEasy_Teplomer_Obyvak_Teplomer Hum:25.00 Tem:20.00
2016-09-28_07:52:13 ESPEasy_Teplomer_Obyvak_Teplomer Temperature: 19.00
2016-09-28_07:52:13 ESPEasy_Teplomer_Obyvak_Teplomer Hum:25.00 Tem:19.00
2016-09-28_07:53:13 ESPEasy_Teplomer_Obyvak_Teplomer Humidity: 23.00
2016-09-28_07:53:13 ESPEasy_Teplomer_Obyvak_Teplomer Hum:23.00 Tem:19.00
2016-09-28_07:53:27 ESPEasy_Teplomer_Obyvak_Teplomer gpio 0 on
2016-09-28_07:56:13 ESPEasy_Teplomer_Obyvak_Teplomer Temperature: 20.00
2016-09-28_07:56:13 ESPEasy_Teplomer_Obyvak_Teplomer Hum:23.00 Tem:20.00
2016-09-28_07:56:13 ESPEasy_Teplomer_Obyvak_Teplomer Humidity: 26.00
2016-09-28_07:56:13 ESPEasy_Teplomer_Obyvak_Teplomer Hum:26.00 Tem:20.00
2016-09-28_07:57:13 ESPEasy_Teplomer_Obyvak_Teplomer Humidity: 23.00
2016-09-28_07:57:13 ESPEasy_Teplomer_Obyvak_Teplomer Hum:23.00 Tem:20.00
2016-09-28_07:57:13 ESPEasy_Teplomer_Obyvak_Teplomer Temperature: 19.00
2016-09-28_07:57:13 ESPEasy_Teplomer_Obyvak_Teplomer Hum:23.00 Tem:19.00
Could you please help me?
You wrote:
Zitat von: feryy am 28 September 2016, 08:06:51
But I do not know how to set it up FHEM.
define espBridge ESPEasy bridge 8383
define ESPEasy_Teplomer_Obyvak_Teplomer ESPEasy 192.168.100.138 80 espBridge Teplomer_Obyvak_Teplomer
define FileLog_ESPEasy_Teplomer_Obyvak_Teplomer FileLog /opt/fhem/log/ESPEasy_Teplomer_Obyvak_Teplomer-%Y.log ESPEasy_Teplomer_Obyvak_Teplomer
ESPEasy module is already set up correctly.
Zitat
2016-09-28_07:46:03 ESPEasy_Teplomer_Obyvak_Teplomer Hum:23.00 Tem:19.00
2016-09-28_07:50:12 ESPEasy_Teplomer_Obyvak_Teplomer Humidity: 22.00
Values are logged correctly.
Zitat
Data it collects but the plots are displayed.
I do not understand your problem, but I assume that your plots are NOT displayed. Right?
In this case it has nothing to do with ESPEasy module and I cannot help you because I do not know much about SVG module. But my hint is to use the graphical svg editor for simple plots.
To create your SVG:
define SVG_Teplomer_Obyvak_Teplomer SVG FileLog_ESPEasy_Teplomer_Obyvak_Teplomer:temp4hum4:CURRENT
Then, modify your layout with Plot Editor.
Sorry, I wrote it wrong :(
I have no problem with SVG. I have a problem with the interpretation put in SVG.
Zitat von: SusisStrolch am 28 September 2016, 12:49:21
To create your SVG:
define SVG_Teplomer_Obyvak_Teplomer SVG FileLog_ESPEasy_Teplomer_Obyvak_Teplomer:temp4hum4:CURRENT
Then, modify your layout with Plot Editor.
I tried to set it up but do not know how to edit the layout :( ad. attachment
The data is written good in the log file?
2016-09-29_06:37:40 ESPEasy_Teplomer_Obyvak_Teplomer Temperature: 18.00
2016-09-29_06:37:40 ESPEasy_Teplomer_Obyvak_Teplomer Hum:23.00 Tem:18.00
2016-09-29_06:37:40 ESPEasy_Teplomer_Obyvak_Teplomer Humidity: 24.00
2016-09-29_06:37:40 ESPEasy_Teplomer_Obyvak_Teplomer Hum:24.00 Tem:18.00
2016-09-29_06:43:41 ESPEasy_Teplomer_Obyvak_Teplomer Humidity: 23.00
2016-09-29_06:43:41 ESPEasy_Teplomer_Obyvak_Teplomer Hum:23.00 Tem:18.00
2016-09-29_06:43:41 ESPEasy_Teplomer_Obyvak_Teplomer Temperature: 19.00
2016-09-29_06:43:41 ESPEasy_Teplomer_Obyvak_Teplomer Hum:23.00 Tem:19.00
Zitat von: feryy am 29 September 2016, 06:46:15
The data is written good in the log file?
2016-09-29_06:37:40 ESPEasy_Teplomer_Obyvak_Teplomer Temperature: 18.00
2016-09-29_06:37:40 ESPEasy_Teplomer_Obyvak_Teplomer Hum:23.00 Tem:18.00
2016-09-29_06:37:40 ESPEasy_Teplomer_Obyvak_Teplomer Humidity: 24.00
Yes, the log file is fine. You may specify a range as [min:max] in svg editor so it looks better.
If there are more questions about SVG plots then feel free to open new post in a better fitting area. See: http://www.fhem.de/MAINTAINER.txt
Hallo Zusammen,
bin über einen Tip aus dem sonoff Fred hier her gekommen.
Habe mir einen sonoff Steckdosenadapter geflash, hat auch alles funktioniert.
Dann die Bridge angelegt und in der ESP WebGUI mal zum Testen RSI unter Devices.
Das Device wurde in Fhem angelegt und die RSSI Werte kommen an.
Soweit alles gut.
Wie bekomme ich jetzt aber das Relai geschalten?
Was muss ich da in der WebGUI unter Device anlegen und was in Fhem??
Zitat von: dev0 am 29 September 2016, 07:34:54
Yes, the log file is fine. You may specify a range as [min:max] in svg editor so it looks better.
If there are more questions about SVG plots then feel free to open new post in a better fitting area. See: http://www.fhem.de/MAINTAINER.txt
And maybe one last question :)
How to define for <ESP> (already measured temperature) switching GPIO?
I tried this but it does not work:
define ESPEasy_Teplomer_Obyvak_Teplomer ESPEasy 192.168.100.138 80 espBridge Teplomer_Obyvak_Teplomer
...
attr ESPEasy_Teplomer_Obyvak_Teplomer icon FS20.off
attr ESPEasy_Teplomer_Obyvak_Teplomer stateFormat GPIO0
attr ESPEasy_Teplomer_Obyvak_Teplomer eventMap /gpio 0 on:on/gpio 0 off:off/status gpio 0:check/
attr ESPEasy_Teplomer_Obyvak_Teplomer devStateIcon on:ios-on-green:off off:ios-off:on .*:ios-NACK:check
...
But this http://192.168.100.138/control?cmd=GPIO,0,1) works => Electrical wiring is correct.
If I would like to define a dummy device, and how?
Hallo,
Du solltest zunächst die GPIO als Switch im ESPEasy definieren. Wenn Du über die ersten zwei bis vier Seiten des Thread gehst, findest Du Definitionen für Attribute, damit Du die GPIO mit Buttons Switches kannst.
Gesendet von iPad mit Tapatalk
Hab es hin bekommen, vielen Dank.
Jetzt muss ich nur noch das Fhem Device "aufhübschen".
Super Modul! Vielen Dank!
Noch eine Frage dazu: der Knopf am Gerät selber geht ja jetzt nicht mehr. Kann ich den auch wieder irgendwie "reinkonfigurieren"?
Zitat von: Mitch am 29 September 2016, 09:55:18
Hoch eine Frage dazu: der Knopf am Gerät selber geht ja jetzt nicht mehr. Kann ich den auch wieder irgendwie "reinkonfigurieren"?
What you have defined the device in WebGUI? And how FHEM? You can make a screenshot, please?
List of the fhem device:
Internals:
.eventMapCmd on:noArg off:noArg check:noArg
DEF 192.168.0.50 80 ESPBridge sonoff1
ESPBridge_MSGCNT 28
ESPBridge_TIME 2016-09-29 10:26:41
HOST 192.168.0.50
IDENT sonoff1
IODev ESPBridge
LASTInputDev ESPBridge
MODULE_VERSION 0.4.4
MSGCNT 28
NAME ESPEasy_sonoff1
NR 973
PORT 80
STATE off
SUBTYPE device
TYPE ESPEasy
Readings:
2016-09-29 10:22:39 GPIO12 off
2016-09-29 10:22:39 GPIO12_mode output
2016-09-29 10:26:41 RSSI -55.00
2016-09-29 10:22:39 _lastAction GPIO 12 Set to 0
2016-09-29 10:23:16 presence present
2016-09-29 10:26:41 state GPI:off GPI:output RSS:-55.00
Helper:
urlcmd /control?cmd=
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 302
TRIGGERTIME 29.09.2016 10:28:17
Attributes:
DbLogExclude .*
IODev ESPBridge
devStateIcon on:ios-on-green:off off:ios-off:on absent:10px-kreis-rot:statusRequest .*:ios-NACK:check
event-on-change-reading .*
eventMap /gpio 12 on:on/gpio 12 off:off/status gpio 12:check/
group ESPEasy Device
stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"GPIO12","")}
verbose 0
Screenshot of WebGUI attached.
If I push the physical button, I can see it in the WebGUI.
But I would like to have the same functionality like original, so if I push the button, the relais will toggle.
Zitat von: Mitch am 29 September 2016, 09:55:18
Noch eine Frage dazu: der Knopf am Gerät selber geht ja jetzt nicht mehr. Kann ich den auch wieder irgendwie "reinkonfigurieren"?
Du Kannst in ESPEasy sog. Rules konfigurieren, also was soll passieren, wenn ein Event ausgelöst wird.
Ich hab meinen Sonoff leider gerade nicht online, hoffe aber, dass ich es noch richtig im Kopf habe:
on SW_1#Switch do
if [SW_1#Switch]=0
gpio,12,0
gpio,13,1
else
gpio,12,1
gpio,13,0
endif
endon
Zitat von: oli82 am 29 September 2016, 10:46:56
Du Kannst in ESPEasy sog. Rules konfigurieren, also was soll passieren, wenn ein Event ausgelöst wird.
Ich hab meinen Sonoff leider gerade nicht online, hoffe aber, dass ich es noch richtig im Kopf habe:
on SW_1#Switch do
if [SW_1#Switch]=0
gpio,12,0
gpio,13,1
else
gpio,12,1
gpio,13,0
endif
endon
Interesting.
It is possible to configure it through FHEM?
Click Button -> set state to FHEM -> defined notify detects status -> FHEM set GPIO's HIGHT
Because how else to read the status of the relay?
Zitat von: Mitch am 29 September 2016, 10:28:52
But I would like to have the same functionality like original, so if I push the button, the relais will toggle.
I think, the relay may not be right in WebGUI devices because it is output. See http://www.esp8266.nu/index.php/Relais
Zitat von: oli82 am 29 September 2016, 10:46:56
Du Kannst in ESPEasy sog. Rules konfigurieren, also was soll passieren, wenn ein Event ausgelöst wird.
Ich hab meinen Sonoff leider gerade nicht online, hoffe aber, dass ich es noch richtig im Kopf habe:
on SW_1#Switch do
if [SW_1#Switch]=0
gpio,12,0
gpio,13,1
else
gpio,12,1
gpio,13,0
endif
endon
Danke, aber irgendwie mag mein ESP die rules nicht, bzw. ignoriert sie einfach.
Habe zum Testen auch mal eine Rule angelegt, dass alles auf 0 geschalten wird beim Booten. Geht aber auch nicht?
So, habe das mit den Rules jetzt hinbekommen.
Leider merkt fhem nicht, dass ich manuell den Knopf gedrückt habe.
Kann/muss man da noch etwas einstellen? Oder ist das nicht möglich?
Hm, hast Du in den Relais Devices "send status " aktiviert?
Gesendet von iPhone mit Tapatalk
PS: Mit ESPEasy, Fhem, und Sonoff als Suchbegriffe in einer Suchmaschine wären auch alle Fragen beantwortet worden....
wenn Du send data meinst, ja
Wenn Du den Taster drückst, schaltet dann das Relais?
Grüße Jörg
Ja, Relais schaltet und LED leuchet, das passt alles.
Nur die Rückmeldung an fhem fehlt.
In der WebGUI von ESPEasy she ich auch die Zustandsänderung.
Hallo,
schau mal in die Readings vom Relais. Dort kannst Du sehen, dass der Status auf on / off wechselt. Es wird nur nicht in das STATE übernommen. Du kannst die Anzeige über das Attribut stateFormat ändern. Dort einfach eintragen:
{ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"value name in esp easy device","")}
Grüße Jörg
Nein, daran liegt es nicht.
Das stateFormat habe ich schon so eingerichtet.
Es wird aber das reading nicht aktualisiert.
Poste doch mal einen Screenshot von Deiner Devicedefinition im ESPEasy.
Grüße Jörg
Hier der list vom fhem Device:
Internals:
.eventMapCmd on:noArg off:noArg check:noArg
CHANGED
DEF 192.168.0.50 80 ESPBridge sonoff1
ESPBridge_MSGCNT 704
ESPBridge_TIME 2016-09-29 20:27:59
HOST 192.168.0.50
IDENT sonoff1
IODev ESPBridge
LASTInputDev ESPBridge
MODULE_VERSION 0.4.4
MSGCNT 704
NAME ESPEasy_sonoff1
NR 973
PORT 80
STATE off
SUBTYPE device
TYPE ESPEasy
Readings:
2016-09-29 20:25:36 GPIO12 off
2016-09-29 20:25:36 GPIO12_mode output
2016-09-29 20:27:59 RSSI -63.00
2016-09-29 20:25:36 _lastAction GPIO 12 Set to 0
2016-09-29 20:25:36 presence present
2016-09-29 20:27:59 state GPI:off GPI:output RSS:-63.00
Helper:
urlcmd /control?cmd=
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 305
TRIGGERTIME 29.09.2016 20:29:55
Attributes:
DbLogExclude .*
IODev ESPBridge
devStateIcon on:ios-on-green:off off:ios-off:on absent:10px-kreis-rot:statusRequest .*:ios-NACK:check
event-on-change-reading presence,GPIO12
eventMap /gpio 12 on:on/gpio 12 off:off/status gpio 12:check/
group ESPEasy Device
stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"GPIO12","")}
verbose 0
und anbei die Screenshots.
2 sonoff haben das "Problem"
Mal eine kurze Zwischenfrage. Wo definiert man denn die Rules. Oder gibt es das noch nicht in der R120?
Grüße
Och ne, schon mal das ESPEasy Wiki konsultiert. Muss man unter Tools/Advanced ganz weit unten das Häckchen setzen.
http://www.esp8266.nu/index.php/Tutorial_Rules
Grüße Jörg
Zitat von: Mitch am 29 September 2016, 20:31:02
Hier der list vom fhem Device
2 sonoff haben das "Problem"
Das sieht eigentlich Ok aus. Sind die Sonoff unterschiedlich benannt. Wurde für jedes Sonoff ein eigenes Fhem Device angelegt? Siehst Du im Device das Reading Relais?
Und, ich würde idx für jedes device mit einer anderen Indexnummer belegen.
Grüße Jörg
Ach so. Trotzdem Danke für Deine Antwort.
@Mitch: Das gezeigte list mit dem IDENT sonoff1 passt nicht zu den Screenshots. Welche ESPEasy Version verwendest Du? Zeig bitte ein list der Bridge und stelle bridge und device auf verbose 4 und zeig dann das Log eines Schaltvorgangs. Ich schaue mir das dann morgen früh an, wenn ich am Rechner bin.
Version R120
List der Bridge:
Internals:
CONNECTS 908
DEF bridge 8383
FD 42
HOST bridge
MODULE_VERSION 0.4.4
NAME ESPBridge
NR 972
PASS *************
PORT 8383
STATE initialized
SUBTYPE bridge
TYPE ESPEasy
USER mbj1703
.clientArray:
ESPEasy
Readings:
2016-09-29 10:18:03 state initialized
Helper:
urlcmd /control?cmd=
192.168.0.50:
presence absent
192.168.0.52:
presence absent
Outdated:
192.168.0.50 1
192.168.0.52 1
Uniqid:
Attributes:
DbLogExclude .*
group Zentrale
icon it_network
room Zentrale
uniqIDs 0
verbose 0
Log mit verbose 4:
2016.09.29 21:55:16.020 4: ESPEasy ESPBridge: data:
2016.09.29 21:55:16.018 4: Connection accepted from ESPBridge_192.168.0.50_1830
2016.09.29 21:55:16.014 4: ESPEasy ESPEasy_sonoff1: _lastAction: GPIO 12 Set to 0
2016.09.29 21:55:16.009 4: ESPEasy ESPBridge: dispatch: sonoff1::192.168.0.50::1::1::setreading||_lastAction||GPIO 12 Set to 0||0
2016.09.29 21:55:15.980 4: ESPEasy ESPEasy_sonoff1: GPIO12: off
2016.09.29 21:55:15.973 4: ESPEasy ESPBridge: dispatch: sonoff1::192.168.0.50::1::1::setreading||GPIO12_state||0||10
2016.09.29 21:55:15.972 4: ESPEasy ESPEasy_sonoff1: GPIO12_mode: output
2016.09.29 21:55:15.966 4: ESPEasy ESPBridge: dispatch: sonoff1::192.168.0.50::1::1::setreading||GPIO12_mode||output||0
2016.09.29 21:55:15.965 4: ESPEasy ESPEasy_sonoff1: presence: present
2016.09.29 21:55:15.959 4: ESPEasy ESPBridge: dispatch: sonoff1::192.168.0.50::1::1::setreading||presence||present||0
2016.09.29 21:55:15.919 3: ESPEasy ESPBridge: send gpio,12,0 to sonoff1 (192.168.0.50)
2016.09.29 21:55:15.918 3: ESPEasy ESPEasy_sonoff1: set ESPEasy_sonoff1 gpio 12 off
2016.09.29 21:55:14.255 4: ESPEasy ESPBridge: data:
2016.09.29 21:55:14.253 4: Connection accepted from ESPBridge_192.168.0.50_27276
2016.09.29 21:55:14.217 4: ESPEasy ESPEasy_sonoff1: _lastAction: GPIO 12 Set to 1
2016.09.29 21:55:14.213 4: ESPEasy ESPBridge: dispatch: sonoff1::192.168.0.50::1::1::setreading||_lastAction||GPIO 12 Set to 1||0
2016.09.29 21:55:14.186 4: ESPEasy ESPEasy_sonoff1: GPIO12: on
2016.09.29 21:55:14.182 4: ESPEasy ESPBridge: dispatch: sonoff1::192.168.0.50::1::1::setreading||GPIO12_state||1||10
2016.09.29 21:55:14.181 4: ESPEasy ESPEasy_sonoff1: GPIO12_mode: output
2016.09.29 21:55:14.177 4: ESPEasy ESPBridge: dispatch: sonoff1::192.168.0.50::1::1::setreading||GPIO12_mode||output||0
2016.09.29 21:55:14.175 4: ESPEasy ESPEasy_sonoff1: presence: present
2016.09.29 21:55:14.171 4: ESPEasy ESPBridge: dispatch: sonoff1::192.168.0.50::1::1::setreading||presence||present||0
2016.09.29 21:55:13.966 3: ESPEasy ESPBridge: send gpio,12,1 to sonoff1 (192.168.0.50)
Was ich noch habe sind eine Menge Fehler im Log:
2016.09.29 15:33:46.686 1: PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/34_ESPEasy.pm line 537.
2016.09.29 15:33:46.686 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/34_ESPEasy.pm line 534.
Du benötigst mindestens ESPEasy R128, so kann ich das nicht supporten. Das steht aber auch in der command ref. Ab der nächsten Modulversion werden ältere ESPEasy Version gar nicht mehr funktionieren.
Ok, hatte auf der Wiki Seite die R120 als letzte stable gefunden.
Da werde ich mich morgen mal dran machen.
Du musst dir die Version aus Git holen und über die Arduino IDE entweder direkt flashen oder eine OTA bin erzeugen.
Offtopic: Habt ihr auch den Fehler, dass der Compiler an folgender Stelle hängen bleibt?
reply += F("<TR><TD>Core Version:<TD>");
reply += ESP.getCoreVersion();
Nein, das Compilieren läuft hier problemlos durch (R128 - R133 getestet).
ZitatGetestete Entwicklungsumgebung:
- Arduino IDE 1.6.9
- Boardmanager -> http://arduino.esp8266.com/stable/package_esp8266com_index.json (http://arduino.esp8266.com/stable/package_esp8266com_index.json) -> esp8266 by ESP8266 Community version 2.3.0
- Libraries aus dem neusten ESPEasy Paket (z.Z R120 (http://www.esp8266.nu/downloads/ESPEasy_R120.zip))
- ab ESPEasy R109 wird die pubsubclient library 2.6+ benötigt -> https://github.com/knolleary/pubsubclient (https://github.com/knolleary/pubsubclient)
- ab ESPEasy R120 wird die ArduinoJson library 5.6.4+ benötigt -> https://github.com/bblanchon/ArduinoJson (https://github.com/bblanchon/ArduinoJson)
Ich möchte euch aber bitten dieses Thema nicht in diesem Thread zu diskutieren. Ein neuer Thread macht an dieser Stelle mehr Sinn, da es auch Nutzer betrifft, die ESPEasy über andere IOs nutzen.
Hallo,
kann jemand die .bin für den OTA Flash zur Verfügung stellen?
Bin leider momentan ohne PC.
Flashen klappt ja auch über Handy gut.
Sent from my iPhone using Tapatalk
Für welches ESP-Board?
Gesendet von iPhone mit Tapatalk
Sorry,
ESP-12E.
Reicht das ?
Danke schonmal.
Natürlich ohne Gewähr ;)
Läuft bei mir aber fehlerfrei
Hat der 12E nicht nen 4mb flash Chip ?
Oder ist das in dem Fall unwichtig ?
Sent from my iPhone using Tapatalk
Eine aktualisierte Version des Modules ist hier zu finden: https://github.com/ddtlabs/ESPEasy/tree/Staging
Wäre nett, wenn sie jemand testen könnte bevor ich sie in den master branch verschiebe.
Release Notes 0.4.8:
- ESP Presence-Erkennung von einem http request auf Readingsalter umgestellt, um auch ESPs im deep sleep zu erkennen. Falls 'uniqIDs' disabled ist, dann gibt es den zusätzlichen Presence Status 'partial absent (ip)', der die ausgefallenen ESP-IPs listet. Der Zeitstempel des Presence Reading ändert sich bei Abwesenheit nicht mehr.
- Attribut 'Interval' kann auf 0 gestezt werden um die Presence-Erkennung und GPIO-Polling abzuschalten.
- Attribut 'adjustValue' kann zum Anpassen von Sensorwerten genutzt werden. Simple Arithme̱tik oder Perl Code.
- Internal 'ESP_CONFIG' zeigt Details des ESP an (ESPEasy Version, deep sleep, unit no).
- ESPEasy Versionen ohne JSON support werden nicht mehr unterstützt.
- Logging angepasst
Edit:
- Devices, die per autocreate angelegt werden, erhalten kein 'event-on-change-reading' Attribut mehr.
Zitat von: deluxe41 am 30 September 2016, 10:17:04
Hat der 12E nicht nen 4mb flash Chip ?
Ist schon richtig. 1MB SPIFFS, 4MB Flash
@Dev0
Lade ich mir gleich mal und werde testen
So, habe jetzt beide sonoff auf R133 geflashed und das Modul Release 0.4.8 installiert, alle Devices aus fhem gelöscht und von Scratch angefangen.
Jetzt läuft alles wie gewünscht, vielen Dank für eure Hilfe!
@dev0
Modul funktioniert bei mir, hat aber wohl ein Problem mit dem übermittelten RSSI Wert:
ESPEasy ESPEasy_Wemos_RSSI: Unkonwn command received via dispatch
Trat das einmalig auf oder erscheint der Logeintrag regelmäßig? Falls regelmäßig, dann wäre ein verbose 5 log mit diesem Phänomen und list von bridge/device hilfreich.
Fehler gefunden!
RSSI benötigt ein Value Name, da sonst als state ":" gesendet wird und das mag das Modul nicht.
list Wemos:
Internals:
DEF 192.168.100.23 80 ESPBridge Wemos_RSSI
ESPBridge_MSGCNT 82
ESPBridge_TIME 2016-09-30 13:59:36
ESP_CONFIG 192.168.100.23:R133,S0,U2
HOST 192.168.100.23
IDENT Wemos_RSSI
INTERVAL 300
IODev ESPBridge
LASTInputDev ESPBridge
MODULE_VERSION 0.4.8
MSGCNT 82
NAME ESPEasy_Wemos_RSSI
NR 393
PORT 80
STATE RSS:-64.00
SUBTYPE device
TYPE ESPEasy
UNIQIDS 1
Readings:
2016-09-30 13:59:36 RSSI -64.00
2016-09-30 13:59:36 presence present
2016-09-30 13:59:36 state RSS:-64.00
Helper:
urlcmd /control?cmd=
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 303
TRIGGERTIME 30.09.2016 14:01:02
Internals:
192.168.100.23:
BUILD 133
SLEEP 0
UNIT 2
Presence:
192.168.100.23 present
Received:
RSSI 192.168.100.23
Attributes:
IODev ESPBridge
group ESPEasy Device
room ESPEasy
list Bridge:
Internals:
CONNECTS 495
DEF bridge 8383
FD 58
HOST bridge
MODULE_VERSION 0.4.8
NAME ESPBridge
NR 359
PASS not defined yet !!!
PORT 8383
STATE initialized
SUBTYPE bridge
TYPE ESPEasy
USER not defined yet !!!
Readings:
2016-09-30 11:14:53 state initialized
Helper:
urlcmd /control?cmd=
Received:
192.168.100.23:
build 133
espName Wemos
sleep 0
unit 2
Attributes:
group ESPEasy Bridge
room CUL_HM
mit Value Name 1:
2016.09.30 14:03:35 3: ESPEasy ESPEasy_Wemos_RSSI: set ESPEasy_Wemos_RSSI statusrequest
2016.09.30 14:03:35 5: ESPEasy ESPEasy_Wemos_RSSI: RemoveInternalTimer(HASH(0x8bd1dc0), ESPEasy_statusRequest)
2016.09.30 14:03:35 5: ESPEasy ESPEasy_Wemos_RSSI: InternalTimer(1475237015.76984+300+3.65349356278495, ESPEasy_statusRequest, HASH(0x8bd1dc0))
2016.09.30 14:03:37 5: ESPEasy ESPEasy_Wemos_RSSI: internal unit: 2
2016.09.30 14:03:37 5: ESPEasy ESPEasy_Wemos_RSSI: internal sleep: 0
2016.09.30 14:03:37 5: ESPEasy ESPEasy_Wemos_RSSI: internal build: 133
2016.09.30 14:03:37 4: ESPEasy ESPEasy_Wemos_RSSI: RSSI: -64.00
ohne Value:
2016.09.30 14:05:38 5: ESPEasy ESPEasy_Wemos_RSSI: internal unit: 2
2016.09.30 14:05:38 5: ESPEasy ESPEasy_Wemos_RSSI: internal sleep: 0
2016.09.30 14:05:38 5: ESPEasy ESPEasy_Wemos_RSSI: internal build: 133
2016.09.30 14:05:38 4: ESPEasy ESPEasy_Wemos_RSSI: :
2016.09.30 14:05:38 1: ESPEasy ESPEasy_Wemos_RSSI: Unkonwn command received via dispatch
2016.09.30 14:06:10 3: ESPEasy ESPEasy_Wemos_RSSI: set ESPEasy_Wemos_RSSI statusrequest
2016.09.30 14:06:10 5: ESPEasy ESPEasy_Wemos_RSSI: RemoveInternalTimer(HASH(0x8bd1dc0), ESPEasy_statusRequest)
2016.09.30 14:06:10 5: ESPEasy ESPEasy_Wemos_RSSI: InternalTimer(1475237170.5783+300+3.12780397419496, ESPEasy_statusRequest, HASH(0x8bd1dc0))
Edit: Ach, Unknown ist falsch geschrieben ;)
Hallo,
vielleicht kann mir jemand helfen, ich bekomme nach dem definieren der ESP-Bridge die folgenden Fehler
2016.09.30 17:21:35 1: reload: Error:Modul 34_ESPEasy deactivated:
Not enough arguments for main::InternalTimer at ./FHEM/34_ESPEasy.pm line 332, near "$hash)"
Not enough arguments for main::InternalTimer at ./FHEM/34_ESPEasy.pm line 792, near "$hash)
"
Too many arguments for main::RemoveInternalTimer at ./FHEM/34_ESPEasy.pm line 1222, near ""ESPEasy_statusRequest") "
Not enough arguments for main::InternalTimer at ./FHEM/34_ESPEasy.pm line 1231, near "$hash)"
2016.09.30 17:21:35 0: Not enough arguments for main::InternalTimer at ./FHEM/34_ESPEasy.pm line 332, near "$hash)"
Not enough arguments for main::InternalTimer at ./FHEM/34_ESPEasy.pm line 792, near "$hash)
"
Too many arguments for main::RemoveInternalTimer at ./FHEM/34_ESPEasy.pm line 1222, near ""ESPEasy_statusRequest") "
Not enough arguments for main::InternalTimer at ./FHEM/34_ESPEasy.pm line 1231, near "$hash)"
Poste dein define Aufruf, die Ausgabe vom Befehl version und die Version vom ESPEasy Modul und der ESPEasy Software. Code Tags verwenden (Button mit dem #).
Deine Frage hat geholfen vielen Dank, ich habe ein upgrade und restart gemacht, jetzt geht alles.
Zitat von: oli82 am 30 September 2016, 09:58:55
Natürlich ohne Gewähr ;)
Läuft bei mir aber fehlerfrei
Tausend dank, hat geklappt ;)
Sent from my iPhone using Tapatalk
Zitat von: oli82 am 30 September 2016, 14:06:47
Fehler gefunden!
RSSI benötigt ein Value Name
Alle Sensorwerte benötigen einen Value Name. Hätte eigentlich auch durch einen Logeintrag gemeldet werden sollen, ist aber beim Umbau des Dispatch an das logische Device unwirksam geworden. Werde ich morgen korrigieren.
Danke.
Eine Frage hab ich aber noch. Ist das so gewollte, dass der Value Name angeschnitten wird? Statt RSSI wird nur RSS im Reading ausgegeben.
Zitat von: HelmutN am 30 September 2016, 18:38:22
Deine Frage hat geholfen vielen Dank, ich habe ein upgrade und restart gemacht, jetzt geht alles.
Das war auch meine Vermutung, aber dann muss Deine Installation schon fast antik gewesen sein ;) Ich konnte mich nur noch schemenhaft an die internalTimer Änderungen erinnern.
@oli82: wird nur im state reading gekürzt, läßt sich mit dem Attribut setState konfigurieren. Commandref lesen ;)
Zitat von: oli82 am 30 September 2016, 14:06:47
Fehler gefunden!
RSSI benötigt ein Value Name
Die aktualisierte Modul Version 0.4.9 liegt wieder im 'staging branch (https://github.com/ddtlabs/ESPEasy/tree/Staging)'.
Release Notes:
0.4.9 - fix check of empty device name, value name and values in received data
- do not process any data and log it continuously if ESPEasy Version
is too old. This will prevent wrong data and simplify support.
Mir ist gerade ein kleiner(?) Schönheitsfehler aufgefallen:
das Modul verwendet das Attribut 'setState' zum Einstellen der Länge im state-reading.
Dies kollidiert vom Namen mit der configDB, da es ja auch den Befehl "setstate" gibt.
2016.10.01 15:13:05 1: configDB: Usage: setstate <name> <state>
where <name> is a single device name, a list separated by komma (,) or a regexp. See the devspec section in the commandref.html for details.
Im log tauchen ständig diese Mitteilungen auf:
2016.10.01 15:51:49 5: No IO device or WriteFn found for ESPbridge_192.168.254.122_XXXXX
2016.10.01 15:51:53 5: ESPEasy ESPbridge_192.168.254.122_XXXXX: ESPbridge_192.168.254.122_XXXXX deleted
wobei XXXXX variiert:
2016.10.01 15:58:13 5: ESPEasy ESPbridge_192.168.254.122_26206: ESPbridge_192.168.254.122_26206 deleted
2016.10.01 15:58:16 5: ESPEasy ESPbridge_192.168.254.122_23965: ESPbridge_192.168.254.122_23965 deleted
2016.10.01 15:58:16 5: ESPEasy ESPbridge_192.168.254.122_22965: ESPbridge_192.168.254.122_22965 deleted
2016.10.01 15:58:18 5: ESPEasy ESPbridge_192.168.254.122_6452: ESPbridge_192.168.254.122_6452 deleted
2016.10.01 15:58:18 5: ESPEasy ESPbridge_192.168.254.122_1804: ESPbridge_192.168.254.122_1804 deleted
2016.10.01 15:58:19 5: ESPEasy ESPbridge_192.168.254.122_4486: ESPbridge_192.168.254.122_4486 deleted
2016.10.01 15:58:20 5: ESPEasy ESPbridge_192.168.254.122_22382: ESPbridge_192.168.254.122_22382 deleted
2016.10.01 15:58:24 5: ESPEasy ESPbridge_192.168.254.122_8861: ESPbridge_192.168.254.122_8861 deleted
2016.10.01 15:58:24 5: ESPEasy ESPbridge_192.168.254.122_24114: ESPbridge_192.168.254.122_24114 deleted
2016.10.01 15:58:24 5: ESPEasy ESPbridge_192.168.254.122_1983: ESPbridge_192.168.254.122_1983 deleted
2016.10.01 15:58:28 5: ESPEasy ESPbridge_192.168.254.122_5028: ESPbridge_192.168.254.122_5028 deleted
2016.10.01 15:58:28 5: ESPEasy ESPbridge_192.168.254.122_6318: ESPbridge_192.168.254.122_6318 deleted
2016.10.01 15:58:28 5: ESPEasy ESPbridge_192.168.254.122_6698: ESPbridge_192.168.254.122_6698 deleted
2016.10.01 15:58:28 5: ESPEasy ESPbridge_192.168.254.122_8566: ESPbridge_192.168.254.122_8566 deleted
2016.10.01 15:58:30 5: ESPEasy ESPbridge_192.168.254.122_1156: ESPbridge_192.168.254.122_1156 deleted
2016.10.01 15:58:30 5: ESPEasy ESPbridge_192.168.254.122_31933: ESPbridge_192.168.254.122_31933 deleted
Zitat von: SusisStrolch am 01 Oktober 2016, 15:22:35
Mir ist gerade ein kleiner(?) Schönheitsfehler aufgefallen:
das Modul verwendet das Attribut 'setState' zum Einstellen der Länge im state-reading.
Dies kollidiert vom Namen mit der configDB, da es ja auch den Befehl "setstate" gibt.
2016.10.01 15:13:05 1: configDB: Usage: setstate <name> <state>
where <name> is a single device name, a list separated by komma (,) or a regexp. See the devspec section in the commandref.html for details.
Mir Verlaub gesagt ist das Quatsch, da kollidiert nichts. Welches Problem configDB da hat weiss ich nicht, es hat aber nichts mit ESPEasy oder dem Attribut setState zu tun. 'setstate' ist davon abgesehen auch kein configDB Befehl, sondern ein globales fhem command.
Zitat von: SusisStrolch am 01 Oktober 2016, 16:46:20
2016.10.01 15:51:53 5: ESPEasy ESPbridge_192.168.254.122_XXXXX: ESPbridge_192.168.254.122_XXXXX deleted
wobei XXXXX variiert
Das sind die child devices der Bridge, die zum Empfangen der ESP Nachrichten benötigt werden. Wenn Du den log level auf debug drehst, dann werden sie angezeigt. In der folgenden Modul Version habe ich die Logzeile zwar geändert, es wird sie aber weiterhin geben.
Zitat von: SusisStrolch am 01 Oktober 2016, 16:46:20
2016.10.01 15:51:49 5: No IO device or WriteFn found for ESPbridge_192.168.254.122_XXXXX
Diese Meldung bzw. das IOWrite an das bridge device habe ich abgestellt. Ich hatte nicht berücksichtigt, dass die temporären child Devices auch gelöscht werden. Danke für den Hinweis. Das wird sich nebenbei auch auf das hier berichtete Verhalten auswirken: https://forum.fhem.de/index.php/topic,58321.msg497339.html#msg497339 , da die Datei uniqueID jetzt nicht mehr so oft gelesen wird.
Die aktualisierte Version 0.5 des Modules habe ich wieder erst in den staging branch gelegt: https://github.com/ddtlabs/ESPEasy/tree/Staging (Edit: korrigiert)
Release Notes 0.5.0:
Zitat
- eval JSON decoding in http response
- removed Authorization String from debug log
- combined internals logging
- more detailed debug log (verbose 5, child bridge)
- check for temporary bridge device in deleteFn and do no IOWrite
see: https://forum.fhem.de/index.php/topic,55728.msg497366.html#msg497366
- added check that fhem.pl is new enough (11000/2016-03-05)
see: https://forum.fhem.de/index.php/topic,55728.msg497094.html#msg497094
Zitat von: dev0 am 02 Oktober 2016, 12:43:14
Die aktualisierte Version 0.5 des Modules habe ich wieder erst in den staging branch gelegt: https://github.com/ddtlabs/ESPEasy/tree/master
Schaut gut aus. Danke
Die Module Version 0.5 liegt hier https://github.com/ddtlabs/ESPEasy/tree/Staging im staging branch und nicht, wie ursprünglich geschrieben, im master branch.
Sorry.
Funktioniert soweit vielen Dank dafür!
Allerdings tauchen bei mir bei jeder Aktualisierung der Devices folgende Meldungen im Log auf!
2016.10.03 08:14:03.804 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/34_ESPEasy.pm line 534.
2016.10.03 08:14:03.806 3: stacktrace:
2016.10.03 08:14:03.807 3: main::__ANON__ called by ./FHEM/34_ESPEasy.pm (534)
2016.10.03 08:14:03.809 3: main::ESPEasy_Read called by fhem.pl (3221)
2016.10.03 08:14:03.810 3: main::CallFn called by fhem.pl (671)
2016.10.03 08:14:03.812 1: PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/34_ESPEasy.pm line 537.
2016.10.03 08:14:03.813 3: stacktrace:
2016.10.03 08:14:03.814 3: main::__ANON__ called by ./FHEM/34_ESPEasy.pm (537)
2016.10.03 08:14:03.816 3: main::ESPEasy_Read called by fhem.pl (3221)
2016.10.03 08:14:03.817 3: main::CallFn called by fhem.pl (671)
2016.10.03 08:14:03.820 1: PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/34_ESPEasy.pm line 537.
2016.10.03 08:14:03.821 3: stacktrace:
2016.10.03 08:14:03.822 3: main::__ANON__ called by ./FHEM/34_ESPEasy.pm (537)
2016.10.03 08:14:03.823 3: main::ESPEasy_Read called by fhem.pl (3221)
2016.10.03 08:14:03.824 3: main::CallFn called by fhem.pl (671)
V5 Log
2016.10.03 08:26:07.567 4: ESPEasy espBridge: dispatch: wemos3::192.168.1.19::1::1::setreading||Uptime||1142.00||0
2016.10.03 08:26:07.567 5: espBridge dispatch wemos3::192.168.1.19::1::1::setreading||Uptime||1142.00||0
2016.10.03 08:26:09.536 4: Connection accepted from espBridge_192.168.1.19_32347
2016.10.03 08:26:09.538 5: ESPEasy espBridge: accepted tcp connect <= 192.168.1.19:32347
2016.10.03 08:26:09.542 5: ESPEasy espBridge: header: {'Connection' => 'close','GET' => '/fhem?cmd=setreading%20wemos3%20RSSI%20-68.00 HTTP/1.1','Host' => '192.168.1.101'}
2016.10.03 08:26:09.544 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/34_ESPEasy.pm line 534.
2016.10.03 08:26:09.546 3: stacktrace:
2016.10.03 08:26:09.547 3: main::__ANON__ called by ./FHEM/34_ESPEasy.pm (534)
2016.10.03 08:26:09.548 3: main::ESPEasy_Read called by fhem.pl (3221)
2016.10.03 08:26:09.550 3: main::CallFn called by fhem.pl (671)
2016.10.03 08:26:09.551 4: ESPEasy espBridge: data:
2016.10.03 08:26:09.554 1: PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/34_ESPEasy.pm line 537.
2016.10.03 08:26:09.555 3: stacktrace:
2016.10.03 08:26:09.556 3: main::__ANON__ called by ./FHEM/34_ESPEasy.pm (537)
2016.10.03 08:26:09.557 3: main::ESPEasy_Read called by fhem.pl (3221)
2016.10.03 08:26:09.559 3: main::CallFn called by fhem.pl (671)
2016.10.03 08:26:09.560 1: PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/34_ESPEasy.pm line 537.
2016.10.03 08:26:09.561 3: stacktrace:
2016.10.03 08:26:09.562 3: main::__ANON__ called by ./FHEM/34_ESPEasy.pm (537)
2016.10.03 08:26:09.563 3: main::ESPEasy_Read called by fhem.pl (3221)
2016.10.03 08:26:09.564 3: main::CallFn called by fhem.pl (671)
2016.10.03 08:26:09.566 5: ESPEasy espBridge: no basic authentication required
2016.10.03 08:26:09.568 4: ESPEasy espBridge: received cmd:setreading device:wemos3 reading:RSSI value:-68.00
2016.10.03 08:26:09.569 4: ESPEasy espBridge: dispatch: wemos3::192.168.1.19::1::1::setreading||RSSI||-68.00||0
2016.10.03 08:26:09.570 5: espBridge dispatch wemos3::192.168.1.19::1::1::setreading||RSSI||-68.00||0
Hallo,
bei mir werden die ESP-Devices mit ihren Readings angelegt, sie geben jedoch nur alle 1 zurück.
ESPEasy_WeMos2_DHT
Hum:1 Tem:1
ESPEasy_WeMos2_RSSI
RSS:1
ESPEasy_WeMos2_Uptime
Upt:1
ESPEasy_wittyrelaisoled_LDR
Ana:1
ESPEasy_wittyrelaisoled_taster
Swi:on
edit: problem gelöst: es lag hier dran -> - ab ESPEasy R120 wird die ArduinoJson library 5.6.4+ benötigt -> https://github.com/bblanchon/ArduinoJson
Hm also beim Build 133 von ESPEasy bekomme ich pro Wert ein neues Device angelegt.
Bei den 120 Build werden die Readings richtig unter einem Device angelegt. Ist das so gewollt?
Zitat von: fh168 am 03 Oktober 2016, 09:57:41
bei mir werden die ESP-Devices mit ihren Readings angelegt, sie geben jedoch nur alle 1 zurück.
Deine ArduinoJson Library ist zu alt. Siehe ersten Beitrag.
Zitat von: P.A.Trick am 03 Oktober 2016, 10:13:24
Bei den 120 Build werden die Readings richtig unter einem Device angelegt. Ist das so gewollt?
R120 wird von dem Modul nicht unterstützt. Ab der aktuellen Modulversion fange ich das auch mit einer Warnung im log ab und Devices werden nicht angelegt/aktualisiert.
Zitat von: P.A.Trick am 03 Oktober 2016, 10:13:24
Hm also beim Build 133 von ESPEasy bekomme ich pro Wert ein neues Device angelegt.
Siehe bitte in den ersten Beitrag zum Attribut uniqIDs und/oder in die commandref. Daraus sollte hervorgehen wie Werte den FHEM Devices zugeordnet werden. Wenn es nicht klar wird, dann melde dich bitte noch einmal und wir verbessern gemeinsam die Beschreibung.
Puh ehrlich gesagt habe ich jetzt wirklich lange gebraucht um zu kapieren wie das funktioniert.
Also erst einmal habe ich das Attribut uniqIDs bei der Bridge auf 0 gesetzt.
Danach habe ich die IDX Values bei den Devices gesetzt (>0).
Beim Device Namen habe ich dann den Namen gesetzt.
Ok, wenn man es einmal verstanden hat ist es ok, aber einfach ist das ehrlich gesagt nicht.
Naja, jetzt will ich nicht meckern sondern mich noch einmal für das tolle Modul bedanken.
Jetzt kann ich wenigstens mein OLED Display schick ansteuern. Vielen lieben Dank dafür und
allen die daran mitgearbeitet haben! Ihr seid die Besten!
Ich habe die Staging Verison in den master branch eingecheckt: https://github.com/ddtlabs/ESPEasy
Damit wird die Version auch automatisch aktualisiert, wenn das Repository ins Update eingebunden wurde (update add https://raw.githubusercontent.com/ddtlabs/ESPEasy/master/controls_ESPEasy.txt).
Änderungen 0.44 <-> 0.51
Zitat
- eval JSON decoding in http response
- removed Authorization String from debug log
- combined internals logging
- more detailed debug log (verbose 5, child bridge)
- check for temporary bridge device in deleteFn and do no IOWrite
see: https://forum.fhem.de/index.php/topic,55728.msg497366.html#msg497366
- added check that fhem.pl is new enough (11000/2016-03-05)
see: https://forum.fhem.de/index.php/topic,55728.msg497094.html#msg497094
- improved generell loggin for more easy support
Zitat von: P.A.Trick am 03 Oktober 2016, 11:55:33
Naja, jetzt will ich nicht meckern sondern mich noch einmal für das tolle Modul bedanken.
Das hat mit mekern nix zu tun. Wenn Du es besser beschreiben kannt, dann ist ein Patch für die commandref gerne gesehen.
Zitat von: dev0 am 03 Oktober 2016, 12:02:45
Das hat mit mekern nix zu tun. Wenn Du es besser beschreiben kannt, dann ist ein Patch für die commandref gerne gesehen.
Hm nein man muss es halt lesen und verstehen! ;-) Ich habe mir nur eben überlegt ob eine bebilderte Anleitung helfen würde.
Was hälst du von einem Wiki Eintrag?
BTW: Ich fände es noch genial, wenn die ESP Easy Version in einem Reading angezeigt werden würde!?
Zitat von: dev0 am 03 Oktober 2016, 11:59:06
Ich habe die Staging Verison in den master branch eingecheckt: https://github.com/ddtlabs/ESPEasy
Damit wird die Version auch automatisch aktualisiert, wenn das Repository ins Update eingebunden wurde (update add https://raw.githubusercontent.com/ddtlabs/ESPEasy/master/controls_ESPEasy.txt).
Änderungen 0.44 <-> 0.51
Leider bekomme ich auch mit dieser Version eine Warnung!
2016.10.03 12:19:41.135 4: ESPEasy espBridge_192.168.1.22_17858: child device deleted
2016.10.03 12:19:46.427 4: Connection accepted from espBridge_192.168.1.19_31419
2016.10.03 12:19:46.431 1: PERL WARNING: Use of uninitialized value in substitution (s///) at ./FHEM/34_ESPEasy.pm line 569.
2016.10.03 12:19:46.432 3: stacktrace:
2016.10.03 12:19:46.433 3: main::__ANON__ called by ./FHEM/34_ESPEasy.pm (569)
2016.10.03 12:19:46.434 3: main::ESPEasy_Read called by fhem.pl (3221)
2016.10.03 12:19:46.435 3: main::CallFn called by fhem.pl (671)
2016.10.03 12:19:46.438 5: ESPEasy espBridge_192.168.1.19_31419: received header: {'Authorization' => undef,'Connection' => 'close','Content-Length' => '214','Host' => '192.168.1.101'}
2016.10.03 12:19:46.438 5: ESPEasy espBridge_192.168.1.19_31419: received content: {"module":"ESPEasy","version":"1.02","data":{"ESP":{"name":"wemos3","unit":0,"version":9,"build":133,"sleep":0,"ip":"192.168.1.19"},"SENSOR":{"0":{"deviceName":"wemos3","valueName":"RSSI","type":1,"value":"-67"}}}}
2016.10.03 12:19:46.442 4: ESPEasy espBridge_192.168.1.19_31419: no basic authentication required
2016.10.03 12:19:46.443 4: ESPEasy espBridge_192.168.1.19_31419: send http close '200 OK'
2016.10.03 12:19:46.447 5: ESPEasy espBridge_192.168.1.19_31419: dispatch: wemos3::192.168.1.19::1::1::0::i||unit||0||0|||i||sleep||0||0|||i||build||133||0|||r||RSSI||-67||1
2016.10.03 12:19:46.448 5: espBridge dispatch wemos3::192.168.1.19::1::1::0::i||unit||0||0|||i||sleep||0||0|||i||build||133||0|||r||RSSI||-67||1
2016.10.03 12:19:46.499 4: ESPEasy espBridge_192.168.1.19_31419: child device deleted
Ok es liegt an der fehlenden User/Pass Kombi. Jetzt habe ich die mal gesetzt und die Warnung ist weg!
Zitat von: P.A.Trick am 03 Oktober 2016, 11:55:33
Also erst einmal habe ich das Attribut uniqIDs bei der Bridge auf 0 gesetzt.
Das Attribut 'uniqIDs' muss nur disabled werden, wenn Du Daten von mehreren ESPs in 1 FHEM Device laufen lassen möchtest. Sonst reicht es aus die 'ESP Device Namen' (nicht den 'ESP Namen'!) identisch zu benennen. Dabei muss man nur darauf auchten, dass die 'Value Namen' alle unterschiedlich sind. Wenn nicht nötig, dann sollte man das Attribut uniqIDs nicht setzen, da sonst nicht mehr eindeutig festgestellt werden kann an welches Devices z.B. ein Befehl ala 'set gpio...' gesendet werden soll. Die wahrscheinlich bessere Alternative zum uniqIDs=0 ist eine zusätzliche readingsGroup. Im Nachhinein wollte ich das im Modul aber nicht mehr ändern um Anwender nicht zuverärgern, die das Attribut bereits nutzen.
Zitat von: P.A.Trick am 03 Oktober 2016, 11:55:33
Danach habe ich die IDX Values bei den Devices gesetzt (>0).
Das ist für das Modul eigentlich uninteressant, aber es scheint ESPEasy Plugins zugeben, die keine Werte schicken, wenn der Wert auf 0 steht.
Zitat von: P.A.Trick am 03 Oktober 2016, 12:16:56
Was hälst du von einem Wiki Eintrag?
Eigentlich nichts, da viele Wiki Beiträge nach einer gewissen Zeit nicht mehr aktuell sind und es keiner merkt. Eine ausführliche commandref sollte das aber abdecken.
Zitat von: P.A.Trick am 03 Oktober 2016, 12:16:56
BTW: Ich fände es noch genial, wenn die ESP Easy Version in einem Reading angezeigt werden würde!?
Das sollte in der aktuellen Modulversion im Internal ESP_CONFIG angezeigt werden.
Zitat von: P.A.Trick am 03 Oktober 2016, 12:21:02
Leider bekomme ich auch mit dieser Version eine Warnung!
Schaue ich mir gleich an, ich vermute, dass Du keine 'basic authentication' verwendest.
Zitat von: P.A.Trick am 03 Oktober 2016, 12:21:02
Leider bekomme ich auch mit dieser Version eine Warnung!
2016.10.03 12:19:46.431 1: PERL WARNING: Use of uninitialized value in substitution (s///) at ./FHEM/34_ESPEasy.pm line 569.
Habe die Version 0.52 in master branch eingecheckt, die die Warnung, zur nicht gesetzten 'basic authorization', nicht ausgibt.
Kannst Du das bitte kurz testen?
Zitat von: dev0 am 03 Oktober 2016, 12:46:58
Habe die Version 0.52 in master branch eingecheckt, die die Warnung, zur nicht gesetzten 'basic authorization', nicht ausgibt.
Kannst Du das bitte kurz testen?
Klappt! Vielen Dank!
Ich habe die aktualisierte Version 0.5.3 auf Github eingecheckt: https://github.com/ddtlabs/ESPEasy
Zitat
- fixed: PERL WARNING: Use of uninitialized value in substitution (s///) at ./FHEM/34_ESPEasy.pm
- fixed: PERL WARNING: Ambiguous use of -time resolved as -&time() at ./FHEM/34_ESPEasy.pm
- attr adjustValue: reading can be a regexp
- code cleanup
Hallo,
erstmal vielen Dank für das Modul habe das mal mit meinem NodeMCU getestet und funktioniert wunderbar.
Jetzt habe ich aber ein Problem"chen" mit dem WeMOS D1:
Der übermittelt irgendwie "true" anstatt den Wert von uptime und WiFi.
Muss ich einen anderen Sketch nehmen für die WeMOS D1?
Die NodeMCU sind mit dem gleichen Sketch (nur anderes Device) geflasht und laufen direkt.
Modul Version 0.54
ESPEasy 135
Zitat von: mutanwulf am 11 Oktober 2016, 23:58:53
Der übermittelt irgendwie "true" anstatt den Wert von uptime und WiFi.
Da mir nur eine Ursache dafür bekannt ist, ist es schwer zu glauben, dass Du die selbe Binärdatei benutzt: Die ArduinoJson Library ist veraltet.
Kontrolliere das bitte noch einmal. Hier (http://www.esp8266.nu/downloads/ESPEasy_R137_RC1.zip) gibt es ESPEasy R137 RC1 auch als fertiges Image.
Hallo
wo ist eigentlich der Unterschied zwischen Wemos und Nodemcu
hab da irgendwie nichts gescheites im Netz gefunden ....
Zitat von: Franz Tenbrock am 12 Oktober 2016, 09:32:56
Hallo
wo ist eigentlich der Unterschied zwischen Wemos und Nodemcu
hab da irgendwie nichts gescheites im Netz gefunden ....
Gute Frage! Schaue einfach mal hier rein: http://frightanic.com/iot/comparison-of-esp8266-nodemcu-development-boards/
Zitat von: dev0 am 12 Oktober 2016, 05:48:49
Da mir nur eine Ursache dafür bekannt ist, ist es schwer zu glauben, dass Du die selbe Binärdatei benutzt: Die ArduinoJson Library ist veraltet.
Kontrolliere das bitte noch einmal. Hier (http://www.esp8266.nu/downloads/ESPEasy_R137_RC1.zip) gibt es ESPEasy R137 RC1 auch als fertiges Image.
Ich hatte den ESPEasy bei mir kompiliert aber auf 2 verschiedenen Rechnern.
Kaum die ArduinoJson aktualisiert schon gehts ;)
Danke
Einer der Unterschiede zwischen WeMOS und NodeMCU ist, das die WeMOS wesentlich kleiner und "stackable" ist. Für den WeMOS gibt es Relais, Temperatur, Feuchte- und Enwicklungsboard als steckbaren Aufsatz.
dann sollten wir uns das in Waltrop mal genau anschauen ..
der Ultraschallsensor in der Zisterne tut das was er soll ;D
Hab noch 2 nodemcus
hast du wemos über?
Freu mich schon auf das Treffen....
Bin hier gerade mit beschäftigt
https://forum.fhem.de/index.php?topic=58904.new#new
Der Abfallkalender schickt mir emails 8)
Ich bringe mal ein oder zwei WEMOS mit!
Hallo zusammen,
jetzt hab ich doch nochmal mein NodeMCU Dev-Board ausgepackt und schnell nen OLED Display + DHT22 drangesteckt.
Geflashed habe ich R137 RC1 vom ESPEasy.
Soweit so gut, das Display zeigt mir jetzt schön die Temperatur und Luftfeuchtigkeit an.
Danach habe ich dein Modul importiert, die Bridge konfiguriert und es wurde auch direkt automatisch ein neues Device "ESP_DEV_DHT22" angelegt ("ESP_DEV" ist der Name vom ESP, "DHT22" der Name vom DHT22 Device in ESPEasy).
Das einzige Problem was ich habe:
Die Readings "Temperature" und "Humidity" sind jeweils mit "true" gefüllt und werden auch regelmäßig damit aktualisiert.
Was mache ich falsch?
Gruß
Hast du in EspEasy in den device-Einstellungen ganz unten auch ein ValueName vergeben?
Ohne das ging es bei mir auch nicht.
Vom ValueName werden auch nur die ersten 3 Zeichen übernommen
Deine ArduinoJson Library ist zu alt. Siehe ersten Beitrag.
Grüße Jörg
Zitat von: SlvrStrko4 am 15 Oktober 2016, 11:32:57
Die Readings "Temperature" und "Humidity" sind jeweils mit "true" gefüllt und werden auch regelmäßig damit aktualisiert.
Man darf in diesem Thread auch lesen, nicht nur schreiben ;)
https://forum.fhem.de/index.php/topic,55728.msg502724.html#msg502724
https://forum.fhem.de/index.php/topic,55728.msg498026.html#msg498026
https://forum.fhem.de/index.php/topic,55728.msg491287.html#msg491287
https://forum.fhem.de/index.php/topic,55728.msg473220.html#msg473220
Zitat von: homeum am 15 Oktober 2016, 11:56:27
Vom ValueName werden auch nur die ersten 3 Zeichen übernommen
Das ist quatsch, ist mit dem Attribut setState einstellbar und betrifft nur state und nicht die regulären Readings.
Zitat von: JoWiemann am 15 Oktober 2016, 11:57:38
Deine ArduinoJson Library ist zu alt. Siehe ersten Beitrag.
Danke für Deine Unterstützung im Kampf gegen Mindmühlen ;)
Hallo,
also ich habe die ArduinoJson Library 5.6.4 und PubSubClient 2.6
Ich hatte es im ersten Post so verstanden als würde man >=5.6.4 brauchen und >=2.6 (also schon gelesen aber ich war davon ausgegangen dass es passt).
Ich packe dann mal die jeweils letzten Versionen rein und flashe den ESP neu.
Danke für die Hilfe
---
edit:
Ich hatte den Thread nach "true" durchsucht, scheinbar hat Chrome mich hier im Stich gelassen, sorry ;-)
---
edit2:
Ok ich hab jetzt das ganze mit neuer ArduinoJson kompiliert und geflashed => klappt, danke :-)
Zitat von: dev0 am 15 Oktober 2016, 12:01:39
ist mit dem Attribut setState einstellbar und betrifft nur state und nicht die regulären Readings.
Aha!
Danke für den Hinweis
Zitat von: JoWiemann am 15 Oktober 2016, 11:57:38
Deine ArduinoJson Library ist zu alt. Siehe ersten Beitrag.
Grüße Jörg
Hallo,
habe leider auch das Problem das bei meinem Temperatursensor DS18B20 nur true anstatt der Temperatur angezeigt wird.
Habe bereits das "ESPEasy R137 RC1als fertiges Image" per Wifi update aufgespielt.
Wie kann ich die ArduinoJson Library aktualisieren?
Güsse Jens
Ich kann nicht ausschließen, dass das fertige Image eine alte Lib enthält, ist aber eher unwahrscheinlich.
Zeig mal ein list der Bridge, in Code Tags bitte (# Button).
Hallo,
hier wie ich hoffe die richtige Information:
Internals
CONNECTS
900
DEF
bridge 8383
FD
15
HOST
bridge
NAME
Witty
NR
1087
PASS
not defined yet !!!
PORT
8383
STATE
initialized
SUBTYPE
bridge
TYPE
ESPEasy
USER
not defined yet !!!
VERSION
0.54
Readings
state
initialized
2016-10-16 20:48:02
Witty
Attributes
group
ESPEasy Bridge
deleteattr
room
ESPEasy
deleteattr
Probably associated with
ESPEasy_Witty_01_Temp_Schwarz
T:true
ESPEasy
ESPEasy_Witty_01_ldr
Ana:true
ESPEasy
Grüsse Jens
Nein, die Info reicht nicht. list siehe: http://fhem.de/commandref.html#list
Edit:
list Witty
in die FHEM Eingabezeile eingeben.
Hallo,
jetzt aber oder?
Internals:
CONNECTS 1596
DEF bridge 8383
FD 15
HOST bridge
NAME Witty
NR 1087
PASS not defined yet !!!
PORT 8383
STATE initialized
SUBTYPE bridge
TYPE ESPEasy
USER not defined yet !!!
VERSION 0.54
Readings:
2016-10-16 20:48:02 state initialized
Helper:
Received:
192.168.113.254:
build 137
espName Witty_01
sleep 0
unit 143
Attributes:
group ESPEasy Bridge
room ESPEasy
Internals:
CFGFN
DEF 192.168.113.254 80 Witty Witty_01_Temp_Schwarz
ESP_CONFIG 192.168.113.254:R137,S0,U143
HOST 192.168.113.254
IDENT Witty_01_Temp_Schwarz
INTERVAL 300
IODev Witty
LASTInputDev Witty
MSGCNT 625
NAME ESPEasy_Witty_01_Temp_Schwarz
NR 1380
PORT 80
STATE T:true
SUBTYPE device
TYPE ESPEasy
UNIQIDS 1
VERSION 0.54
Witty_MSGCNT 625
Witty_TIME 2016-10-16 22:28:12
Readings:
2016-10-16 22:28:12 T true
2016-10-16 21:12:54 Tem true
2016-10-16 22:25:24 presence present
2016-10-16 22:25:24 state T:true
Helper:
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 306
TRIGGERTIME 16.10.2016 22:30:29
Internals:
192.168.113.254:
BUILD 137
SLEEP 0
UNIT 143
Presence:
192.168.113.254 present
Received:
T 192.168.113.254
Attributes:
IODev Witty
group ESPEasy Device
room ESPEasy
Vielen Dank Jens
Dann scheint das fertige R137RC1 Image tatsächlich mit der alten ArduinoJson Lib kompiliert worden zu sein. Dann eben selbst kompilieren. Die ArduinoJson Lib im R137RC1 Paket, ist neu genug, das hatte ich mal getestet.
Welche bin Datei hast Du genau benutzt?
Kannst Du bitte noch ein verbose 5 log mit einer Datenübertragung hier posten, dann würde ich das an die ESPEasy Entwickler melden.
attr ESPEasy_Witty_01_Temp_Schwarz verbose 5
Edit:
Das Log brauchst Du nicht mehr posten, da ich es gerade nachgestellt habe. Die aktuelle R140_RC2 verhält sich ebenfalls so, wenn man die kompilierten Images verwendet. Den ESPEasy Entwicklern habe das kurz geschildert...
Im ESPEasy R140_RC3 Paket befinden sich nun Images, die mit der aktuellen ArduinoJson Library gebaut wurden. Die 4MB Variante habe ich bereits erfolgreich getestet. Vielleicht mag ja jemand die anderen Images noch testen? Die aktuelle Version R140_RC3 ist hier (http://www.esp8266.nu/index.php/Main_Page#Stable) zu finden.
Zitat von: dev0 am 17 Oktober 2016, 13:36:56
Im ESPEasy R140_RC3 Paket befinden sich nun Images, die mit der aktuellen ArduinoJson Library gebaut wurden.
Die Libraries, die im R140_RC3 Paket angehängt sind, sind aber immer noch
Source\Libraries\ArduinoJson\library.propertiesversion=5.6.4In github ist aber schon v5.6.7 ...
Gruß PeMue
Werde ich den Entwicklern mitteilen, wobei der beschiebene Bug ab der Version 5.6.4 gefixed ist.
Vielen Dank für's genaue hingucken ;)
Zitat von: dev0 am 17 Oktober 2016, 14:03:17
Werde ich den Entwicklern mitteilen, wobei der beschiebene Bug ab der Version 5.6.4 gefixed ist.
Die war aber auch schon im ESPEasy_R140_RC2.zip mit drin ;)
Gruß PeMue
Die sind ja noch chaotischer als wir hier ;)
Hallo,
die neue Version funktioniert! :) :) :) :) :)
VIELEN DANK!!!!!!!
Zitat von: dev0 am 17 Oktober 2016, 14:17:55
Die sind ja noch chaotischer als wir hier ;)
Unmöglich! ;-)
Hallo Leute,
ich finde das thema mit den ESP8266 ganz interessant.
Ich würde gerne den ESP in verbindung mit BME280 benutzten.
Hat jemand Erfahrung mit der Batterielebensdauer bei solch einer Kombination?
Wollte zwei AA Batterien benutzten.
Hat jemand noch ein Tip zu einem günstigen, WAF tauglichen Gehäuse?
Gruß Robert
Zitat von: no_Legend am 18 Oktober 2016, 08:02:29
Ich würde gerne den ESP in verbindung mit BME280 benutzten.
Hat jemand Erfahrung mit der Batterielebensdauer bei solch einer Kombination?
Wollte zwei AA Batterien benutzten.
Ca. 50-60 Tage wenn du alle 5 Minuten die Daten abrufst und versendest. Kann auch kürzer oder länger werden, je nach dem welche Hardware du genau verwendest.
Zitat von: sbiermann am 18 Oktober 2016, 08:25:16
Ca. 50-60 Tage wenn du alle 5 Minuten die Daten abrufst und versendest. Kann auch kürzer oder länger werden, je nach dem welche Hardware du genau verwendest.
Danke für die Antwort.
Das ist aber nicht wirklich lange.
Vll sollte ich doch dafür die Homematic sender direkt nehmen.
Oder auf den ESP32 warten, der soll noch niedrigeren Energieverbrauch haben.
Zitat von: sbiermann am 18 Oktober 2016, 11:14:19
Oder auf den ESP32 warten, der soll noch niedrigeren Energieverbrauch haben.
ist da auch eine espeasy unterstützung geplant?
Wie sieht es denn mit der Laufzeit bei nem LIPO mit 200mAh oder 2400mAh aus?
Ich denke ein Polling von allen 15min sollte eigentlich reichen.
Ich will Ihn als Innenraum Sensor benutzen.
Luftdruck brauch ich jetzt nicht unbedingt. Denke aber mal das macht bei der laufzeit wohl nichts aus. Oder lieg ich da falsch?
Gruß Robert
Zitat von: no_Legend am 18 Oktober 2016, 11:29:01
ist da auch eine espeasy unterstützung geplant?
Das kann Dir Martinus im ESPEasy Forum beantworten.
ESP32, Batterielaufzeiten, etc. soll in diesem Thread bitte kein Thema werden. Hier geht es um das ESPEasy Modul.
Zitat von: dev0 am 17 Oktober 2016, 13:36:56
Im ESPEasy R140_RC3 Paket befinden sich nun Images, die mit der aktuellen ArduinoJson Library gebaut wurden.
Ich habe mal mit der ArduinoJson Library 5.6.7 kompiliert, konnte aber leider noch nicht testen (siehe Anhang, die SPIFFS Größen weiß ich leider nicht mehr).
Gruß PeMue
Ich habe an meinem ESP ein DHT22 angeschlossen. Die gemessenen werte kann ich nun unter http://"espIP"/devices sehen.
wie kann ich diese nun mit fhem abfragen?
Befehle an den ESP mit fhem senden funktioniert schon.
hier noch mein code aus der fhem.cfg:
###ESPEasy###
define ESPBridge ESPEasy bridge 8383
attr ESPBridge group ESPEasy Bridge
attr ESPBridge room ESPEasy
define ESP01 ESPEasy 192.168.2.106 80 ESPBridge ESP01
attr ESP01 IODev ESPBridge
attr ESP01 room ESPEasy
Zitat von: jan4321 am 19 Oktober 2016, 18:08:52
Ich habe an meinem ESP ein DHT22 angeschlossen. Die gemessenen werte kann ich nun unter http://"espIP"/devices sehen.
wie kann ich diese nun mit fhem abfragen?
Befehle an den ESP mit fhem senden funktioniert schon.
Wie hast Du denn den DHT22 im ESPEasy als Device definiert?
Grüße Jörg
Zitat von: JoWiemann am 19 Oktober 2016, 18:31:26
Wie hast Du denn den DHT22 im ESPEasy als Device definiert?
Grüße Jörg
folgendermaßen sieht die übersicht aus:
Hast Du auch Send Data angeklickt? Und setze bitte einen Namen für value.
Grüße Jörg
Zitat von: JoWiemann am 19 Oktober 2016, 19:00:10
Hast Du auch Send Data angeklickt? Und setze bitte einen Namen für value.
Grüße Jörg
Send Data ist aktiviert.
Nur ist mir nicht klar, wie und wo ich die Daten in FHEM abgreifen kann.
hier nochmal die Einstellungen:
Das Modul legt automatisch entsprechende Devices in Fhem an. Du musst also eigentlich gar nichts weiteres tun.
Grüße Jörg
PS: Findest Du etwas im Log von Fhem?
Nach mal PS. Welche ESPEasy Version benutzt Du und hast Du das aktuelle Fhem Modul installiert. Irgendwie passt was nicht zusammen.
Grüße Jörg
Zitat von: JoWiemann am 19 Oktober 2016, 19:10:50
Das Modul legt automatisch entsprechende Devices in Fhem an. Du musst also eigentlich gar nichts weiteres tun.
Grüße Jörg
PS: Findest Du etwas im Log von Fhem?
Also neue Devices wurden bei mir nirgendwo angelegt. (habe ich auch noch nie erlebt, dass etwas selbsständig Devices anlegt)
Im Log stand leider auch nichts zu ESPEasy (verbouse 3)
PS. ich benutze build 140 auf einem nodemcu und das fhem modul ist Version 0.54
nochmal PS. ;) ich habe den Fehler gefunden: Ich habe beim einrichten vergessen, auf dem ESP den controller zu konfigurieren...
Ich glaube, du hast noch das alte Modul. Nimm doch bitte die aktuellen Versionen, sowohl ESPEasy als auch des Fhem Moduls aus dem ersten Post.
Grüße Jörg
Zitat von: JoWiemann am 19 Oktober 2016, 19:29:11
... sowohl ESPEasy ...
ESPEasy R140 (https://forum.fhem.de/index.php?action=dlattach;topic=55728.0;attach=59984)
Gruß PeMue
Hallo,
anbei ein paar Infos, falls jemand die neue Sonoff dual nutzen möchte: http://support.iteadstudio.com/support/discussions/topics/11000006870
Grüße Jörg
Sonoff pow, eine experimentelle Implementation: https://github.com/arendst/Sonoff-MQTT-OTA-Arduino/tree/master/sonoff
Grüße Jörg
Hi,
ich hab einen DHT22 am ESP, im ESP Web wird mir auch Temperatur und Feuchte angezeigt.
Aber im (automatisch angelegten) Device bekomm ich nur für beide Werte nur eine 1
Humidity
1
2016-10-21 19:44:51
Temperature
1
2016-10-21 19:44:51
presence
present
2016-10-20 20:15:26
state
Hum:1 Tem:1
2016-10-20 20:15:26
Jemnad einen Tipp wonach ich schauen könnte?
Danke für die Hilfe und Gruß
Timo
Welche ESPEasy Version hast Du und ist die richtige Json Lib compiliert worden?
Gesendet von iPhone mit Tapatalk
Hallo Jörg,
also die Build Version 140 und die Json Bibliothek in der Arduino IDE wird mir als 5.6.7 angezeigt.
Hatte zum Versuchen auch mal die 139 drauf mit gleichem Ergebnis.
Danke & Gruß
Timo
Wenn die Werte auf der ESP Webseite korrekt angezeigt werden, aber als 1 oder true übertragen werden, dann liegt es an einer zu alten ArduinoJson Library. Ob die Werte schon falsch übertragen werden siehst du im Log mit verbose 5. Wahrscheinlich hast du mehrere Versionen der Library installiert.
Die Werte der Sensoren werden immer direkt nach den 'Value Names' übertragen:
Zitat
BA_SEN1::192.168.30.148::1::1::1::i||unit||4||0|||i||sleep||0||0|||i||build||140||0|||r||humidity||39.8||2|||r||temperature||20.9||2
Hi,
tatsächlich zwei Json-libs ....
Jatzt klappts! Danke für die schnelle und korrekte Fehleranalyse 8)
Gruß
Timo
Zitat von: lonzo am 22 Oktober 2016, 16:50:42
tatsächlich zwei Json-libs ....
Ich trenne die verschiedenen Versionen dadurch, dass ich die Arduino-IDE nicht installiere, sondern als portable anlege.
Also auch mehrer nebeneinander. Beim kompilieren werden dann nur die Libraries benutzt die im Unterverzeichnis ./portable liegen.
Habe ich hier schon mal erklärt: https://forum.fhem.de/index.php/topic,58138.msg495778.html#msg495778 (https://forum.fhem.de/index.php/topic,58138.msg495778.html#msg495778)
Gruß Friedrich
Die aktualisierte Modul Version 0.6 liegt auf Github: https://github.com/ddtlabs/ESPEasy
Main Release Notes:
Zitat
0.6.0 - increase verbose level for startup/shutdown log messages
- new attribute parseCmdResponse
- disabled parsing httpRequests by default, enable with attr parseCmdResponse
- more relaxed checking of existenz of 'esp name' and 'device name'.
- dispatch error msgs to device, show last WARNING in internals
- new attribute allowedIPs
- added default attributes for auto created devices
Details: see module command reference or readme.md on github
Zitat von: dev0 am 23 Oktober 2016, 12:40:37
Die aktualisierte Modul Version 0.6 liegt auf Github: https://github.com/ddtlabs/ESPEasy
Main Release Notes:
Nach dem Update muss unbedingt das Attribut "allowedIPs" mit den IPs der ESP gefüllt werden, sonst kommen keine Messwerte mehr rein.
Das sollte so nicht sein, prüfe ich morgen früh.
Zitat von: dev0 am 23 Oktober 2016, 17:56:10
Das sollte so nicht sein, prüfe ich morgen früh.
Danke für die schnelle Rückmeldung.
Vielleicht hilft es ja:
Bei verbose5 sieht das wie folgt aus:
2016.10.23 17:10:53 4: Connection accepted from ESPbridge_192.168.0.24_23473
2016.10.23 17:10:53 4: ESPEasy ESPbridge_192.168.0.24_23473: Peer address rejected
2016.10.23 17:10:53 4: ESPEasy ESPbridge_192.168.0.24_23473: Closing tcp session.
Ist gefixed. Version 0.61 liegt auf Github bereit.
Kannst Du es bitte kurz testen?
Zitat von: Pyromane am 23 Oktober 2016, 17:36:34
Nach dem Update muss unbedingt das Attribut "allowedIPs" mit den IPs der ESP gefüllt werden, sonst kommen keine Messwerte mehr rein.
Damit kämpfe ich seit 2 Stunden bei meinen 3 ESP's.
Habe inzwichen alles neu kompiliert auf 141, hatte zuvor 138, trotzdem kein Erfolg,
als Notlösung habe ich das Backup des Moduls reaktiviert.
Nun habe ich die Lösung gefunden
Japp, ist mit 0.61 gefixt. :)
Besten Dank!
Hallo dev0,
könntest Du auch noch die Blacklist (deniedIPs) für die IP-Adressen implementieren?
Welchen genauen Anwendungsfall möchtest Du damit abdecken, der sich nicht oder nur umständlich über allowedIPs umsetzen läßt.
Nun, der Usecase ist der Gleiche wie bei 'allowedIP'.
Allerdings ist es bei >4 Devices deutlich weniger fehlerträchtig eine Blacklist zu führen.
Kann ich nicht nachvollziehen. Zeige das mal bitte anhand eines Beispiels auf.
Hallo Dev
Erst mal danke für das gute Tool. Mein Problem ich schalte Relais, nach Reset, schalten die Relais nicht wieder in die Pos vor Reset, kann man das einstellen.
Zitat von: Peter_64 am 27 Oktober 2016, 00:46:59
nach Reset, schalten die Relais nicht wieder in die Pos vor Reset
Ob ein Relais nach dem Einschalten des ESPs immer ein- oder ausgeschaltet seinen soll kannst Du mit einer Rule auf dem ESP bestimmen.
Damit der Zustand der Relais nach nach aus/einschalten wiederhergestellt wird, kannst Du ein Notify verwerden, dass auf das presence Reading triggert: absent -> on/off der gpios in einem eigenen Reading speichern, present -> Deine Readings wieder auslesen und den ESP setzen. Das funktioniert allerdings nur dann, wenn das Interval der Presence Detection kurz genug ist um die Abwesenheit zu erkennen. Bei einem Reset wird das schwierig.
Wenn es auch bei einem Reset und unabhängig von FHEM funktionieren soll, dann mußt Du das in die ESPEasy Software implementieren -> Den Zustand immer ins EEprom schreiben und beim Booten auslesen und setzen. Schreibzyklen des EEProms sind aber begrenzt. 100.000(?)
Btw: die Presence Detection des Moduls hat noch eine Macke: nach einem FHEM Neustart gehen alle ESPs auf present, auch wenn sie sich nicht melden. Das fixe ich am Wochenende in einer neuen Version.
Hallo Dev,
alles klar vielen Dank für den Tipp
Gruß
Hallo,
ich muss mich vorab als Anfänger der Materie outen.
Ich habe das Thema FHEM zum Anlass genommen, mich in die Heimautomatiesierungsmaterie ein wenig einzuarbeiten.
Stand der Dinge:
FHEM auf raspberry - läuft
3 Funksteckdosen + LD382-Wifi-LED-Controller (https://www.amazon.de/XCSOURCE-Controller-Lichtstreifen-Smartphone-LD382/dp/B00Q7STR4E) - läuft
H801-Wifi-LED-Controller (https://www.domoticz.com/forum/viewtopic.php?t=7957) mit ESPEasy geflasht - läuft
Steuerung via http-command (http://www.letscontrolit.com/wiki/index.php/GPIO) - läuft
http://<ESP IP address>/control?cmd=PWM,<pin>,<level>
Pin Function
15 Output red
13 Output green
12 Output blue
14 Output white 1
04 Output white 2
<level> 0..1024 (zumindest scheint es die Range zu sein)
Ich würde gerne wie schon beim LD382 auch hier ein Element mit Colorpicker nutzen.
attr espeasy-wifi-led webCmd RGB
attr espeasy-wifi-led widgetOverride RGB:colorpicker,RGB
1. Frage/Problem:
Wie kann ich die Werte "RGB,brightness,hue,saturation" aus dem colorpicker-Modul in die benötigten Werte für den http-Aufruf (0..1024) der einzelnen Farben RGBW umrechnen)?
2. Frage
Lässte sich die Kommunikation (ja, eher einseitig) mit dem "34_ESPEasy.pm" realisieren oder ist das Overkill?
Im Modul Wifilight sind nur die properitären Ansteuerungen der einzelnen Geräte. Gibt "98_HTTPMOD.pm" noch etwas zur Lösung her?
Ich bin für jede Anregung und Hilfe dankbar. Meine Programmierkentnisse begrenzen sich leider eher auf das Abtippen von Code. :-[
Bei Erfolg sollte es möglich sein, alle (chinesischen/selbstbau/etc) RGBW-Wifi-ESP8266-Clones nach Flashen mit ESPEasy mit der selben Methode ansteurn zu können.
So long.
Meiner Meinung nach ist ESPEasy nicht wirklich geeignet einen RGBWW Controler anzusteuern, zumindest nicht ohne passendes Plugin. Dieses Projekt (https://forum.fhem.de/index.php/topic,48918.0.html) hat beispielsweise wesentlich mehr Potenzial dazu.
Zitat von: freddy_mabuse am 28 Oktober 2016, 20:56:59
Wie kann ich die Werte "RGB,brightness,hue,saturation" aus dem colorpicker-Modul in die benötigten Werte für den http-Aufruf (0..1024) der einzelnen Farben RGBW umrechnen)?
Vermutlich so: Die (hex-rgb?) Werte in die 3/5 Kanäle splitten, in dezimal Werte umwandeln und auf den Range von 0..1023 skalieren. Diese Werte dann einzeln an Deinen Controller schicken. Dazu benötigst Du ein userReading und etwas Perl Code. Oder Du schreibest ein Plugin für die ESPEasy Software, das mit RGBWW Werten zurecht komt.
Zitat von: freddy_mabuse am 28 Oktober 2016, 20:56:59
Lässte sich die Kommunikation (ja, eher einseitig) mit dem "34_ESPEasy.pm" realisieren oder ist das Overkill?
Ja. Den overkill sehe ich nicht.
Ohne Programmierkenntnisse wirst Du es mit einem Perl Framework, wie FHEM, schwer haben.
Ob Du mit HTTPMOD etwas anfangen kannst, mußt Du selbst entscheiden, Fragen dazu bitte im passenden Bereich/Thread oder im Anfängerbereich stellen.
Zitat von: SusisStrolch am 26 Oktober 2016, 20:04:18
Nun, der Usecase ist der Gleiche wie bei 'allowedIP'.
Allerdings ist es bei >4 Devices deutlich weniger fehlerträchtig eine Blacklist zu führen.
Zitat von: dev0 am 26 Oktober 2016, 20:14:58
Kann ich nicht nachvollziehen. Zeige das mal bitte anhand eines Beispiels auf.
Da Du darauf bisher nicht geantwortet hast, habe ich das Feature so implementiert, wie ich es für sinnvoll erachte:
Das Attribut 'allowedIPs' erlaubt weiterhin einzelne IPs und/oder Subnetze und verbietet alles Andere. Das neue Attribut 'deniedIPs' verbietet einzelne IPs und/oder Subnetze und verbietet auch Überschneidungen mit 'allowedIPs'.
So kann man beispielsweise den Zugriff auf zwei Class-C Netze beschränken, einer IP und einem Subnetz von 4 Hosts darin den Zugriff verweigern:
attr bridge allowedIPs 172.16.0.0/23
attr bridge deniedIPs 172.16.0.10,172.16.10.32/30
Version 0.64 liegt auf Github...
Zitat
- fixed faulty presence detection after FHEM restart
- close open tcp session immediately if ESP is going to deep sleep (EPSEasy bug?)
- added attribut deniedIPs
Zitat von: PeMue am 18 Oktober 2016, 21:14:35
Ich habe mal mit der ArduinoJson Library 5.6.7 kompiliert, konnte aber leider noch nicht testen (siehe Anhang).
dito für ESPEasy R142 (siehe Anhang, die eingestellten SPIFFS Größen weiß ich leider nicht mehr).
Sind die Images kompatibel zu den "Originalen", die im ESP Easy Wiki angeboten werden (esp8266.nu / letscontrolit.com)?
Wenn ich mich nicht irre und man beim Kompilieren/Upload eine andere SPIFFS Größe angibt, dann ist nach einem (OTA-)Update die Config weg. Oder täusche ich mich?
Zitat von: dev0 am 29 Oktober 2016, 08:00:38
Version 0.64 liegt auf Github...
Hallo,
ich bekommen folgenden Fehler bei einem reload:
Not enough arguments for main::ESPEasy_isAuthenticated at /usr/share/fhem/FHEM/34_ESPEasy.pm line 606, near "})"
BEGIN not safe after errors--compilation aborted at /usr/share/fhem/FHEM/34_ESPEasy.pm line 1717.
PS: Nach einem zweiten reload ist alles Ok! Wunder über Wunder
Du hast nicht neu gestartet (wie nach einem normalem FHEM Update), sondern nur reload '34_ESP...' ausgeführt?
Zitat von: dev0 am 29 Oktober 2016, 11:19:08
Du hast nicht neu gestartet (wie nach einem normalem FHEM Update), sondern nur reload '34_ESP...' ausgeführt?
Ja, mache ich in meinem Testsystem fast immer, wenn ich ein einzelnes Modul aktualisiere.
Grüße Jörg
Ich vermute, dass ich dieses Verhalten, durch die Deklaration aller Subs am Anfang des Moduls, vermeiden kann. In der nächsten Modul Version sollte es somit nicht mehr auftreten.
Danke für den Hinweis.
Zitat von: dev0 am 29 Oktober 2016, 07:56:57
Da Du darauf bisher nicht geantwortet hast, habe ich das Feature so implementiert, wie ich es für sinnvoll erachte:
Das Attribut 'allowedIPs' erlaubt weiterhin einzelne IPs und/oder Subnetze und verbietet alles Andere. Das neue Attribut 'deniedIPs' verbietet einzelne IPs und/oder Subnetze und verbietet auch Überschneidungen mit 'allowedIPs'.
Sorry, war auf Dienstreise und deshalb ein wenig eingeschränkt...
Prima - genau so hatte ich mir das gewünscht/vorgestellt!
Zitat von: dev0 am 29 Oktober 2016, 08:57:02
Sind die Images kompatibel zu den "Originalen", die im ESP Easy Wiki angeboten werden (esp8266.nu / letscontrolit.com)?
Wenn ich mich nicht irre und man beim Kompilieren/Upload eine andere SPIFFS Größe angibt, dann ist nach einem (OTA-)Update die Config weg. Oder täusche ich mich?
Hm, ich habe nirgendwo die SPIFFS Größe angegeben gesehen, daher habe ich immer mit der größten Größe kompiliert. Oder sollte man da die kleinste nehmen? Ehrlich gesagt, ich habe keine Ahnung ...
Gruß PeMue
Super Modul! Ich bin auch durch Zufall über dei Möglichkeiten vom ESP8266 gestolpert und warte nun sehnsüchtig auf meine Module. Aber ich hatte ja, nachdem ich diese Ecke gefunden habe, erst einmal 22 Seiten zu lesen ;)
Schön, dass ich nun nicht noch MQTT meinem PI antun muss oder dafür einen weiteren PI brauche.
Zitat von: P.A.Trick am 03 Oktober 2016, 12:16:56Was hälst du von einem Wiki Eintrag?
Zitat von: dev0 am 03 Oktober 2016, 12:29:21
Eigentlich nichts, da viele Wiki Beiträge nach einer gewissen Zeit nicht mehr aktuell sind und es keiner merkt. Eine ausführliche commandref sollte das aber abdecken.
Na ja, ich habe auf den letzen 22 Seiten auch viel gelesen, was nicht mehr aktuell ist. Jeder, der am Wiki-Artikel scheitert, wird sich irgendwo melden und so ggf. auch eine Anpassung des Wiki-Artikels vornehmen oder durch seinen Hilferuf auslösen.
Ich sehe den Vorteil eines Wiki-Artikels gegenüber der commandref darin, dass man etwas links und rechts vom Modul schauen kann, besser auf die Hardware eingehen kann, Bilder einbinden kann etc.
Aber das sollte natürlich nicht Aufgabe der Entwickler sein - die sollen das machen, was ihnen Spaß macht - coden! Aber alle Nutznießer der Module halte ich für aufgerufen, dem Projekt etwas zurückzugeben und am Wiki zu arbeiten, sobald sie ein Modul / eine Lösung so gut verstanden haben um es zu erklären.
Ist natürlich nur meine Meinung ;)
dokumentierte Grüße
Niels
Zitat von: P.A.Trick am 03 Oktober 2016, 12:16:56
Was hälst du von einem Wiki Eintrag?
Zitat von: Muschelpuster am 29 Oktober 2016, 18:15:32
Ich sehe den Vorteil eines Wiki-Artikels gegenüber der commandref darin, dass man etwas links und rechts vom Modul schauen kann, besser auf die Hardware eingehen kann, Bilder einbinden kann etc.
Nur weil ich Wiki-Artikeln gegenüber kritisch eingestellt bin oder Vorurteile habe, heißt es nicht, dass Ihr keinen Artikel schreiben könnt. Alles was dem Anwender hilft ist willkommen und das Modul sollte bald auch einen Status erreicht haben, an dem es nicht mehr grundlegend geändert wird.
Ich denke darüber nach das Attribut 'uniqIDs' aus dem Modul zu entfernen, da es den Code an einigen Stellen enorm verkompliziert und dadurch auch die Wartung/Weiterentwicklung erschwert. Es gibt schon jetzt Einschränkungen, wenn man das Attribut disabled. Die Funktionalität (mehrere ESPs in einem Device darzustellen) läßt sich mit einer readingsGroup (http://fhem.de/commandref.html#readingsGroup) sogar wesentlich flexibler umsetzen.
Meinungen, Einwände?
Finde ich gut!
Schließe mich an
Beispiele für readingsGroups (http://fhem.de/commandref.html#readingsGroup) im Zusammenhang mit ESPEasy. Vielleicht kann es jemand mal gebrauchen...
Sysinfos aus meheren Devices darstellen. Die verwendeten 'value names' (-> Readings) sind in diesem Beispiel RSSI, voltage und uptime aus allen ESPEasy Devices.
(raw definition (https://forum.fhem.de/index.php/topic,56949.msg508815.html#msg508815)):
defmod rg_ee_si readingsGroup <Device>,<RSSI [dBm]>,<Voltage [V]>,<Uptime [m]> TYPE=ESPEasy:RSSI,voltage,uptime
Selbiges, aber etwas formatierter und bunter.
(raw definition (https://forum.fhem.de/index.php/topic,56949.msg508815.html#msg508815)):
defmod rg_ee_si readingsGroup <Device>,<RSSI [dBm]>,<Voltage [V]>,<Uptime [y ddd hh.mm]> TYPE=ESPEasy:RSSI,voltage,uptime
attr rg_ee_si cellStyle { 'style="margin: 0 20px 0 10px"' }
attr rg_ee_si style style="width:700px;;"
attr rg_ee_si valueColumn { RSSI => 1, voltage => 2, uptime => 3 }
attr rg_ee_si valueFormat {\
return "" if ($READING ne "uptime");;\
my $m = $VALUE;;\
return sprintf "0 000 00:%02d", $m if $m < 60;;\
my $h = $m / 60;; $m %= 60;;\
return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;;\
my $d = $h / 24;; $h %= 24;;\
return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;;\
my $y = $d / 365;; $d %= 365;;\
return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m;;\
}
attr rg_ee_si valueStyle {\
if ($READING eq "RSSI") {\
if ($VALUE > -75) { undef }\
else {($VALUE <= -85) ? 'style="color:red"' : 'style="color:orange"' }\
}\
elsif ($READING eq "voltage") {\
if ($VALUE >= 3.2) { undef }\
else { ($VALUE < 3.0) ? 'style="color:red"' : 'style="color:orange"' }\
}\
else { undef }\
}
Mehrere Relais eines Devices darstellen und schalten. In diesem Beispiel werden die Relais (Relay1, Relay2, Relay3) des Device KE_HTR1 benutzt, die mit den GPIOs 12, 13 und 15 verbunden sind.
(raw definition (https://forum.fhem.de/index.php/topic,56949.msg508815.html#msg508815)):
defmod rg_ee_relays readingsGroup <%sani_heating>,<Relay1>,<Relay2>,<Relay3> KE_HTR1:Relay1,Relay2,Relay3
attr rg_ee_relays commands { \
'Relay1.on' => 'set $DEVICE gpio 12 off',\
'Relay1.off' => 'set $DEVICE gpio 12 on',\
'Relay2.on' => 'set $DEVICE gpio 13 off',\
'Relay2.off' => 'set $DEVICE gpio 13 on',\
'Relay3.on' => 'set $DEVICE gpio 15 off',\
'Relay3.off' => 'set $DEVICE gpio 15 on'\
}
attr rg_ee_relays style style="width:700px;;"
attr rg_ee_relays valueIcon {\
'Relay1.on' => 'ios-on-green',\
'Relay1.off' => 'ios-off',\
'Relay2.on' => 'ios-on-green',\
'Relay2.off' => 'ios-off',\
'Relay3.on' => 'ios-on-green',\
'Relay3.off' => 'ios-off'\
}
Nice :)
ZitatBeispiele für readingsGroups im Zusammenhang mit ESPEasy. Vielleicht kann es jemand mal gebrauchen...
Hallo. Ich habe die Beispiele mit den readingsGroups mal ausprobiert. Das scheint bei mir nicht so recht zu funktionieren. Es werden alle Devices/Values in einer neuen Zeile Angezeigt. Bei mir sind auch alle Values in eigenen Devices gespeichert. Ist das überhaupt richtig so. Scheint mir als hätte ich irgendwo ein Konfigfehler. Sollte das Device "ESPEasy_AZ_..." nur einmal auftauchen oder nicht?
Edit: Ich habs. Habe einfach auf dem ESP den "Namen" im Device weggelassen. Das habe ich scheinbar überlesen.
Da ich das mit den Readings jetzt verstanden habe, habe ich das Beispiel von dev0 um die IP erweitert. So kann ich direkt aus FHEM in des entsprechende Device switchen.
Wer's braucht. ;)
defmod rg_ee_si readingsGroup <Device>,<RSSI [dBm]>,<Voltage [V]>,<Uptime [y ddd hh.mm]>,<IP> TYPE=ESPEasy:RSSI,Voltage,Uptime,+HOST
attr rg_ee_si cellStyle {'style="margin: 0 20px 0 10px"'}
attr rg_ee_si room ESPEasy
attr rg_ee_si style style="width:700px;;;;"
attr rg_ee_si valueColumn {RSSI => 1, Voltage => 2, Uptime => 3, +HOST => 4}
attr rg_ee_si valueFormat {\
if ($READING eq "Uptime")\
{\
my $m = $VALUE;;\
return sprintf "0 000 00:%02d", $m if $m < 60;;\
my $h = $m / 60;;;; $m %= 60;;\
return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;;\
my $d = $h / 24;;;; $h %= 24;;\
return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;;\
my $y = $d / 365;;;; $d %= 365;;\
return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m;;\
}\
elsif ($READING eq "HOST")\
{\
return "<a href=http://".$VALUE." target= \"_blank\">".$VALUE."</a>";;\
}\
else\
{\
return ""\
}\
}
attr rg_ee_si valueStyle {\
if ($READING eq "RSSI") {\
if ($VALUE > -75) { undef }\
else {($VALUE <= -85) ? 'style="color:red"' : 'style="color:orange"' }\
}\
elsif ($READING eq "Voltage") {\
if ($VALUE >= 3.2) { undef }\
else { ($VALUE < 3.0) ? 'style="color:red"' : 'style="color:orange"' }\
}\
else { undef }\
}
Hallo,
ich habe jetzt über ESPEasy einen DHT22 für Temperatur und Luftfeuchtigkeit eingerichtet.
Im ESPEasy ist dabei die Reihenfolge der Werte Temperature, Humidity
Im state für das Device in fhem werden die aber anders herum angezeigt, also H: T:
Im Prinzip wäre es mir egal, aber irgendwie scheint das Dewpoint-Modul damit ein Problem zu haben,
denn bei den anderen Sensoren mit Temperatur und Luftfeuchtigkeit ist immer T der erste Wert, dann H und danach kann Dewpoint den errechneten Wert anhängen, was nun hiermit irgendwie nicht funktioniert
Kann man die Reihenfolge der Werte im state verändern, so dass es konform mit der üblichen Darstellung von Devices mit temperature und humidity ist?
Für STATE geht es ja über das Attribut stateformat aber generell, um die übliche Darstellung von Sensoren zu erreichen...?
Edit:
Ich habe da noch ein weiteres Problem bezüglich state der ESPEasy-Devices.
In allen Devices von ESPEasy wird der state auch im Filelog kein SPACE zwischen den Werte-Bezeichnungen und den eigentlichen Werten ausgegeben.
Wenn ich nun nur state logge, ist es damit nicht mehr möglich, plots korrekt aus dem Filelog zu generieren, da die Positionen der Werte ja durch den Trenner SPACE festgelegt wird.
FileLog Auszug eines ESPEasy-Devices.
2016-11-04_19:43:48 ESPEasy_Witty3_DHT22 H:80 T:2.6
2016-11-04_19:45:49 ESPEasy_Witty3_DHT22 H:80 T:2.5
2016-11-04_19:46:49 ESPEasy_Witty3_DHT22 H:80 T:2.6
2016-11-04_19:47:49 ESPEasy_Witty3_DHT22 H:80 T:2.5
2016-11-04_19:49:49 ESPEasy_Witty3_DHT22 H:81 T:2.6
FileLog Auszug eines normalen Temp/Hum-Sensors
2016-11-04_19:38:09 CUL_TCM97001_145 T: 4.1 H: 95 D: 3.4
2016-11-04_19:43:28 CUL_TCM97001_145 T: 4.1 H: 95 D: 3.4
2016-11-04_19:48:45 CUL_TCM97001_145 T: 4.1 H: 95 D: 3.4
Hier sind die Werte für T an der eindeutigen Position 4 mit dem Wert "4.1"
Oben im Logauszug von ESPEasy-Device wäre Position 4 belegt mit "T:2.6", welches das Problem im Plot verursacht und damit auch im FTUI nicht dargestellt wird.
Ist es also möglich, die state-Angaben entsprechend den anderen Formaten in fhem nach dem Doppelpunkt generell mit einem SPACE zu trennen?
Ich denke, das kann nur Modul-intern angepasst werden und nicht durch attr ... ?
Zitat von: majorshark am 04 November 2016, 11:54:50
Edit: Ich habs. Habe einfach auf dem ESP den "Namen" im Device weggelassen. Das habe ich scheinbar überlesen.
Du kannst den 'device name' weglassen, wenn der 'esp name' gesetzt ist. Dann kannst Du aber für diese Sensoren keine Regeln auf dem ESP anlegen. Die bessere Variante wäre identische Namen für alle 'esp devices' zu vergeben, die in einem FHEM Device dargestellt werden sollen.
Zitat von: homeum am 04 November 2016, 18:43:54
Im state für das Device in fhem werden die aber anders herum angezeigt, also H: T:
Im Prinzip wäre es mir egal, aber irgendwie scheint das Dewpoint-Modul damit ein Problem zu haben,
Schau Dir bitte in der commandref die optionalen Parameter des dewpoint Modules an und benutze die einzelnen Readings und nicht state.
Zitat von: homeum am 04 November 2016, 18:43:54
Kann man die Reihenfolge der Werte im state verändern, so dass es konform mit der üblichen Darstellung von Devices mit temperature und humidity ist?
Es gibt keine übliche Reihenfolge von Werten im Reading state. Wenn ein anderes Modul genau die, von Dir beschriebene, Darstellung benötigt, dann kannst Du das Attribut setState disablen und Dich selbst mit einem userReading oder notify darum kümmern, dass es so gesetzt wird, wie Du es möchtest. Im Fall von dewpoint ist das aber unnötig.
Zitat von: homeum am 04 November 2016, 18:43:54
In allen Devices von ESPEasy wird der state auch im Filelog kein SPACE zwischen den Werte-Bezeichnungen und den eigentlichen Werten ausgegeben.
Das fehlende space werde ich in die nächste Version einbauen. Bedenke aber, dass state nicht nur Sensorwerte darstellt, sondern auch andere Status darstellt wie absent, present, opened. Wenn das nicht erwünscht ist, dann ein userReading benutzen.
Zitat von: dev0 am 05 November 2016, 07:38:01
... Dann kannst Du aber für diese Sensoren keine Regeln auf dem ESP anlegen...
Stimmt daran habe ich nun auch wieder nicht gedacht. Also noch einmal umkonfigurieren.
Edit: Die Rules scheinen mit den gleichen deviceNamen nicht mehr zu Funktionieren. Kann das jemand bestätigen?
Das schrieb schon mal jemand im Sonoff Thread. Ich kann das aber nicht bestätigen, denn bei mir funktioniert das bisher problemlos.
Hallo, hab bei mir ein SONOFF mit ESPEasy gemäß WIKI aufgesetzt.
Läuft im Prinzip bis auf die Tatsache dass ich im FHEM immer wieder die Meldung
WARNING_192.168.148.13
192.168.148.13: No route to host
bekomme.
Damit kann ich dann auch nicht mehr schalten.
Im Log sieht das so aus.
2016.11.06 09:30:55 2: ESPEasy ESPEasy_Sonoff_1_PUMP: WARNING: 192.168.148.13: No route to host
2016.11.06 10:00:54 2: ESPEasy ESPEasy_Sonoff_1_PUMP: RESOLVED: 192.168.148.13: No route to host
2016.11.06 10:03:07 2: ESPEasy ESPEasy_Sonoff_1_PUMP: WARNING: 192.168.148.13: No route to host
2016.11.06 10:08:26 2: ESPEasy ESPEasy_Sonoff_1_PUMP: RESOLVED: 192.168.148.13: No route to host
2016.11.06 10:09:42 2: ESPEasy ESPEasy_Sonoff_1_PUMP: WARNING: 192.168.148.13: No route to host
Was könnte das sein? Wie kann ich das Problem eingrenzen?
Billy
Zitat von: Billy am 06 November 2016, 10:22:45WARNING_192.168.148.13
192.168.148.13: No route to host
Was könnte das sein? Wie kann ich das Problem eingrenzen?
Kannst du das ESP dann pingen?
Kommst du auf die ESP Webseite?
Zitat von: Pyromane am 06 November 2016, 10:53:55
Kannst du das ESP dann pingen?
Kommst du auf die ESP Webseite?
--> Geändert, da so nicht richtig.
Nach Meldung --> 192.168.148.13: No route to host
Komme ich nicht auf Webseite, Ping geht auch nicht.
Irgendwann steht die Verbindung dann wieder
Frage ist wieso steigt die Verbindung aus?
hat mein SONOFF eine Macke?
Zitat von: Billy am 06 November 2016, 11:20:32
--> Geändert, da so nicht richtig.
Nach Meldung --> 192.168.148.13: No route to host
Komme ich nicht auf Webseite, Ping geht auch nicht.
Irgendwann steht die Verbindung dann wieder
Frage ist wieso steigt die Verbindung aus?
hat mein SONOFF eine Macke?
Hast Du vielleicht den Sleep-Modus im esp aktiviert?
So, Problem eingegrenzt. War das WLAN Netz. :-\
Wenn ich die Sonoff am WIFI der Fritzbox betreibe geht alles problemlos.
Sobald ich sie an meinen Ubiquiti Unifi AP einbinde, gibt es reihenweise den "No route to host".
Immerhin kann ich jetzt Ursachenforschung betreiben.
Alle anderen WLan Geräte haben mit dem Ubiquiti Unifi AP kein Problem.
Ich mag ja jetzt etwas blind sein, aber wo bekomme ich denn jetzt ein aktuelles fertig kompiliertes Image her? Auf Sourceforge.net gibt es nur die R120, auf der Website http://www.letscontrolit.com/ finde ich überhaupt keine Downloads und auf Github nur die Sources.
blinde Grüße
Niels
Zitat von: Muschelpuster am 06 November 2016, 18:47:34
Ich mag ja jetzt etwas blind sein, aber wo bekomme ich denn jetzt ein aktuelles fertig kompiliertes Image her?
PeMue hatte eines ein paar Beiträge weiter vorne hochgeladen:
https://forum.fhem.de/index.php/topic,55728.msg511856.html#msg511856
Ah ja - Danke.
gefundene Grüße
Niels
Zitat von: Pyromane am 06 November 2016, 18:50:40
PeMue hatte eines ein paar Beiträge weiter vorne hochgeladen:
das waren alle drei ;)
Gruß PeMue
Und schon drauf auf meinem ESP ;)
Nur leider kommt mein ESP nach dem Update von R120 nicht mehr auf die Füße :-\
Hoffentlich klemmt es nicht irgendwo im ESPeasy-Projekt. Wäre schade drum...
aktualisierte Grüße
Niels
Zitat von: Muschelpuster am 06 November 2016, 20:00:45Nur leider kommt mein ESP nach dem Update von R120 nicht mehr auf die Füße :-\
Schon mal nachgeschaut ob seriell noch Daten raus kommen?
Jo, gerade getan: ets Jan 8 2013,rst cause:4, boot mode:(3,6)
wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09826c6d
~ld
serielle Grüße
Niels
Läuft wieder. Habe versucht, den Flash zu löschen (http://www.s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/131-loeschen-des-gesamten-flashspeichers), hat nicht geklappt, aber danach erneutes Flashen war erfolgreich.
Aber der Versuch des IR-Sensors war nicht so von Erfolg gekrönt. Scheinbar werden die IR-Meldungen in mehreren Teilstrings übertragen und so steht im Reading immer was Anderes. Aber das hat ja nichts mit dem Modul zu tun.
restaurierte Grüße
Niels
Ohne genauere Details zu kennen würde ich vermuten, dass es nach dem ersten Flashen gereicht hätte die WIFI Parameter über die serielle Schnittstelle neu zu setzen. Ich vermute weiterhin, dass die Images von PeMue eine andere SPIFFS Größe haben als die, die es auf esp8266.nu/letscontrolit.com gibt und die Config des ESPs dadurch geschrottet wurde.
Wenn man einen ESP aktualisiert, dann sollte man mMn entweder mit den gleichen Einstellungen selbst kompilieren oder die Images von letscontrolit.com benutzen, die es im www.letscontrolit.com/wiki (http://www.letscontrolit.com/wiki/index.php/ESPEasy#Loading_firmware) gibt. Vielleicht hat Peter auch Lust einen eigenen Thread, mit stets akuellen ESP Easy Images, zu pflegen? ;)
Zitat von: dev0 am 07 November 2016, 07:33:53
Ich vermute weiterhin, dass die Images von PeMue eine andere SPIFFS Größe haben als die, die es auf esp8266.nu/letscontrolit.com gibt und die Config des ESPs dadurch geschrottet wurde.
Gibt es irgendwo Infos darüber, welche SPIFFS Größe verwendet wird? Dann kann ich mich ja an die Gepflogenheiten con letscontrolit anpassen. Eigentlich habe ich das nur gemacht, um meine Entwicklungsumgebung auf Funktion zu testen ;D
Gruß PeMue
Ich meine das mal im ESPEasy Forum gelesen zu haben, jetzt auf die Schnelle aber nicht gefunden. Sonst einfach Martinus dort kurz fragen.
Wenn das nächste Stable Release in Kürze veröffentlicht wird, dann würde sich der Eine oder Andere bestimmt wieder über fertige Images freuen, um neue Features nutzen zu können ohne selbst kompilieren zu müssen.
Oder hier (http://www.letscontrolit.com/wiki/index.php/Tutorial_Arduino_Firmware_Upload) schauen ;)
ZitatGeneric ESP boards: If you use a generic ESP module with 512k Flash, like the blue colored ESP-01 or the ESP-12 or ESP-201, you have to set parameters manually. In this case it is very important to select the right SPIFFS size!!: (Without at least 64k reserved for SPIFFS, ESP Easy will not work!)
Zitat von: amunra am 07 November 2016, 09:31:19
Oder hier (http://www.letscontrolit.com/wiki/index.php/Tutorial_Arduino_Firmware_Upload) schauen ;)
... d.h. SPIFFS ist immer 64k bzw. der kleinste Wert den die IDE hergibt?
Zitat von: dev0 am 07 November 2016, 07:33:53...oder die Images von letscontrolit.com benutzen, die es im www.letscontrolit.com/wiki (http://www.letscontrolit.com/wiki/index.php/ESPEasy#Loading_firmware) gibt...
Da findest Du dort mehr wie ich ::)
blinde Grüße
Niels
Hallo zusammen.
ich habe eine kurze Zwischenfrage und konnte dazu in Netz und im Forum hier noch nichts finden:
Ich würde mit einem ESPEasy-Baustein gerne einen WS2812b-LED-Stripe ansteuern und per Fhem unterschiedliche Farben & Modi (zb. Lauflicht oder Regenbogen) starten. Eine Sound-Steuerung oder Equalizer wäre super, aber etwas komplizierter... wegen Mic.
Habt ihr einen Tipp wie das Zusammenspiel zwischen ESPEasy und WS2812b funktionieren kann. Leider gibt es ja kein eigenes WS2812er Easy-Modul.
Gruß, zYloriC
Zitat von: zYloriC am 07 November 2016, 14:24:26
Habt ihr einen Tipp wie das Zusammenspiel zwischen ESPEasy und WS2812b funktionieren kann. Leider gibt es ja kein eigenes WS2812er Easy-Modul.
Selbst das Plugin schreiben?
Zitat von: zYloriC am 07 November 2016, 14:24:26
Hallo zusammen.
ich habe eine kurze Zwischenfrage und konnte dazu in Netz und im Forum hier noch nichts finden:
Ich würde mit einem ESPEasy-Baustein gerne einen WS2812b-LED-Stripe ansteuern und per Fhem unterschiedliche Farben & Modi (zb. Lauflicht oder Regenbogen) starten. Eine Sound-Steuerung oder Equalizer wäre super, aber etwas komplizierter... wegen Mic.
Habt ihr einen Tipp wie das Zusammenspiel zwischen ESPEasy und WS2812b funktionieren kann. Leider gibt es ja kein eigenes WS2812er Easy-Modul.
Gruß, zYloriC
Es gibt aus dem playground ein plugin, das brauchst du nur reinkompilieren.
https://github.com/ESP8266nu/ESPEasyPluginPlayground/blob/master/_P101_NeoClock.ino (https://github.com/ESP8266nu/ESPEasyPluginPlayground/blob/master/_P101_NeoClock.ino)
Hab das aber nn ausprobiert und kann nicht sagen wie es funktioniert.
Gruß
Karl
Sent from my iPad using Tapatalk
Zitat von: PeMue am 07 November 2016, 13:35:27
... d.h. SPIFFS ist immer 64k bzw. der kleinste Wert den die IDE hergibt?
Wie bei so vielen Dingen, kann man das so pauschal nicht sagen. :-\
Die originalen Images werden wie folgt kompiliert:512 =>
(64K SPIFFS) – Vermutlich damit auch noch die kleinen ESP82866-01 etc. funktionieren (siehe Wiki)
1024 => ?
4096 =>
(3M SPIFFS)Wenn die Größe nicht passt, dann wird der Speicher (in dem sich die Settings befinden), wie dev0 bereits schrieb, entsprechend gelöscht - das sieht man auch in der Konsole beim ersten Boot nach dem flashen.
Das sieht dann in etwas so aus:
....
FLASH: Erase Sector: 1022
FLASH: Erase Sector: 1023
FLASH: Zero Fill Sector: 256
FLASH: Zero Fill Sector: 257
FLASH: Zero Fill Sector: 258
....Woher ich das weiß? Na, ja ich habe es ausprobiert.
P.S: Ich dachte, dass Du hier der Build-Manager bist. ;) ;D
Zitat von: amunra am 07 November 2016, 17:15:20
1024 => ?
Woher ich das weiß? Na, ja ich habe es ausprobiert.
... jetzt weiß ich, warum Du die 1 MB nicht ausprobiert hast. Es stehen folgende Optionen zur Verfügung: 512k, 256k, 192k, 160k, 144k, 128k und 64k ;)
Kann man denn anhand der BIN Datei herausbekommen, wie groß der SPIFSS Speicher ist?
Zitat von: amunra am 07 November 2016, 17:15:20
1024 => ?
P.S: Ich dachte, dass Du hier der Build-Manager bist. ;) ;D
Ich wollte doch nur meine IDE ausprobieren ;D
Gruß PeMue
ZitatIch wollte doch nur meine IDE ausprobieren
Zu spät gesagt ;D
Hallo PeMue,
Zitat von: PeMue am 07 November 2016, 20:09:46
Ich wollte doch nur meine IDE ausprobieren ;D
;);)
Zitat von: PeMue am 07 November 2016, 20:09:46
... jetzt weiß ich, warum Du die 1 MB nicht ausprobiert hast. Es stehen folgende Optionen zur Verfügung: 512k, 256k, 192k, 160k, 144k, 128k und 64k ;)
Hm, ich dachte schon es fällt nicht auf ;) ;D
Zitat von: PeMue am 07 November 2016, 20:09:46
Kann man denn anhand der BIN Datei herausbekommen, wie groß der SPIFSS Speicher ist?
Immer diese Fragen ;) Das kannst Du gerne versuchen... Ich würde eher den einfachen Weg, den dev0 vorgeschlagen hat, nehmen "den Entwickler der die Images baut fragen" oder im Forum suchen, vielleicht ist es beschrieben (ich habe auch auf die schnelle nichts gefunden)? ;)
Aber bald kommt hoffentlich die Erlösung.
Fazit:
1) Entweder selbst kompilieren und Wissen was man macht.
oder
2) Nur die fertig kompilierten Images verwenden.
Aber bitte 1) und 2) nicht kombinieren und wenn dann nur wenn man die Parameter kennt.
;)
Zitat von: amunra am 07 November 2016, 17:15:20
512 => (64K SPIFFS) – Vermutlich damit auch noch die kleinen ESP82866-01 etc. funktionieren (siehe Wiki)
1024 => ?
4096 => (3M SPIFFS)
Ok, neuer Versuch mit folgenden Parametern für die R143:
512k =>
64k SPIFFS1M =>
256k -> 64k SPIFFS (
Kompatibilität mit dem offiziellen Image noch nicht verifiziert)
4M =>
3M SPIFFSHier gibt es noch weiterführende Infos:
http://esp8266.github.io/Arduino/versions/2.0.0/doc/filesystem.html
http://www.letscontrolit.com/forum/viewtopic.php?f=4&t=1930&hilit=SPIFFS+size&start=20#p9397
Gruß PeMue
Edit: 1M Image auf 64k SPIFFS angepasst.
Also ich switche zwischen den offiziellen und eigenen Versionen. Die eigenen Versionen habe immer mit 512k/64k, 1M/64K oder 4M/3M kompiliert. Die Konfigurationen blieben dabei immer erhalten.
Zum Thema Rules mit gleichen Devicenamen auf dem ESP
Zitat von: dev0 am 05 November 2016, 19:43:02
Das schrieb schon mal jemand im Sonoff Thread. Ich kann das aber nicht bestätigen, denn bei mir funktioniert das bisher problemlos.
Das geht bei mir definitiv nicht. Nach div Test konnte ich den Fehler eingrenzen.
Das Event "On Name#Value do" wird auf dem ESP noch ausgelöst, und abgearbeitet. Aber die im Event enthaltenen If-Vergleiche werden nicht ausgeführt.
Beispiel:
# Kontrolle ob Solltemperatur erreicht ist
On AZ#IstTemp do
if [AZ#IstTemp]>[AZ#SollTemp]
gpio,12,0
endif
if [AZ#IstTemp]<[AZ#SollTemp]-1
gpio,12,1
endif
endonWenn ich bspw. ein "gpio,12,1" direkt in das Event einsetzte wird der Port sofort nach eintreten des Events auf 1 gesetzt. Sieht man auch so im Log des ESP.
Wie Daten an OLED (an ESPEasy 142RC5 angeschlossen) mit ESPEasy-Modul senden
Wie kann ich denn einen, in FHEM eingelesenen Temperatur/Humidity-Wert an einen ESPEasy 8266 senden um am dortigen OLED anzuzeigen?
Das OLED habe ich aktuell so definiert (was vielleicht noch nicht ganz koerrekt ist?):
define ESPEasy_wemos1_display ESPEasy 192.168.178.41 80 espBridge wemos1_display
attr ESPEasy_wemos1_display IODev espBridge
attr ESPEasy_wemos1_display Interval 300
attr ESPEasy_wemos1_display group ESPEasy Device
In der FHEM-GUI kann ich beliebeigen Text mit ,,set ESPEasy_wemos1_display 5 1 Hallo" senden.
Aber wie kann ich permanent z.B. ,,Heizung_Vorlauf" dahin senden?
yamfhem
notify, at, InternalTimer, cron, ...
Moin Moin,
ich habe an einer EspEasy R137 zwei "Switches" definiert.
der ESP heisst shutter_livingroom. die Switches heißen "up" und "down"
im Webinterface sind die stati korrekt.
FHEM tut auch was, allerdings hatte ich mir erhofft, dass ein FHEM-Device shutter_livingroom die passenden Readings bekommt, und sobald der Status am ESP wechselt, dies dank des EspEasy-Moduls an mein FHEM gepusht wird.
also ich dann readings â la "up : 1" oder "down: 0" bekomme....
Anscheinend ist grad die Doku von EspEasy down, ich habe folgende "Rules" probiert:
on GPIO12#Switch do
SendToHTTP 192.168.20.116,8083,fhem?cmd=setreading%20shutter_livingroom%20up%20[GPIO12#Switch]
endon
on driveDown do
SendToHTTP 192.168.20.116,8083,/fhem?cmd=setreading%20shutter_livingroom%20down%20[GPIO14#Switch]
endon
funktioniert auch nicht....
Was muss ich dafür tun?
Danke!
Für jedes Device in ESPEasy bekommst du auch ein Device in FHEM.
So werden die jedenfalls durch autocreate in FHEM angelegt, wenn alles richtig eingestellt ist.
Du musst keine rules anlegen. Es reicht auf esp Seite den Controller zu konfigurieren und auf fhem Seite die espeasy Bridge. Danach werden die devices per autocreate angelegt, sobald Daten eintreffen...
Ist das vielleicht der gleiche Fehler, den ich zuerst gemacht habe? Ich hatte die Version 120 installiert, die ich als Letzte gefunden hatte. Dabei hatte ich die Versionsanforderung im Startbeitrag großzügig ignoriert. Dann steht im Log von FHEM ein Hinweis auf die falsche Version und die Devices werden nicht angelegt.
inaktuelle Grüße
Niels
R137 ;)
Devices werden angelegt,
Aber die Reading dadrin sind Müll.
Das RSSI Device hat Reading
"rssi: true" das macht keinen Sinn :/ ?!
Aber ich kann der Bridge nicht sagen:
Alle "Devices" von einem ESP in ein einziges FHEM-Device?
Zu alte json lib.
Esp device names identisch benamsen.
Und neue Json Lib, wie Regel ich das?
Ein Licht geht auf!
"Device" gleich, Values unterschiedlich?
Aktuelle Version benutzen.
Ja, oder auf die nächste Modulversion warten.
Wie mache ich das? CPAN?
Es geht um die ArduinoJson Lib, die ESPEasy benötigt. Steht schon mehrfach hier im Thread. Man darf den Thread auch lesen, kostet nix extra.
Alles klar, danke!
Jetzt funktioniert das erstmal gut!
Allerdings bekomme ich jetzt kein RSSI mehr gesendet?! :D... Ich bekomme aber schon im Webinterface kein RSSI im Device angezeigt, vorne schon.
BTW:
Wo bekomme ich offiziell die neuen releases her?
Schau ins letscontrolit wiki
hatte ich schon, hast du einen Tipp wonach ich suchen sollte?
ESPEasy Modulversion 0.66 ist auf Github verfügbar.
Release Notes:
- Ein zusätzliches Leerzeichen trennt Readingnamen und Wert im Reading 'state' um die Erstellung von Plots zu erleichtern (Forum #55728.msg515626)
- Das Attribut 'uniqIDs' wird nicht weiter unterstützt. Bei Verwendung wird eine Warnung is Log und die Internals der Bridge geschrieben. In der nächsten Modulversion ist das Attribut nicht mehr verfügbar.
- Das neue Attribut 'combineDevices' dient dazu alle Werte eines einzelnen ESP in ein FHEM device laufen zu lassen. Dabei ist es dann egal ob die 'ESP Devices Names' unterschiedlich oder identisch sind. Zur identifizierung des ESP wird dann nur der 'ESP Name' benutzt. Ist der ESP Name nicht vergeben, dann wird die IP Adresse benutzt.
Zitat von: dev0 am 11 November 2016, 06:38:45
Das neue Attribut 'combineDevices' dient dazu alle Werte eines einzelnen ESP in ein FHEM device laufen zu lassen. Dabei ist es dann egal ob die 'ESP Devices Names' unterschiedlich oder identisch sind. Zur identifizierung des ESP wird dann nur der 'ESP Name' benutzt. Ist der ESP Name nicht vergeben, dann wird die IP Adresse benutzt.
Dafür gibt es doch gleich mal ein Like von mir.
Hallo!
Danke für die vielen wertvollen Tipps hier im Forum!
Grundsätzliche Frage zum Flashen der ESPEasy auf einem WeMOS D1 mini:
Ich habe nach Anleitung ESP Easy (ESPEasy_R120_4096.bin) auf den WeMos geflashed und entsprechend in Heim WLAN angemeldet. Lief auch soweit, das war o.k.
Nächsten Morgen sendet zwar das Modul (sichtbar in der Fritz.box -> WLAN -> Funknetz - Übersicht) ist aber über die IP Adresse nicht mehr erreichbar?
Hat jemand eine Idee?
Gruss Richs
Vermutlich ist Sleep auf dem Modul aktiv. Nebenbei ist die 120 für FHEM zu alt (s. meine Beiträge etwas zurück bzw. Startbeitrag).
vermutliche Grüße
Niels
Danke für deine Info. Das mit der R140 habe ich im Startbeitrag überlesen.
Sleepmode wurde nicht aktiviert bei der Einstellung über das ESP Easy Web GUI.
Ich habe nun auch versucht die R140 zu flashen, ging aber nicht, da sich das WeMos immer noch mit R120 meldet.
Irgend eine Idee, was ich falsch mache?
Grüsse, Richs
Hi Richs...
Hat das Flashen auf v.14x denn geklappt oder nicht?
Wenn ja: Browser-Reload oder Browser-Cache leeren. War bei meiner Windoof Kiste auch so.
Gruss
Alex
Hi Alex, danke für deine Antwort.
Das flashen hat nun geklappt. Habe jetzt R140 drauf. Cache des Browsers gelehrt....
Das ist der Output des Arduino Serial Monitors:
INIT : Booting Build nr:140
IP : Static IP :192.186.178.43
WIFI : Connecting... 1
WIFI : Connected!
INIT : I2C
INIT : SPI not enabled
INIT : Boot OK
INIT : Normal boot
WD : Uptime 0 ConnectFailures 0 FreeMem 27712
WD : Uptime 1 ConnectFailures 0 FreeMem 27680
WD : Uptime 1 ConnectFailures 0 FreeMem 27648
Frage an die Netzwerkspezialisten: Mein Home Netzwerk ist auf 192.168.178.xx konfiguriert. 8266 meldet sich mit 192.186.172.43
Kann ich den WeMOS irgendwie auf 192.168.178.xx mit einer Statischen IP Adresse bringen oder muss ich mein Netzwerk 'kurzfristig' umkonfigurieren (hoffe nicht :-\ )
Es kann mir gestern schon ein Zahlendreher passiert sein (es war schon spät) aber warum das gestern alles gefunzt hat (mit Zahlendreher) und heut nicht mehr ist mir rätselhaft....
Kann mir jemand weiterhelfen?
Elektronische Grüsse, Richs
Die IP kannst Du auch über die serielle Schnittstelle konfigurieren. Syntax sie ESP Easy Command Reference im letscontrolit wiki.
wenn du mit dem seriell Monitor noch drauf kommst, dann kannst du versuchen den Wifi Mode in den AP zu schalten. Dann wiederrum kommst du mit dem Laptop wieder drauf (192.168.4.1).
Ansonsten such im Google nach "esp8266 at commands" , da gibt es zahlreiche Listen mit den möglichen Kommandos!
LG
ESP Easy versteht AT Befehle?
Zitat von: yamfhem am 08 November 2016, 14:13:54
Wie Daten an OLED (an ESPEasy 142RC5 angeschlossen) mit ESPEasy-Modul senden
Wie kann ich denn einen, in FHEM eingelesenen Temperatur/Humidity-Wert an einen ESPEasy 8266 senden um am dortigen OLED anzuzeigen?
Das OLED habe ich aktuell so definiert (was vielleicht noch nicht ganz koerrekt ist?):
define ESPEasy_wemos1_display ESPEasy 192.168.178.41 80 espBridge wemos1_display
attr ESPEasy_wemos1_display IODev espBridge
attr ESPEasy_wemos1_display Interval 300
attr ESPEasy_wemos1_display group ESPEasy Device
In der FHEM-GUI kann ich beliebeigen Text mit ,,set ESPEasy_wemos1_display 5 1 Hallo" senden.
Aber wie kann ich permanent z.B. ,,Heizung_Vorlauf" dahin senden?
yamfhem
... leider bin ich hier noch nicht viel weiter gekommen und stell mich sicher nur zu blöd an, vielleicht kann mir trotzdem jemand helfen :-[
set ESPEasy_wemos1_display oled 3 1 $Wasserzeigt mir am Oled immer nur $Wasser an, aber nicht den Inhalt der Variablen!? Was muss ich tun?
Ich bitte um Hilfe!!!
Lies die angehefteten Beiträge im Anfängerbereich und die Einsteigerdoku. Fragen zu den FHEM Grundlagen bitte auch im Anfängerbereich stellen.
Hallo zusammen,
erstmal vielen Dank für das Modul. Ich nutze noch MQTT, möchte aber langfristig auf das ESPEasy-Modul umsteigen. Dazu ein paar Fragen:
Kann man einen GPIO-Ausgang von FHEM aus setzen, wenn der sleep mode beim ESPEasy gesetzt ist (der reagiert dann natürlich nur in den kurzen Aufwach-Phasen)?
Feature Request: Kann man den sleep mode über FHEM (de-)aktivieren? Ich möchte nämlich einen ESP8266 als Heizungssteuerung her nehmen und er soll bei abgeschalteter Heizung alle x Minuten die aktuelle Raum- und Heizkörpertemperatur an FHEM berichten. Falls die Heizung geregelt wird, soll der ESP8266 kontinuierlich eingeschaltet (also sleep mode abgeschaltet) sein, damit die Regelung schneller reagieren kann. Außerdem soll der delay des sensors (sozusagen das update interval) in diesem Fall verkürzt werden. Muss (bzw. kann) ich eine entsprechende Regel in ESPEasy anlegen oder wäre so etwas auch über FHEM möglich, falls so ein feature in das 34_ESPEasy-Modul implementiert wird? Dann wäre ich flexibler und kann die Regeln direkt in FHEM anlegen und maintainen ;).
Vielen Dank!
Zitat von: Elektrofreak am 17 November 2016, 10:44:04
Kann man einen GPIO-Ausgang von FHEM aus setzen, wenn der sleep mode beim ESPEasy gesetzt ist (der reagiert dann natürlich nur in den kurzen Aufwach-Phasen)?
...
Feature Request: Kann man den sleep mode über FHEM (de-)aktivieren?
In beiden Fällen: nein. Das unterstützt die ESP Easy Firmware mWn nicht: der ESP wacht auf - sendet - schläft wieder ein. Oder ich habe den ESP Easy Code nicht verstanden... Der deep sleep mode läßt isch mWn nur in den 30 Sekunden nach "stromlos" deaktivieren.
Zitat von: dev0 am 17 November 2016, 12:03:53
In beiden Fällen: nein. Das unterstützt die ESP Easy Firmware mWn nicht: der ESP wacht auf - sendet - schläft wieder ein. Oder ich habe den ESP Easy Code nicht verstanden... Der deep sleep mode läßt isch mWn nur in den 30 Sekunden nach "stromlos" deaktivieren.
Das ist richtig. Der Deep Sleep ist eine reine Hardwarelösung. Durch diesen Modus wird der ESP herunter gefahren. Aktiv bleibt nur der Timer. Bei erreichen der Aufweckzeit wird ein Hardwarereset durchgeführt. Der ESP starten genau so, als wenn eine Versorgungsspannung angelegt wird. Es gibt im Netz Ideen dieses WackUp durch einen externen Trigger, wie z.B. einen 433 MHz Empfänger, machen zu lassen. Eine Lösung über einen Atiny gibt es schon.
Gesendet von iPad mit Tapatalk
Zitat von: JoWiemann am 17 November 2016, 12:43:00Der Deep Sleep ist eine reine Hardwarelösung. Durch diesen Modus wird der ESP herunter gefahren. Aktiv bleibt nur der Timer. Bei erreichen der Aufweckzeit wird ein Hardwarereset durchgeführt.
Da hast du recht, die Hardware muss dafür konfiguriert sein. Die Frage ist jene, ob man anstatt über das Webinterface auch anders die (Re-)Aktivierung des Modus' verhindern kann. Das ist ja auch möglich, wenn man die Versorgungsspannung einschaltet und dann den Haken im Webinterface löscht. Bei dem Vorgang bleibt der ESP8266 ja auch noch 30 Sekunden im normalen Betrieb bevor er (von der ESPEasy-Firmware initiiert) in den Sleep Modus geht. Man müsste nur genau den Zeitpunkt erwischen, wenn der ESP8266 eine Verbindung aufgebaut hat und auf befehle reagiert. Dazu könnte man z.B das WiFi noch 1 Sekunde länger an, wie ESPEasy eig. zum Senden der Daten brauchen würde. Man könnte dann in diesem Zeitraum die erneute Aktivierung des Modus' verhindern.
Das wäre dann eine Software-Lösung zur Deaktivierung des Sleep-Modes ::)
Tja, dann muss in der ESP Easy ein neuer command implementiert werden. In der aktuellen Liste finde ich nichts: http://www.letscontrolit.com/wiki/index.php/ESPEasy_Command_Reference
Gesendet von iPad mit Tapatalk
Hallo.
Zitat von: JoWiemann am 17 November 2016, 15:55:51
Tja, dann muss in der ESP Easy ein neuer command implementiert werden. In der aktuellen Liste finde ich nichts: http://www.letscontrolit.com/wiki/index.php/ESPEasy_Command_Reference
Das ist ein guter Ansatz. Ich wusste gar nicht, dass es die Command Reference Liste gibt ::). Und da es diesen Befehl noch nicht gibt, dieser aber einfach zu implementieren sein sollte, habe ich mal ein Feature Request geschrieben ;D. Dann könnte die Funktionalität über ein DOIF oder ein notify (wenn FHEM den ESP nicht braucht, nach dem Erhalt der Daten bitte in den Sleep Mode schicken) implementiert werden. Dann müsste das ESPEasy-Modul nur einen set-Befehl (z.B. set ESPEasy sleepFor [seconds]) bekommen.
Edit: Ich denke es ist einfacher, den Sleep Mode per command zu pushen/setzen als irgendwie die Check-Box in der kurzen Phase zu manipulieren und dadurch den Sleep Mode zu (de-)aktivieren. Dann müssten die ESPEasy-Developer mehr programmieren ;).
Hier der Link zu dem Feature Request:
http://www.letscontrolit.com/forum/viewtopic.php?f=2&t=2302 (http://www.letscontrolit.com/forum/viewtopic.php?f=2&t=2302)
Ich habe das Problem das mein sonoff nach Ca. 9min Inaktivität in fhem als absent angezeigt wird.
Sobald ich den Schalter am device drücke ist es sofort wieder da! Jemand eine Idee?
Software ist die R145 RC 5
Grüße
Matze
Zitat von: smoudo am 18 November 2016, 20:07:16
Ich habe das Problem das mein sonoff nach Ca. 9min Inaktivität in fhem als absent angezeigt wird.
Sobald ich den Schalter am device drücke ist es sofort wieder da! Jemand eine Idee?
Ist die command reference an der Stelle so unverständlich formuliert? Die Frage ist, in diesem Fall, ernst gemeint und nicht rhetorisch ;)
Zitat
presenceCheck
Used to enable/disable presence check for ESPs
Presence check determines the presence of a device by readings age. If any reading of a device is newer than interval seconds than it is marked as being present. This kind of check works for ESP devices in deep sleep too but require at least 1 reading that is updated regularly.
So wie ich das verstehe fragt presence Check nach dem gesetzten interval ab und setzt den Status. Bei mir ist das device nach jeder Abfrage absent und erst wieder nach einem betätigen des Schalters am esp erreichbar! Sobald ich beide Attribute auf 0 setze ist der esp dauerhaft da! Allerdings zeigt es mir dann auch nicht an wenn ich den esp vom Netz nehme! WLAN am esp ist stabil da, sleep Mode ist aus.
Update: Habe versucht das ganze mit einem at Befehl zeitgesteuert zu schalten. Auch hier bekomme ich im log einen Timeout angezeigt. Wenn ich den Schaltvorgang nach ein paar Sekunden wiederhole, funktionierts!
Gibt es noch eine Art Standby im esp den man steuern kann? Oder im bridgemodul?
Bin grad ein bisschen ratlos.
Grüße
Matze
Zitat von: smoudo am 19 November 2016, 10:37:43So wie ich das verstehe fragt presence Check nach dem gesetzten interval ab und setzt den Status.
So wie ich das sehe, verstehst Du das falsch. Bei jedem Event was vom Device kommt wird quasi die Stoppuhr der Präsenz auf 0 gesetzt und läuft los. Ist die Zeit auf der Stoppuhr größer als der Wert vom Attribut Intervall, dann wird das Device auf Abwesend gesetzt. IMHO läuft da keine Kommunikation mit dem ESP.
Zitat von: smoudo am 19 November 2016, 10:37:43Bei mir ist das device nach jeder Abfrage absent und erst wieder nach einem Betätigen des Schalters am esp erreichbar!
Ich gehe mal davon aus, dass Du meinst, einen der Taster die Du überwachst, nicht Reset o.ä.. Nach dem oben beschriebenen Verfahren der Abwesenheitserkennung ist das ja erst einmal grundsätzlich richtig. Ich gehe auch mal davon aus, dass die Konfig-Seiten des ESP dauerhaft verfügbar sind.
Zitat von: smoudo am 19 November 2016, 10:37:43Sobald ich beide Attribute auf 0 setze ist der esp dauerhaft da! Allerdings zeigt es mir dann auch nicht an wenn ich den esp vom Netz nehme!
Damit das funktioniert braucht es eine zyklische Meldung vom ESP. Das kann man aber ganz leicht realisieren (s. Screenshot im Anhang). Evtl. ist RSSI zur Problembeobachtung viel interessanter, aber was Du sendest ist für Dein Thema erst einmal egal. Bei 45 Sekunden Delay kann man dann das Intervall auf 60 Sekunden setzen und hat eine recht enge Überwachung. Allerdings nicht in dem Taster, sondern in einem extra Device, aber dass kann man ja auf Wunsch miteinander verheiraten.
zyklische Grüße
Niels
Danke @Muschelpuster & dev0
ich dachte die Kommunikation geht von fhem aus!
Wieder was gelernt!
Grüße
Matze
ESPEasy Modulversion 0.71 auf Github verfügbar.
- Modulintern wurde für das presence und state Reading bisher event-on-change-reading angewendet. Meiner jetzigen Ansicht nach ist das aber nicht korrekt, da der Anwender selbst entscheiden sollte, ob Events generiert werden sollen oder nicht und habe es geändert. Bspw. konnten die fehlenden Events bei Loggen von state störend sein.
Mit den globalen Attributen event-on-change-reading, event-on-update-reading, event-min-interval und timestamp-on-change-reading kann nun jeder selbst das gewünschte Verhalten einstellen. Details siehe: readingFnAttributes (http://fhem.de//commandref.html#readingFnAttributes)
- Da ich mehrfach darum gebeten wurde, habe ich eine Möglichkeit ins Modul eingebaut, um auf einfache(?) Weise, RGB Lampen zu steuern: Wenn das Attribut 'rgbGPIOs' definiert ist, dann steht der neue set-Befehl 'rgb' zur Verfügung. Mit dem Attribut 'colorpicker' kann ausgewählt werden, ob das Colorpicker Widget im RGB, HSV oder HSVp Modus angezeigt wird, wenn 'rgb' im Attribute 'webCmd' verwendet wird. In der Command Reference (https://github.com/ddtlabs/ESPEasy/wiki/1.2-Command-Reference) findet sich ein Beispiel zur Verwendung.
- Wie angekündigt, wurde das Attribut uniqIDs entfernt.
Zitat von: dev0 am 20 November 2016, 11:38:23
ESPEasy Modulversion 0.71 auf Github verfügbar.
Wenn ich mir die Bilder so anschaue, muss ich doch mal einen ESP hernehmen und schauen, was damit möglich ist ;D Leider sind momentan andere Dinge wichtiger :(
Zitat von: PeMue am 20 November 2016, 12:00:53
Wenn ich mir die Bilder so anschaue, muss ich doch mal einen ESP hernehmen und schauen, was damit möglich ist
Ich selbst bin von dieser Modul-RGB Lösung nicht wirklich überzeugt, da es mMn sinnvoller wäre ein ESPEasy Plugin dafür zu schreiben, aber um mich dort tiefer einzuarbeiten fehlt mir auch die Zeit. Das Modul nimmt einfach die RGB Werte und schickt 3 einzelne Kommandos an den ESP. Diese Modul Lösung war aber simple umzusetzen (Dank an Andre(?) für das verwendete color.pm Modul) und funktioniert zumindest bei mir auf dem Steckbrett ;)
Der RGB Plugin Feature Request im ESP Easy Forum ist mit "mit der Hardware nicht möglich" gekennzeichnet ?? Daher vermute ich, dass von den ESP Easy Leuten nichts in dieser Richtung zu erwarten ist. Vielleicht findet sich ja hier jemand, der das übernehmen mag...
Vielen Dank in die Mühe, die Du in das Modul steckst. So ist es auch Programmier-Legasthenikern wie mir ein recht einfacher Einstig in die ESP-Welt möglich. RGB eröffnet ja schon wieder neue Möglichkeiten ;)
Wäre es an dieser Stelle dann aber nicht konsequent, wahlweise auch RGBW zu unterstützen?
dankbare Grüße
Niels
Zitat von: Muschelpuster am 20 November 2016, 14:48:00
Wäre es an dieser Stelle dann aber nicht konsequent, wahlweise auch RGBW zu unterstützen?
Kann man, dann sollte man aber auch noch WW+CW, Gammakorrektur, Weißabgleich, Fading, Command Queues, usw. unterstützen.
Alles kein Hexenwerk, man muss sich _nur_ damit beschäftigen. Wenn Du (oder jemand anderes) einen Patch schreiben möchtest, nur zu, die meisten Routinen wird man sogar in anderen FHEM Modulen finden. Ausreden ala "Programmier-Legastheniker" lasse ich nicht gelten, denn vor einem Jahr dachte ich auch noch, dass Perl ein billiger Online-Händler wäre.
Hallo,
ich habe noch einen bug beim setzen des GPIO-Ausganges gefunden. Irgendwie kann ich über FHEM (set ESP8266 gpio 0 1) nicht den GPIO 0 setzen. Über einen http-command geht es aber. Das müsste also ein bug des FHEM-Modules sein, oder? ::)
Edit: Die GPIO4 und 5 funktionieren über FHEM... Nur falls jemand fragt, ob es überhaupt klappt ;D
LG
Zitat von: Elektrofreak am 21 November 2016, 20:54:01
ich habe noch einen bug beim setzen des GPIO-Ausganges gefunden. Irgendwie kann ich über FHEM (set ESP8266 gpio 0 1) nicht den GPIO 0 setzen.
Gefixed und auf Github eingecheckt.
Zitat von: dev0 am 22 November 2016, 05:39:05
Gefixed und auf Github eingecheckt.
Danke, werde ich heute oder morgen Abend ausprobieren ;)
Habe das modul heute mal eingesetzt, da ich es besser finde als MQTT. Allerdings zeigt der bei mir immer nur 1 als wert an, von meinen Sensoren :(
Habe ein eigenes CO2 Sensor plugin für das MHZ-14 im Einsatz und BME280, alle zeigen aber nur 1 anstatt den Messwert. in MQTT funktioniert das allerdings ohne Probleme.
Woran kann das liegen, habe ich ewtl etwas beim Konfigurieren übersehen ?
ESP Easy Version 145
Die ArduinoJson Lib ist zu alt. Siehe ersten Beitrag.
Ohh, hatte die in Ubuntu upgedatet aber nicht an den ESP gedacht :(
So Update durchgeführt, werte kommen an :D
Kaum macht man es richtig geht es ;D
Danke dev0
O.T was mir jetzt aufgefallen ist, das mein Online Update nicht geht, beim Upload kommt immer Fehler, musste die ESP manuell flashen :(
Kennt jemand den Fehler ? .ERROR[8]: Flash config wrong real: 4194304 IDE: 16777216 ist ein ESP12E oder F . Ist bei 3 von meinen 4 Sensoren der fall, der 4 geht aber ich sehe keinen Unterschied zwischen den Sensoren.
Hallo dev0,
vielen Dank für das Modul!
Hast du das Protkoll-Plugin für ESP Easy auch geschrieben? Ich frage nur, weil ich aktuell Probleme damit habe.
Ich verwende derzeit einen ESP8266 ESP-12E NodeMCU v1.0. Wenn ich meine FHEM-Devices über das HTTP Protokoll aktualisieren lassen, läuft der ESP ohne Probleme tagelang. Sobald ich auf FHEM HTTP umstelle, kann ich darauf warten, dass er nach kurzer Zeit immer wieder mit einem wdt reset bootet. Aber scheinbar immer beim client.connect(...). Mal ständig, dann mal wieder nach 10 Minuten. Soweit ich das sehe wird ja nur zusätzlich das JSON in den Body geschrieben. Ich probiere nun schon seit Tagen....
Vielleicht hatte ja jemand auch das Problem?
Vielen Dank.
Ja, das HTTP-FHEM Controller Plugin ist auch von mir.
Ich kann das Problem nicht nachvollziehen, meine Wemos Module und einzelne ESP8266 haben aktuell uptimes von 40-50 Tagen und senden Daten im 10s Takt. Ich habe bisher auch noch nichts davon gehört.
Es soll bei suspekten Problem schon geholfen haben das komplette Flash zu löschen.
Zur anderen Frage: Das ESPEasy Modul verwendet nur die JSON Daten, alternativ kann man statt des ESPEasy Moduls auch auf einen FHEMWEB Port connecten um dann die Daten in Dummy Readings zu schreiben. Hierbei werden die Daten über die url übergeben: ?cmd=...
Letztere Variante wird auf Dauer aus dem Plugin entfernt. Ich wollte aber vor dem nächsten ESPEasy Release keine größeren Änderungen mehr vornehmen.
Zitat von: dev0 am 22 November 2016, 05:39:05
Gefixed und auf Github eingecheckt.
Guten Morgen,
ich habe das Modul mit den Befehlen
update add https://raw.githubusercontent.com/ddtlabs/ESPEasy/master/controls_ESPEasy.txt
updatevor ca. einer Woche installiert, ein normales
updatescheint aber nicht das gefixte Modul nachzuladen. Im Header der Datei 34_ESPEasy.pm steht noch
# $Id: 34_ESPEasy.pm 72 2016-10-02 08:30:00Z dev0 $Es scheint also noch eine alte Version zu sein. Mache ich etwas falsch? ???
Hallo,
ich habe gestern mein erstes ESPEasy in Betrieb genommen. Daran hängen 2 Temperatursensoren, die auch korrekte Werte liefern. Leider habe ich über Nacht 2 Ausreißer Werte gehabt (s.u.). An welcher Stelle kann ich mit der Fehlersuche beginnen? Falls sich das nicht beheben läßt - kann man irgendwo einen plausibilitätscheck einbauen "Wenn Wert > 100 oder < -100 dann Wert verwerfen" ?
2016-11-24_00:00:21 13.50
2016-11-24_00:03:05 13.50
2016-11-24_00:09:21 13.50
2016-11-24_00:13:08 13.50
2016-11-24_00:14:22 13.50
2016-11-24_00:15:22 13.50
2016-11-24_00:18:12 13.50
2016-11-24_00:18:22 13.50
2016-11-24_00:19:22 13.50
2016-11-24_00:23:16 13.50
2016-11-24_00:23:22 13.44
2016-11-24_00:25:22 13.44
2016-11-24_00:28:21 13.44
2016-11-24_00:33:23 13.44
2016-11-24_00:33:23 13.44
2016-11-24_00:34:23 13.44
2016-11-24_00:38:23 13.44
2016-11-24_00:38:28 13.44
2016-11-24_00:39:23 13.44
2016-11-24_00:40:23 13.44
2016-11-24_00:43:29 13.44
2016-11-24_00:56:25 13.44
2016-11-24_00:58:36 13.44
2016-11-24_01:01:25 13.44
2016-11-24_01:02:25 13.44
2016-11-24_01:03:39 13.44
2016-11-24_01:04:26 13.44
2016-11-24_01:08:26 13.44
2016-11-24_01:08:42 13.44
2016-11-24_01:14:26 13.44
2016-11-24_01:18:46 13.44
2016-11-24_01:27:28 13.44
2016-11-24_01:28:55 13.44
2016-11-24_01:43:29 13.38
2016-11-24_01:44:07 13.38
2016-11-24_01:44:29 13.38
2016-11-24_01:45:29 13.38
2016-11-24_01:49:11 13.38
2016-11-24_01:54:29 13.44
2016-11-24_01:58:30 13.44
2016-11-24_01:59:16 13.44
2016-11-24_02:23:32 13.38
2016-11-24_02:26:49 13.38
2016-11-24_02:31:33 13.38
2016-11-24_02:31:54 13.38
2016-11-24_02:32:33 1575.75
2016-11-24_02:34:33 13.38
2016-11-24_02:36:55 13.38
2016-11-24_02:49:36 13.38
2016-11-24_02:52:01 13.38
2016-11-24_02:52:36 13.38
2016-11-24_02:57:06 13.38
2016-11-24_03:05:37 13.44
2016-11-24_03:07:08 13.44
2016-11-24_03:12:38 13.44
2016-11-24_03:15:38 13.44
2016-11-24_03:17:15 13.44
2016-11-24_03:17:38 13.38
2016-11-24_03:20:38 13.38
2016-11-24_03:21:38 13.38
2016-11-24_03:22:16 13.38
2016-11-24_03:24:38 13.38
2016-11-24_03:26:38 13.38
2016-11-24_03:27:17 13.38
2016-11-24_03:28:39 13.38
2016-11-24_03:29:39 13.38
2016-11-24_03:32:18 13.38
2016-11-24_03:43:40 13.44
2016-11-24_03:46:40 13.44
2016-11-24_03:47:23 13.44
2016-11-24_03:52:40 13.44
2016-11-24_03:57:28 13.44
2016-11-24_03:58:41 -2042.62
2016-11-24_04:00:41 13.44
2016-11-24_04:01:41 13.44
2016-11-24_04:02:31 13.44
2016-11-24_04:05:41 13.38
2016-11-24_04:07:32 13.38
2016-11-24_04:13:41 13.38
2016-11-24_04:17:37 13.38
2016-11-24_04:20:42 13.38
2016-11-24_04:22:40 13.38
2016-11-24_04:23:42 13.38
2016-11-24_04:27:41 13.38
2016-11-24_04:27:42 13.38
2016-11-24_04:32:44 13.38
2016-11-24_04:35:43 13.38
Welche Temperatursensoren hast Du?
Für einen Plausi-Check kannst Du ein userReading definieren.
Gesendet von iPad mit Tapatalk
Zitat von: Elektrofreak am 24 November 2016, 07:30:17
# $Id: 34_ESPEasy.pm 72 2016-10-02 08:30:00Z dev0 $
Es scheint also noch eine alte Version zu sein. Mache ich etwas falsch? ???
Du hast bereits die aktuelle Verison. Die $ID Zeile wird normalerweise automatisch durch das Einchecken ins offzielle FHEM SVN gesetzt. Damit sich der FHEM version Befehl nicht über eine fehlende ID beschwert, habe ich diese Fake-Zeile eingefügt und pflege nur die Verisons Nr. darin. In diesem Fall 72 -> Version 0.72. Nach einem Update und shutdown restart wird die Versoin in den Internals korrekt angezeigt.
Zitat von: JoWiemann am 24 November 2016, 09:45:33
Welche Temperatursensoren hast Du?
Für einen Plausi-Check kannst Du ein userReading definieren.
Gesendet von iPad mit Tapatalk
2 Stück DS18B20 (die Wasserdichten mit 1m Kabel) parallel an D4 mit einem 4,7k pullup zu VCC, also quasi Standard. Das soll eine Messung für Heizungs Vor-/Rücklauf werden.
Userreading ist klar, ich würde aber gern der Sache auf den Grund gehen. Momentan zeige ich die Daten nur in einem Chart an. Ich wüßte gern, ob die Daten falsch vom ESP kommen oder in der Bridge falsch aufbereitet werden. Ich habe die Bridge jetzt erstmal auf verbose 5 gestellt. Dort sieht man den JSON auflaufen - darüber sollte man es rausfinden. Ich vermute den Fehler eher im ESP. Leider ist ESPEasy schlecht dokumentiert, ich weiß nicht, ob man da mit "formula" was regeln kann. Ich denke aber eher nicht.
Zitat von: Waldmensch am 24 November 2016, 09:26:58
An welcher Stelle kann ich mit der Fehlersuche beginnen?
Vermutlich bei Deiner Hardware: zu lange Kabel, schlechte Lötstellen, defekter Sensor, ...
Zitat von: JoWiemann am 24 November 2016, 09:45:33
Für einen Plausi-Check kannst Du ein userReading definieren.
Oder das Reading mit dem Attribut adjustValue direkt modifizieren. Ab der nächsten Modulversion können Werte auch ignoriert werden, wenn die adjustValue Funktion undef zurückliefert. Besser aber Du findest den Fehler.
Zitat von: Waldmensch am 24 November 2016, 10:30:26
Ich wüßte gern, ob die Daten falsch vom ESP kommen oder in der Bridge falsch aufbereitet werden.
Wenn Du das adjustValue Attribut nicht gesetzt hast, dann werden die Werte nicht angefasst.
Der DS18B20 signalisiert über komische Temperaturen auch Fehlerzustände: http://datasheets.maximintegrated.com/en/ds/DS18B20.pdf . Leider taucht Dein Wert -2042.62 nicht auf.
Gesendet von iPad mit Tapatalk
Hardware: die 3 Lötstellen habe ich unter der Lupe begutachtet, das passt schon. Sensor defekt würde ich ausschließen. Der 2. Sensor hatte gestern auch einen Ausreißer. Dann müssten Beide defekt sein. Zudem werden in langer Folge normale Werte geliefert. Leider hängt der ESP momentan an einer Stelle wo er nur RSSI von -80 hat. Daran kann es aber glaube auch nicht liegen, da dann der JSON vermutlich, bei Netzwerkfehler, nicht lesbar wäre.
Werte ignorieren: klingt sehr gut, auch wenn es nur das Symptom bekämpft. Mit Userreading und adjustValue kann man ja nicht einen Wert ganz verwerfen, sondern nur modifizieren. Da könnte man maximal den letzten Wert aus der DB fischen und setzen. Ein Defaultwert würde ja auch immer einen knick im Diagramm bedeuten
adjustValue: ist nicht gesetzt, habe ich auch grade erst entdeckt ;)
Zitat von: Waldmensch am 24 November 2016, 10:53:53
Mit Userreading und adjustValue kann man ja nicht einen Wert ganz verwerfen, sondern nur modifizieren
Doch, das geht jetzt auch schon mit beiden Varianten indem Du mit ReadingsVal den alten Wert ausliest und diesen zurückgibst.
Zitat von: JoWiemann am 24 November 2016, 10:48:08
Der DS18B20 signalisiert über komische Temperaturen auch Fehlerzustände: http://datasheets.maximintegrated.com/en/ds/DS18B20.pdf . Leider taucht Dein Wert -2042.62 nicht auf.
Ich habe 3 Ausreißer im Datenblatt finde ich keine Fehlercodes (oder ich habe Tomaten auf den Augen):
Sensor1: 1575,69 (gestern abend)
Sensor2: 1575,75 (heute morgen s. Log)
Sensor2: -2042,62 (heute morgen s. Log)
Am Rande: Ich konnte über das rgbGPIOs-Dropdown bei den Attributen keine Auswahl treffen und habe das Attribut über die Befehlszeile setzen müssen.
attr ESPEasy_ESP01_LED_Green rgbGPIOs D6,D7,D8
Zitat von: FunkOdyssey am 24 November 2016, 11:50:11
Ich konnte über das rgbGPIOs-Dropdown bei den Attributen keine Auswahl treffen und habe das Attribut über die Befehlszeile setzen müssen.
Ist mir nicht aufgefallen, da ich es wohl nur über die command line getestet hatte. Ist in der nächsten Version gefixed oder Du entfernst in Zeile 254 den Doppelpunkt.
Ich muss das jetzt einfach mal loswerden: Dieses Modul ist ein verdammt geiles Stück Software (mal abgesehen von FHEM selbst natürlich ;) )
Vorher hatte ich sehr viele Dinge mit MQTT und Node-Red abgebildet. Jetzt wird das Stück für Stück "zurückgebaut". Läuft jetzt viel zuverlässiger.
Vielen Dank und bitte so weitermachen.
gruß
Danke für die Blumen, aber MQTT läuft unter FHEM in Verbindung mit dem Mosquitto Broker ebenfalls sehr stabil und hat auch seine Berechtigung.
Ich bin auch schwer begeistert . Ich habe 2 Hoflichter, die über FS20 nur sehr unzuverlässig arbeiten. Die werde ich auf WLAN mit diesen supergünstigen SONOFF Schaltern umrüsten. Da die auch nur einen ESP drin haben, werden die sofort auf ESP Easy umgeflasht. Billiger kann man keine FHEM 220V Aktoren kriegen
http://www.aliexpress.com/item/32744811540/32744811540.html
Gesendet von iPhone mit Tapatalk
Zitat von: thegimliboy am 24 November 2016, 17:58:50
Ich muss das jetzt einfach mal loswerden: Dieses Modul ist ein verdammt geiles Stück Software (mal abgesehen von FHEM selbst natürlich ;) )
Vorher hatte ich sehr viele Dinge mit MQTT und Node-Red abgebildet. Jetzt wird das Stück für Stück "zurückgebaut". Läuft jetzt viel zuverlässiger.
Vielen Dank und bitte so weitermachen.
gruß
Da schließe ich mich mal an! Top Arbeit! Danke Dev0!
Aktualisierte Modulversion 0.73 auf Github:
- Fixed: Attribut rgbGPIOs leeres Selectmenü in FHEMWEB.
- Erweiterung: Liefert die adjustValue Funktion 'undef' zurück, dann wird der empfangene Wert ignoriert. Modifizierte und ignorierte Werte werden im System Log (verbose 4) dementsprechend markiert. Verbose 5 liefert weitere Details dazu.
Kurze Rückmeldung: es sind keine Fehlmessungen mehr aufgetreten. Habe jetzt einen Platz mit -73 RSSI gefunden.
Update auf 0.73 gemacht, läuft unauffällig
Gesendet von iPhone mit Tapatalk
Edit: Sorry für den Mehrfachpost, Tapatalk war anscheinend der Meinung, dass es mehrfach senden müsste :-/
Ich arbeite gerade an ein esp easy plugin für den H801 RGBWW dimmer, soweit habe ich schon etwas rudimentär laufen.
Aktuelle Parameter im Plugin selber sind die Kanäle für die Ausgänge frei konfigurierbar um das auch auf anderer Hardware zu implementieren.
Kommandos sind aufgebaut wie folgt um möglichst Flexibel zu bleiben für die verschieden Einsatz Szenarien
rgbww,FFFFFFFFFF (Rot,Grün,Blau,W1,W2 0 bis 255 Hex)
rgb,FFFFFF (Rot,Grün,Blau 0 bis 255 Hex)
ww,FFFF ( Weiss kanal1, Weiss kanal2 0 bis 255 Hex) zum Mischen zwischen Kalt und Warmweiss
w1,FF (Weiss kanal1 0 bis 255 Hex)
w2,FF ((Weiss kanal2 0 bis 255 Hex)
noch nicht implementiert
scene,xx,yy ( scenen auswahl DEC, parameter DEC) um verschieden Szenarien abzubilden
Die Frage wie könnte ich das am besten Gestalten um mit dem FHEM Modul kompatibel bin um collor picker, mischer usw.. einzusetzen, die Befehlsstruktur kann ich natürlich noch anpassen
Nur mal interessehalber, meinst Du diesen hier? Einen ESP hat der ja sicher drin, aber 500mW ist ja gar nichts.
Schau, was ich auf AliExpress gefunden
http://www.aliexpress.com/item/32634286022/32634286022.html
Andererseits hängen da meist zig LED dran, wie z.B in diesem Video. Das sind doch mehr als 500mW
https://youtu.be/OrIDz9ky8zk
Gesendet von iPhone mit Tapatalk
Zitat von: Maiks am 26 November 2016, 12:48:21
Ich arbeite gerade an ein esp easy plugin für den H801 RGBWW dimmer, soweit habe ich schon etwas rudimentär laufen
Hört sich gut an, ich habe hier zum Testen auch noch einen H801er liegen, aber noch nicht mit ESPEasy geflashed (weigert sich noch).
Zitat von: Maiks am 26 November 2016, 12:48:21
Die Frage wie könnte ich das am besten Gestalten um mit dem FHEM Modul kompatibel bin um collor picker, mischer usw.. einzusetzen, die Befehlsstruktur kann ich natürlich noch anpassen
Aus dem Bauch würde ich sagen, dass FHEM (bzw. color.pm (http://www.fhemwiki.de/wiki/Color)) nur "echte" 6-stellige RGB Werte unterstützt. Bei 4/5 Kanälen kommen wir mit rgb nicht weiter, CT bzw. echtest HSV müßte vom Plugin unterstützt werden, wenn ich das richtig verstanden habe. Ich habe mich aber mit den ganzen Farbmodellen noch nicht wirklich auseinandergesetzt.
Vielleicht liest justme1968 oder auch jemand anderes hier mit und kann aushelfen?
Wenn Änderungen/Erweiterungen am ESPEasy Modul notwenig sind, dann bau ich die gerne ein, um das Plugin zu unterstützen. Muss aber auch erst einmal drüber nachdenken wie und was... ;)
Zitat von: Waldmensch am 26 November 2016, 12:56:29
aber 500mW ist ja gar nichts.
Dann ist die Beschreibung falsch, es sind 3A (oder sogar 5A?) pro Kanal.
Okay, 2 geordert. Stehe dann in 3-4 Wochen als Tester zur Verfügung. Diese ESP Dinger machen irgendwie süchtig
Ja das ist der H801, die Angabe ist definitiv falsch habe auch einen Langen Streifen dran.
Das einzig dumme ist, das beim Strom an die LEDS alle für ein paar Sekunden eingeschaltet werden, da der Ausgang beim ESP sich resetet beim einschalten und ESP EASY langsam ist, die Eingänge zu Initialisieren, mit meiner eigenen test FW sind es nur Bruchteile einer Sekunde. Aber ich mag ESP Easy, hat alles integriert was man braucht incl online update. Habe schon mehrere Module mit ESP Easy gebaut CO2 Sensor mit MH-Z14 und einen Tür Gong mit einem MP3 modul :D Jeweils mit eigenen plugins in ESP Easy, was mir sogar als nicht "Programmierer" möglich war 8)
Na wenn deine eigene FW schneller ist, simuliere doch einfach ESPEasy, damit es zum Modul kompatibel ist. Ist ja niemand mit ESPeasy verheiratet
Gesendet von iPhone mit Tapatalk
Das könnte man machen, aber da muss halt alles drumherum noch gemacht werden.
Hatte die eigene nur sehr Rudimentär gemacht um etwas zu schalten und ESP Easy finde ich einfach super von den Möglichkeiten, muss nur ein plugin schreiben und das ganze handling drumherum ist schon fertig und man kann zusätzlich auch andere Sensoren mit anschließen ohne Programmieraufwand usw...
Es betrifft übrigens nur den Moment wo Strom eingeschaltet wird, das ist ein Problem vom Design des ESP und dem H801, das ist auch bei der Originalen FW zu beobachten. Bei mir ist aber der Strom normaler weise immer an am H801 ;)
Man kann auch das https://forum.fhem.de/index.php/topic,48918.0.html Projekt nehmen, dort ist sehr viel abgedeckt, dass sieht sehr gut aus. Für mich ist eigentlich das Ansteuern von Weiss und RGB direkt mit Farbauswahl das was ausreicht ohne blinken usw.....
Hallo
Gibt es eine Möglichkeit mit dem ESPEasy oder FHEM einen Ausgang an dem ESP für 0,10 sec zu schalten ?
0,10 ist nur ein Beispiel!
Egal ob von 0 zu 1 oder 1 zu 0.
Mit einem notify ist mir das zu unsicher.
Wenn es so was in der ESPEasy Firmware geben könnte wäre das ne feine Sache.
Würde gerne eine Tastendruck simulieren um z.B. Geräte zu schalten. Oder anders gesagt um die Knöpfe an Geräte / Kaffeemaschine etc. zu betätigen.
Gruß
set <esp> pulse <pin> <duration in ms>
Zitat von: Maiks am 26 November 2016, 12:48:21
Ich arbeite gerade an ein esp easy plugin für den H801 RGBWW dimmer
Wo findes ich das Plugin? Im ESPEasyPluginPlayground (https://github.com/ESP8266nu/ESPEasyPluginPlayground) habe ich es nicht entdeckt. Hast Du vor das Plugin offiziell in ESPEasy zu integrieren?
Zitat von: Maiks am 26 November 2016, 12:48:21
rgbww,FFFFFFFFFF (Rot,Grün,Blau,W1,W2 0 bis 255 Hex)
Du wirst nicht umhinkommen dich mit Farbmodellen zu beschäftigen und diese in Dein Plugin zu integrieren, rgb reicht an der Stelle mWn nicht aus. Zumindest dann nicht, wenn man mehr als 3 Kanäle unterstützen möchte. ct (Farbtemperatur in kelvin) benötigest Du bspw. um den, in FHEM verfügbaren, ct colorpicker zu benutzen. Theoretisch kann man das natürlich alles im Modul abbilden und umrechnen, aber es ist ja eben Sinn eines rgb Plugins, diese Aufgaben selbständig in _Echtzeit_ (vll. sogar mit weichen Übergängen) zu übernehmen.
Ich könnte Dir eine Modulversion zum Testen aufbereiten, die rgb, hsv, xy und ct an den ESP schickt um die Colorpicker nutzen zu können, wenn Du das Plugin in diese Richtung weiterentwickeln möchtest.
Btw: Wenn ich hier über Farbmodelle schreibe, dann bewege ich mich auf ganz dünnen Eis ;) Wenn Du konkrete Unterstützung bei der Umsetzung oder Planung benötigst, dann macht es wahrscheinlich mehr Sinn einen eigenen Thread dafür zu starten, der auch von unseren Farbprofis gelesen wird.
Ich bin gerade noch am Anfang vom Modul, erst mal das erste zum laufen zu bekommen, daher ist es nicht bei Playgrounds eingecheckt.
Farbräume usw... ist noch (wenn überhaupt) in weiter ferne. Da muss ich auch noch meine Programmierfähigkeiten Erweitern. Ich kann das mal hier hoch laden sobald ich ein wenig weiter bin.
Aktuell ist es ziemlich dumm und macht nur RGB und Weiss ohne schnick schnack.
Habe color picker jetzt mal über dummy gelöst und raw senden,geht auch ganz gut für RGB.
Dimmen wollte ich jetzt vermutlich bei mir über Befehl einbauen, z.b dimup dimdown pro Befehl immer eins runter oder rauf.
Mit den Befehlen einbinden sollten wir noch warten ob die Struktur überhaupt Sinn macht oder nicht.
Im WifiLight Modul findest Du vielleicht auch noch Anregungen/Funktionen/Formeln. z.B. WifiLight_HSV2fourChannel() um den Weißanteil aus dem HSV/RGB Wert herauszuziehen um einen getrennten Weißkanal anzusteuern ansatt die rgb-Weißmischung zu benutzen. Diesen Weißanteil könnte man dann noch in ww/cw splitten...
Hallo zusammen,
irgendwie vermisse ich in dem Modul einen set-Parameter: irsend.
ESPEasy unterstützt das Senden von Infrarot-Fernsteuerbefehlen.
Die folgende Notify-Definition funktioniert, ist aber unschön:
Yamaha_Power:toggle { GetHttpFile("192.168.17.170:80", "/control?cmd=IRSEND,NEC,7E81542B,32") }
Da wäre ein "set ESPEasy_ir1 set irsend NEC 7E81542B 32" zur Nutzung der ESPEasy-Bridge doch deutlich schöner.
(Der Befehl schaltet einen Yamaha Receiver R-S600 ein bzw aus, weitere Befehle habe ich noch nicht eingebaut).
Gibt es evtl. eine Möglichkeit, "raw" Daten an das Modul zu übergeben?
Das Empfangen von IR-Steuerbefehlen geht einwandfrei, die Möglichkeiten der Auswertung auf dem ESPEasy sind limitiert, reichen aber aus.
Für beides nutze ich ein kleines IR-Transceivermodul mit einem ESP-01. Es wurde bereits einiges Gerät damit getestet, TV-Geräte, einen Blu-Ray Player, LED-Streifen aus dem Baumarkt etc.
Link zum ESPEasy-Forenthread: http://www.letscontrolit.com/forum/viewtopic.php?f=5&t=328&hilit=IRSEND (http://www.letscontrolit.com/forum/viewtopic.php?f=5&t=328&hilit=IRSEND)
Zitat von: Shardan am 27 November 2016, 22:22:02
irgendwie vermisse ich in dem Modul einen set-Parameter: irsend.
Wenn das Plugin Teil der ESPEasy Software ist, dann werde ich den Befehl ins Modul aufnehmen.
Zitat von: Shardan am 27 November 2016, 22:22:02
Gibt es evtl. eine Möglichkeit, "raw" Daten an das Modul zu übergeben?
Ja, siehe commandref.
Hallo dev0,
das wäre super, vielen Dank.
Ja, siehe z.B. hier: http://letscontrolit.com/wiki/index.php/IRTX (http://letscontrolit.com/wiki/index.php/IRTX)
Das PlugIn ist Bestandteil der normalen Binaries bzw Sources.
ZitatJa, siehe commandref.
Kannst du mir bitte mal ein Beispiel geben?
In der Commandref habe ich nach ESPEasy und ESPBridge gesucht, keine Treffer.. ESP8266 als Suche führt in etwas andere Gefilde.
Ansonsten: Danke für das supereinfach benutzbare Modul.... da ich eher hardwarelastig bin und
Perl für mich eher eine Elektro-Resterampe sind solche Module eine unbezahlbare Hilfe.
LG
Shardan
Zitat von: Shardan am 28 November 2016, 15:32:45Kannst du mir bitte mal ein Beispiel geben?
In der Commandref habe ich nach ESPEasy und ESPBridge gesucht, keine Treffer.. ESP8266 als Suche führt in etwas andere Gefilde.
Wenn Du unter einem ESPEasy-Device einfach auf den Link 'Device specific help' klickst, dann findest Du folgendes unter set:
Zitat von: Device specific helpraw
Can be used for own ESP plugins that are not considered at the moment.
Usage: raw <cmd> <param1> <param2> <...>
eg: raw myCommand 3 1 2
Kannst Du auch im Device neben der set-Funktion im Pulldown-Menü finden.
nachgeschlagene Grüße
Niels
Wo ist die Syntax zum irsend (gibt es noch weitere?) Befehl offiziell beschrieben? In der ESPEasy command ref. ist der Befehl nicht enthalten. Deshalb ist irsend auch noch nicht im Modul verfügbar.
Hallo dev0,
eine "offizielle" Beschreibung gibt es derzeit wohl nicht, soweit ich das sehe.
In dem Thread unter http://www.letscontrolit.com/forum/viewtopic.php?f=5&t=328&hilit=IRSEND (http://www.letscontrolit.com/forum/viewtopic.php?f=5&t=328&hilit=IRSEND) sind eine Menge Info's,
das scheint wohl auf der arduino "irremote" Library zu beruhen, die für den ESP8266 angepasst wurde (IRremoteESP8266).
Ohne Gewähr, der Thread ist da etwas verwirrend.
Anyways, ich habe grade mal das Modul (P035_IRTX.ino) durchgesehen. Die Syntax geht demnach:
control?cmd=IRSEND,<Protokoll>,<Hexcode>,<Länge>
Protokoll: kann lt. Sourcecode dabei sein: NEC, JVC, RC5, RC6, SAMSUNG, SONY, PANASONIC.
Hexcode: Der auszusendende Code in Hexadezimalschreibweise
Länge: Die Bitlänge des Codes.
Das alles ist ein kommagetrennter Befehl, daher gehe ich mal davon aus, dass das alles ein String als Datentyp ist.
Beste Grüße
Shardan
Version 0.74 incl. irsend verfügbar.
Super, das ging ja schnell... Vielen Dank dafür.
Ich stoße heute abend das Update an und teste es.
Ich bekomme gelegentlich folgende Fehlermeldung:
ESPEasy Beleuchtung: WARNING: http://192.169.179.71:80/control?cmd=mcpgpio,10,1: empty answer received
Kann man irgendwie definieren, dass der Befehl noch mal wiederholt wird, wenn der ESPEasy nichts zurück meldet?
Hallo dev0,
der IRSEND funktioniert bis jetzt tadellos.
Vielen Dank für deine Mühe mit dem Modul und der Erweiterung.
Shardan
Zitat von: max333 am 29 November 2016, 20:43:50
Ich bekomme gelegentlich folgende Fehlermeldung:
ESPEasy Beleuchtung: WARNING: http://192.169.179.71:80/control?cmd=mcpgpio,10,1: empty answer received
Kann man irgendwie definieren, dass der Befehl noch mal wiederholt wird, wenn der ESPEasy nichts zurück meldet?
Hallo Max333,
das scheint möglicherweise ein Problem des ESP zu sein, das in den letzten Tagen im dortigen Forum die Runde macht:
Der Webserver antwortet (zumindest zeitweise) nicht mehr. ( http://www.letscontrolit.com/forum/viewtopic.php?f=6&t=2107&start=100 (http://www.letscontrolit.com/forum/viewtopic.php?f=6&t=2107&start=100) )
Reagiert dein ESP denn, wenn du den Befehl mehrfach sendest?
Wenn nicht, ist das evtl. das beschriebene Problem. In dem Falle erstmal ein Upgrade auf R146 oder R147 versuchen.
Grüße
Shardan
Zitat von: max333 am 29 November 2016, 20:43:50
ESPEasy Beleuchtung: WARNING: http://192.169.179.71:80/control?cmd=mcpgpio,10,1: empty answer received
Kann man irgendwie definieren, dass der Befehl noch mal wiederholt wird, wenn der ESPEasy nichts zurück meldet?
Das ist mAn ein Fehler der ESPEasy Software, das Modul meldet nur, dass die Antwort keinen Inhalt hatte. Ich halte es (erst einmal) für sinnvoller das Problem auf ESP Seite zu beheben (wenn es eins gibt). Frag doch mal bei den ESPEasy Entwicklern nach.
Diese Fehlermeldung kommt fast immer, wenn 2 verschiedene DOIF zur selben Zeit auf dem gleichen ESPEasy verschiedene Ausgänge schalten. Der erste Befehl wird ausgeführt und der 2. nicht. Deshalb habe ich schon die Schaltpunkte verschoben, jedoch kann es dennnoch vorkommen. Da wäre es schön, wenn der Befehl wiederholt wird.
Wenn ich mit manuell über die Weboberfläche schalte, dann funktioniert das zuverlässig.
Ich habe noch mal mein Log-File durchsucht, die letzte Fehlermeldung kam, als genau in der gleichen Sekunde zusätzlich 2 Funksteckdosen geschalten wurden. Diese haben auch geschaltet, nur der ESP nicht. Der 433Mhz Sender ist nicht in der Nähe des ESPs montiert.
Ich implemetiere zur Zeit eine command queue, damit nicht zu viele gleichzeitige Verbindungen zum ESP aufgebaut werden. Das wird aber nicht dein Problem beheben, da ESPEasy mit zumindest 4 oder soagr 5 Verbindungen "gleichzeitig" umgehen kann. Ein resend bei einer leeren Antwort ist zur Zeit nicht geplant, da ich die Notwendigkeit (noch?) nicht sehe.
Um das zu klären kannst du mal einen einfachen Test machen:
Setz in die DOIF doch mal eine Zeitverzögerung, so dass die Befehle nicht auf einen Schlag durchlaufen, sondern nacheinander mit 0,3...1 Sekunden Verzögerung.
Das zeigt, ob da etwas im ESP hakt oder im FHEM.
Grüße
Shardan
Wenn in einem DOIF die Befehle direkt nacheinander gesendet werden, habe ich keinerlei Fehler, nur wenn 2 unterschiedliche DOIF zur gleichen Zeit senden wollen, dann wird nur ein Befehl ausgeführt.
Hallo,
ich habe noch eine Frage:
Wenn ich den befehl longPulse verwenden möchte, bekomme ich folgende Meldung:
Zitat
Command 'longpulse' is deactivated until attribute 'rgbGPIOs' is set.
Ich möchte aber keine rgb-LEDs verwenden ::). Was muss ich machen? :P
Ich tippe auf eine nachlässig geschriebene regexp, die in meiner aktuellen Version schon gefixt ist, da ich es nicht nachvollziehen kann. Ich tippe drauf, dass Du eventMap verwendest...
Nimm mal bitte die Version aus dem staging branch https://github.com/ddtlabs/ESPEasy/tree/Staging und sag bitte bescheid ob es damit wieder funktioniert.
Zitat von: Kalli01 am 26 August 2016, 19:48:18
Ein angelegter Switch an GPIO 14 wird aber nur in der Oberfläche von ESPeasy angezeigt. Der Status in FHEM steht immer auf off.
Version ist die R120
Was muss ich machen, um einen Schalter mit seinen Status in FHEM zu sehen?
Hallo,
ich habe scheinbar das selbe Problem, die Antwort von dev0 war, dass es in R120 einen Fehler gab, und dass Input Switch als Device versendet werden soll.
Ich nutze aktuell R147 und möchte ein Sonoff einbinden. GPIO12 ist der zu schaltende Pin.
Damit der Webschalter funktioniert behelfe ich mich aktuell, indem ich auf "Relay" statt "GPIO12" abfrage da der Status vom Relay richtig gesetzt wird.
Meine Definition und ein Screenshot der ESP-Definition angehängt. Irgend eine Idee? Kann es sein, dass R147 den Fehler aus R120 immer noch hat?
Danke für eure Tips!
Ich habe fertige BIN installiert ... Quelle: http://www.letscontrolit.com/wiki/index.php/ESPEasy#Loading_firmware (http://www.letscontrolit.com/wiki/index.php/ESPEasy#Loading_firmware)
define espBridge ESPEasy bridge 8383
attr espBridge room ESPEasy
define ESP_SW2 ESPEasy 192.168.0.39 80 espBridge ESP_SW2_SW2
attr ESP_SW2 DbLogExclude .*
attr ESP_SW2 IODev espBridge
attr ESP_SW2 Interval 300
attr ESP_SW2 devStateIcon on:ios-on-blue:off off:ios-off:on absent:10px-kreis-rot:statusRequest .*:ios-NACK:check
attr ESP_SW2 eventMap /gpio 12 on:on/gpio 12 off:off/status gpio 12:check/
attr ESP_SW2 group ESPEasy Device
attr ESP_SW2 room ESPEasy
attr ESP_SW2 stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"Relay","")}
#attr ESP_SW2 stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"GPIO12","")}
attr ESP_SW2 webCmd on:off
attr ESP_SW2 setState 3
Zitat von: kadettilac89 am 04 Dezember 2016, 08:23:45
Damit der Webschalter funktioniert behelfe ich mich aktuell, indem ich auf "Relay" statt "GPIO12" abfrage da der Status vom Relay richtig gesetzt wird.
Wenn der ESP Device Name Relay ist, dann muss Du natürlich auch Relay in stateFormat verwenden. Wenn der verwendete Name GPIO12 ist, dann GPIO12.
ZitatKann es sein, dass R147 den Fehler aus R120 immer noch hat?
Ich verstehe dein Problem nocht nicht. Was funktioniert denn jetzt konkret nicht?
Im staging branch liegt die Modulversion 0.76 bereit. Da es intern einige Änderungen gab, möchte ich die Version noch nicht im master branch automatisch verteilen lassen, bis ich ein paar Rückmeldungen bekomme. Der Idealfall wäre natürlich, wenn die neuen Funktionen explizit getestet würden. (Das Queuing wird in dieser Version noch mit verbose 3 gelogged)
https://github.com/ddtlabs/ESPEasy/tree/Staging
Was ist neu:
Zitat
0.7.5 - Added a command queue due to not overrun esp's ip stack (limit concurrent sessions)
- Added attr maxQueueSize (default 250)
- Added attr maxHttpSessions (default 5)
- Added attr resendFailedCmd (default enabled)
- Added bridge commands: get queueSizes, set clearQueue
- status command returns "?" in cause of of unknown gpio state
- removed useless predefined subs, shutdown restart is required after module update
0.7.6 - revised more inexact regexps
shutdown restart required after update. Do not use reload!
Das Neue in dieser Version ist eine sogenannte 'Command Queue', die Befehle zwischenspeichert um:
- den ESP nicht, mit zuvielen "gleichzeitigen" Anfragen, zu überlasten.
- bei nicht Erreichbarkeit die Befehle wiederholt zu senden
Konfigurierbar sind die maximalen Einträge der Queue (attr maxQueueSize, default 250, möglich 10..∞) und ab wievielen "gleichzeitigen" Requests Befehle in die Queue geschoben werden (attr maxHttpSessions, default 5, möglich 1-9, 0 = Queuing disabled). Befehle, die eine Fehlermeldung (warning im log) verursacht haben, werden (wieder) an den Anfang der Queue gestellt, damit sie als nächstes wieder an der Reihe sind (FIFO bleibt erhalten). Sollen Befehle verworfen werden, die einen Fehler erzeugt haben, dann kann man das auch einstellen (attr: resendFailedCmd, default: 1 (resend enabled), möglich: 0|1). Ist die Queue voll, dann werden alle weiteren Befehle verworfen und geloggt. Es gibt pro ESP jeweils eine getrennte Queue.
Meine Erfahrung bisher ist, dass der ESP 5 Requests verträgt bevor es sich komisch verhält. Getestet habe ich das mit den Befehlen status,pwm und gpio. Komisch heißt an der Stelle: reboot des ESP oder auch das von max333 angesprochene "empty answer received". Die Anzahl der gleichzeitig möglichen Requests hängt aber vielleicht auch noch von den verwendeten Plugins/Devices ab.
Was ich moch frage ist: Mit welchem verbose level soll gelogged werden, dass Befehle verworfen werden, wenn eine Queue voll ist?
Ich meine: eigentlich mit min. 2, da schließlich Befehle verworfen werden. Auf der anderen Seite kann das aber auch das Log fluten, wenn z.b. im 30s Takt zehn GPIOs gepollt werden (attr pollGPIOs) und der ESP nicht erreichbar ist.
Alternativen wären:
- den Befehl status nicht zu loggen um das Volumen zu reduzieren (status wird benutzt u.a. beim Polling benutzt)
- Verbose 5, um es nur beim Debugging zu loggen.
Meinungen?
Probleme?
Zitat von: dev0 am 04 Dezember 2016, 08:37:23
Wenn der ESP Device Name Relay ist, dann muss Du natürlich auch Relay in stateFormat verwenden. Wenn der verwendete Name GPIO12 ist, dann GPIO12.
Ich verstehe dein Problem nocht nicht. Was funktioniert denn jetzt konkret nicht?
Device name ist Relay, das habe auch im stateFormat. Wenn ich Fhem neu starte habe ich als status von Relay "gpio" woraufhin das Icon den Zustand für undefiniert anzeigt da "on" oder "off" erwartet wird. Hier hätte ich gerne den Zustand der vor dem Reboot gesetzt war.
Da Relay und GPIO12 als Reading automatisch angelegt wurden, hatte ich erwartet dass GPIO12 von Relay gesetzt wird. Darum habe ich auch mit GPIO12 getestet. Der Wert von GPIO12 wird auch in fhem.save als letzter Wert off gespeichert, er ist halt immer "off". Oder hat GPIO12 einen anderen Zweck, oder ist beim Autocreate was falsch gelaufen?
Die eigentliche Frage ... gibt es eine Möglichkeit, den letzten Wert von Relay in die fhem.save aufzunehmen und beim Starten zu übernehmen?
List direkt nach Reboot
Internals:
CFGFN ./config/LivingRoom_DBLog.cfg
DEF 192.168.0.39 80 espBridge ESP_SW2_SW2
HOST 192.168.0.39
IDENT ESP_SW2_SW2
INTERVAL 300
IODev espBridge
LASTInputDev espBridge
MSGCNT 2
NAME ESP_SW2
NOTIFYDEV global
NR 173
NTFY_ORDER 50-ESP_SW2
PORT 80
STATE gpio
SUBTYPE device
TYPE ESPEasy
VERSION 0.75
espBridge_MSGCNT 2
espBridge_TIME 2016-12-04 11:31:46
Readings:
2016-12-04 11:31:46 GPIO12 off
2016-12-04 11:31:46 GPIO12_mode output
2016-12-03 17:56:57 Key gpio
2016-12-04 11:31:08 Relay gpio
2016-12-04 11:31:07 presence present
2016-12-04 11:31:46 state GPI: off
Helper:
fpc 1480847492
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 304
TRIGGERTIME 04.12.2016 11:36:35
Received:
GPIO12 1480847506
GPIO12_mode 1480847506
Attributes:
DbLogExclude .*
IODev espBridge
Interval 300
devStateIcon on:ios-on-blue:off off:ios-off:on absent:10px-kreis-rot:statusRequest .*:ios-NACK:check
eventMap /gpio 12 on:on/gpio 12 off:off/status gpio 12:check/
group ESPEasy Device
presenceCheck 1
readingSwitchText 1
room ESPEasy
setState 3
stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"Relay","")}
webCmd on:off
List nachdem der Schalter "on" ist
Internals:
CFGFN ./config/LivingRoom_DBLog.cfg
DEF 192.168.0.39 80 espBridge ESP_SW2_SW2
ESP_BUILD 147
ESP_SLEEP 0
ESP_UNIT 0
HOST 192.168.0.39
IDENT ESP_SW2_SW2
INTERVAL 300
IODev espBridge
LASTInputDev espBridge
MSGCNT 3
NAME ESP_SW2
NOTIFYDEV global
NR 173
NTFY_ORDER 50-ESP_SW2
PORT 80
STATE on
SUBTYPE device
TYPE ESPEasy
VERSION 0.75
espBridge_MSGCNT 3
espBridge_TIME 2016-12-04 11:35:27
Readings:
2016-12-04 11:31:46 GPIO12 off
2016-12-04 11:31:46 GPIO12_mode output
2016-12-03 17:56:57 Key gpio
2016-12-04 11:35:27 Relay on
2016-12-04 11:31:07 presence present
2016-12-04 11:35:27 state GPI: off Rel: on
Helper:
fpc 1480847492
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 304
TRIGGERTIME 04.12.2016 11:36:35
Received:
GPIO12 1480847506
GPIO12_mode 1480847506
Relay 1480847727
Attributes:
DbLogExclude .*
IODev espBridge
Interval 300
devStateIcon on:ios-on-blue:off off:ios-off:on absent:10px-kreis-rot:statusRequest .*:ios-NACK:check
eventMap /gpio 12 on:on/gpio 12 off:off/status gpio 12:check/
group ESPEasy Device
presenceCheck 1
readingSwitchText 1
room ESPEasy
setState 3
stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"Relay","")}
webCmd on:off
Zitat von: dev0 am 04 Dezember 2016, 08:37:23
Wenn der ESP Device Name Relay ist, dann muss Du natürlich auch Relay in stateFormat verwenden. Wenn der verwendete Name GPIO12 ist, dann GPIO12.
==> Update
1) Mit der neuesten Version des Moduls erzeugt Autocreate kein GPIO12 sondern nur noch Relay als Reading
2) Ich habe jetzt das Device in GPIO12 umbenannt, alles neu angelegt. Status wird beim Starten nicht gesetzt aber mit "Statuscheck" wird jetzt der richtige Status im Device gesetzt
Ob es nun an der Version aus dem Staging Tree liegt oder das Umbennenen weiß ich nicht.
Das Verhalten ist nun OK. Vielen Dank für das Modul, macht es einfacher als über MQTT-Broker.
Zitat von: dev0 am 03 Dezember 2016, 16:22:49
Ich tippe auf eine nachlässig geschriebene regexp, die in meiner aktuellen Version schon gefixt ist, da ich es nicht nachvollziehen kann. Ich tippe drauf, dass Du eventMap verwendest...
Nimm mal bitte die Version aus dem staging branch https://github.com/ddtlabs/ESPEasy/tree/Staging und sag bitte bescheid ob es damit wieder funktioniert.
Hallo,
das sieht schon besser aus :D. Ich teste gleich auch mal die Queue mit ;)
Zitat von: Elektrofreak am 04 Dezember 2016, 19:33:52
Ich teste gleich auch mal die Queue mit ;)
Bis jetzt sieht es viiiiel besser aus wie zuvor. Ich hatte ohne die Queue immer Probleme, dass ein PID-Regler an einem Endpunkt hängen geblieben ist und nicht wieder zurück kam, da der ESP8266 nicht wirklich auf die Befehle von FHEM reagiert hat.
Was ich auch noch beobachtet habe: Mein FHEM war vor dem Update extremst langsam (z.T. mehr wie 3 Minuten, bis sich das Web-Interface aktualisiert hat). Jetzt ist es immer noch nicht wirklich schnell, aber es reagiert immerhin innerhalb von ca. 3-30 Sekunden (je nach Seite). Ich kann allerdings nicht genau sagen, ob es an dem ESPEasy-Modul liegt oder nicht, da ich es z.Z. nicht raus schmeißen kann. Sonst würde die Heizung ausfallen :'(
PS: Nur falls jemand fragt: Das DBLog-Modul läuft im History-Modus und loggt per default nur UserReadings, die per Include markiert sind ::). Und das installierte perfmon-modul zeigte auch nichts auffälliges an...
Zitat von: Elektrofreak am 05 Dezember 2016, 08:35:17
Bis jetzt sieht es viiiiel besser aus wie zuvor.
Schön zu hören.
Zitat von: Elektrofreak am 05 Dezember 2016, 08:35:17
Was ich auch noch beobachtet habe: Mein FHEM war vor dem Update extremst langsam (z.T. mehr wie 3 Minuten, bis sich das Web-Interface aktualisiert hat).
Es ist sehr unwahrscheinlich, dass das in Verbindung mit dem ESPEasy Modul steht, da es durchgehend non-blocking arbeiten sollte.
Hallo,
ich bin Neunutzer und experimentiere gerade mit dem ESP8266 herum.
Habe eine Frage, auf die ich keine Antwort im Forum gefunden habe. Kann man die Log-Rückmeldung die der ESP sendet irgendwie direkt als Rückmeldung des Bausteins fürs FHEM verarbeiten?
Gruß
Falken
Das ESPEasy Modul macht das intern, wenn das Attribut parseCmdResponse gesetzt ist. Wenn Du httpUtils in eigenen Funktionen benutzt, dann ist das auch möglich. Bei Fragen zu letzteren bitte einen eigenen Thread öffnen.
Hallo zusammen.
Habe auf einer nodemcu das espeasy R147RC8 geflasht und für das WLAN eingerichtet.
Port 8383 ist geblieben und Controller IP habe ich die IP der nodemcu eingetragen. Protokoll ist FHEM HTTP.
Habe auch versucht die Bridge in FHEM zu defninieren.
Bekomme dann nur die die Meldung "Cannot load module ESPEasy"
Habe auch zuvor das FHEM Modul manuel rüber kopiert und die Rechte vergeben.
Jemand eine Idee warum das nicht funktioniert ?
Gruß und Danke
Sascha
Fhem restart schon gemacht? Das war bei mir der Fehler.
Gesendet von meinem SM-G935F mit Tapatalk
Auch gemacht. Bringt nix
Von mobil gesendet daher kurze Antwort
Controller IP muss der FhEM IP entsprechen. Warum das Modul nicht geladen wird steht im Log.
@dev0: habe heute den ersten Sonoff nach Wiki eingestellt. Folgende Sachen habe ich festgestellt:
1. das Device wird erst erstellt, nachdem ich den Button am Sonoff betätigt habe
2. scheint die Verbindung irgendwie einzuschlafen. Nach ca 1/2 Stunde bekomme ich "No Route to Host" wenn ich schalten will, obwohl das ESPEasy Webinterface im Browser erreichbar ist. Habe eine Zyklische RSSI Meldung eingebaut, dann gibt es diese Meldung nicht und jedes Signal an den Sonoff kommt durch.
Habe schon die nächsten geordert. Peu a peu schmeiss ich den FS20 Kram raus
Gesendet von iPhone mit Tapatalk
Zitat von: Waldmensch am 07 Dezember 2016, 21:39:56
1. das Device wird erst erstellt, nachdem ich den Button am Sonoff betätigt habe
So ist es in der commandref beschrieben: ohne Daten kein Device, ohne Arme keine Kekse ;)
Zitat von: Waldmensch am 07 Dezember 2016, 21:39:56
2. scheint die Verbindung irgendwie einzuschlafen. Nach ca 1/2 Stunde bekomme ich "No Route to Host" wenn ich schalten will, obwohl das ESPEasy Webinterface im Browser erreichbar ist.
Die Meldung "No Route to Host" kommt von Betriebssystem und wird nur vom Modul ausgegeben, wenn das Gerät angesprochen wird, aber nicht erreichbar ist. Empfangsprobleme? In dem Moment ist das Gerät definitiv nicht erreichbar gewesen.
Zitat von: dev0 am 07 Dezember 2016, 20:15:24
Controller IP muss der FhEM IP entsprechen. Warum das Modul nicht geladen wird steht im Log.
Hier der Log Eintrag,warum das Modul nicht geladen wird.
2016.12.08 05:56:12 0: Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 44 at ./FHEM/34_ESPEasy.pm line 22.
Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 44 at ./FHEM/34_ESPEasy.pm line 22.
2016.12.08 05:56:12 1: reload: Error:Modul 34_ESPEasy deactivated:Wie gesagt, manuell rüber kopiert, Rechte vergeben und FHEM Neustart durchgeführt, FHEM IP in ESPEasy eingetragen.
Griß und Danke
Sascha
Vermutlich ist die Datei nicht ok.
Danke. Werde es heute nachmittag testen.
Gruß Sascha
Von mobil gesendet daher kurze Antwort
P.S.: Habe die Datei jetzt nochmal aus dem MasterBranch runter geladen und rüber kopiert. Brachte aber keine Änderung nach dem Neustart !
Schick mir die Datei mal per PM.
Zitat von: sash.sc am 08 Dezember 2016, 05:59:47
Hier der Log Eintrag,warum das Modul nicht geladen wird.
2016.12.08 05:56:12 0: Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 44 at ./FHEM/34_ESPEasy.pm line 22.
Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 44 at ./FHEM/34_ESPEasy.pm line 22.
2016.12.08 05:56:12 1: reload: Error:Modul 34_ESPEasy deactivated:
Wie gesagt, manuell rüber kopiert, Rechte vergeben und FHEM Neustart durchgeführt, FHEM IP in ESPEasy eingetragen.
Griß und Danke
Sascha
Genau das habe ich auch immer, wenn ich Änderungen mit dem WebIf mit dem Smartphone vor nehme.
Ich weiß jetzt nicht genau, wie ich es dir am besten erkläre, aber wenn ich am Smartphone ändern möchte, z.B. ein Notify, dann auf "DEF" gehe und danach auf "modify..." dann haut er mir immer falsche Zeilenumbrüche mit rein. Ich muss dann immer wieder am Laptop das eben geänderte öffnen, jeden Zeilenumbruch löschen und neu machen.
Gleiches passiert mir oft bei Copy & Paste.
Gesendet von meinem EVA-L09 mit Tapatalk
Habe die Definition aus dem Anfangsthread einfach per Copy and Paste in die komandozeile bei FHEM eingegeben !
Gruß
Sascha
Ich schrieb PM nicht ins Forum. Lösch die Datei bitte wieder.
Die Datei ist Schrott. Benutz das FHEM Update, wie ist auf Github beschrieben.
Danke
Von mobil gesendet daher kurze Antwort
Ich wollte gerade einen normalen Longpulse (also ein simplen on-for-timer) an den sonoff schicken und kriege das
2016.12.08 12:01:31 3 : ESPEasy ESPEasy_ESPEasy_sonoff_1_Schalter: set ESPEasy_ESPEasy_sonoff_1_Schalter longpulse 12 1 60
2016.12.08 12:01:31 2 : ESPEasy ESPEasy_ESPEasy_sonoff_1_Schalter: Command 'longpulse' is deactivated until attribute 'rgbGPIOs' is set.
Ich will ja nur das relay schalten.
Was ich noch gemerkt habe, nach einem shutdown restart weiß FHEM nicht wie das relay steht (on oder off) man kann in dem Moment nicht schalten. Das Icon (schaltzustand) ist gelb. Abhilfe habe ich geschaffen, indem ich auf dem ESP beim relay ein Delay von 60 eingetragen hab. Dadurch liefert der ESP alle 60 Sekunden den Zustand des GPIO. Eventuell könnte die Bridge beim Laden (nach shutdown restart) einmal die GPIO aller ESP durchpollen um die zustände zu kennen?!
Verwendete Version ist die 0.74
Zitat von: Waldmensch am 08 Dezember 2016, 12:18:05
Command 'longpulse' is deactivated until attribute 'rgbGPIOs' is set.
Wurde schon besprochen: https://forum.fhem.de/index.php/topic,55728.msg532791.html#msg532791
Zitat von: Waldmensch am 08 Dezember 2016, 12:18:05
Eventuell könnte die Bridge beim Laden (nach shutdown restart) einmal die GPIO aller ESP durchpollen um die zustände zu kennen?!
siehe commandref: pollGPIOs und parseCmdResponse
Ich stehe gerade auf dem Schlauch und finde nicht die richtige Antwort. Wie sende ich den via HTTP aus einem Notify an den ESP.
Ich möchte zum Beispiel:
http://192.168.3.204/control?cmd=setvalue,1,1,$EVENT
an den ESP senden.
Hat sich erledigt:
system('curl -s http://192.168.3.204/control?cmd=event,setvalue='.$EVENT.'');
Dein Systemaufruf arbeitet blockierend. Besser wäre es noch ein & ans Ende zu stellen oder die "..." Syntax zu benutzen, die auch nicht blockierend arbeitet.
Aber warum nutzt Du nicht das ESPEasy Modul? Wäre das nicht noch einfacher?
Das longpulse ist mit der Staging gefixt - supi!
Das mit pollGPIOs habe ich in der Commandref schon gelesen. Da nichts weiter dazu steht, dachte ich, dass das dann zyklisch stattfindet und nicht nur einmalig. Ich würde als Standard gern den ESP pushen lassen. Ich weiß nicht warum die Verbindung einschläft und denke, das ich ihn auf die Weise aktiv halten kann. Ich habe ja ein bisschen die Fritz im Verdacht, das die einen Client als offline betrachtet wenn er sich länger nicht meldet.
Gesendet von iPhone mit Tapatalk
pollGPIOs arbeitet in der Tat zyklisch, es ist eigentlich für pwm etc gedacht, wenn ein ESPEasy Plugin keine Daten aktiv schickt. Wenn der ESP die Daten schickt, dann ist das unnötig.
Ist ja halb so wild. Ich habe das Delay auf 60 Sekunden eingestellt. Also kennt FHEM spätestens 60 Sek nach Start den Status und der Schalter geht von Gelb nach rot oder grün. Solange der Schalter Gelb ist sendet das Modul immer "off" und der Schalter bleibt Gelb. Ich kenn mich mit dem webcmd Gedöns nicht aus. Letztlich werden sonoff aber eh über Programmierung (at oder DOIF) geschaltet und nicht über die Oberfläche. Damit kann ich leben. Ein Pollen bekannter GPIOs bei Modulstart wäre nice to have.
Gesendet von iPhone mit Tapatalk
ESPEasy 0.78 released:
Zitat
- revised more inexact regexps
- Added a command queue due to not overrun esp's ip stack
- Added attr maxQueueSize (default 250)
- Added attr maxHttpSessions (default 3)
- Added attr resendFailedCmd (default disabled)
- new bridge commands: get queueSizes, set clearQueue
- status command returns "?" in case of an unknown gpio state
- removed useless predefined subs, shutdown restart is required after module update
- fixed: Command 'xyz' is deactivated until attribute 'rgbGPIOs' is set.
> shutdown restart required after update<
Zitat von: dev0 am 08 Dezember 2016, 19:32:29
Dein Systemaufruf arbeitet blockierend. Besser wäre es noch ein & ans Ende zu stellen oder die "..." Syntax zu benutzen, die auch nicht blockierend arbeitet.
Aber warum nutzt Du nicht das ESPEasy Modul? Wäre das nicht noch einfacher?
Das ESPEasy Modul benutze ich schon. Aber wie mache ich das aus dem Modul heraus. In der Device specific help habe ich nichts entsprechendes gefunden.
Wenn der ESPEasy-Befehl dem Modul noch nicht bekannt ist, dann kann man das über 'raw' machen. Alles nach raw wird 1:1 an den ESP geschickt.
set <ESP> raw setvalue 1 1 $EVENT
Edit: 1:1 ist nicht ganz exakt: die Paramater werden automatisch durch die nötigen Kommata getrennt.
Zitat von: sash.sc am 08 Dezember 2016, 05:59:47
Hier der Log Eintrag,warum das Modul nicht geladen wird.
2016.12.08 05:56:12 0: Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 44 at ./FHEM/34_ESPEasy.pm line 22.
Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 44 at ./FHEM/34_ESPEasy.pm line 22.
2016.12.08 05:56:12 1: reload: Error:Modul 34_ESPEasy deactivated:
Wie gesagt, manuell rüber kopiert, Rechte vergeben und FHEM Neustart durchgeführt, FHEM IP in ESPEasy eingetragen.
Griß und Danke
Sascha
Hallo Sascha,
ist mir gestern auch passiert. Du hast die Datei als "HTML" heruntergeladen. Siehst Du leicht im Inhalt. Man muss erst die Ansicht auf RAW schalten und dann speichern unter im Browser. Da wird es eine Textdatei.
Nur zur Erklärung ;)
Gruß Otto
Copy/paste würde ich vermeiden (wegen cr/lf Problematik). Besser: ins FHEM Update einbinden, als zip Downloaden oder das Repository clonen.
Danke für die Hinweise.
Gruß Sascha
Von mobil gesendet daher kurze Antwort
Das mit dem HTML ist mir bei der Staging auch so gegangen. Im GIT rechts oben ist ein Button "als ZIP downloaden". Damit geht es 1A. Ansonsten ins Update einbinden wie dev0 sagte.
Bei mir ist der 2. sonoff heute and Netz gegangen, 5 weitere sind im Zulauf. Daumen hoch für dieses geile Modul!
Gesendet von iPhone mit Tapatalk
Zitat von: dev0 am 09 Dezember 2016, 05:22:09
ESPEasy 0.78 released:
Nach dem Update haben nun alle meine ESP Device ein ON/OFF daben, siehe Anhang.
Ein list vom Device hätte mehr Informationsgehalt.
Sonst noch jemand betroffen?
Zitat von: dev0 am 09 Dezember 2016, 16:46:22
Ein list vom Device hätte mehr Informationsgehalt.
Betroffen sind alle Devices bei mir, hier das vom Screen:
Internals:
DEF 192.168.0.124 80 ESPbridge ESPTest_System
ESP_BUILD 142
ESP_SLEEP 0
ESP_UNIT 1
ESPbridge_MSGCNT 1276
ESPbridge_TIME 2016-12-09 16:46:36
HOST 192.168.0.124
IDENT ESPTest_System
INTERVAL 300
IODev ESPbridge
LASTInputDev ESPbridge
MSGCNT 1276
NAME ESPEasy_ESPTest_System
NOTIFYDEV global
NR 47
NTFY_ORDER 50-ESPEasy_ESPTest_System
PORT 80
STATE ram: 24960 rss: -80 upt: 47248
SUBTYPE device
TYPE ESPEasy
VERSION 0.78
Helper:
Dblog:
Ram:
Mydblog:
TIME 1481298396.37354
VALUE 24960 rss: -80 upt: 47248
Rss:
Mydblog:
TIME 1481285649.49768
VALUE -79 upt
Rssi:
Mydblog:
TIME 1481298396.37354
VALUE -80
Upt:
Mydblog:
TIME 1481298382.35953
VALUE 47248
Readings:
2016-12-09 16:45:35 presence present
2016-12-09 16:46:29 ram 24960
2016-12-09 16:46:36 rssi -80
2016-12-09 16:46:36 state ram: 24960 rss: -80 upt: 47248
2016-12-09 16:46:22 upt 47248
Helper:
fpc 1481285636
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 304
TRIGGERTIME 09.12.2016 16:50:39
Received:
ram 1481298389
rssi 1481298396
upt 1481298382
Attributes:
IODev ESPbridge
Interval 300
event-on-change-reading .*
group ESPEasy Device
presenceCheck 1
readingSwitchText 1
room ESPEasy
setState 3
In dem List gibt es kein 'on off', weder in state noch in STATE.
Ich habe gerade eben auf die Version 0.74 zurück gesprungen und ON/OFF ist weg:
Internals:
CHANGED
DEF 192.168.0.124 80 ESPbridge ESPTest_System
ESP_BUILD 142
ESP_SLEEP 0
ESP_UNIT 1
ESPbridge_MSGCNT 8
ESPbridge_TIME 2016-12-09 17:02:30
HOST 192.168.0.124
IDENT ESPTest_System
INTERVAL 300
IODev ESPbridge
LASTInputDev ESPbridge
MSGCNT 8
NAME ESPEasy_ESPTest_System
NOTIFYDEV global
NR 47
NTFY_ORDER 50-ESPEasy_ESPTest_System
PORT 80
STATE ram: 25328 rss: -80 upt: 47264
SUBTYPE device
TYPE ESPEasy
VERSION 0.74
Helper:
Dblog:
Ram:
Mydblog:
TIME 1481299343.41717
VALUE 25328 rss: -80 upt: 47264
State:
Mydblog:
TIME 1481299276.84583
VALUE present
Upt:
Mydblog:
TIME 1481299343.41717
VALUE 47264
Readings:
2016-12-09 16:58:29 presence present
2016-12-09 17:02:30 ram 25328
2016-12-09 17:02:07 rssi -80
2016-12-09 17:02:30 state ram: 25328 rss: -80 upt: 47264
2016-12-09 17:02:23 upt 47264
Helper:
fpc 1481299276
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 304
TRIGGERTIME 09.12.2016 17:06:19
Received:
ram 1481299350
rssi 1481299327
upt 1481299343
Attributes:
IODev ESPbridge
Interval 300
event-on-change-reading .*
group ESPEasy Device
presenceCheck 1
readingSwitchText 1
room ESPEasy
setState 3
Es liegt an den noch undokumentierten und neuen on/off Befehlen.
Wirst Du mit
attr <esp> webCmd :
abstellen können, wenn es Dich stört.
War mir noch gar nicht aufgefallen, aber stimmt. Bei Sensoren macht das natürlich keinen Sinn. Auf Klick wird im Eventmonitor auch ein "set <device> on " bzw. off angezeigt.
(http://uploads.tapatalk-cdn.com/20161209/8d1cfd32809dac77c9db91445f8315ad.jpg)
Gesendet von iPhone mit Tapatalk
Die on,off,... Befehle sind nicht dauerhaft. Ich brauche sie im Moment nur zum einfacheren Testen meines rgbww Plugins. On/off wird von FHEM automatisch angezeigt, wenn es sie gibt.
Mich stört es nicht. Bei den Sensoren sind eh nur die Plots wichtig
Was ein nice to have wäre, wär en die -for-timer Settings, das man nicht die longpulse Syntax verwenden muss. Keine Ahnung wie schwer die Umsetzung ist.
Gesendet von iPhone mit Tapatalk
Die On/off Befehle kann man wit webCmd abschalten, falls es stört.
on-for-timer siehe ersten Beitrag, ist dort beschrieben.
Leider funktioniert bei mir doch die queue nicht so wie gewünscht. Ich nutze einen PID20-Regler und einen longpulse aus Ausgangswert. Es wird einmal alle 60 Sekunden der Wert ausgegeben (mit pidAktorKeepAlive). Leider kommt nur ein anderer Wert bei dem ESP an, der per gpio gesetzt wird. Ich sehe, dass der PID-Regler alle 60 Sekunden artig seine Readings aktualisiert, nur kommt im ESP-Log der longpulse nicht an.
Könnte man das WARNING-Internal in ein Reading umwandeln? Dann sieht man zumindest, wann der Fehler aufgetreten ist und ich könnte besser herausfinden, wo das Problem liegt.
Zitathttp://192.168.***.***:80/control?cmd=longpulse,3,1,59: empty answer received
Edit: Es kann natürlich noch an etwas anderem liegen, auch wenn die queue am Naheliegendsten ist :'(
Edit2: Man sollte auch das resendFailedCmd-Attribut aktivieren ;D. Trotzdem die Bitte mit dem Error-Reading 8)
Hallo zusammen.
Habe nun endlich espeasy am Laufen. Bin bis jetzt auch recht zufrieden mit den erfassten Temperaturen.. Diese kommen über 2 ds18b20 auf den esp8622. Jetzt sehe ich, daß eine permanente auslastung der CPU von ca. 12 bis 20% anliegt. Ist das normal?
Habe auch je einen 4k7 pull up auf die datenleitung liegen.
Müssen die dran? Da gibt es ja unterschiedliche Anleitungen für?
Danke für das Modul.
Gruß Sascha
Ob eine CPU Last von x% normal ist kann man ohne weitere Details nicht sagen.
Hardwarefragen bitte in einem passenden Thread stellen, hier geht es mus ESPEasy Modul. Bitte hab Verständnis dafür.
Ok. Kein Problem.....
Gruß und danke
Sascha
Von mobil gesendet daher kurze Antwort
Wenn Du Belege dafür hast, dass das ESPEasy Modul ursächlich für die erhöhte CPU Last verantwortlich ist, dann können wird natürlich probieren das zu analysieren. Ich gehe aber davon aus, dass das nicht der Fall ist. Mir ist bspw. ein Fall bekannt in dem das ESPEasy Modul indirekt eine höhere Last erzeugt hat. Im Endeffekt lag es aber an dem erhöhten Logaufkommen in Zusammenspiel mit dblog und einem langsamen I/O Subsystem.
Das das Modul die Last verursacht, so war das nicht gemeint. Mir ist nur aufgefallen das mit nur 2 temp. Sensoren schon die Last so "hoch" ist.
Gruß Sascha
Von mobil gesendet daher kurze Antwort
Zitat von: sash.sc am 12 Dezember 2016, 15:22:02
Hallo zusammen.
Habe nun endlich espeasy am Laufen. Bin bis jetzt auch recht zufrieden mit den erfassten Temperaturen.. Diese kommen über 2 ds18b20 auf den esp8622. Jetzt sehe ich, daß eine permanente auslastung der CPU von ca. 12 bis 20% anliegt. Ist das normal?
Habe auch je einen 4k7 pull up auf die datenleitung liegen.
Müssen die dran? Da gibt es ja unterschiedliche Anleitungen für?
Danke für das Modul.
Gruß Sascha
Hi,
ich habe auch ein Modul mit zwei Sensoren und insgesamt 4 Werten. Die Last des ESP Modul liegt beii 14%.
Gruß Otto
Zitat von: sash.sc am 12 Dezember 2016, 15:22:02
Habe auch je einen 4k7 pull up auf die datenleitung liegen.
Hört sich an, als würdest du 2 gtrennte Datenleitungen verwenden.
Von den ds18b20 kannst etliche auf
eine Datenleitung legen.
EDIT: Load = 13% sind es bei diesem ESP
Zitat von: pink99panther am 12 Dezember 2016, 20:49:19
Hört sich an, als würdest du 2 gtrennte Datenleitungen verwenden.
Von den ds18b20 kannst etliche auf eine Datenleitung legen.
Jepp. Habe es erst mal so gemacht. Einfach um das System zu laufen zu bekommen. Werde bei Zeiten die beiden Sensoren zusammen auf einen Port legen.
Gruß Sascha
Von mobil gesendet daher kurze Antwort
Dann reicht auch ein Pullup, läuft zumindest bei mir reibungslos
CPU Load kann ich bei mir kaum feststellen (2x Sonoff, 2 nodeMCU mit diversen Senoren - alles pusht im 60sek Intervall) zwischen 0-8% CPU, ab und zu ein Peak auf 20%. Bananapi
Gesendet von iPhone mit Tapatalk
Ich glaube er meinte die Last vom ESP und nicht vom Pi
Gesendet von meinem EVA-L09 mit Tapatalk
Zitat von: tiwo85 am 13 Dezember 2016, 07:58:41
Ich glaube er meinte die Last vom ESP und nicht vom Pi
@sash.sc: Ist das so?
Jepp
Von mobil gesendet daher kurze Antwort
@sash.sc:
Hast du mein EDIT oben gelesen?
Bei 2 Datenleitungen muß der ESP ja auch doppelt so viel arbeiten :)
Ich habe ein NodeMCU mit 2 DS18b20 auf einem Pin mit einem Pullup zur Messung von Vor-und Rücklauf meiner Heizung.
Gesendet von iPhone mit Tapatalk
Stop! Dieser Thread dient dem ESPEasy Modul Support, für Hardwarediskussionen bitte einen neuen oder passenden Thread wählen.
Danke.
Meine Sonoff Steckdosen laufen jetzt soweit super.
Nach dem Delay setzen ist der Status auch aktuell!
Ich schalte 3 Steckdosen um 17 Uhr ein und um 22 Uhr aus.
Gestern war um Ca. 18 Uhr wieder eine aus nachdem sie schon an war.
Frage: was passiert wenn eine Dose kurzzeitig kein wlan hat?
Fällt das Relais dann ab? Anders könnte ich mir das Phänomen
nicht erklären!
Grüße
Matze
Zitat von: smoudo am 17 Dezember 2016, 14:18:55
Frage: was passiert wenn eine Dose kurzzeitig kein wlan hat?
Teste es ausführlich und wenn du der Meinung bist, dass das Modul darauf einen Einfluss hat oder nehmen sollte, dann berichte es hier.
Zitat von: smoudo am 17 Dezember 2016, 14:18:55
Fällt das Relais dann ab?
Wenn es so wäre, dann bitte an die ESPEasy Developer wenden -> www.letscontrolit.com
Hallo dev0.
Feines Modul!
Mein erster 'produktiver' UseCase ist ein IR2FHEM-Gateway.
Gebaut mit ESP-01(512k) mit ESPEasy R147_RC8 und TSOP4838.
Geflasht an einem Raspi über die eingebauten UART-Pins.
Eine zusätzliche LED gibt noch per notify eine optische Rückmeldung, wenn FHEM etwas empfangen hat.
Am längsten habe ich gebraucht, um herauszufinden in welcher Reihenfolge man die Pins beschalten muss, um den Flashmode im ESP zu aktivieren.
Der Rest funktionierte dann wie beschrieben.
Gruß Ralf
Kannst Du deine Lösung in einem separaten Thread vorstellen? Ich habe da großes Interesse dran, aber eher am IR Senden für die Klimaanlage. In diesem Thread wärs aber OT.
Gesendet von iPhone mit Tapatalk
Habe Probleme mit einem Dummy Device. Dieses sollte eigentlich 4 Readings en Block liefern. Ist das ein Problem auf ESP Seite?
Verbose 5:
2016.12.20 01:42:50 4 : Connection accepted from espBridge_192.168.178.20_15643
2016.12.20 01:42:50 4 : ESPEasy espBridge_192.168.178.20_15643: Peer address accepted
2016.12.20 01:42:50 5 : ESPEasy espBridge_192.168.178.20_15643: Received header: {'Connection' => 'close','Content-Length' => '222','Host' => '192.168.178.47'}
2016.12.20 01:42:50 5 : ESPEasy espBridge_192.168.178.20_15643: Received content: {"module":"ESPEasy","version":"1.02","data":{"ESP":{"name":"lichtsensor","unit":0,"version":9,"build":146,"sleep":0,"ip":"192.168.178.20"},"SENSOR":{"0":{"deviceName":"collect","valueName":"dunkel","type":1,"value":"1"}}}}
2016.12.20 01:42:50 4 : ESPEasy espBridge_192.168.178.20_15643: No basic authentication required
2016.12.20 01:42:50 4 : ESPEasy espBridge_192.168.178.20_15643: Send http close '200 OK'
2016.12.20 01:42:50 5 : ESPEasy espBridge_192.168.178.20_15643: Dispatch: lichtsensor_collect::192.168.178.20::1::1::1::i||unit||0||0|||i||sleep||0||0|||i||build||146||0|||r||dunkel||1||1
2016.12.20 01:42:50 5 : espBridge dispatch lichtsensor_collect::192.168.178.20::1::1::1::i||unit||0||0|||i||sleep||0||0|||i||build||146||0|||r||dunkel||1||1
2016-12-20 01:42:51 ESPEasy ESPEasy_lichtsensor_collect dunkel: 1
2016-12-20 01:42:51 ESPEasy ESPEasy_lichtsensor_collect dun: 1
2016.12.20 01:42:51 4 : ESPEasy espBridge_192.168.178.20_15643: Closing tcp session.
Der empfangene JSON String ist vollständig/gültig und der Content-Length Header entspricht den empfangenen Daten -> mehr wurde nicht gesendet.
Hast Du vielleicht unterschiedliche Delays eingetragen?
Der dummy hat ja nur ein Delay und ist "hart" für 4 Values vorgesehen. Ich fülle ihn per Rule mit den Werten aus den anderen devices, die selber nicht senden sollen (das spart 3 einzelne Übertragungen). Der JSON sieht für mich auch okay aus, nur das 3 values fehlen.
Gesendet von iPhone mit Tapatalk
MEIN Fehler! Alles Okay! Bin in die Falle getappt und habe "SENSORTYPE SINGLE" gehabt. Mit "QUAD" werden alle 4 Werte gesendet und auch vom Modul verwertet. Das mit dem Dummy Device ist eine tolle Sache, so werden nur 1x Daten statt 4x übertragen. Entsprechend weniger Netzwerktraffic und weniger Arbeit (Events) für FHEM.
2016.12.20 08:59:17 4 : Connection accepted from espBridge_192.168.178.20_2935
2016.12.20 08:59:17 4 : ESPEasy espBridge_192.168.178.20_2935: Peer address accepted
2016.12.20 08:59:17 5 : ESPEasy espBridge_192.168.178.20_2935: Received header: {'Connection' => 'close','Content-Length' => '441','Host' => '192.168.178.47'}
2016.12.20 08:59:17 5 : ESPEasy espBridge_192.168.178.20_2935: Received content: {"module":"ESPEasy","version":"1.02","data":{"ESP":{"name":"lichtsensor","unit":0,"version":9,"build":146,"sleep":0,"ip":"192.168.178.20"},"SENSOR":{"0":{"deviceName":"collect","valueName":"dunkel","type":7,"value":"0"},"1":{"deviceName":"collect","valueName":"licht","type":7,"value":"735"},"2":{"deviceName":"collect","valueName":"RSSI","type":7,"value":"-68"},"3":{"deviceName":"collect","valueName":"Pressure","type":7,"value":"1026"}}}}
2016.12.20 08:59:17 4 : ESPEasy espBridge_192.168.178.20_2935: No basic authentication required
2016.12.20 08:59:17 4 : ESPEasy espBridge_192.168.178.20_2935: Send http close '200 OK'
2016.12.20 08:59:17 5 : ESPEasy espBridge_192.168.178.20_2935: Dispatch: lichtsensor_collect::192.168.178.20::1::1::1::i||unit||0||0|||i||sleep||0||0|||i||build||146||0|||r||licht||735||7|||r||Pressure||1026||7|||r||dunkel||0||7|||r||RSSI||-68||7
2016.12.20 08:59:17 5 : espBridge dispatch lichtsensor_collect::192.168.178.20::1::1::1::i||unit||0||0|||i||sleep||0||0|||i||build||146||0|||r||licht||735||7|||r||Pressure||1026||7|||r||dunkel||0||7|||r||RSSI||-68||7
2016-12-20 08:59:17 ESPEasy ESPEasy_lichtsensor_collect licht: 735
2016-12-20 08:59:17 ESPEasy ESPEasy_lichtsensor_collect Pressure: 1026
2016-12-20 08:59:17 ESPEasy ESPEasy_lichtsensor_collect dunkel: 0
2016-12-20 08:59:17 ESPEasy ESPEasy_lichtsensor_collect RSSI: -68
2016-12-20 08:59:17 ESPEasy ESPEasy_lichtsensor_collect Pre: 1026 RSS: -68 dun: 0 lic: 735
2016.12.20 08:59:17 4 : ESPEasy espBridge_192.168.178.20_2935: Closing tcp session.
Beispiel für die Rule, die den Dummy füllt. Falls es jemand nachmachen möchte
on helligkeit#licht do
TaskValueSet 4,2,[helligkeit#licht]
if [helligkeit#licht]<200
TaskValueSet 4,1,1
endif
if [helligkeit#licht]>300
TaskValueSet 4,1,0
endif
endon
on rs#RSSI do
TaskValueSet 4,3,[rs#RSSI]
endon
on druck#Pressure do
TaskValueSet 4,4,[druck#Pressure]
endon
Coole nummer mit den Dummys und den rules. Das haben die in der espeasy 147rc8 noch nicht drin.
Von mobil gesendet daher kurze Antwort
Zitat von: sash.sc am 20 Dezember 2016, 09:34:51
Coole nummer mit den Dummys und den rules. Das haben die in der espeasy 147rc8 noch nicht drin.
Beides gibt es schon länger, siehe Releasenotes.
Zitat von: sash.sc am 20 Dezember 2016, 09:34:51
Coole nummer mit den Dummys und den rules. Das haben die in der espeasy 147rc8 noch nicht drin.
Du hast vermutlich die Rules nicht eingeschaltet. Versteckt sich in den advanced Settings ganz unten
Ok. Danke für den Hinweis
Von mobil gesendet daher kurze Antwort
Danke für dein Modul – finde ich prima und es erleichtert einem eine ganze Menge.
Bei meinen 1. Versuchen habe ich u.a. einen BME280 angeschlossen. Funktioniert so weit auch ganz gut. Nur die Anzeige in FHEM passt nicht (im STATE).
Ich habe sogar extra ein stateFormat definiert. Das kommt aber nicht zur Anwendung (oder wird überschrieben).
Internals:
DEF 192.168.0.40 80 espBridge 1Wire_1_BME280
ESP_BUILD 147
ESP_SLEEP 0
ESP_UNIT 2
HOST 192.168.0.40
IDENT 1Wire_1_BME280
INTERVAL 300
IODev espBridge
LASTInputDev espBridge
MSGCNT 2
NAME ESPEasy_1Wire_1_BME280
NOTIFYDEV global
NR 884
NTFY_ORDER 50-ESPEasy_1Wire_1_BME280
PORT 80
STATE T: 22.5 D: 8.6
SUBTYPE device
TYPE ESPEasy
VERSION 0.78
espBridge_MSGCNT 2
espBridge_TIME 2016-12-22 15:08:01
Readings:
2016-12-22 15:08:01 H 41
2016-12-22 15:08:01 P 1029
2016-12-22 15:08:01 T 22.5
2016-12-22 15:05:55 presence present
2016-12-22 15:08:01 state H: 41 P: 1029 T: 22.5
Helper:
fpc 1482415632.13661
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 304
TRIGGERTIME 22.12.2016 15:12:15
Received:
H 1482415681.04625
P 1482415681.04766
T 1482415681.04696
Attributes:
IODev espBridge
Interval 300
group ESPEasy Device
presenceCheck 1
readingSwitchText 1
room ESPEasy
setState 3
stateFormat Temp: T, Feuchte: H, Druck: P
Aufgrund des ,,D: 8.6 " im STATE könnte ich mir vorstellen, dass es in Verbindung mit dem Modul dewpoint (berechnet den Taupunkt aufgrund von Temperatur und Luftfeuchte in Ereignissen, die von allen Geräten erzeugt wurden die diese Werte ausgeben und ergänzt mit diesem Wert den Status STATE) zu Konflikten kommt. Das Modul habe ich auch im Einsatz und so definiert wie als Beispiel in der Commandref beschrieben:
define dew_state dewpoint dewpoint .* T H D
- Du kannst mit dem Attribut setState die Erstellung des Reading state auch abschalten. Das Internal STATE wird vom Modul nicht angefasst: stateFormat funktioniert.
- Das Modul Dewpoint kann auch x beliebige Readings verwenden und ist nicht auf state/STATE angewiesen.
- Wurde alles schon in diesem Thread beschrieben ;)
Hallo,
Ich habe das Problem wenn ich im EspEasy die Controller IP eingetragen habe, das sich der ESP nach einem neustart nicht mehr mit dem Wlan verbindet.
Bekomme aber vor dem neustart die Werte in Fehm angezeigt.
Hat Jemand eine Idee wo dran das liegen könnte?
EspEasy Build 147 und
Nicht das er vom Router eine andere IP bekommen hat? Im der Fritte kann man ein Häkchen setzen "immer diese IP geben". Oder halt mit festen IP's arbeiten.
Gesendet von iPhone mit Tapatalk
Zitat von: Ascoban am 22 Dezember 2016, 22:03:36
Hallo,
Ich habe das Problem wenn ich im EspEasy die Controller IP eingetragen habe, das sich der ESP nach einem neustart nicht mehr mit dem Wlan verbindet.
Bekomme aber vor dem neustart die Werte in Fehm angezeigt.
Hat Jemand eine Idee wo dran das liegen könnte?
EspEasy Build 147 und
Ich habe ein ESP8266 welches einfach defekt ist. ESPEasy verbindet sich nach Power Reset nicht mehr mit Wlan, weil offenbar die Wlan Konfig im defekten Speicher abgelegt wird.
Mit anderen Systemen (NodeMcu Lua, AT ) funktioniert diese Modul.
Ein anderes ESP Modul funktioniert mit ESPEasy auf Anhieb einwandfrei.
Gruß Otto
@Ascoban: Wie Otto schon schrieb würde ich auch auf einen defekten ESP tippen. Nimm mal ein anderes Modul.
@Waldmensch: Selbst wenn der ESP eine neue IP bekommen hat, dann müßte er dennoch die Daten senden und sie würden vom Modul auch verarbeitet werden. Man könnte in diesem Fall nur keine Befehle zum ESP senden.
Servus Zusammen,
erstmal vielen Dank für das tolle Modul! Funktioniert super und einfach. Davor mit MQTT öfters Probleme gehabt.
Nun zu einer frage. Du hast bei set den Befehl IRsend.
Wie kann man diesen Command benutzen und wie schaut es mit der Hardware config aus?
Dankeschön!
Viele Grüße
Nico
Zitat von: Otto123 am 23 Dezember 2016, 00:01:32
Ich habe ein ESP8266 welches einfach defekt ist. ESPEasy verbindet sich nach Power Reset nicht mehr mit Wlan, weil offenbar die Wlan Konfig im defekten Speicher abgelegt wird.
Mit anderen Systemen (NodeMcu Lua, AT ) funktioniert diese Modul.
Ein anderes ESP Modul funktioniert mit ESPEasy auf Anhieb einwandfrei.
Gruß Otto
An der Wlan Config ändert sich ja nichts die daten habe ich vorher im sketch eingetragen.
Es geht nur nicht mehr wen ich ihm sage wie die ip von fhem ist.
Zitat von: accloginsell am 23 Dezember 2016, 07:22:17
Du hast bei set den Befehl IRsend.
Wie kann man diesen Command benutzen und wie schaut es mit der Hardware config aus?
Die Syntax zum Befehl bekommst Du mit 'set <esp> help irsend'. Den Rest must Du beim Plugin Autor erfragen, da es bisher nicht dokumentiert ist.
In diesem Thread hier findest Du einen Link ins letscontrolit Forum, dort gibt es wohl ein paar Hinweise dazu.
Zitat von: Ascoban am 22 Dezember 2016, 22:03:36
Bekomme aber vor dem neustart die Werte in Fehm angezeigt.
Zitat von: Ascoban am 23 Dezember 2016, 07:43:28
An der Wlan Config ändert sich ja nichts die daten habe ich vorher im sketch eingetragen.
Es geht nur nicht mehr wen ich ihm sage wie die ip von fhem ist.
Da es vor dem Reboot mit dem Modul/FHEM funktioniert kannst Du davon ausgehen, dass es nicht am Modul/FHEM liegt.
Hast Du den ESP jetzt schon mal ausgetauscht?
kann mir jemand helfen, wie ich in die eventMap einse ESP device ein on-till einbaue?
Momentan sieht das Atribut so aus
/gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/longpulse 12 on:on-for-timer/longpulse 12 off:off-for-timer/
Hallo zusammen,
neugierig, habe ich mir auch zum "Spielen" zwei Sonoff bestellt und erfolgreich mit ESPEasy geflasht.
Leider habe ich Probleme, diese in FHEM einzubinden.
Ich habe das Modul in den FHEM Ordner, wo die Module abgespeichert sind´, eingefügt.
Wenn ich das Modul aufrufe, erhalte ich folgende Fehlermeldung:
Unknown command ESPEasy
Im Log steht folgendes:
2016.12.24 14:03:59 1: reload: Error:Modul 34_ESPEasy deactivated:
Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 44 at ./FHEM/34_ESPEasy.pm line 22.
2016.12.24 14:03:59 0: Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 44 at ./FHEM/34_ESPEasy.pm line 22.
Kennt jemand das Problem bzw. kann mir helfen?
Vielen Dank im Voraus.
Frank
Zitat von: Franki112 am 24 Dezember 2016, 14:05:37
Hallo zusammen,
neugierig, habe ich mir auch zum "Spielen" zwei Sonoff bestellt und erfolgreich mit ESPEasy geflasht.
Leider habe ich Probleme, diese in FHEM einzubinden.
Ich habe das Modul in den FHEM Ordner, wo die Module abgespeichert sind´, eingefügt.
Wenn ich das Modul aufrufe, erhalte ich folgende Fehlermeldung:
Unknown command ESPEasy
Im Log steht folgendes:
2016.12.24 14:03:59 1: reload: Error:Modul 34_ESPEasy deactivated:
Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 44 at ./FHEM/34_ESPEasy.pm line 22.
2016.12.24 14:03:59 0: Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 44 at ./FHEM/34_ESPEasy.pm line 22.
Kennt jemand das Problem bzw. kann mir helfen?
Vielen Dank im Voraus.
Frank
Siehe ab Beitrag #492 hier im thread. Hatte das gleiche Problem! ;)
Gruß Sascha
Von mobil gesendet daher kurze Antwort
Hallo zusammen.
Hab seit heute folgendes Problem:
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/34_ESPEasy.pm line 343.
In Zeile 343 steht folgendes.
$ret .= getKeyValue($hash->{TYPE}."_".$hash->{NAME}."-".lc $reading);
Seitdem stehen die ESP auf absent.
Hallo Ascoban,
Zitat von: Ascoban am 22 Dezember 2016, 22:03:36
Hallo,
Ich habe das Problem wenn ich im EspEasy die Controller IP eingetragen habe, das sich der ESP nach einem neustart nicht mehr mit dem Wlan verbindet.
Bekomme aber vor dem neustart die Werte in Fehm angezeigt.
Hat Jemand eine Idee wo dran das liegen könnte?
EspEasy Build 147 und
Das Problem hatte ich auch und es hat mich Tage gekostet den Grund dafür herauszubekommen. Der WPA Key wird verändert, wenn Du auf die Config-Seite gehts - gewollt oder ungewollt. Speichert man die Änderung auf der Config-Seite hat man für die WiFi Anmeldung die falschen credentials. Seitdem ich bei Änderungen den WPA Key mit eintrage funktioniert die Anmeldung wieder problemlos.
ciao Walter
Zitat von: Waldmensch am 24 Dezember 2016, 10:03:42
kann mir jemand helfen, wie ich in die eventMap einse ESP device ein on-till einbaue?
Du müsstest die notwendigen Sekunden für 'longpulse', mit etwas Perlcode, selbst ermitteln. Wenn Du Lust hast (oder jemand anderes), diese Funktionalität ins Modul zu integrieren, dann bin ich einem fertigen Patch gegenüber offen. Nur bitte ohne die setExtensions, sondern mit dem ESP Timern (pulse/longpulse), da die Hardware diese Möglichkeit bietet. Auf meiner Todo Liste steht es im Moment aber nicht.
Zitat von: Cihan am 24 Dezember 2016, 21:12:31
Hab seit heute folgendes Problem:
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/34_ESPEasy.pm line 343.
...
Seitdem stehen die ESP auf absent.
Diese Perl Warnung erscheint, wenn keine basic auth credentials hinterlegt sind, diese aber mit 'get <bridge> user/pass' abgefragt werden.
Bei den dürftligen Informationen von Dir kann ich nur raten: Du benutzt basic auth und hast den Namen der Bridge in der fhem.cfg direkt geändert oder hast es sonst irgendwie geschaft die Datei ./FHEM/FhemUtils/uniqueID zu schrotten. Abhilfe: die authorization credentials mit 'set <bridge> user/pass <xyz>' neu setzen.
Zitat von: wkarl am 25 Dezember 2016, 06:09:27
Der WPA Key wird verändert, wenn Du auf die Config-Seite gehts - gewollt oder ungewollt. Speichert man die Änderung auf der Config-Seite hat man für die WiFi Anmeldung die falschen credentials. Seitdem ich bei Änderungen den WPA Key mit eintrage funktioniert die Anmeldung wieder problemlos.
Danke für den Hinweis. Ich habe allerdings die Vermutung, dass dabei dann mehrere Faktoren eine Rolle spielen müssen, da das sonst öfters auftreten würde.
Zum WLAN Connect Problem: Ich habe massive Probleme mit dem Wizard und SSID's wie "Fritz!...." (Also mit Sonderzeichen) Gebe ich alles unter /config ein statt den Wizard unter /setup zu machen und mache nach dem Speichern einen Kaltstart, dann klappt der Verbindungsaufbau zu 85%
Zum on-till:
Es gibt in den 99_Utils eine Funktion abstime2rel($)
Ich habe die einfach umgebaut und nach 99_myUtils und als abstime2relSec($) gepackt. Dies liefert die Sekunden bis zur Zielzeit, auch wenn diese nach Mitternacht liegt. Also perfekt um einen longpulse zu bestücken. Ich habe mir den Source deines Moduls noch gar nicht angesehen, ich denke mal wenn du den Code copy paste reinmachst geht das schneller. Ich weiß nicht, ob man eine Perl Funktion mit Variablenübergabe in eventMap einbauen kann. In der Commandref steht nix dazu.
##################### datdiff seconds ######### expect String e.g. "08:45:20"
sub
abstime2relSec($)
{
my ($h,$m,$s) = split(":", shift);
$m = 0 if(!$m);
$s = 0 if(!$s);
my $t1 = 3600*$h+60*$m+$s;
my @now = localtime;
my $t2 = 3600*$now[2]+60*$now[1]+$now[0];
my $diff = $t1-$t2;
$diff += 86400 if($diff <= 0);
return $diff;
}
So eine Funktion gehört auch weiterhin in eine 99_xyzUtils.pm. Bei dem Patch hatte ich eher an eine Itegration von Befehlen wie on-for-timer, etc in das Modul gedacht.
Zitat von: wkarl am 25 Dezember 2016, 06:09:27
Hallo Ascoban,
Das Problem hatte ich auch und es hat mich Tage gekostet den Grund dafür herauszubekommen. Der WPA Key wird verändert, wenn Du auf die Config-Seite gehts - gewollt oder ungewollt. Speichert man die Änderung auf der Config-Seite hat man für die WiFi Anmeldung die falschen credentials. Seitdem ich bei Änderungen den WPA Key mit eintrage funktioniert die Anmeldung wieder problemlos.
ciao Walter
Kann es sein das du die Funktion "Passwort speichern" deines Browsers nutzt? Bzw schau mal ob im Passwortspeicher unter der IP des ESP Eintrag vorhanden ist.
Zitat von: dev0 am 25 Dezember 2016, 09:01:10
So eine Funktion gehört auch weiterhin in eine 99_xyzUtils.pm. Bei dem Patch hatte ich eher an eine Itegration von Befehlen wie on-for-timer, etc in das Modul gedacht.
Wenn man das implementieren will, müsste man einen defaultGPIO als Attribut angeben. Die standardisierten Funktionen on-for-timer, on-till usw. haben ja nur einen parameter. Hattest du so etwas schon vorgesehen? So wie ich das im Modulcode verstehe prüfst Du ja nur die Syntax und schickst das Kommando per http weiter an das device. Bei den on-xxx Kommandos müsste man dann im Modul entscheiden an welchen GPIO das longpulse gehen soll und entsprechend den http request erst bauen. Ein Device könnte ja mehrere schaltbare GPIO haben. Wenn kein defaultGPIO gesetzt ist, müsste man die on-xxx Kommandos als Fehler ausgeben. Wie denkst Du darüber?
Gesendet von iPhone mit Tapatalk
Zitat von: dev0 am 25 Dezember 2016, 07:31:39
Diese Perl Warnung erscheint, wenn keine basic auth credentials hinterlegt sind, diese aber mit 'get <bridge> user/pass' abgefragt werden.
Bei den dürftligen Informationen von Dir kann ich nur raten: Du benutzt basic auth und hast den Namen der Bridge in der fhem.cfg direkt geändert oder hast es sonst irgendwie geschaft die Datei ./FHEM/FhemUtils/uniqueID zu schrotten. Abhilfe: die authorization credentials mit 'set <bridge> user/pass <xyz>' neu setzen.
Hallo, das was du geschrieben hast hat geklappt.
Es ist kein Kernfrisches System gewesen mit einem einmaligen update aufruf.
Zitat von: sash.sc am 24 Dezember 2016, 15:21:15
Siehe ab Beitrag #492 hier im thread. Hatte das gleiche Problem! ;)
Gruß Sascha
Von mobil gesendet daher kurze Antwort
Hallo zusammen,
ich steh vollkommen auf dem Schlauch. Habe mir die Beiträge durchgelesen.
Ich fand dort den Hinweis: Zitat: Benutz das FHEM Update, wie ist auf Github beschrieben.
Ist hier das klassische Update in FHEM gemeint?
Wenn ich das ausführe, wird kein ESPEasy Modul installiert.
Könnte mir jemand die Schritte mitteilen, wie ich das Modul ESPEasy in FHEM implementiert werden kann.
Danke
Frank
Die Datei von github runterladen und manuell kopieren.
Dann sollte es klappen
Von mobil gesendet daher kurze Antwort
setze in FHEM das Kommando
update add https://raw.githubusercontent.com/ddtlabs/ESPEasy/master/controls_ESPEasy.txt
ab. Dann Konfig speichern. Ab da wird bei jedem Update das Modul mit eingeschlossen.
Zitat von: Waldmensch am 25 Dezember 2016, 17:23:38
setze in FHEM das Kommando
update add https://raw.githubusercontent.com/ddtlabs/ESPEasy/master/controls_ESPEasy.txt
ab. Dann Konfig speichern. Ab da wird bei jedem Update das Modul mit eingeschlossen.
Vielen Vielen Dank,
für die Hilfestellung - das wars. Nach einfügen des Befehls wurde das Modul beim update registriert und installiert.
Frank
Vielleicht kann es @dev0 im ersten Post noch dazuschreiben. Irgendwo im Thread steht es aber auch.
Gesendet von iPhone mit Tapatalk
Zitat von: Waldmensch am 25 Dezember 2016, 14:33:30
Wenn man das implementieren will, müsste man einen defaultGPIO als Attribut angeben.
Vermutlich, ich denke bei Gelegenheit mal drüber nach, ob es nicht einen einfacheren Weg gibt.
Zitat von: Waldmensch am 25 Dezember 2016, 19:05:30
Vielleicht kann es @dev0 im ersten Post noch dazuschreiben. Irgendwo im Thread steht es aber auch.
Wie üblich ist alles Notwendige auf der Github Projektseite beschrieben:
Zitat
Requirements, installation, command reference, ... see wiki pages (https://github.com/ddtlabs/ESPEasy/wiki)
Vermutlich könnte ich das noch blinkendrot in den ersten Beitrag schreiben und es würde von dem Einen oder Anderen nicht gelesen ;)
Ich habe mal eine Verständnisfrage zum longpulse: wird ein gesetzter longpulse gelöscht, wenn ich in die Zeispanne hinein ein ein "on" setze?
Hintergrund ist, ich will mein Hoflicht mit einem Taster schalten. Ein einfacher Tastendruck soll einen longpulse 120 auslösen. Ein doppelter Tastendruck soll das Licht dauerhaft einschalten. Dazu müsste aber der longpulse quasi gelöscht werden.
Gesendet von iPhone mit Tapatalk
also ich weiß nicht mehr, so dusselig kann ich doch nicht sein.
wenn ich den esp mit
define espBridge ESPEasy 192.168.178.39 8383
einbinden will sagt der mir
ERROR: missing arguments for subtype device:
Use 'define <name> ESPEasy <bridge> <PORT>
Use 'define <name> ESPEasy <ip|fqdn> <PORT> <IODev> <IDENT>
versuche ich das exakt so wie im Post 1 und trage statt der IP nur Bridge ein wird es definiert, jedoch ist es Essig da ich keine Daten rein bekomme.
was läuft da falsch ?
Genau das einrichten:
Zitat von: BlackStone am 27 Dezember 2016, 23:43:57
versuche ich das exakt so wie im Post 1 und trage statt der IP nur Bridge ein wird es definiert
Und dann noch bei deinem ESP unter "Controller IP" die IP des FHEM Servers eintragen.
Du hast aber in global ein web mit 8083 angelegt?
Auf dem ESP musst du mindestens ein Device anlegen mit Delay und einem Haken bei send Data. Erst dann sendet der ESP Daten und die Bridge legt in FHEM ein Device an. Wenn du keinen Sensor dran hast nimm ein System Device, Bsp RSSI, mit einem Delay von 60. Dann wird alle 60Sek der RSSI Wert an FHEM geschickt.
Die Bridge mal auf verbose 5 setzen kann auch nicht schaden. Da kommen sehr viel nützliche Meldungen.
Gesendet von iPhone mit Tapatalk
Man glaubt es kaum, warum auch immer es war die Controller IP.
Dafür Grätscht jetzt der Watchdog und löst resets am laufendem band aus. ^^
ist ein BMP085, DHT22, BH1750 (GY-30) und ein OLED dran. sollte also eigendlich passen.
Zitat von: Waldmensch am 26 Dezember 2016, 14:59:47
wird ein gesetzter longpulse gelöscht, wenn ich in die Zeispanne hinein ein ein "on" setze?
Ich habe es noch nicht ausprobiert. Aber Du in der Zwischenzeit bestimmt doch, oder?
Zitat von: BlackStone am 28 Dezember 2016, 01:10:20
Dafür Grätscht jetzt der Watchdog und löst resets am laufendem band aus. ^^
Um diesen Satz zu verstehen benötigt man wohl mehr Informationen...
Zitat von: dev0 am 28 Dezember 2016, 06:05:19
Ich habe es noch nicht ausprobiert. Aber Du in der Zwischenzeit bestimmt doch, oder?
Also was ich bis jetzt beobachtet habe, wenn man einen longpulse in einen laufenden longpulse absetzt, dann scheint der zweite "auf Halde" zu liegen und nach Ablauf des ersten longpulse ausgeführt zu werden. Das äußert sich durch ein unschönes flackern der Hofbeleuchtung, da nach Ablauf des ersten das Relais kurz abfällt. Schöner wäre es, wenn ein 2. longpulse den ersten einfach in der Zeitspanne verlängern würde. Wenn im dunkeln 10 30W LED Strahler flackern sieht das echt übel aus. Den Fall, das longpulse im andere "reingeschoben" werden, hat man ja bei PIR Meldern und Bewegung auf dem Hof
Gesendet von iPhone mit Tapatalk
Zitat von: dev0 am 28 Dezember 2016, 06:14:06
Um diesen Satz zu verstehen benötigt man wohl mehr Informationen...
Leider muss ich sagen, ist das genauso gemeint. Mein nodemcu (ESP 12-E) resetet immer wieder. Hab schon verschiedene Netzteile probiert, darunter auch ein Labor netzgerät.
Drauf gebrannt habe ich die 147 rc 8, vom image.
Werd mal schauen ob ich die 146 noch zupfen kann, sonst wohl mal über die ide den Source kompilieren.
Naja mit den ESP ist für mich Neuland.
Dann nimm doch mal alle devices raus und teste jeweils nur eins. Eventuell macht ja auch der 5V ->3,3V Wandler auf dem Board schlapp. Eventuell mal mit dem Labornetzteil direkt 3,3V auf einen entsprechenden Pin geben, ohne USB Netzteil. Das labornetzteil zeigt dir ja dann auch den Strom an.
Gesendet von iPhone mit Tapatalk
Zitat von: Waldmensch am 28 Dezember 2016, 08:39:44
Schöner wäre es, wenn ein 2. longpulse den ersten einfach in der Zeitspanne verlängern würde.
Der (long)pulse Befehl wird in _P001_Switch.ino definiert, vielleicht kannst Du das (für Dich) anpassen. Die ESPEasy Entwickler scheinen seit Wochen untergtaucht zu sein oder reagieren nur auf meine Anfragen nicht :(
Ich habe das leider auch schon gesehen, wie Du dich im Forum dort abmühst :(
Ich hätte da auch für analoge Sensoren einen energiesparenden Multiplex Ansatz. Ich trau mich blos mangels Doku nicht an den Source ran. Für intensives abtauchen fehlt mir aktuell die Freizeit :(
Gesendet von iPhone mit Tapatalk
Ich habe mir mal die Funktion setSystemTimer() angeschaut, die da benutzt wird. Die sieht eigentlich ein reUse vor, sprich addieren eines Zeitwertes zu einem bestehenden Timer. Als indetifier wird Par1 benutzt. Dieser wird durch die pulse Funktion auf die Nummer des GPIO Pin gesetzt. Im Fall Sonoff also 12. Das sollte so eigentlich im ESPEASY alles passen.
Wartest du im Modul eventuell mit dem nächsten longpulse oder schiebst Du den sofort raus?
Meine initiale Frage hat sich anhand des Codes aber auch beantwortet. Bei einem normalen gpio Befehl wird ein eventueller Timer nicht gelöscht. Das heißt, egal was während des longpulse an Kommandos abgesetzt wird, wenn der Timer abgelaufen ist wird der geplante Zustand gesetzt. Man müsste eine resetSystemTimer() in ESPEasy.ino einbauen und in case "gpio" vorher anspringen, um den Timer zu löschen.
Gesendet von iPhone mit Tapatalk
Generell verändert das Modul nichts an den Befehlen, eine Ausnahme ist das Mapping von off/on -> 0/1, wenn man off/on statt 0/1 verwendet.
Also wenn ich 2 longpulse hintereinander absetze dann werden die auch sofort an den ESP geschickt. Dann muss ich mal gucken woran das noch liegen könnte.
Gesendet von iPhone mit Tapatalk
Zitat von: BlackStone am 28 Dezember 2016, 08:55:16
Leider muss ich sagen, ist das genauso gemeint. Mein nodemcu (ESP 12-E) resetet immer wieder. Hab schon verschiedene Netzteile probiert, darunter auch ein Labor netzgerät.
Drauf gebrannt habe ich die 147 rc 8, vom image.
Werd mal schauen ob ich die 146 noch zupfen kann, sonst wohl mal über die ide den Source kompilieren.
Naja mit den ESP ist für mich Neuland.
Mein Modul (https://www.amazon.de/gp/product/B018E741G4/ref=oh_aui_search_detailpage?ie=UTF8&psc=1) ist einfach kaputt, sprich es hat eine Macke. Mit dem Netzteil wird das nichts zu tun haben. Ich habe mir daraufhin noch andere Module geholt, damit kann solche trivial Fehler gut ausschließen.
Gruß Otto
Na da habe ich wohl 9 kaputte. ;)
Ich denke mal das es ein Sensor ist.
Das Du neun Stück hattest konnte ich ja nicht wissen. Es klang nur genau wie mein Modul.
Na die Sensoren kannst Du ja reihum mal abziehen. 8)
Gruß Otto
Woher auch, hatte es ja nicht erwähnt. Scheint der dht zu sein, zumindest gibt der mir Werte aus die wo der Hygrometer nicht plausibel ist. Mal weitertesten.
Gesendet von meinem E6853 mit Tapatalk
Edit:/ So habe das Rätzel gelöst, es war Tatsächlich der Watchdog. der zugeschlagen hat.
Ich hatte die Delay werte zu knapp bemessen, habe nun wie Vorher die gleichen Sensoren dran
BH1750
BMP085
DHT22
und das Display :
OLED (126x64)
Das ganze auf dem NODEMCU von AMICA (Devkit 1.0).
Nach dem ich die Sensor delay`s jetzt auf 20 Sekunden habe, und das sende Delay auf 15 (Ok kürzer als die Sensoren ist eigentlich Quatsch) läuft es nun sauber und ohne reset.
ich hatte die vorher auf 2 sekunden stehen, erstmal damit was drin steht, und selbst bei 10 Sekunden ist er mir noch sporadisch Reset. ist ja erstmal ein Testaufbau auf einem Breadboard.
Wen sich das bewährt kommt das auf eine Platine, in ein Gehäuse unterm vordach (da ist es eh trocken bei uns), der BH1750 würde eigendlich reichen denke aber wäre verschenkte Kapazität nur das Display kommt später nicht fest dran. ^^
Aktualisierte Modul Version 0.80 auf Github verfügbar:
- Neues Attribut mapLightCmds:
Schaltet die Befehle rgb, ct, pct, on, off und toggle frei und mappt sie auf einen ESPEasy Befehl.
- Neue Attribute colorpickerCTww + colorpickerCTcw:
Mit diesen Attributen kann man den Farbtemperaturbereich des ct Colorpickers einstellen.
Diese Attribute benötigt man, um Colorpicker zB. mit dem RGBWW Plugin Lights (https://forum.fhem.de/index.php?topic=63622) benutzen zu können.
Ich habe auch grad einen Pullrequest gemacht bezüglich des Setup Wizard (Anzeige RSSI und BSSID). Da sind aber noch etliche andere offen. Ich hoffe das Projekt schläft nicht ein :(
Gesendet von iPhone mit Tapatalk
Bis zum nächsten stable Release gibt es einen Feature Freeze: http://www.letscontrolit.com/forum/viewtopic.php?f=6&t=2167#p10210
Meine Vermutung ist, dass nach dieser Version aber auch eher an ESPEasy Mega weitergearbeitet wird. Leider gibt es davon zZ. nur Binaries und keine Sourcen.
Verdammt! Ich repariere grad den pulsecount, bzw. dass ein evtl. laufender pulsecount gelöscht wird, wenn ein gpio request eingeht. Ich empfinde das aktuelle Verhalten als Bug.
Falls Du dir was in deinen Fork rüberziehen willst: Tommy-LSA
Als nächstes wollte ich dann an das Analog Plugin ran für ein Multiplex.
Edit: Ich bin ein absoluter Git Dau. Eigentlich wollte ich den Bugfix in einen separaten Pullrequest haben, Git hat ihn aber in den anderen PR mit reingenommen. https://github.com/ESP8266nu/ESPEasy/pull/101
Gesendet von iPhone mit Tapatalk
Wer 2 Analog Sensoren anschließen oder einfach nur Strom sparen will, kann diesen Patch nutzen. Keine Ahnung, ob das jemals ins offizielle Git wandert.
https://github.com/Tommy-LSA/ESPEasy/commit/4d6f1c3449f4b83bcc01ad4ea3b9aeaf703f6f4b
Mit dem ESPEasy Modul harmoniert es werden in jedem Fall 2 Werte übermittelt. Wenn kein oder nur ein GPIO genutzt wird, ist der andere Wert 0
Kann es sein das ein dht22 (habe 3 getestet) auf ESPeasy kontinuierlich knapp 10 % Luftfeuchtigkeit zu niedrig anzeigt.
Ich habe für die Fußbodenheizung in jedem Raum einen HM-TC-IT-WM-W-EU diese zeigen in der Luftfeuchtigkeit immer knappe 10% mehr an.
Hab jetzt jedoch noch ned verglichen ob es auf einem Nano , Mega 2650 oder auf einem Yun auch so ist.
Gesendet von iPad mit Tapatalk
Zitat von: BlackStone am 30 Dezember 2016, 02:29:53
Kann es sein das ein dht22 (habe 3 getestet) auf ESPeasy kontinuierlich knapp 10 % Luftfeuchtigkeit zu niedrig anzeigt.
Ich habe dazu einen neuen Thread gestartet, da es hier offtopic ist:
https://forum.fhem.de/index.php?topic=63679
Hallo,
Neu beim FHEM, probiere ich ein Sonoff anzuschlissen.
ESPEasy flash is gut gelaufen: version 147, web config gemacht.
FHEM ist neu auf ein Debian server installiert.
ESPEasy module in modules Verzeichniss gelagert, fhem process restartet.
Eine Zeile in fhem.cfg addiert:
define sonoffAD04 ESPEasy 192.168.193.34 8383
In log sehe ich nun folgende Fehlermeldungen:
2016.12.31 00:43:18 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2016.12.31 00:43:18 1: reload: Error:Modul 34_ESPEasy deactivated:
Not enough arguments for main::InternalTimer at ./FHEM/34_ESPEasy.pm line 321, near "$hash)"
Too many arguments for main::RemoveInternalTimer at ./FHEM/34_ESPEasy.pm line 1500, near ""ESPEasy_statusRequest")"
Not enough arguments for main::InternalTimer at ./FHEM/34_ESPEasy.pm line 1514, near "$hash)"
BEGIN not safe after errors--compilation aborted at ./FHEM/34_ESPEasy.pm line 2026, <$fh> line 28.
2016.12.31 00:43:18 0: Not enough arguments for main::InternalTimer at ./FHEM/34_ESPEasy.pm line 321, near "$hash)"
Too many arguments for main::RemoveInternalTimer at ./FHEM/34_ESPEasy.pm line 1500, near ""ESPEasy_statusRequest")"
Not enough arguments for main::InternalTimer at ./FHEM/34_ESPEasy.pm line 1514, near "$hash)"
BEGIN not safe after errors--compilation aborted at ./FHEM/34_ESPEasy.pm line 2026, <$fh> line 28.
2016.12.31 00:43:18 1: Including ./log/fhem.save
2016.12.31 00:43:18 1: configfile: Cannot load module ESPEasy
2016.12.31 00:43:18 1: usb create starting
2016.12.31 00:43:18 1: usb create end
2016.12.31 00:43:18 2: Error messages while initializing FHEM: configfile: Cannot load module ESPEasy
2016.12.31 00:43:18 0: Featurelevel: 5.7
2016.12.31 00:43:18 0: Server started with 9 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user root, pid 20253)
"version" Befehl gibt folgendes:
File Rev Last Change
fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig
98_autocreate.pm 9415 2015-10-09 17:22:35Z rudolfkoenig
91_eventTypes.pm 8725 2015-06-10 09:50:06Z rudolfkoenig
01_FHEMWEB.pm 9867 2015-11-12 16:41:48Z rudolfkoenig
92_FileLog.pm 9838 2015-11-09 17:32:44Z rudolfkoenig
91_notify.pm 8953 2015-07-13 15:13:06Z rudolfkoenig
99_SUNRISE_EL.pm 9831 2015-11-08 19:13:09Z rudolfkoenig
98_telnet.pm 9511 2015-10-18 10:13:01Z rudolfkoenig
99_Utils.pm 7914 2015-02-08 11:14:10Z rudolfkoenig
Wie kann ich nun weiter?
Danke und Gruss,
Jacques-D.
Nun fast den gleichen Fehler habe ich auch gemacht. da der define nicht über die fhem Eingabezeile ging. ;)
Die Zeile
define sonoffAD04 ESPEasy 192.168.193.34 8383
nicht in die fhem.cfg rein editieren, das ergebnis ist bei dir ja zu sehen. also wieder raus editieren ;)
Du musst Tatsächlich wie im ersten post zu lesen
define sonoffAD04 ESPEasy bridge 8383
in die Fhem Eingabe zimmern.
Dabei wirst evtl. noch eine Meldung bekommen das ein Module fehlt, bei mir war es JSON. das musst dann noch als perl Module installieren.
Dann natürlich im sonoff Webconfig, die Fhem server ip und den Port 8383 als Controller eintragen
dazu habe ich noch :
update add https://raw.githubusercontent.com/ddtlabs/ESPEasy/master/controls_ESPEasy.txt
in die fhem eigabe gezimmert und danach selbstverständlich die config gespeichert.
So wird bei jedem update gleichzeitig das ESPeasy module mit upgedatet (nicht das auf deinem sonoff).
Zitat von: jdpiguet am 31 Dezember 2016, 00:58:02
fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig
Deine FHEM ist zu alt: Du hast nur Die Version 5.7 installiert und noch kein Update gemacht. Diese Version ist über 13 Monate alt.
Zuerst das Perl Modul JSON instalieren, dann über die FHEM Eingabezeile (oder Telnet) folgendes ausführen:
update add https://raw.githubusercontent.com/ddtlabs/ESPEasy/master/controls_ESPEasy.txt
update
shutdown restart
define ESPEasy_Bridge ESPEasy 8383
Danach werden die einzelnen Devices automatisch angelegt, wenn Daten empfangen werden.
Zitat
Eine Zeile in fhem.cfg addiert:
Es ist unnötig, masochistisch und in den meisten Fällen kontraproduktiv die fhem.cfg von Hand zu editieren. Besser ist es die WEB GUI zu benutzen oder per Telnet. Wenn Du DIch mit devspec und Co. mal angefreundet hast, dann geht es so auch wesentlich schneller.
Noch ein Tipp: Lies die Einsteiger Doku, die im Anfängerbereich verlinkt ist, das erspart Dir viel Zeit unterm Strich ;)
Zitat von: dev0 am 31 Dezember 2016, 05:48:57
Noch ein Tipp: Lies die Einsteiger Doku, die im Anfängerbereich verlinkt ist, das erspart Dir viel Zeit unterm Strich ;)
Und den verlinkten angepinnten Anfänger Kurs, (https://wiki.fhem.de/wiki/Erste_Schritte_in_fhem) der schult den Umgang mit der WebGUI.
Guten Rutsch
Otto
Danke an dev0 und Blackstone: es hat geklappt.
ZitatDeine FHEM ist zu alt: Du hast nur Die Version 5.7 installiert und noch kein Update gemacht. Diese Version ist über 13 Monate alt.
Ich habe FHEM direkt mit aptitude installiert: https://debian.fhem.de/ (https://debian.fhem.de/)
Das Repository scheint nicht so oft aufdatiert sein :'(
Es ist möglich Sonoff/ESPEasy devices via "FHEM HTPP" oder "MQTT" anzuschliessen, was sind die Vor-/Nachteile von beiden Lösungen?
Gruss und guten rutsch,
Jacques-D.
Zitat von: jdpiguet am 31 Dezember 2016, 11:09:44
Das Repository scheint nicht so oft aufdatiert sein :'(
Aktuell sollten die nightly builds sein.
Zitat von: jdpiguet am 31 Dezember 2016, 11:09:44
Es ist möglich Sonoff/ESPEasy devices via "FHEM HTPP" oder "MQTT" anzuschliessen
Ja.
Zitat von: jdpiguet am 31 Dezember 2016, 11:09:44
was sind die Vor-/Nachteile von beiden Lösungen?
Das MQTT Modul kannst Du für alle möglichen Anbinden nutzen, das ESPEasy Modul ist auf ESPEasy zugeschnitten.
Zitat von: jdpiguet am 31 Dezember 2016, 11:09:44
Es ist möglich Sonoff/ESPEasy devices via "FHEM HTPP" oder "MQTT" anzuschliessen, was sind die Vor-/Nachteile von beiden Lösungen?
Die ESPEasy Bridge wurde ja extra entwickelt um den Usern die Arbeit mit Fhem zu erleichtern, aber leider unterstützt ESPEasy nicht alle Module von Sonoff. Die Bridge kann da ja nichts dafür, die leitet ja ESPEasy nur 1:1 durch. Wenn du POW, Slampher oder den CH4 einsetzen willst, musst du mehr oder weniger auf MQTT ausweichen. Bei MQTT brauchst du deshalb auch einen anderen Sketch als ESPEasy, eben einen der diese Module (zB: Arends) unterstützt.
Es funktionieren aber beide Protokolle auch parallel nebeneinander, nur halt nicht am selben Modul gut möglich. Ansonsten kann man pauschal nicht sagen was besser ist, jedes Protokoll hat seine Stärken und auch seine Berechtigung. Ich habe beides im Einsatz und auch beide Protokolle schätzen gelernt.
LG
Zitat von: jdpiguet am 31 Dezember 2016, 11:09:44
Ich habe FHEM direkt mit aptitude installiert: https://debian.fhem.de/ (https://debian.fhem.de/)
Das Repository scheint nicht so oft aufdatiert sein :'(
Naja bei allem was täglich in Entwicklung ist, ist es schwierig für alle zweifelsfrei zu beschreiben was wie genau funktioniert ;D ;D ;D
Auf dieser Seite sind drei Methoden beschrieben. Die ersten zwei führen zum gleichen Ziel -> stable Version 5.7 vom vorigen Jahr. Zu einem neuen stable Release konnten sich die Entwickler scheinbar nicht durchringen, bzw. gab es wichtigeres zu tun in der verfügbaren Zeit.
In beiden Fällen muss nach der Installation ein Update gemacht werden, sonst hat man einfach die Entwicklung/Neuigkeiten des letzten Jahres nicht.
Ich empfehle für alle, die es nicht besser wissen aber genau diese Vorgehensweise!Wobei man auch damit Tagesabhängig mal Pech haben kann, in der Regel werden Fehler innerhalb eines Tages behoben.
Die dritte Variante liefert sofort die Version von gestern. Aber es kann auch mal sein, dass etwas "nicht zusammen passt" ich hatte schon Fälle wo diese Variante nicht auf Anhieb lief, während "stable + Update" sofort lief!
Gruß Otto
Ich würde gerne in einem Sonoff ein Dummy Device anlegen und diesem von FHEM aus den Wert 0 oder 1 zuweisen.
Hintergrund ist, ich habe einen Bewegungsmelder an den freien GPIO gehängt, der den Sonoff über eine Rule schalten soll. Der Dummy soll dabei berücksichtigt werden (Autarkmodus on/off sozusagen)
Wie kann ich das realisieren? Adhoc würde mit nur einfallen, statt dem Dummy einen Switch zu nehmen, diesen an einen freien GPIO zu binden und von FHEM aus über den gpio Befehl zu schalten. Geht es auch eleganter?
Gesendet von iPhone mit Tapatalk
genau für diesen Fall gibt es den Wall Switch von Arends, brauchst nur in der user_config.h aktivieren. Hier musst du nur den GPIO 14 mit dem Bewegungsmelder auf GND ziehen.
* Wall switch and HC-SR501
\*-------------------------------------------------------------------------------------------*/
#define SWITCH_PIN 14 // GPIO 14 = Standard wall switch to Gnd (Sonoff_TH10A(16A), Sonoff SV)
#define SWITCH_MODE TOGGLE // [SwitchMode] TOGGLE, FOLLOW, FOLLOW_INV, PUSHBUTTON or PUSHBUTTON_INV (the wall switch state)
#define USE_WALL_SWITCH // Enable the use of a standard wall switch to control the relay
und in der sonoff.ino den gewünschten Modus auswählen.
#define SWITCH_MODE TOGGLE // TOGGLE, FOLLOW or FOLLOW_INV (the wall switch state)
das wars. Ich hahe noch 2 Sonoff Switch bestellt, die ich ebenfalls so betreiben möchte.
Der Vorteil, es geht auch ohne Fhem autark, wie ein gewöhnlicher Bewegungsmelder. Selbstverständlich kannst du das aber auch mit Rules in ESPEasy nachbilden, habe ich aber noch nicht versucht.
LG
Kurze Frage in die Runde:
Lässt sich mit dem Modul auch ein WS2801 LED Stripe an einem ESP ansteuern? Mir würde es im Prinzip ausreichen, wenn alle LEDs in der selben Farbe leuchten würden.
Zitat von: Reinhart am 31 Dezember 2016, 16:12:51
genau für diesen Fall gibt es den Wall Switch von Arends, brauchst nur in der user_config.h aktivieren. Hier musst du nur den GPIO 14 mit dem Bewegungsmelder auf GND ziehen.
* Wall switch and HC-SR501
[/quote]
Das kann ich bestätigen, geht ja auf meine Idee zurück.
Siehe auch Bilder vom Einbau in normale Verteilerdose.
Sonoff habe ich einfach gekürzt.
Übrigens geht seit gestern auch der Blink Modus. Damit kann man im Alarmfall z.B. Alle Strahler rings ums Haus
im Alarmfall blinken lassen. ;D
Billy
@Reinhart, @Billy: Ich glaube nicht, dass das so geht. Ich will die LEDs im Badschrank schon über FHEM Zeitsteuern. Dh. sie werden eingeschaltet über Helligkeitssensor und schalten 0:00 ab. Jetzt soll der Bewegungsmelder aktiv sein, d.h. wenn Papa um 1:00 noch ein Bier wegbringen muss, sollen die LED über den Bewegungsmelder angehen. Während der Regulären "an" Zeiten und wenn der Lichtsensor über 500 Lux meldet, will ich nicht, dass mir der Bewegungsmelder "reinpfuscht". Ich will also schon über FHEM volle Steuerungsgewalt haben, aber auch sagen können, das er autark arbeiten soll.
Mal noch ein ungewöhnliches Verhalten in einem DOIF
Folgendes wirft den Fehler, das Der Sonoff 4 das Kommando nicht kennt und zeigt mir supportete Kommandos an. Mit FS20 Geräten kann man das so machen
([ESPEasy_Helligkeit_collect:med] eq 0) (set ESPEasy_sonoff_4_Schalter,ESPEasy_sonoff_5_Schalter,OG.bz.DU.LED_regular off)
DOELSEIF ([ESPEasy_Helligkeit_collect:med] eq 1) (set ESPEasy_sonoff_4_Schalter,ESPEasy_sonoff_5_Schalter,OG.bz.DU.LED_regular on)
DOELSEIF ([05:30]) (set ESPEasy_sonoff_4_Schalter,ESPEasy_sonoff_5_Schalter,OG.bz.DU.LED_regular on)
DOELSEIF ([23:59]) (set ESPEasy_sonoff_4_Schalter,ESPEasy_sonoff_5_Schalter,OG.bz.DU.LED_regular off)
So, also wenn ich alle "set" einzeln schreibe, funktioniert es
([ESPEasy_Helligkeit_collect:med] eq 0) (set ESPEasy_sonoff_4_Schalter off, set ESPEasy_sonoff_5_Schalter off, set OG.bz.DU.LED_regular off)
DOELSEIF ([ESPEasy_Helligkeit_collect:med] eq 1) (set ESPEasy_sonoff_4_Schalter on, set ESPEasy_sonoff_5_Schalter on, set OG.bz.DU.LED_regular on)
DOELSEIF ([05:30]) (set ESPEasy_sonoff_4_Schalter on, set ESPEasy_sonoff_5_Schalter on, set OG.bz.DU.LED_regular on)
DOELSEIF ([23:59]) (set ESPEasy_sonoff_4_Schalter on, set ESPEasy_sonoff_5_Schalter off, set OG.bz.DU.LED_regular off)
Das heißt, das das on/off Kommando durchaus bekannt ist nur im kombinierten "set" nicht funktioniert. Ich weiß nicht ob das am Modul liegt oder grundsätzlich nicht bei eventMap Kommandos geht. Das on/off ist ja auf gpio 12 0/1 gemappt und nicht "nativ"
Das DOIF für den PIR im Bad sieht derzeit so aus, davon will ich aber weg, weil es bei jedem PIR Event abgearbeitet wird, rund um die Uhr. Ich will den PIR eigentlich gar nicht in FHEM sehen. Wenn er autark arbeiten würde, könnte ich das "SendData" abschalten
([ESPEasy_sonoff_5_Schalter:PIR] eq "on" and [OG.bz.DU.LED_regular:state] eq "off" and [ESPEasy_Helligkeit_collect:med] eq 0) (set ESPEasy_sonoff_5_Schalter longpulse 12 1 30)
ok, davon hast du aber vorher nichts geschrieben, das dies eine etwas komplexere Steuerung als nur ein Bewegungsmelder autark ist.
Wenn ich sehe, dass hier immer mehrere Sonoff gleichzeitig geschalten werden sollen, wäre das vielleicht eine Überlegung dies mit MQTT Group Topic zu steuern. Ein Group Befehl steuert dir alle darin befindlichen Sonoff mit dieser Topic gleichzeitig an. Das würde aber nur die "doelseif" vereinfachen und nicht das Problem "autark Steuerung" lösen.
Wenn ich dich richtig verstehe, dann hast du bereits ja alles gelöst nur willst es irgendwie einfacher machen, indem du die "autark" Lösung mit einbauen kannst?
Ich habe so eine ähnliche Aufgabenstellung wie du mit einem PIR der zu unterschiedlichen Zeiten unterschiedliche Lichtszenen auslösen soll und es noch verknüpft mit einem HM Taster und hier noch extra die "short" und "longpulse" auswerte. Ich habe einfach mehre If Bedingungen mit der Zeitverknüpfung aufgebaut. Das wird dann aber auch ähnlich wie dein Konstrukt und ist nicht einfacher und den PIR brauche ich in Fhem weil ich ihn ja zu bestimmten Zeiten eben bestimmte Handlungen ausführen lasse und er immer das Event erzeugt.
LG
@Billy
versorgst du den PIR mit der VCC (3,3V) des Sonoff an der Pinleiste?
Könntest du mit deinem PIR und der Wall einen eigenen Thread machen, weil das sicher mehr interessiert und hier sonst unübersichtlich wird?
LG
Bei mir reichen die 3,3 vom Seriellen Port. Man könnte aber auch den Regler vom PIR brücken. Der PIR arbeitet nur mit 3,3 und der Regler ist nur für 5V Kompatibilität drauf
Gesendet von iPhone mit Tapatalk
Zitat von: Spezialtrick am 31 Dezember 2016, 16:29:47
Lässt sich mit dem Modul auch ein WS2801 LED Stripe an einem ESP ansteuern? Mir würde es im Prinzip ausreichen, wenn alle LEDs in der selben Farbe leuchten würden.
Wenn Dein ESP mit ESPEasy die WS2801 Stripes steuern kann, dann unterstützt das Modul das auch (raw Befehl). Eine fertiges ESPEasy Plugin für WS2801 Stripes kenne ich nicht, für WS2811/WS2812 Stripes könntest Du auf dem Neopixel Plugin aufbauen.
@All: Bitte die Diskussionen ohne Bezug zum Thema dieses Threads einstellen.
Ich habe das mal getestet, den freien GPIO14 auf einen Switch zu legen. Ein set sonoff gpio 14 1 schaltet zwar den gpio Pin auf dem ESP, allerdings zieht der Switch (Task) nicht mit und sein value wird nicht gesetzt. Warum funktioniert das bei gpio 12, was das Relay ist? Dort schicke ich doch auch nur den gpio Befehl hin und der an den gpio gebundene Task setzt seinen value.
Gesendet von iPhone mit Tapatalk
Was kann das ESPEasy Modul daran ändern? Werden Befehle nicht korrekt übertragen?
Das weiß ich noch nicht. Ich denke nicht, da der gpio selbst ja gesetzt wird. Ist im command der Task mit enthalten? Bei mir heißen ja alle Task im Sonoff "Schalter", damit sie als ein Device auflaufen. Unterscheiden tuen sie sich nur im Value. Falls nicht nur der GPIO Sondern auch der Taskname mit übertragen wird, könnte ich mir vorstellen, das der Befehl im ersten passenden Task landet
Gesendet von iPhone mit Tapatalk
Es ist in der Tat so, das man einem Task, den man mit einem gpio (mit-)setzen möchte, einen uniquen Namen geben muss. Dann legt die Bridge ein eigenes Device an und auf diesem muss man dann den gpio setzen.
Gesendet von iPhone mit Tapatalk
Hallo,
ich habe mir das ESPEasy-Modul gerade eingerichtet und einen Sonoff konfiguriert.
Es hat mich ein bisschen Aufwand gekostet, weil ich zunächst keine Readings erhalten habe. Daher wurde das Gerät auch immer als "absent" markiert.
Geholfen hat dann, dem Attribut pollGPIOs den Wert 12 zu geben.
Geschaltet hat das Gerät trotzdem schon. Aber der Status wurde nicht sofort aktualisiert. Dazu musste ich jedesmal ein statusRequest absetzen.
Daher habe ich in der 34_ESPEasy.pm, Zeile 541, noch einen Aufruf der Methode ESPEasy_statusRequest($hash); ergänzt.
Evtl. könnte der Autor des Moduls das noch ergänzen. Vielen Dank!
Für jeden,der ähnliche Probleme hat wie ich, hier nochmal meine Konfiguration dazu:
define SonoffNordterrasse ESPEasy 192.168.178.121 80 espBridge SonoffNordterrasse
attr SonoffNordterrasse IODev espBridge
attr SonoffNordterrasse devStateIcon devStateIcon on:FS20.on:off off:FS20.off:on absent:10px-kreis-rot:statusRequest .*:ios-NACK:statusRequest
attr SonoffNordterrasse eventMap /gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/
attr SonoffNordterrasse group Schalten
attr SonoffNordterrasse pollGPIOs 12
attr SonoffNordterrasse room ESPEasy,Garten
attr SonoffNordterrasse setState 1
attr SonoffNordterrasse stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"GPIO12","")}
Zitat von: Waldmensch am 01 Januar 2017, 17:47:00
Es ist in der Tat so, das man einem Task, den man mit einem gpio (mit-)setzen möchte, einen uniquen Namen geben muss. Dann legt die Bridge ein eigenes Device an und auf diesem muss man dann den gpio setzen.
Wenn Du verhindern möchtest, dass mehrere FHEM Devices, für unterschiedliche ESP Devices (tasks), angelegt werden, dann kannst Du das (sehr flexible) Attribut combineDevices aktivieren.
Zitat von: peterboeckmann am 01 Januar 2017, 17:50:52
Daher habe ich in der 34_ESPEasy.pm, Zeile 541, noch einen Aufruf der Methode ESPEasy_statusRequest($hash); ergänzt.
Evtl. könnte der Autor des Moduls das noch ergänzen. Vielen Dank!
Nein. Du hast zwei Dinge noch nicht verstanden:
- Wenn Du ESPEasy auf dem ESP mit einem Device vom Typ 'Input Switch' konfigurierst, dann werden die Status aktiv vom ESP an FHEM gemeldet. Auch dann, wenn Du am Gerät selbst schaltest oder von sonst wo
- Wenn Du keinen 'Input Switch' definieren möchtest (warum auch immer?), dann kannst Du den Status, auch ohne im Quellcode zu wildern, nach dem Schalten mit Hilfe des Attributs 'parseCmdResponse' setzten lassen. In diesem Fall wird dann die JSON Antwort von ESPEasy auf den HTTP Request benutzt um den aktuellen Zustand zu ermitteln.
Btw: Wenn Du meinst, dass der zweite Punkt in der Commandref nicht ausreichend beschrieben ist, dann kannst Du das gerne mit einem Pull Request ergänzen.
Hallo dev0,
danke erstmal für die schnelle Antwort.
Zitat von: dev0 am 02 Januar 2017, 07:30:29Wenn Du ESPEasy auf dem ESP mit einem Device vom Typ 'Input Switch' konfigurierst, dann werden die Status aktiv vom ESP an FHEM gemeldet.
Mein Fehler scheint dann noch irgendwo anders zu liegen. Das Device ist als "switch input" definiert, aber im FHEM kommen keine Redings an.
Ein autocreate ist auch nicht erfolgt. Kann ja auch nicht, ohne dass Readings ankommen.
Kannst Du mir da evtl. einen Tipp geben? Ich habe die ESP-Konfiguration mal angehängt.
Auf dem Reiter "Rules" habe ich außerdem noch folgendes eingefügt:
on Licht#Key do
if [Licht#Relay]=1
gpio,12,0
else
gpio,12,1
endif
endon
on Licht#Relay do
if [Licht#Relay]=1
gpio,13,0
else
gpio,13,1
endif
endon
Mein FHEM läuft mit https und basicAuth. Kann das das Problem sein?
Zitat von: dev0 am 02 Januar 2017, 07:30:29
Btw: Wenn Du meinst, dass der zweite Punkt in der Commandref nicht ausreichend beschrieben ist, dann kannst Du das gerne mit einem Pull Request ergänzen.
Mit derCommandref meinst Du scheinbar nicht diese? http://fhem.de/commandref_DE.html (http://fhem.de/commandref_DE.html) Dort habe ich leider nichts zu ESPEasy gefunden.
Ich habe mir wohl aus verschiedenen Quellen zusammengesucht, was ich brauchte. Dabei ist wohl ein bisschen was schief gegangen...
Viele Grüße,
Peter
Moin, Nein, er meint Deine persönliche Command Reference! Diese wird bei jedem neuen Modul (oder Update) erweitert und ist in Deinem FHEM im Browser links unten zu finden. Alternativ im ESPEasy Device ganz unten rechts "Hilfe zu diesem Device" (oder so ähnlich ;-)
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Die eingetragene Controller IP entspreicht der FHEM IP Adresse?
Zitat von: dev0 am 02 Januar 2017, 09:42:18
Die eingetragene Controller IP entspreicht der FHEM IP Adresse?
Ja. Port, Username und Password sind auch korrekt.
Die Firmware auf dem Sonoff hat die R140.
Edit:
Mir fällt gerade auf, dass ich der ESPBridge den Port 8383 gegeben habe. Keine Ahnung, wo ich das gelesen hatte.
Muss hier der FHEM-Port (8083) oder der ESPEasy-Port (80) angegeben werden?
Ich würde:
- Die selbst angelegten FHEM Devices löschen, deaktivieren wird nicht ausreichen.
- Auf dem dem ESP noch ein zusätzliches Device vom Type "System Info" z.B. Wifi/RSSI anlegen, dass regelmäßig sendet.
- attr <esp-bridge> verbose 5
- ins log gucken ob Daten ankommen.
Wenn das auch nicht funktioniert, dann bitte noch ein list der Bridge in Code-Tags hier anhängen: 'list <esp-bridge>'
Danke nochmal für die Hilfe!
Ich habe den Fehler gerade gefunden: Ich hatte in der Main Config des ESPEasy den Port 8083 angegeben, nicht den Port 8383 der ESPEasy-Bridge.
Zitat von: peterboeckmann am 02 Januar 2017, 09:50:17
Edit:
Mir fällt gerade auf, dass ich der ESPBridge den Port 8383 gegeben habe. Keine Ahnung, wo ich das gelesen hatte.
Muss hier der FHEM-Port (8083) oder der ESPEasy-Port (80) angegeben werden?
Der Port der ESPEasy Bridge muss identisch mit dem Port sein, den Du auf dem ESP als Controller Port einträgst. Also auf beiden Seiten 8383, wenn Du der Bridge den Port 8383 gegeben hast.
... Aber das hast Du ja inzwischen korrigiert.
In dem Zusammenhang vielleicht noch einen Tipp (an alle): Wie Waldmensch schrieb kann es zu Problemen kommen, wenn man für mehrere ESP Devices (tasks) den gleichen Namen verwendet. Deshalb besser eindeutige Namen verwenden und das Attribut combineDevices benutzen, damit nicht mehrere FHEM Devices für einen ESP angelegt werden.
Da nun alles funktioniert, inkl. autocreate, hätte ich noch einen Wunsch:
Könntest Du in einer der nächsten Versionen noch den toggle-Befehl mit einbauen?
Mein Hintergedanke: Ich würde das Gerät gerne per AndFHEM-Widget als Umschalter steuern können. (Oder brauche ich dafür etwas anderes?)
Zitat von: peterboeckmann am 02 Januar 2017, 10:35:47
Könntest Du in einer der nächsten Versionen noch den toggle-Befehl mit einbauen?
Mit eventMap solltest Du genau das selbst machen können. In Deinem geposteten Definitionen benutzt Du eventMap ja auch schon für on-for-timer...
Edit: Habe in der Commandref gesehen, dass eventMap keinen Perl Code erlaubt, daher wird das wohl nicht funktionieren. Dann wäre es mMn am sinnvollsten Toggle als Parameter des gpio Befehls im Switch Plugin zu implementieren. Dann funktioniert eventMap.
Zitat von: dev0 am 02 Januar 2017, 10:58:15
Dann wäre es mMn am sinnvollsten Toggle als Parameter des gpio Befehls im Switch Plugin zu implementieren. Dann funktioniert eventMap.
Sorry, das hab ich nicht verstanden. ???
Was soll ich machen?
Zitat von: peterboeckmann am 02 Januar 2017, 12:05:24
Was soll ich machen?
Toggle als Parameter in das ESPEasy Switch Plugin einbauen, damit man z.B. 'set <esp> gpio 15 toggle' benutzen kann. Dann könntest Du mit eventMap den Toggle Befehl in FHEM benutzen.
Semi OT: Ich habe es mal in das switch Plugin eingebaut: https://github.com/Tommy-LSA/ESPEasy/commit/bd1d99e3cf9553fe189b9f290f2af1ba616a4b40
FHEM Befehl: set <device> toggle <pin>
Erfolgreich getestet auf einer nodeMCU. Vermutlich wird es nicht mehr ins offizielle Git wandern. Schwere Entscheidung, was man da nun machen soll.
Schon mal ein Ansatz. Wobei ich es sinnvoller fände, toggle nicht als command sondern als parameter des GPIO Befehls zu implementieren:
'set <esp> gpio 15 toggle'.
Hintergrund dieser Ansicht ist, dass auch andere Plugins toggle als Parameter verwenden können. Aus diesem Grund habe ich zB. auch beim RGBWW Lights Plugin Befehle wie rgb, on, off toggle, ... hinter dem eigentlichen Lights Befehl implementiert. So kommen sich die Plugins nicht in die Quere und Chance, das der Patch ins ESPEasy übernomen wird ist größer. Just my 2 cents...
Naja, Par1-3 sind Integer. Das wär dann ne größere Baustelle geworden, oder man hätte als Par2 dann eine 2 nehmen müssen (0= off, 1= on, 2= toggle)
also set <esp> gpio 15 2
struct EventStruct
{
byte Source;
byte TaskIndex;
byte BaseVarIndex;
int idx;
byte sensorType;
int Par1;
int Par2;
int Par3;
byte OriginTaskIndex;
String String1;
String String2;
byte *Data;
};
Keine große Baustelle.
statt:
int i = event->Par2;
so:
str s = parseString(string, 3);
if (s == 0) { ...
Die Variable string wird der Funktion Plugin_001() bereits übergeben.
So tief habe ich in den Code nicht reingeschaut. Die Arduino IDE ist mir einfach zu grottig um intensiv damit zu arbeiten. Ich brauch das "toggle" auch nicht unbedingt. Wenn es jemand weiterentwickeln will - kein Problem, die Kernfunktionalität lässt sich ja copy/paste verwenden. Ich weiß auch nicht, ob das checken des Pinmode nötig ist. Ich habs vorsichtshalber gemacht, um nicht in einen Fehler bei "jungfräulichem" Pin zu rennen. Keine Ahnung, ob die pinmodesbeim Boot gesetzt werden. Ich bin davon ausgegangen das nicht, weil konsequent im Switch Plugin der Mode jedes mal auf OUTPUT gesetzt wird.
Ich glaube nicht, dass man in der Firmware rumbasteln muss.
Reicht es nicht aus, FHEM-seitig je nach aktuellem Status entweder "set <esp> gpio 12 1" oder "set <esp> gpio 12 2" aufzurufen?
Wie gesagt, es geht mir auch nicht um das "toggle" an sich.
Ich will halt nur gerne den Umschalte im AndFHEM-Widget nutzen.
dann mach einen dummy mit nur einem State und fackel das toggle über ein DOIF ab indem du den aktuellen Zustand des ESP einbeziehst. Das hat aber dann als solches nichts mehr mit dem Modul zu tun.
Hallo,
ein Toggle lässt sich auch mit einem benutzerspezifischen Event auf dem ESP erzeugen.
auf dem Relais GPIO muss natürlich ein Switch zur Statusanzeige definiert werden.
Mit der folgenden Rule lässt sich dann der toggle Befehl definieren:
on toggle do
if [Relais#Output]=1
gpio,13,0
else
gpio,13,1
endif
endon
Mit dem Befehl:
set ESPEasy_Test raw event toggle
kann man dann schon mal schalten.
Mit evntMap und webCMD kann man dann einen Toggle-Button erzeugen:
attr ESPEasy_Test eventMap /gpio 13 on:on/gpio 13 off:off/gpio 13 gpio:off/gpio 13 output:off/raw event toggle:toggle/
attr ESPEasy_Test webCmd on:off:toggle
Bei mir funktioniert das ganz gut.
Gut kombiniert ;)
Hi,
Testing the esp module with sonoff.
I mad a switch input, on gpio12 and created this in fhem
define Dressoirlamp ESPEasy 192.168.180.71 80 Woonkameresp Dressoirlamp
attr Dressoirlamp IODev Woonkameresp
attr Dressoirlamp devStateIcon on:FS20.on off:FS20.off
attr Dressoirlamp eventMap /gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/
attr Dressoirlamp group Lampen
attr Dressoirlamp Interval 300
attr Dressoirlamp icon light_cabinet
attr Dressoirlamp readingSwitchText 1
attr Dressoirlamp room Woonkamer
attr Dressoirlamp webCmd on:off
attr Dressoirlamp setState 3
attr Dressoirlamp stateFormat Switch
If works alomst 100%. But if I restart fhem then I get first opened, and than i get value gpio
l Dressoirlamp
Internals:
DEF 192.168.180.71 80 Woonkameresp Dressoirlamp
HOST 192.168.180.71
IDENT Dressoirlamp
INTERVAL 300
IODev Woonkameresp
NAME Dressoirlamp
NOTIFYDEV global
NR 457
NTFY_ORDER 50-Dressoirlamp
PORT 80
STATE gpio
SUBTYPE device
TYPE ESPEasy
VERSION 0.8
Readings:
2017-01-02 19:23:48 GPIO12 gpio
2017-01-02 19:23:48 GPIO12_mode output
2017-01-02 20:36:15 Switch gpio
2017-01-02 20:38:50 presence present
2017-01-02 20:43:14 state present
Helper:
fpc 1483386194
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 303
TRIGGERTIME 02.01.2017 20:48:17
Received:
Attributes:
IODev Woonkameresp
Interval 300
devStateIcon on:FS20.on off:FS20.off
eventMap /gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/
group Lampen
icon light_cabinet
readingSwitchText 1
room Woonkamer
setState 3
stateFormat Switch
webCmd on:off
If I do an on or off than I get the right value.
[fhem> l Dressoirlamp
Internals:
DEF 192.168.180.71 80 Woonkameresp Dressoirlamp
ESP_BUILD 147
ESP_SLEEP 0
ESP_UNIT 1
HOST 192.168.180.71
IDENT Dressoirlamp
INTERVAL 300
IODev Woonkameresp
LASTInputDev Woonkameresp
MSGCNT 1
NAME Dressoirlamp
NOTIFYDEV global
NR 457
NTFY_ORDER 50-Dressoirlamp
PORT 80
STATE off
SUBTYPE device
TYPE ESPEasy
VERSION 0.8
Woonkameresp_MSGCNT 1
Woonkameresp_TIME 2017-01-02 20:46:14
Readings:
2017-01-02 19:23:48 GPIO12 gpio
2017-01-02 19:23:48 GPIO12_mode output
2017-01-02 20:46:14 Switch off
2017-01-02 20:38:50 presence present
2017-01-02 20:46:14 state Swi: off
Helper:
fpc 1483386194
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 303
TRIGGERTIME 02.01.2017 20:48:17
Received:
Switch 1483386374
Attributes:
IODev Woonkameresp
Interval 300
devStateIcon on:FS20.on off:FS20.off
eventMap /gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/
group Lampen
icon light_cabinet
readingSwitchText 1
room Woonkamer
setState 3
stateFormat Switch
webCmd on:off
Is it possible, that het retrieves the right value when I (re)start fhem?
regards RIchard
Zitat von: roelleke am 02 Januar 2017, 20:17:04
Hallo,
ein Toggle lässt sich auch mit einem benutzerspezifischen Event auf dem ESP erzeugen.
auf dem Relais GPIO muss natürlich ein Switch zur Statusanzeige definiert werden.
...
Das Toggle funktioniert auch bei mir auf Anhieb.
Aber scheinbar braucht es doch noch etwas anderes für die Steuerung über AndFHEM. Kennt sich da jemand aus?
Zitat von: kroonen am 02 Januar 2017, 20:48:37
I mad a switch input, on gpio12 and created this in fhem
Update to the current module version 0.8 first.
Do you have manually created the device Dressoirlamp or was it done by autocreate?
If it was not done by autocreate then your ESP setup is not correct or you have disabled autocreate globally.
Zitat von: kroonen am 02 Januar 2017, 20:48:37
Is it possible, that het retrieves the right value when I (re)start fhem?
Yes.
Zitat von: peterboeckmann am 02 Januar 2017, 22:03:55
Aber scheinbar braucht es doch noch etwas anderes für die Steuerung über AndFHEM.
Wende Dich am Besten direkt an den AndFHEM Autor and klär was das Widget benötigt.
Hallo zusammen,
da das ESPEasy-Modul offenbar doch mächtiger ist, als ich es benötige, bin ich wieder auf meine alte Lösung umgestiegen: ein dummy repräsentiert den Sonoff und ein paar notify (+ ein paar Perl-Methoden) zum steuern.
Falls es jemanden interessiert, hab ich hier mal den Code zusammengestellt:
fhem.cfg:
define LampenNordterrasse dummy
attr LampenNordterrasse setList statusRequest toggle on off
attr LampenNordterrasse webCmd statusRequest:toggle:on:off
define notify_LampenNordterrasse_off notify LampenNordterrasse:off {setEspPINState("192.168.178.121",12,0)}
define notify_LampenNordterrasse_on notify LampenNordterrasse:on {setEspPINState("192.168.178.121",12,1)}
define notify_LampenNordterrasse_statusRequest notify LampenNordterrasse:statusRequest {getEspPINState("LampenNordterrasse","192.168.178.121",12)}
define notify_LampenNordterrasse_toggle notify LampenNordterrasse:toggle {toggleEspPinState("LampenNordterrasse","192.168.178.121",12)}
99_myUtils.pm
sub setEspPINState
{
Log 4, "esp Starte setEspPINState";
my $espdev = $_[0];
my $gpio = $_[1];
my $event = $_[2];
my $ret = "";
Log 4, "setEspPINState Aufruf: http://$espdev/control?cmd=GPIO,$gpio,$event";
$ret .= system("wget -q -O /dev/null 'http://$espdev/control?cmd=GPIO,$gpio,$event'");
$ret =~ s,[r
]*,,g;
Log 3, "esp $espdev returned: $ret";
}
sub getEspPINState
{
Log 4, "esp Starte getEspPINState";
my $devicename = $_[0];
my $espdev = $_[1];
my $gpio = $_[2];
my $ret = "";
Log 4, "esp Aufruf: http://$espdev/control?cmd=Status,GPIO,$gpio";
$ret = get("http://$espdev/control?cmd=Status,GPIO,$gpio");
if (index($ret, "\"state\": 0") != -1)
{
Log 3, "getEspPINState: off";
fhem("set $devicename off");
}
else
{
Log 3, "getEspPINState: on";
fhem("set $devicename on");
}
}
sub toggleEspPinState
{
Log 4, "esp Starte toggleEspPin";
my $devicename = $_[0];
my $espdev = $_[1];
my $gpio = $_[2];
my $ret = "";
Log 4, "esp Aufruf: http://$espdev/control?cmd=Status,GPIO,$gpio";
$ret = get("http://$espdev/control?cmd=Status,GPIO,$gpio");
if (index($ret, "\"state\": 0") != -1)
{
Log 3, "toggleEspPin: off->on";
system("wget -q -O /dev/null 'http://$espdev/control?cmd=GPIO,$gpio,1'");
}
else
{
Log 3, "toggleEspPin: on->off";
system("wget -q -O /dev/null 'http://$espdev/control?cmd=GPIO,$gpio,0'");
}
getEspPINState("$devicename","$espdev",$gpio)
}
Ich gebe zu, an einigen Stellen könnte man sauberer arbeiten (z.B. mit JSON), aber das funktioniert für meine Zwecke gut. (auch über AndFHEM)
Hallo, seit kurzem nutze ich ESPEasy mit einem Wechselstromzähler und Counter für S0-Bus.
Probleme habe ich aber bei der Übermittlung der Zeit zwischen 2 Impulsen.
Liegt daran das Counter einen Impuls doppelt zählt - also Impuls an und Impuls aus erzeugt einen Zähler +1.
Damit übermittelt er mir als Zeit immer die Impulslänge und nicht die Zeit bis zum nächsten Zählimpuls.
Der Wechseltromzähler hat 1000 Impulse je kWh und eine Impulslänge von 90ms.
Habt ihr einen Tip woran das liegen könnte bzw. wie ich die "richtige" Zeit übermittelt bekomme?
Kannst du nicht im ESP in Formula gleich /2 teilen? Ansonsten solltest Du die Frage im ESPEASY Forum stellen.
Gesendet von iPhone mit Tapatalk
Hallo peterboeckmann,
sieht aufwändig und kompliziert aus.
bei mir funktioniert das auch so:
define EasySwitch dummy
attr EasySwitch cmdIcon on:Restart off:Shutdown
attr EasySwitch room ESPEasy
attr EasySwitch setList on off
define espNotify notify EasySwitch.* set ESPEasy_Test $EVENT
attr espNotify room ESPEasy
Das andFHEM widget wir damit Problemlos unterstützt.
Hallo,
ich möchte ein Sonoff mit espeasy über Tablet-ui steuern.
Das Sonoff wird erkannt und auch in Fhem angelegt.
Das Sonoff lässt sich vom Tablet schalten und auch vor ort am Modul mit dem Taster. (Rules)
Der Zustand vom Relais wird auch richtig zurückgemeldet
state Key: off Rel: on upt: 7 2017-01-03 15:43:42
Bei der Version 0.8 kann das attr : devStateIcon kann aber nicht mehr angewählt werden.
Bei Bei der Version 0.66 war das noch möglich.
Jemand eine Idee??
Hi,
I tried the autocreate, but the problem is the following
eventMap /gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/
adding this and restarting fhem, I get the Switch value gpio , when pressing the on of off, the value is ok.
Any idea how the event map should be?
Hi
bei mir funktioniert das Sonoff
ausser devStateIcon kann ich nicht anwählen!
defmod ESPEasy_Son96_SW2 IODev espBridge
attr ESPEasy_Son96_SW2 Interval 300
attr ESPEasy_Son96_SW2 eventMap /gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/
attr ESPEasy_Son96_SW2 group ESPEasy Device
attr ESPEasy_Son96_SW2 presenceCheck 1
attr ESPEasy_Son96_SW2 readingSwitchText 1
attr ESPEasy_Son96_SW2 room ESPEasy
attr ESPEasy_Son96_SW2 setState 3
attr ESPEasy_Son96_SW2 stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"Relay","")}
setstate ESPEasy_Son96_SW2 off
setstate ESPEasy_Son96_SW2 2017-01-04 07:18:32 Key off
setstate ESPEasy_Son96_SW2 2017-01-04 07:18:31 Relay off
setstate ESPEasy_Son96_SW2 2017-01-04 07:21:53 presence present
setstate ESPEasy_Son96_SW2 2017-01-04 07:22:48 state Key: off Rel: off upt: 890
setstate ESPEasy_Son96_SW2 2017-01-04 07:22:48 uptime 890
Zitat von: rboelli am 03 Januar 2017, 15:51:22
Bei der Version 0.8 kann das attr : devStateIcon kann aber nicht mehr angewählt werden.
Bei Bei der Version 0.66 war das noch möglich.
Das kann ich nicht reproduzieren, zumal devStateIcon ein globales Attribut ist, dass nicht vom Modul implementiert wird sondern von FHEM core.
Zitat von: rboelli am 04 Januar 2017, 07:28:22
ausser devStateIcon kann ich nicht anwählen!
Nicht so ungeduldig, bitte.
attr ESPEasy_Son96_SW2 eventMap /gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/
Woher hast Du diese Zeile kopiert?
Zitat von: kroonen am 03 Januar 2017, 20:50:43
eventMap /gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/
Any idea how the event map should be?
It should be:
eventMap /gpio 12 on:on/gpio 12 off:off/
But I can reproduce the effect with this settings, too. I am not sure if this is an ESPEasy Modul or eventMap misconduct at the moment. But this should not be a problem at all because after a few seconds the ESP sends it current values and the spooky is over when the ESP is configures correcty.
Sorry ,
ich wollte nicht ungeduldig sein,
sondern freue mich dass du überhaupt so schnell antwortest.
Also das Device ESPEasy_Son96_SW2 wurde automatisch angelegt.
Folgende attr habe ich von Hand eingegeben
attr "eventMap /gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/"
eben so attr "stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"Relay","")}
Bei dem Auswahlfenster attr fehlen bei mir einfach die zeilen "devStateIcon" und "devStateStyle"
.....
comment
deniedlPs
disabele
do_not_notify
event-aggregator
.....
Versuchs mal über die commandleiste direkt reinzumachen oder in die fhem.cfg
attr ESPEasy_Son96_SW2 devStateIcon on:rc_GREEN:off off:rc_RED:on absent:rc_BLUE:off gpio:rc_YELLOW:off
Grüße
Matze
Zitat von: rboelli am 04 Januar 2017, 10:40:07
Bei dem Auswahlfenster attr fehlen bei mir einfach die zeilen "devStateIcon" und "devStateStyle"
Ich kann mich an der Stelle nur wiederholen: Die Ursache dafür liegt nicht im ESPEasy Modul, es handelt sich um globale Attribute.
Zitat von: rboelli am 04 Januar 2017, 10:40:07
attr "eventMap /gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/"
Auch hier möchte ich meine Frage an Dich wiederholen: Woher stammt diese Syntax? Wiki, Forum,...? Sie ist nämlich nicht korrekt, siehe meine Antwort an kroonen.
Jepp im espeasy Wiki ist es als Beispiel so hinterlegt
Grüße
Matze
attr "eventMap /gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/"
habe ich auch aus dem wiki https://wiki.fhem.de/wiki/Sonoff
Wenn ich es direkt eingebe bekomme ich diese Fehlermeldung:
ESPEasy_Son96_SW2: unknown attribute devStateIcon. Type 'attr ESPEasy_Son96_SW2 ?' for a detailed list.
Ich denke esliegt an meine Fhem instalation auf dem rpi
Auch bei einem dummy fehlt mir dieses attribut.
Hi,
I get the gpio away bij setting the switch input with a delay of 60 on the esp
Then I get every a minute ths settinge udate. Is this required??
Now I dont know how late the device went on or off
regards Richard
Zitat von: kroonen am 04 Januar 2017, 16:37:42
Then I get every a minute ths settinge udate. Is this required??
Now I dont know how late the device went on or off
If this workaround do not fit your needs then you have to look whats going wrong with eventMap Attribut. I do not see any ESPEasy module misconducts.
welchen ESPEasy Build würdet Ihr aktuell empfehlen? Ich habe mit dem aktuellen "stable" Build (R120) einige Probleme.
Zitat von: gerhardg am 04 Januar 2017, 18:16:24
welchen ESPEasy Build würdet Ihr aktuell empfehlen? Ich habe mit dem aktuellen "stable" Build (R120) einige Probleme.
Ich habe mir die r147rc8 installiert. Habe auch die r120 ausprobiert. Die r147rc8 ist definitiv schneller. Probiere gerade auf einem esp8622 auch die espeasy mega aus.
Gruß Sascha
Aktuelle Github Version.
Hallo,
das ist jetzt ein bisschen offtopic, ich stelle meine Frage aber trotzdem ;):
Was passiert denn, wenn es einen Stromausfall gibt und der Router und der ESP weg ist. Wenn der Router länger braucht, um WiFi zur Verfügung zu stellen, was macht dann der ESP dann? Oder ist da irgendetwas konfigurierbar (sorry, ich habe mich noch nicht wirklich intensiv mit dem Thema auseinandergesetzt).
Danke + Gruß
PeMue
Zumindest die aktuellen Versionen verbinden sich nach einen WLAN Ausfall/Maintenance wieder.
Jo, ist bei mir auch so. Verbindet sich einfach wieder.
Gesendet von meinem E6853 mit Tapatalk
Wlan Verbindung steht zwar dannach wieder, aber der Relays / gpio Status wird nicht wieder hergestellt nach Stromausfall am ESP.
Wenn nur WLAN abbricht bleibt der Status gesetzt bis wieder Verbindung da ist und vom Modul ein neuer
Schaltvorgang ausgelöst wird.
Hatte an einem Sonoff irgendwo einen Wackler und das Ding hat mich fast Wahnsinnig gemacht weil andauernd Strom weg war (blöd an der Weihnachtsaußenbeleuchtung auf 3m Höhe). Anscheinend sind die Module sehr anfällig auf Netzschwankungen.
Grüße
Matze
Zitat von: rboelli am 04 Januar 2017, 13:03:07
Ich denke esliegt an meine Fhem instalation auf dem rpi
Auch bei einem dummy fehlt mir dieses attribut.
Dev0 hat recht! Das Attribut ist vermutlich nicht gesetzt!
Teste mal:
Beim Device global unter: userattr, DevStateIcon und DevStateStyle einfügen und vorne auf attr klicken
Grüße
Matze
Danke Matze,
Asche auf mein Haupt ::)
in der config war das attr auskommentiert
#attr global userattr cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride
Alles ist gut. :D
lg Rainer
Bei MySensors ist es möglich, Gateways und Sensoren gleichzeitig in mehreren FHEM-Instanzen zu verwenden. Ist das bei ESPEasy auch (irgendwie) realisierbar?
Eine Bridge habe ich in einer 2. FHEM-Instanz definiert, es werden aber keine Devices angelegt. Daher meine Frage.
Meines Erachtens nicht. ESPEASY broadcastet ja nicht, sondern ruft gezielt eine FHEM Instanz über HTTP auf. Ob man das jetzt irgendwie von einer FHEM Instanz an eine weitere übergeben kann weiß ich nicht. Eventuell könnte @dev0 mal schauen ob man auf einfache Weise ein Paket bei Ankunft, bevor es bearbeitet wird, an eine, über einen Parameter festgelegte Adresse, zusätzlich zu forwarden. Dann könnte die Hauptinstanz die Pakete verwursten und die Nebeninstanz ebenso. Für die Nebeninstanz würde es so aussehen als ob der Aufruf direkt vom ESP kommt.
Gesendet von iPhone mit Tapatalk
Zitat von: Omega am 08 Januar 2017, 13:02:25
Bei MySensors ist es möglich, Gateways und Sensoren gleichzeitig in mehreren FHEM-Instanzen zu verwenden. Ist das bei ESPEasy auch (irgendwie) realisierbar?
Eine Bridge habe ich in einer 2. FHEM-Instanz definiert, es werden aber keine Devices angelegt. Daher meine Frage.
Falls du das unbedingt brauchst, mit MQTT geht das problemlos.
Zitat von: Omega am 08 Januar 2017, 13:02:25
Bei MySensors ist es möglich, Gateways und Sensoren gleichzeitig in mehreren FHEM-Instanzen zu verwenden. Ist das bei ESPEasy auch (irgendwie) realisierbar?
Das ESPEasy Modul verwendet zur Kommunikation zwischen logischen und physikalischen Modul ausschließlich IOWrite() und Dispatch(), daher sollte genau das möglich sein. Ich habe es aber noch nie verwendet.
Hi zusammen ich habemal eine frage, wenn an den ESP8266s mit der esp easy Firmware ein Passwort gesetzt ist muss ich das in FHEM irgendwo hinterlegen? Momentag glaube ich läuft irgendwas bei mir noch nicht so richtig.
define espBridge ESPEasy bridge 8383
attr espBridge authentication 0
attr espBridge autocreate 1
attr espBridge autosave 1
attr espBridge combineDevices 0
attr espBridge group ESPEasy Bridge
attr espBridge room ESPEasy
define ESP02 ESPEasy 192.168.1.66 80 espBridge ESP02_analog02
attr ESP02 IODev espBridge
attr ESP02 room ESPEasy
Zitat von: evilknivel am 10 Januar 2017, 13:48:14
Hi zusammen ich habemal eine frage, wenn an den ESP8266s mit der esp easy Firmware ein Passwort gesetzt ist muss ich das in FHEM irgendwo hinterlegen? Momentag glaube ich läuft irgendwas bei mir noch nicht so richtig.
Hi
ein Passwort??? An welcher Stelle? Du kannst dort viele Passwörter setzen.
Du meinst bei FHEM HTTP? Ja das müsste dann auf beiden Seiten gesetzt werden, aber wenn Du generelle Probleme hast lass doch die Authentifizierung erstmal weg. Es eght auch ohne.
Gruß Otto
Hi danke für deine Antwort!,
Nein ich meine das password was man im espeasy setzten kann in der config. Dann muss man immer erst ein Passwort eingeben wenn man die Einstellungen am ESP ändern will.
Soll ich das lieber nicht setzten?
Meinst Du das?
Einfach erst mal weg lassen.
Hi,
ja ganz genau. Okay dann mach ich das mal so. Sieht der Part aus meiner fhem.cfg denn soweit gut aus?
Ja, sieht gut aus. Würde aber das Device in FHEM selbständig anlegen lassen. Also das ESP02 nocheimal löschen und warten das es angelegt wird. Wenn es nicht angelegt wird sendet der ESP keine Daten. Da musst Du noch einmal in den Devices auf dem ESP nachsehen ob da auch 'Send' eingeschaltet ist und eine Zeit unter Delay in Minuten eingetragen ist.
Die autocreate und autosave Attribute brauchst du nicht extra setzen. Diese hier überschreiben nur die globalen Attribute. Und die sind normalerweise an.
combineDevice kann man auch auf 1 stellen. Da hast du dann nicht für jedes angelegte Device auf dem ESP eine eigenes Device im FHEM. Da die ESP Device immer selbständig angelegt werden kann man diese einfach wieder löschen und neue Einstellungen ausprobieren. Geht aber auch mit der Einstellung Null.
Hi,
super vielen Dank für die Antworten ihr habt mir sehr geholfen! Dann wird das heute Abend ja wohl endlich mal klappen :-)
Wir ziehen nähmlich in 2 Wochen endlich in unser Haus und ich will damit den guten alten Telefonkontakt von unserer Gasterme aktivieren um eine Absenkung der Tempeatur zu erreichen wenn wir nicht zuhause sind.
Ich gebe Rückmeldung wenn es geklappt hat.
Mir ist grad was beim Attribut eventMap aufgefallen. Folgendes Kommando soll ausgelöst werden
set ESPEasy_sonoff_10_S_Schalter on-for-timer 10
eventMap hat die beiden x-for-timer hinten stehen
/gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/longpulse 12 on:on-for-timer/longpulse 12 off:off-for-timer/
Ergebnis ist ein Fehler
2017.01.12 19:01:09 3 : ESPEasy ESPEasy_sonoff_10_S_Schalter: set ESPEasy_sonoff_10_S_Schalter gpio 12 on-for-timer 10
2017.01.12 19:01:09 2 : ESPEasy ESPEasy_sonoff_10_S_Schalter: gpio 12 on-for-timer 10 => unknown argument: 'on-for-timer'
Wenn man die beiden x-for-timer an den Anfang des Attributes schreibt
/longpulse 12 on:on-for-timer/longpulse 12 off:off-for-timer/gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/
funktioniert es einwandfrei
2017.01.12 19:03:41 3 : ESPEasy ESPEasy_sonoff_10_S_Schalter: set ESPEasy_sonoff_10_S_Schalter longpulse 12 on 10
Normal sollte es doch egal sein, wie rum das eventMap Attribut aufgebaut ist, solange es Syntaktisch richtig ist?!
Wenn ich das "eventMap" ändere bekomme ich nicht die Meldung das ich die "Save Config" speichern kann bzw. muss, ist das bei euch auch? Liegt das am Modul selber?
Zitat von: Waldmensch am 12 Januar 2017, 19:13:46
Normal sollte es doch egal sein, wie rum das eventMap Attribut aufgebaut ist
Das mußt Du schon den eventMap (fhem.pl) Maintainer fragen.
Zitat von: SamNitro am 12 Januar 2017, 22:34:27
Wenn ich das "eventMap" ändere bekomme ich nicht die Meldung das ich die "Save Config" speichern kann bzw. muss, ist das bei euch auch? Liegt das am Modul selber?
Nein und Nein.
Aktualisierte Modulversion 0.81:
- ESP commands reboot, reset und erase hinzugefügt. Die Befehle reset und erase löschen den Flash Speicher, reboot start den ESP neu.
Guten Morgen.
Wie verhält sich erase und reset, wenn man einen ESP im deepsleep betreibt?
Muss danach noch ein reboot gesendet werden?
Probiere es doch einfach aus und lasse uns dann an Deinen Erkenntnissen teilhaben...
Zitat von: dev0 am 13 Januar 2017, 10:02:01
Probiere es doch einfach aus und lasse uns dann an Deinen Erkenntnissen teilhaben...
Das wollte ich vermeiden. habe aktuell nur einen esp im deepsleep und der läuft produktiv ;)
Die Referenz sagt dazu auch nichts:
Reboot Internal Reboot the ESP Reboot
Reset Internal Reset config to factory default Reset if (strcasecmp_P(Command, PSTR("Reboot")) == 0)
{
success = true;
pinMode(0, INPUT);
pinMode(2, INPUT);
pinMode(15, INPUT);
ESP.reset();
}
if (strcasecmp_P(Command, PSTR("Restart")) == 0)
{
success = true;
ESP.restart();
}
if (strcasecmp_P(Command, PSTR("Erase")) == 0)
{
success = true;
EraseFlash();
ZeroFillFlash();
saveToRTC(0);
WiFi.persistent(true); // use SDK storage of SSID/WPA parameters
WiFi.disconnect(); // this will store empty ssid/wpa into sdk storage
WiFi.persistent(false); // Do not use SDK storage of SSID/WPA parameters
}
if (strcasecmp_P(Command, PSTR("Reset")) == 0)
{
success = true;
ResetFactory();
}
Zitat von: oli82 am 13 Januar 2017, 08:17:40
Guten Morgen.
Wie verhält sich erase und reset, wenn man einen ESP im deepsleep betreibt?
Muss danach noch ein reboot gesendet werden?
Im deep sleep reagiert der ESP nicht, da nur noch der interne Timer läuft. Dieser weckt den ESP über den Resetpin wieder auf, so dass dieser dann neu bootet.
Grüße Jörg
Gesendet von iPhone mit Tapatalk
@dev0: Ich habe heute meine H801 bekommen. Ich würde gern Dein Plugin in mein ESPEasy Git einbinden und für die User ein Binary für den H801 zur Verfügung stellen (wenn es bei mir läuft). Ich weiß nicht ob bei Dir da noch große Änderungen einfließen, oder ob es so bleibt. Der Kreis der Tester würde sich mit einem fertigen Binary sicher vergrößern.
In das offizielle ESPEasy Git wird es ja leider nicht mehr aufgenommen. Wär schade um die Arbeit.
Guten Tag,
vermutlich blöde Frage (hab nur keine passen Frage/Antwort im Thread gefunden):
ESPEasy läuft wunderbar, bis auf ein kleines Detail.
Warum bekomme ich prinzipiell doppelte Werte im LOG ?
2017-01-17_14:27:50 ESPEasy_esp_waschraum_rssi rssi: -70.00
2017-01-17_14:27:50 ESPEasy_esp_waschraum_rssi rssi: -70.00
2017-01-17_14:26:34 ESPEasy_esp_waschraum_gassensor ppm: 54
2017-01-17_14:26:34 ESPEasy_esp_waschraum_gassensor ppm: 54
2017-01-17_14:24:48 ESPEasy_esp_waschraum_system load: 8
2017-01-17_14:24:48 ESPEasy_esp_waschraum_system load: 8
Meine (sub) Config für den Bereich:
###################
## Modul ESPEasy ##
###################
define espBridge ESPEasy bridge 8383
attr espBridge authentication 0
attr espBridge group ESPEasy Bridge
attr espBridge room ESPEasy
attr espBridge ueberwache_attribut STATE=initialized
#############################################
# ESPEasy FileLog fuer alle ESPEasy devices #
#############################################
define FileLog_ESPEasy_all FileLog /opt/fhem/log/ESPEasy_all-%Y.log ESPEasy_.*
attr FileLog_ESPEasy_all logtype text
attr FileLog_ESPEasy_all room ESPEasy
#####################
# ESPEasy Waschraum #
#####################
# GAS
define ESPEasy_esp_waschraum_gassensor ESPEasy 192.168.100.61 80 espBridge esp_waschraum_gassensor
attr ESPEasy_esp_waschraum_gassensor IODev espBridge
attr ESPEasy_esp_waschraum_gassensor Interval 0
attr ESPEasy_esp_waschraum_gassensor alias ESP Waschraum GAS-Sensor
attr ESPEasy_esp_waschraum_gassensor group ESPEasy Device
attr ESPEasy_esp_waschraum_gassensor presenceCheck 1
attr ESPEasy_esp_waschraum_gassensor readingSwitchText 1
attr ESPEasy_esp_waschraum_gassensor room ESPEasy
attr ESPEasy_esp_waschraum_gassensor setState 3
attr ESPEasy_esp_waschraum_gassensor ueberwache_attribut presence=present
# RSSI
define ESPEasy_esp_waschraum_rssi ESPEasy 192.168.100.61 80 espBridge esp_waschraum_rssi
attr ESPEasy_esp_waschraum_rssi IODev espBridge
attr ESPEasy_esp_waschraum_rssi Interval 0
attr ESPEasy_esp_waschraum_rssi alias ESP Waschraum RSSI
attr ESPEasy_esp_waschraum_rssi group ESPEasy Device
attr ESPEasy_esp_waschraum_rssi presenceCheck 0
attr ESPEasy_esp_waschraum_rssi readingSwitchText 0
attr ESPEasy_esp_waschraum_rssi room ESPEasy
attr ESPEasy_esp_waschraum_rssi setState 4
# System load
define ESPEasy_esp_waschraum_system ESPEasy 192.168.100.61 80 espBridge esp_waschraum_system
attr ESPEasy_esp_waschraum_system IODev espBridge
attr ESPEasy_esp_waschraum_system Interval 0
attr ESPEasy_esp_waschraum_system alias ESP Waschraum system load
attr ESPEasy_esp_waschraum_system group ESPEasy Device
attr ESPEasy_esp_waschraum_system presenceCheck 0
attr ESPEasy_esp_waschraum_system readingSwitchText 1
attr ESPEasy_esp_waschraum_system room ESPEasy
attr ESPEasy_esp_waschraum_system setState 4
Viele Grüße!
Andreas
Hallo Andreas,
ist auf alle Fälle nicht normal. Ich denke, Du duplizierst irgendwo den Event.
Schau Dir das im Eventmonitor an.
Ich habe bei den ESPEasy_ noch event-on-change reading gesetzt.
Was macht das attr espBridge ueberwache_attribut STATE=initialized ? Gibt es bei mir nicht.
Gruß Otto
Zitat von: Otto123 am 17 Januar 2017, 14:46:15
Hallo Andreas,
ist auf alle Fälle nicht normal. Ich denke, Du duplizierst irgendwo den Event.
Schau Dir das im Eventmonitor an.
Ich habe bei den ESPEasy_ noch event-on-change reading gesetzt.
Was macht das attr espBridge ueberwache_attribut STATE=initialized ? Gibt es bei mir nicht.
Gruß Otto
Hallo Otto,
okay Danke für die schnelle Antwort.
Bei mir ist es jetzt "temporary solved". Ich habe schlicht "attr xxxxx setState 0" bei allen ESP Devices gesetzt und die doppelten Events (und damit auch im FileLog) sind nun weg.
D.h. im Umkehrschluss darf ich nicht setState > 0 setzen, dann bekomme ich alles doppelt ?
Die "attr espBridge ueberwache_attribut STATE=initialized" sind es nicht, das ist eine meiner 99_utils... funktionen, die alle Devices überwachen und dann (bei Ausfall) mir mails schicken.
Viele Grüße!
Andreas
Hallo Andreas,
ZitatsetState
Summarize received values in state reading.
A positive number determines the number of characters used for reading names. Only readings with an age less than interval will be considered. If your are not satisfied with format or behavior of setState then disable this attribute (set to 0) and use global attributes userReadings and/or stateFormat to get what you want.
Possible values: integer >=0
Default: 3 (enabled with 3 characters abbreviation)
Ich verstehe das auf die Schnelle nicht, ich habe aber nichts gesetzt -> d.h Standard=3?
Gruß Otto
setState macht nix anderes als die reading namen im State zu verkürzen. Aus dem Reading "Helligkeit" wird bei setState 3 "HEL" und bei setState 1 "H" im state.
Zitat von: Waldmensch am 17 Januar 2017, 13:52:25
@dev0: Ich habe heute meine H801 bekommen. Ich würde gern Dein Plugin in mein ESPEasy Git einbinden und für die User ein Binary für den H801 zur Verfügung stellen (wenn es bei mir läuft).
Kannst Du machen, aber ein Binary macht aus meiner Sicht nicht viel Sinn, da das Plugin noch nicht fertig ist. Es fehlt eine Farb/Gamma-Korrektur, wenn man keinen oder nur 1 Weißkanal benutzt. Mit 2 weißen Kanälen (ww/cw) finde ich es für schon brauchbar, zumindest nutze ich es im Moment noch so. Habe mir aber schon für ein paar Cent 4MBit Flash Chips bestellt, die ich einlöten werde um die Software aus für diesen Controller (https://forum.fhem.de/index.php/topic,48918.0.html) mit dem H801 zu nutzen.
Aktuell schreibe ich eine Software für WS2812B/SK6812 und benutze die Fastled Library, die hat Funktionen zur Farbkorrektur schon eingebaut ;) Ist zwar kein ESPEasy Plugin, aber läßt sich über das ESPEasy Modul wie ein Plugin steuern.
Zitat
In das offizielle ESPEasy Git wird es ja leider nicht mehr aufgenommen. Wär schade um die Arbeit.
Bisher ist die Arbeit an ESPEasy(Mega) nur auf Hold, oder hast Du andere Infos?
Zitat von: fhem-challenge am 17 Januar 2017, 14:32:50
Warum bekomme ich prinzipiell doppelte Werte im LOG ?
Kann ich nicht nachvollziehen. Die Ursache sehe ich (noch?) nicht im ESPEasy Modul, die Events werden irgendwo anders in Deiner Installation erzeugt.
Zitat von: Waldmensch am 17 Januar 2017, 15:53:24
setState macht nix anderes als die reading namen im State zu verkürzen.
Das Attribut setState=0 schaltet die Generierung des State Readings komplett ab. Es wird dann nur noch mit open/initialized beschrieben.
Zitat von: fhem-challenge am 17 Januar 2017, 14:57:34
D.h. im Umkehrschluss darf ich nicht setState > 0 setzen, dann bekomme ich alles doppelt ?
Nein, das heißt es nicht.
ZitatHabe mir aber schon für ein paar Cent 4MBit Flash Chips bestellt, die ich einlöten werde um die Software aus für diesen Controller mit dem H801 zu nutzen.
Wenn ich das richtig interpretiere hat mein H801 einen 8MBit SPI Flash (BergMicro 25Q80ASTIG (https://www.elnec.com/en/device/Berg+Micro/BG25Q80A+(ISP)/)). Eine Board Revision steht leider nirgendwo drauf
- 25Q,25QA, 25QF, 25QH = 3.0V Serial Flash with 4KB uniform-sector, dual and quad I/O
- 80, 80A = 8Mbit (1024kx8)
Sorry, ich meinte ein 4 MByte Flash, nicht MBit. Bei mir ist leider nur ein 512 kByte Chip verbaut.
Warum nutzt Du die FastLed Library nicht im ESPEASY Plugin? Wenns um Platz geht, könnte man ja die ganzen Sensoren Plugins aus dem Sketch kicken. Die wird man ja auf einem H801 nie brauchen.
Gesendet von iPhone mit Tapatalk
Zitat von: Waldmensch am 17 Januar 2017, 15:53:24
setState macht nix anderes als die reading namen im State zu verkürzen. Aus dem Reading "Helligkeit" wird bei setState 3 "HEL" und bei setState 1 "H" im state.
ja richtig. Nur wenn ich setState=0 setzen, wird das "state" reading nicht mehr mit dem Inhalt der Variable (in meinem Fall RSSI -Wert) gesetzt, sondern steht lediglich auf "opened". Das verhindert bei mir die doppelten Events.
Nur ist die Frage, ist es ein Workaround (in meinem Fall) , oder ist es gewünscht, dass der Wert bei setState > 0 dann auch im reading "state" geschrieben wird, was ja der Fall ist ?
Ich habe mal die drei Bilder angehängt, die das Problem verdeutlichen:
Bild1: Hier steht im reading "state" "opened" wie erwartet, weil ich setState=0 gesetzt habe
Bild2: Hier wird (parallel zum Reading "rssi") auch das Reading "state" mit dem wert von rssi gefüllt (dadurch kommen bei mir doppelte Events)
Bild3: Hier das logFile vor, und nach dem Setzen von setState=4
ggf. ist ein "event.on-change-reading" ... auch eine Lösung die doppelten Events zu verhindern (also nur bei WerteÄnderung) ?
Viele Grüße!
Andreas
Hallo Andreas,
alles gut, Du hast die Erklärung gefunden. Ich wurde sagen: works as designed 8)
Ich würde generell mit event-on-change loggen, da fällt viel weniger an Daten an. Aber das löst dein "Problem" nicht, weil Du einfach alles von allen ESPEasy_ Geräten loggst. Das ist zwar ein einfaches regEx aber wie Du siehst nicht so gut.
Stell doch einfach Dein regEx schärfer und logge nur die Daten die Du wirklich brauchst.
Gruß Otto
Zitat von: fhem-challenge am 19 Januar 2017, 09:20:09
Das verhindert bei mir die doppelten Events.
Die Events sind nicht doppelt. Einmal ist das Event vom RSSI Reading und einmal vom Reading state. In Deinem Fall sind die Events identisch, da Du nur ein Reading pro FHEM Device benutzt. Hättest Du mehrere Readings (attr combineDevices), dann wäre das nicht so.
Da ich den Benutzer nicht bevormunden möchte, für welche Readings Events erzeugt werden und für welche nicht, werden immer alle Events erzeugt und der Anwender kann mit den globalen Attributen event-.* und timestamp-.* selbst entscheiden unter welchen Umständen Events erzeugt werden sollen.
Wenn Du eine Anzeige in STATE haben möchtest, aber setState auf 0 setzt, dann kannst Du das mit dem Attribut stateFormat selbst vornehmen.
Edit: Wenn Du die identisch lautende Events auseinander halten möchtest, dann kannst Du in den Zieldevices wie notify oder filelog auch das Attribut addStateEvent setzen.
Zitat von: dev0 am 19 Januar 2017, 09:54:55
Die Events sind nicht doppelt. Einmal ist das Event vom RSSI Reading und einmal vom Reading state. In Deinem Fall sind die Events identisch, da Du nur ein Reading pro FHEM Device benutzt. Hättest Du mehrere Readings (attr combineDevices), dann wäre das nicht so.
Da ich den Benutzer nicht bevormunden möchte, für welche Readings Events erzeugt werden und für welche nicht, werden immer alle Events erzeugt und der Anwender kann mit den globalen Attributen event-.* und timestamp-.* selbst entscheiden unter welchen Umständen Events erzeugt werden sollen.
Wenn Du eine Anzeige in STATE haben möchtest, aber setState auf 0 setzt, dann kannst Du das mit dem Attribut stateFormat selbst vornehmen.
Edit: Wenn Du die identisch lautende Events auseinander halten möchtest, dann kannst Du in den Zieldevices wie notify oder filelog auch das Attribut addStateEvent setzen.
Vielen Dank für die schnellen Antworten (auch an Otto123)
ich denke, ich werde event-on-change reading in Kombination mit event-min-interval (wg. der besseren Darstellung in den gplots, falls sich lange nichts an den werten ändert) nutzen (das mache ich auch bei vielen anderen Devices bereits) ... und (in der Tat) mein RegEx weniger "global" definieren (derzeit ist das ESPEasy Modul) noch bei mir in der Testphase ... deshalb ist mein Log-RegEx auch so global, weil zunehmend mehr ESP8266 bei mir dran kommen.
Momentan ist es ein! ESP8266 (12E) mit Gassensor, Radar Bewegungsmelder, 2 TürSensoren (reed) , ein BME280 und zwei WasserSensoren (... da sind nun alle GPIO's weg (auch serial ports)) ... aber es geht.
Bis dato läuft das ESPEasy-Modul sehr gut ... und ich denke, das ich es in Kürze dann auch produktiv verwenden werde und ich nun kein MQTT mehr mache (weil so einfacher).
Viele Grüße!
Andreas
Hallo,
ich habe masseweise
2017.01.16 12:05:56 2: ESPEasy espBridge_192.168.11.5_5184: No basic authentication active but credentials received
Im Log stehen. Ich habe passwd und user gesetzt. Habe jetzt erst einmel verbise auf 1 gesetzt, aber woher kommen diese Meldungen und wie bekomme ich die weg.
Gruß Christoph
Zitat von: Bennemannc am 21 Januar 2017, 07:52:47
und wie bekomme ich die weg.
Commandref lesen ;)
Zitat
Attributes (bridge)
...
authentication
Used to enable basic authentication for incoming requests.
Note that user, pass and authentication attribute must be set to activate basic authentication
Possible values: 0,1
Default: 0
Zitat von: Bennemannc am 21 Januar 2017, 07:52:47
Hallo,
ich habe masseweise
2017.01.16 12:05:56 2: ESPEasy espBridge_192.168.11.5_5184: No basic authentication active but credentials received
Im Log stehen. Ich habe passwd und user gesetzt. Habe jetzt erst einmel verbise auf 1 gesetzt, aber woher kommen diese Meldungen und wie bekomme ich die weg.
Gruß Christoph
Hallo Christoph,
hatte ich auch. Ich dachte ich müsste credentials eintragen im ESP Modul als es ist sofort ging. Danach gin es sofort, ohne das ich welche im FHEM eingetragen hatte. 8)
Also einfach die Credentials im ESP löschen, oder im FHEM welche eintragen.
Gruß Otto
Folgende Meldungen kann das ESPEasy Modul in diesem Zusammenhang ausgeben. Die Verbose 2 Logeinträge werden erzeugt, wenn etwas nicht stimmt. Wobei die erste Meldung dazu dienen soll den Anwender nicht in trügerischer Sicherheit zubelassen, dass basic auth aktiviert ist (auf dem ESP), aber nicht abgefragt wird.
Verbose 2: "No basic authentication active but credentials received"
Verbose 2: "Basic authentication rejected"
Verbose 2: "Basic authentication active but no credentials received"
Verbose 4: "No basic authentication required"
Verbose 4: "Basic authentication accepted"
Zitat von: dev0 am 21 Januar 2017, 12:09:36
Folgende Meldungen kann das ESPEasy Modul in diesem Zusammenhang ausgeben. Die Verbose 2 Logeinträge werden erzeugt, wenn etwas nicht stimmt. Wobei die erste Meldung dazu dienen soll den Anwender nicht in trügerischer Sicherheit zubelassen, dass basic auth aktiviert ist (auf dem ESP), aber nicht abgefragt wird.
Verbose 2: "No basic authentication active but credentials received"
Verbose 2: "Basic authentication rejected"
Verbose 2: "Basic authentication active but no credentials received"
Verbose 4: "No basic authentication required"
Verbose 4: "Basic authentication accepted"
Danke :D
Zitat von: dev0 am 17 Januar 2017, 17:28:08
Kannst Du machen, aber ein Binary macht aus meiner Sicht nicht viel Sinn, da das Plugin noch nicht fertig ist. Es fehlt eine Farb/Gamma-Korrektur, wenn man keinen oder nur 1 Weißkanal benutzt. Mit 2 weißen Kanälen (ww/cw) finde ich es für schon brauchbar, zumindest nutze ich es im Moment noch so. Habe mir aber schon für ein paar Cent 4MBit Flash Chips bestellt, die ich einlöten werde um die Software aus für diesen Controller (https://forum.fhem.de/index.php/topic,48918.0.html) mit dem H801 zu nutzen.
Ich habe jetzt mal eine ESPEasy mit deinem Plugin geflasht. Sobald der H801 bestromt wird, leuchten die LED blau. Ich habe keine GPIO <-> Farbe Belegung im Netz gefunden. Nach Board Layout müssten
gpio 14 - blau
gpio 13 - rot
gpio 12 - grün
die Farben sein. Wenn ich nun ein "lights rgb FF0000" sende, müßte der Stripe rot leuchten. Im Log auf dem ESP kommt auch was an. (letzte Zeile für vorbenannten befehl). Selbst wenn ich die Farben vertauscht hätte, müsste ja auf ff0000,00ff00,0000ff jeweils eine einzelne Farbe leuchten. Es bleibt aber beim konstanten blau :(
1265200 : WD : Uptime 21 ConnectFailures 0 FreeMem 25520
1295201 : WD : Uptime 21 ConnectFailures 0 FreeMem 25520
1298499 : Lights: rgb: 4352 ct: 3000 pct: 0 cm: 2
1311570 : Lights: Set 1023/0/0/-200832/-200832
1325202 : WD : Uptime 22 ConnectFailures 0 FreeMem 25520
1349663 : Lights: Set 0/0/0/-200832/-200832
1355212 : WD : Uptime 22 ConnectFailures 0 FreeMem 25520
1358657 : Lights: rgb: 0 ct: 3000 pct: 0 cm: 1
1366245 : Lights: Set 1023/0/0/-200832/-200832
Hi,
"red pin 15 green pin 13 blue pin 12 white pin 14"
Quelle: http://www.domoticz.com/forum/viewtopic.php?t=7957&start=40
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Okay habe ich jetzt so, scheint aber nicht zu interessieren. Wenn ich im ESP noch zusätzlich einen Switch anlege, damit ich den gpio Befehl habe, dann kann ich damit die 3 Pins (Farben) ein und ausschalten. Das H801 ist also nicht kaputt. Das Problem muss am Plugin selber liegen. Da es die Befehle ordentlich zu bekommen scheint und scheinbar auch die Werte setzt, fürchte ich, dass es an der PWM Aufbereitung liegt
Im Log kommen bei setzen seltsam hohe negativ werte
Lights: Set: 1023/0/0/-200832/-200832
Gesendet von iPhone mit Tapatalk
Hallo zusammen,
kurze Frage zum device "Infrared Receive - TSOP4838" - ich bekomme das prima im modul angelegt, die readings kommen aber in dezimal, nicht HEX.
Gibt es hier eine Konversionsroutine (ich will die IR codes danach wieder an meinen Beamer schicken)?
defmod ESPEasy_wemos_pro_5_IR_1Rec ESPEasy 192.168.178.53 80 ESP_Bridge wemos_pro_5_IR_1Rec
attr ESPEasy_wemos_pro_5_IR_1Rec IODev ESP_Bridge
attr ESPEasy_wemos_pro_5_IR_1Rec Interval 300
attr ESPEasy_wemos_pro_5_IR_1Rec group ESPEasy Device
attr ESPEasy_wemos_pro_5_IR_1Rec presenceCheck 1
attr ESPEasy_wemos_pro_5_IR_1Rec readingSwitchText 1
attr ESPEasy_wemos_pro_5_IR_1Rec room ESPEasy
attr ESPEasy_wemos_pro_5_IR_1Rec setState 3
setstate ESPEasy_wemos_pro_5_IR_1Rec IR-: 657079140
setstate ESPEasy_wemos_pro_5_IR_1Rec 2017-01-22 08:05:23 IR-1 657079140
setstate ESPEasy_wemos_pro_5_IR_1Rec 2017-01-22 08:09:33 presence present
setstate ESPEasy_wemos_pro_5_IR_1Rec 2017-01-22 08:09:33 state IR-: 657079140
Aszug aus dem log:
2017.01.22 08:26:17 5: ESPEasy ESPEasy_wemos_pro_5_IR_1Rec: Received: wemos_pro_5_IR_1Rec::192.168.178.53::1::1::1::i||unit||5||0|||i||sleep||0||0|||i||build||148||0|||r||IR-1||657079140||20
2017.01.22 08:26:17 4: ESPEasy ESPEasy_wemos_pro_5_IR_1Rec: IR-1: 657079140
2017.01.22 08:26:17 5: ESPEasy ESPEasy_wemos_pro_5_IR_1Rec: Internals: unit:5 sleep:0 build:148
2017.01.22 08:26:17 4: ESPEasy ESPEasy_wemos_pro_5_IR_1Rec: presence: present
2017.01.22 08:26:18 5: ESPEasy ESPEasy_wemos_pro_5_IR_1Rec: Received:
ESPEASY Build 148
FHEM aktuell
VG Timmo
Zitat von: Waldmensch am 21 Januar 2017, 19:58:22
Okay habe ich jetzt so, scheint aber nicht zu interessieren. Wenn ich im ESP noch zusätzlich einen Switch anlege, damit ich den gpio Befehl habe, dann kann ich damit die 3 Pins (Farben) ein und ausschalten. Das H801 ist also nicht kaputt. Das Problem muss am Plugin selber liegen. Da es die Befehle ordentlich zu bekommen scheint und scheinbar auch die Werte setzt, fürchte ich, dass es an der PWM Aufbereitung liegt
Das gpio Kommando zu benutzen wird kontraproduktiv sein. Ist hier aber offtopic, bitte diesen Thread (https://forum.fhem.de/index.php/topic,63622.0.html) benutzen und mehr Details bitte, sonst kann man nur raten.
Zitat von: Tsturm am 22 Januar 2017, 08:28:39
Gibt es hier eine Konversionsroutine
Sollte mit dem Attribut adjustValue und einwenig Perl zu lösen sein.
Zitat von: dev0 am 22 Januar 2017, 08:37:06
Sollte mit dem Attribut adjustValue und einwenig Perl zu lösen sein.
Moin,
{sprintf("%x",657079140)}Gruß Otto
Super, danke - Perl Programmierung hatte ich noch nicht ... VG Timmo
Zitat von: Tsturm am 22 Januar 2017, 13:27:35
Super, danke - Perl Programmierung hatte ich noch nicht ... VG Timmo
Hi Timmo,
Ein Lehrer hat zu mir mal gesagt:Man muss nicht alles wissen, man muss nur wissen wo es steht :)
Hier schau ich immer mal:
https://wiki.selfhtml.org/wiki/Perl
https://de.wikibooks.org/wiki/Perl-Programmierung
Und Google hilft auch.
Gruß Otto
Hallo Experten,
Erstmal Respekt für das SUPER Modul.
Echt Klasse wie einfach das geht.
Nun zu meinem Problem:
Ich möchte 2 oder mehr "ESPEasy Bridge" verwenden.
Also Port 8383 und 8384.
Da sagt mir Fhem aber es geht nicht.
ERROR: only 1 ESPEasy bridge can be defined!
Ist das überhaupt so möglich???
Gruss Denny
Das Design sieht nur eine Bridge vor. Was möchtest Du mit einer 2. Bridge erreichen?
Ich möchte mehrere Sensoren aufbauen welche dann im WLAN hängen.
Ergo 3-4 Reed Kontakte.
Ich bin davon ausgegangen, dass dies möglich wäre, da ja unterschiedliche Ports angegeben werden können und das die Trennung ist.
Ist das via. MQTT Broker möglich??
Gruss Denny
Zitat von: rohlande am 24 Januar 2017, 21:09:21
Ich möchte mehrere Sensoren aufbauen welche dann im WLAN hängen.
Ergo 3-4 Reed Kontakte.
Ich bin davon ausgegangen, dass dies möglich wäre, da ja unterschiedliche Ports angegeben werden können und das die Trennung ist.
Ist das via. MQTT Broker möglich??
Gruss Denny
Ich habe auch mehrere esp8266 / nodemcu /wemos d1.
Alles über einen Port, ergo über eine bridge.
Läuft ohne Probleme. Du musst die einzelnen esp8266 im Webgui nur entsprechend benennen. So tauchen diese dann auch in der bridge auf.
Gruß Sascha
Von mobil gesendet daher kurze Antwort
IHR seit die BESTEN.
Herzlichen DANK! Wieder etwas gelernt.
Dann mache ich mal weiter mit meiner Bastelei :-)
Das rettet den Abend........................
Super geile Sache mit der ESPEasy und FHEM Anbindung..............
Großen Respekt!!!!
Gruss Denny
Schönen Abend Zusammen!
Hallo Liebe Community,
ich habe eine Sonoff1 Relaiskarte hier mit EspEasy 147v. Die Bridge ist definiert und ich kann auch via webCmd den GPIO12 pin über fhem ein und ausschalten.
Ich habe mir einen Sonoff Touch Schalter geholt diesen auch richtig geflasht und Verbindung zu FHEM klappt auch wunderbar.
Wie kann ich nun mit dem Touch Schalter der am ESP1 an GPIO0 hängt das Relais am ESP2 an GPIO12 schalten?
Unter Rules habe ich am TouchSchalter das eingefügt.
SendTo 2,event, teston. Oder SendTo 2, GPIO, 12,1 auch schon probiert. Die LEDs auf den Karten Leuchten also die IF und Do Abfragen in Rules passen. Jedoch weiß ich nicht welchen Befehl ich brauche um von einem ESP das andere ESP zu schalten.
Bitte um Hilfe.
Um den Überblick in diesem Thread nicht ganz verlieren, möchte ich Dich/Euch bitten zu diesem Thema einen eigenen Thread hier oder im Letscontrolit Forum zu eröffnen. In diesem Thread geht es um das ESPEasy Modul.
Guten Morgen zusammen.
Habe da mal ne Frage.
Das Modul läuft soweit super. Es vereinfacht doch einiges sehr.
In den Readings wird ja der Status der empfanhgenen ESP´s angezeigt.
Ich habe 2 Stück davon im netz am laufen.
Beide liefern fleißig Ihre Daten.
Beide werden jedoch mit Status mit absent gezeigt !
Sollte da nicht was anderes angezeigt werden?
Hier mal ein List von den ESP´s
Internals:
DEF 192.168.2.145 80 espBridge multisens
HOST 192.168.2.145
IDENT multisens
INTERVAL 300
IODev espBridge
NAME ESPEasy_multisens
NOTIFYDEV global
NR 387
NTFY_ORDER 50-ESPEasy_multisens
PORT 80
STATE absent
SUBTYPE device
TYPE ESPEasy
VERSION 0.81
Readings:
2017-01-26 06:27:11 presence absent
2017-01-26 06:27:11 state absent
Helper:
fpc 1485377880
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 302
TRIGGERTIME 26.01.2017 06:32:12
Received:
Attributes:
IODev espBridge
Interval 300
group ESPEasy Device
presenceCheck 1
readingSwitchText 1
room ESPEasy
setState 3
Internals:
DEF 192.168.2.103 80 espBridge nodeESP_01
HOST 192.168.2.103
IDENT nodeESP_01
INTERVAL 300
IODev espBridge
NAME ESPEasy_nodeESP_01
NOTIFYDEV global
NR 304
NTFY_ORDER 50-ESPEasy_nodeESP_01
PORT 80
STATE absent
SUBTYPE device
TYPE ESPEasy
VERSION 0.81
Readings:
2017-01-26 06:27:16 presence absent
2017-01-26 06:27:16 state absent
Helper:
fpc 1485377875
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 302
TRIGGERTIME 26.01.2017 06:32:17
Received:
Attributes:
IODev espBridge
Interval 300
group ESPEasy Device
presenceCheck 1
readingSwitchText 1
room ESPEasy
setState 3
Danke und Gruß
Sascha
Beide gezeigten
ESPs FHEM ESPEasy Devices haben überhaupt noch keine Daten empfangen, daher: presence -> absent.
Zitat
Presence check determines the presence of a device by readings age. If any reading of a device is newer than interval seconds than it is marked as being present. This kind of check works for ESP devices in deep sleep too but require at least 1 reading that is updated regularly.
Zitat von: dev0 am 26 Januar 2017, 06:41:54
Beide gezeigten ESPs FHEM ESPEasy Devices haben überhaupt noch keine Daten empfangen, daher: presence -> absent.
Macht Sinn mit dem senden. Beide haben ihre Sensoren und senden fleißig!
Oder liegt es daran, dass die Sensoren als untergeordnete Geräte angelegt sind?
Von mobil gesendet daher kurze Antwort
Zitat von: sash.sc am 26 Januar 2017, 08:04:32
Beide haben ihre Sensoren und senden fleißig!
Ich kann mich nur wiederholen: In beiden gezeigten lists wurden noch keine Daten empfangen und dadurch auch keine Readings angelegt. Ohne empfangene Daten/Readings ist und bleibt der Presence Status absent. Works as designed.
Hallo zusammen,
ich habe einen ESP-01 mit ESPEasy R148 (inkl. SSSRV Plugin von amunra) geflasht und eingerichtet und einen DS18B20 mit pullup an GPIO0 gehängt. Der Sensor liefert auch Werte in der ESPEasy Oberfläche.
In fhem habe ich mit
define espBridge ESPEasy bridge 8383
die Bridge definiert, aber es passiert nichts. Mit manueller Definition bekomme ich dann Zugriff auf den ESP (ich kann rebooten, resetten >:( (jetzt weiß ich auch, was damit gemeint ist), usw., aber es kommen keine Sensorwerte.
Daher meine Fragen:
- Woher weiß fhem mit der o.kg. Definition, auf welcher IP Adresse es lauschen muß, damit aus den empfangenen Werte devices angelegt werden können? Es fehlt m.E. hier die Definition der IP Adresse ???
- Woran könnte das liegen, dass keine Devices definiert werden (autocreate ist an, mein 433 MHz nanoCUL liefert regelmößig neue Sensoren und erkennt irgendwelche Patterns nicht ;)).
- Welche fhem Version brauche ich (ich vermute, meine ist so vom September letzten Jahres)?
Danke schon mal für ein paar Tips.
Gruß PeMue
Hallo,
wer kann mir mal auf die Sprünge helfen. Ich möchte Relais mit einem WEMOS ansteueren. Was muss ich dort am Device einstellen (gerne auch Screenshot) und wie bzw. mit welchem Befehl kann ich das Relais dann schalten ?
Gruß Christoph
Zitat von: PeMue am 26 Januar 2017, 08:22:15
die Bridge definiert, aber es passiert nichts.
Dann werden auch keine Daten empfangen. In der ESP Config muss "FHEM HTTP" als Controller konfiguriert sein. Controller IP muss der FHEM IP entsprechen und der Controller Port muss der Port sein, den Du im Define der Bridge angegeben hast.
Um zu sehen ob Daten empfangen werden, kannst die den Verbose Level der Bridge hoch drehen und dann ins log schauen. Wenn dann Daten empfangen werden, dann ist das Modul sehr geschätzig.
attr espBridge verbose 5
Zitat
Woher weiß fhem mit der o.kg. Definition, auf welcher IP Adresse es lauschen muß, damit aus den empfangenen Werte devices angelegt werden können? Es fehlt m.E. hier die Definition der IP Adresse
Es wird auf allen aktiven NICs gelauscht, die auf dem Host definiert sind.
FHEM muss min. Version 11000 sein. Wenn das nicht der Fall wäre, dann steht das auch im Log.
Im Moment würde ich vermuten, dass der ESP die Daten noch nicht an FHEM sendet. Von manuellem Anlegen der Devices würde ich abraten.
Zitatich vermute, meine ist so vom September letzten Jahres
Inhaltlich kann ich deine Frage nicht beantworten. Ich kann mir allerdings kaum vorstellen, dass eine so "alte" Installation mit den neuen Möglichkeiten wirklich sinnvoll funktionieren kann. U.a. das ESPEasy-Modul hat viele Änderungen erfahren.
Oder es fehlt die Info, dass du in deine September-Version das aktuelle ESPEasy integriert hast ;)
Zitat von: Bennemannc am 26 Januar 2017, 09:07:37
Ich möchte Relais mit einem WEMOS ansteueren. Was muss ich dort am Device einstellen (gerne auch Screenshot)
Wenn Du möchtest, dass der Status aktiv vom ESP gesendet wird, dann auf dem ESP ein 'Switch Imput' device anlegen.
https://raw.githubusercontent.com/wiki/ddtlabs/ESPEasy/screenshots/esp-ke-relay.png
Zitatund wie bzw. mit welchem Befehl kann ich das Relais dann schalten ?
set <esp> gpio <pin> on/off
Wenn Du
[Edit:] on/off nur on/off, ohne gpio ..., verwenden möchtest, dann mit EventMap, ist schon mehrfach hier beschrieben, auch im ersten Beitrag. Weitergehende Details dazu bitte der commandref entnehmen.
Zitat von: Omega am 26 Januar 2017, 09:08:19
Oder es fehlt die Info, dass du in deine September-Version das aktuelle ESPEasy integriert hast ;)
Das Modul ESPEasy ist die 0.81 (manuell reinkopiert), sollte also relativ aktuell sein ;)
Zitat von: PeMue am 26 Januar 2017, 09:23:57
Das Modul ESPEasy ist die 0.81 (manuell reinkopiert), sollte also relativ aktuell sein ;)
Nach dem das download von solchen Modul Dateien bei mir immer mal schief gegangen ist, bevorzuge ich diese Methode:
update all https://raw.githubusercontent.com/ddtlabs/ESPEasy/master/controls_ESPEasy.txt
;) und finde diese wesentlich entspannter als das gefrickel mit den Dateien.
Noch entspannter empfinde ich das Einbinden in den normalen Update-Prozess ;)
Zitatupdate add https://raw.githubusercontent.com/ddtlabs/ESPEasy/master/controls_ESPEasy.txt
Zitat von: dev0 am 26 Januar 2017, 09:45:34
Noch entspannter empfinde ich das Einbinden in den normalen Update-Prozess ;)
Ja, ich weiß. Mach ich auch.
Aber für den der nicht so oft updates macht... ;D :-X
Wenn Du das Git mit update add zugefügt hast, kannst du es auch gezielt solo updaten, ohne FHEM updates zu bekommen.
Gesendet von iPhone mit Tapatalk
Leute, ich bin zu doof für ESPEasy ???
Was ich gemacht habe:
- fhem aktualisiert, update check bringt
Zitatnothing to do...
- das Modul ESPEasy aktualisiert
- folgende Definition
define PMESPbridge01 ESPEasy bridge 8383
attr PMESPbridge01 allowedIPs 192.168.188.39
attr PMESPbridge01 verbose 5
attr PMESPbridge01 combineDevices 1
der Rest
attr PMESPbridge01 authentication 0
attr PMESPbridge01 autocreate 1
attr PMESPbridge01 group ESPEasy Bridge
attr PMESPbridge01 room ESPEasy
kommt von alleine. Der ESP01 ist mit FHEM HTTP bzw. einem DS18B20 eingerichtet, Send Date ist angehakt, delay steht auf 0 und der Sensor zeigt in der ESPEasy Oberfläche auch vernünftige Temperaturen an.
Habt ihr mir einen Tipp, wo ich noch suchen soll? Braucht ihr noch eine Info?
Internals:
CFGFN
DEF bridge 8383
FD 16
HOST bridge
MAX_HTTP_SESSIONS 3
MAX_QUEUE_SIZE 250
NAME PMESPbridge01
NOTIFYDEV global
NR 329
NTFY_ORDER 50-PMESPbridge01
PASS not defined yet !!!
PORT 8383
STATE initialized
SUBTYPE bridge
TYPE ESPEasy
USER not defined yet !!!
VERSION 0.81
Readings:
2017-01-26 21:32:05 state initialized
Attributes:
allowedIPs 192.168.188.39
authentication 0
autocreate 1
combineDevices 1
group ESPEasy Bridge
room ESPEasy
verbose 5 Oder soll ich einfach mal per OTA Update (es ist ein 1MB Modul) eine vorcompilierte Version draufmachen?
Danke + Gruß
PeMue
Hallo PeMue,
bei mir steht delay per default auf 60.
Ich weiß nicht ob 0 - never bedeutet?
Hast Du zuviel gemacht? Zu kompliziert gedacht? Ich habe mein erstes Vorgehen mal aufgeschrieben:
http://heinz-otto.blogspot.de/2017/01/esp8266-in-fhem.html
So sieht meine espBridge aus, einfach define gemacht:
Internals:
CONNECTS 12082
DEF bridge 8383
FD 13
HOST bridge
NAME espBridge
NOTIFYDEV global
NR 41
NTFY_ORDER 50-espBridge
PASS ****
PORT 8383
SESSIONS 0
STATE initialized
SUBTYPE bridge
TYPE ESPEasy
USER ESP
VERSION 0.74
Readings:
2017-01-22 17:30:44 state initialized
Helper:
Received:
192.168.178.74:
build 147
espName LoLin
sleep 0
unit 0
Attributes:
combineDevices 0
group ESPEasy Bridge
room ESPEasy
Gruß Otto
Ich würde auch erst einmal ein Delay > 0 einstellen, wenn das nicht hilft, dann zeig bitte mal Screenshots vom Config Tab und von der DS Detailseite.
Ich korrigiere mal:
Zitat von: PeMue am 26 Januar 2017, 08:22:15
ich habe einen ESP-01 mit ESPEasy R148 (inkl. SSSRV Plugin von amunra) geflasht und eingerichtet
Es ist ein ESP Plugin von immi und nicht von mir.
@PeMue, schau doch einfach mal in die Doku (https://forum.fhem.de/index.php/topic,56606.msg481618.html#msg481618) 7.3 dort steht wie man ESPEasy mit ESPEasy FHEM Modul in Betrieb nimmt.
Zum Testen der grundsätzlichen Funktionalität kannst Du einfach nur ein System Info Device (siehe 7.3.2) einrichten.
Ach,noch etwas - zum Einbinden des DS18B20 brauchst Du übrigens das SSSRV Plugin gar nicht, da der Sensor bereits built-in unterstütz wird.
Zitat von: amunra am 26 Januar 2017, 23:32:56
@PeMue, schau doch einfach mal in die Doku (https://forum.fhem.de/index.php/topic,56606.msg481618.html#msg481618) 7.3 dort steht wie man ESPEasy mit ESPEasy FHEM Modul in Betrieb nimmt.
Zum Testen der grundsätzlichen Funktionalität kannst Du einfach nur ein System Info Device (siehe 7.3.2) einrichten.
Hi PeMue,
da finde ich die Beschreibung in meinem Link wesentlich einfacher, aber ich habe sie auch geschrieben 8)
Gruß Otto
Hallo Otto,
Zitat von: Otto123 am 27 Januar 2017, 00:03:56
da finde ich die Beschreibung in meinem Link wesentlich einfacher, aber ich habe sie auch geschrieben 8)
ZitatName: <Eindeutiger Name> damit es im eigenen Netzwerk auffindbar ist.
Protocol: FHEM HTTP
Locate Controller: Auswahl entweder Name oder IP Adresse
Controller IP: <IPAdresse des FHEM Servers>
Controller Port:8383 (Das Gleiche wie beim define der Bridge)
Das war's. Ich habe die Adresse des ESPEasy eingetragen in der irrigen Annahme, dass das fhem ESPEasy Modul eine IP Addresse des ESP's braucht. Nun ist es aber gerade anders herum, der ESP braucht die Adresse des fhem Servers ...
Funktioniert, vielen Dank.
@amunra: vielleicht kannst Du das in Deiner v1.0a auch mit aufnehmen, damit solche Schlafmützen wie ich das nicht verpennen ;D
Gruß PeMue
Zitat von: PeMue am 27 Januar 2017, 21:05:34
Hallo Otto,
Das war's. Ich habe die Adresse des ESPEasy eingetragen in der irrigen Annahme, dass das fhem ESPEasy Modul eine IP Addresse des ESP's braucht. Nun ist es aber gerade anders herum, der ESP braucht die Adresse des fhem Servers ...
Funktioniert, vielen Dank.
Zitat von: PeMue am 27 Januar 2017, 21:05:34
@amunra: vielleicht kannst Du das in Deiner v1.0a auch mit aufnehmen, damit solche Schlafmützen wie ich das nicht verpennen ;D
Bei aller Liebe PeMue, aber ich verstehe aktuell nicht was an dieser Aussage:
"Zitat Doku:"Zitat3) Controller IP: IP-Adresse oder den Hostname des FHEM Servers eingeben.
missvertändlich sein soll?
Sorry dev0...
Zitat von: amunra am 27 Januar 2017, 23:54:33
Sorry dev0...
Kein Problem, die Hauptsache ist, dass PeMue's ESP nun funktioniert.
An eine falsche IP hatte ich auch als erstes gedacht und weiter oben auch geschrieben, aber manchmal sieht man den Baum vor lauter Wäldern nicht ;)
Zitat von: amunra am 27 Januar 2017, 23:54:33
Bei aller Liebe PeMue, aber ich verstehe aktuell nicht was an dieser Aussage:
"Zitat Doku:"missvertändlich sein soll?
Ähm, die Schlafmütze ??? hat nur Kapitel 5.5 gelesen. Vielleicht könntest Du die Kapitel 7.3.1 - 7.3.3 nach Kapitel 5.5 schieben 8)
Aber nun ist es selbst mir klar 8) 8) 8)
Vielen Dank an alle für Eure Geduld.
Gruß PeMue
Guten Tag,
Öfter muss ich Dummy Werte im ESPEasy zeitnah zum FHEM übertragen.
Frage: Welche Möglichkeit, abseits vom definierten "delay" im ESPEasy, habe ich, bei einem "Dummy Device" die Daten nach Änderung auch sofort (als Event) zum FHEM zu schicken ?
U.A. habe ich beispielhaft in den Rules:
on gassensor#ppm>120 do
TaskValueSet 2,1,1
endon
on gassensor#ppm<120 do
TaskValueSet 2,1,0
endon
... nur sehe ich natürlich den Wert des Dummy (hier TaskValueSet 2,1) erst nach "delay" Sekunden. Hier die Sekunden auf "min 10" zu reduzieren ist auch aus meiner Sicht keinen Lösung, da sonst eben alle 10s Daten übertragen werden, bei denen keinen Änderung sich ergeben hat.
SendToHTTP 192.168.x.x,8085,/fhem?cmd=attr%20move.i.ESP.waschraum%20disable%201
Derzeit nutze ich SendToHTTP als Interimslösung in den Rules. Nur eben das möchte ich vermeiden, denn sonst benötige ich auch kein "ESPEasy.pm" mehr in FHEM, und kann ja ohnehin alles via SendToHTTP übertragen.
Viele Grüße!
Andreas
Zitat von: fhem-challenge am 30 Januar 2017, 14:23:11
Frage: Welche Möglichkeit, abseits vom definierten "delay" im ESPEasy, habe ich, bei einem "Dummy Device" die Daten nach Änderung auch sofort (als Event) zum FHEM zu schicken ?
Ich sehe zwei Möglichkeiten:
- Die Funktion sendData(event) an geeigneter Stelle in ESPEasy aufrufen. sendData ist die Funktion, die die Werte an den Controller verschickt.
- Die Werte von gassensor#ppm in FHEM auswerten und per notify das Attribut disable setzen.
Zitat
denn sonst benötige ich auch kein "ESPEasy.pm" mehr in FHEM, und kann ja ohnehin alles via SendToHTTP übertragen.
Auch ein Variante, Dich zwing niemand das Modul zu nutzen ;)
Danke für die schnelle Antwort!
Zitat von: dev0 am 30 Januar 2017, 15:59:37
Ich sehe zwei Möglichkeiten:
- Die Funktion sendData(event) an geeigneter Stelle in ESPEasy aufrufen. sendData ist die Funktion, die die Werte an den Controller verschickt.
- Die Werte von gassensor#ppm in FHEM auswerten und per notify das Attribut disable setzen.
Auch ein Variante, Dich zwing niemand das Modul zu nutzen ;)
Nein, es sollte keinen Kritik von meiner Seite sein... und ja , es hat sicherlich Vorteile ESPEasy.pm zu nutzen (ganz klar).
Ich habe nun eine andere Lösung für das Problem:
Ich habe ein "Wifi Relay (nein, nicht von SONOFF)" --> http://www.electrodragon.com/w/ESP_Relay_Board
Mit den beiden Buttons kann man mit einfachen Rules die Releais schalten. Dumm ist es nur, wenn man via FHEM die Releais schaltet, dann braucht man innerhalb der Rules den Status der Relais (hier GPIO12 & GPIO13), damit man beim nächsten Betätigen der Taster den "richtigen" erforderlichen Toggle hinbekommt (also wenn Relais=1, dann Relais=0 und vice versa).
Ich habe es nun anders gelöst:
GPIO12 & GPIO13 sind die beiden RELAIS Ports. Ich habe nun (abwohl es ausgänge zu den Relais sind) zwei Devices in ESPEasy (auf dem 8266) angelegt, die als Eingang eben auch GPIO 12 & 13 haben. Dieser Status wird ja unmittelbar bei einem Event an FHEM übermittelt, Somit kann ich nun auch in FHEM sofort sehen, welchen Status die beiden GPIO12 & 13 (also die Relais) haben, ohne von FHEM aus pollen zu müssen.
// Relais 1
on sw1#status do
if [licht#lux]<35
if [controlSW1#status]=1
gpio,13,0
else
gpio,13,1
timerSet,1,3
endif
endif
endon
on Rules#Timer=1 do
gpio,13,0
endon
// Relais 2
on sw2#status do
if [licht#lux]<35
if [controlSW2#status]=1
gpio,12,0
else
gpio,12,1
timerSet,2,3
endif
endif
endon
on Rules#Timer=2 do
gpio,12,0
endonDie Lösung mit sendData habe ich (noch) nicht verstanden ? Kann ich das in den Rules des 8266 nutzen ?
In den commandref's (http://www.letscontrolit.com/wiki/index.php/ESPEasy_Command_Reference) ist zu sendData nichts zu finden.
Viele Grüße!
Andreas
Im ersten Beitrag las es sich so, dass Du auf die Dummy Device Daten angewiesen wärst. Egal, den typischen Weg hast Du ja jetzt gefunden.
Die Funktion sendData findest Du im Quellcode.
Für "senddata" kann man doch ein Häkchen unten im Device setzen. Dann wird eine Wertänderung sofort übertragen und bei Delay nochmal extra. Oder meint ihr jetzt was anderes?
Vielleicht einfach statt den gpio zu setzen in der Rule mit "TaskValueSet <taskID>,<valueID>,<Wert>" arbeiten (oder zusätzlich) das der Task die Änderung mitbekommt. Bsp (setzen von 4 Werten als Sammlung in einen Dummy):
on lu#Lux do
TaskValueSet 3,1,[lu#Lux]
if [lu#Lux]<800
TaskValueSet 3,3,1
endif
if [lu#Lux]>820
TaskValueSet 3,3,0
endif
if [lu#Lux]<20
TaskValueSet 3,4,1
endif
if [lu#Lux]>30
TaskValueSet 3,4,0
endif
endon
on rs#RSSI do
TaskValueSet 3,2,[rs#RSSI]
endon
Gesendet von iPhone mit Tapatalk
Funktionierte früher mit dem Dummy Device nicht. Wenn es jetzt geht, dann ist es in der Tat überflüssig dort etwas zu fixen.
Sehe grad, das er das mit dem TaskValueSet schon macht. Vielleicht noch ein "TaskRun <taskID>" hinterherschieben?
Zitat von: Waldmensch am 30 Januar 2017, 19:36:09
Sehe grad, das er das mit dem TaskValueSet schon macht. Vielleicht noch ein "TaskRun <taskID>" hinterherschieben?
Ja, aber ein TaskValueSet überträgt die Daten zum FHEM nur nach der "delay" eingestellten Zeit (min 10s). Genau das ist das Problem. (ich benutze die letzte ESPEasy R.148).
Viele Grüße!
Andreas
TaskRun mal gemacht? Ich glaube was anderes wird nach Delay auch nicht gemacht
Gesendet von iPhone mit Tapatalk
Hallo,
ich möchte die ESP8266 als Spannungsüberwachung von Fahrzeugbatterien bei der Feuerwehr einsetzen, hab die Hardware soweit zusammen und mache momentan noch nen Testlauf mit meinem PKW. Dabei ist mir aufgefallen, dass die ESP-Devices in FHEM nach einem FHEM restart immer auf present stehen, auch wenn sie vorher auf absent standen und der ESP8266 gar nicht 'anwesend' ist - also auch nicht sendet.
Soll das so sein, oder hab ich da was falsch gemacht?
Gruß
Ingo
Das war in alten Modulversionen der Fall, sollte aber eigentlich seit Monaten gefixed sein.
Du benutzt die aktuelle Version?
wollte grad schreiben das ich heute Morgen noch ein Update gemacht hab... :-[ :-[
nein, aktuell nicht - aber gleich...
sorry für die unnötige Frage.
Hi Liebe FHEM-Community, ;)
ich habe das ESPEasy Modul in FHEM integriert.
Die Messwert meines NodeMCUs werden mir auch angezeigt. 8)
Seitdem ich aber den sleep-mode drin habe nicht mehr. :(
Muss ich etwas beachten ?
Hat noch wer dieses Problem ?
Mfg
Philipp ;D
Hallo Philipp,
Zitat von: EnderPhilipp am 03 Februar 2017, 20:49:50
Seitdem ich aber den sleep-mode drin habe nicht mehr. :(
ich habe auch mal spaßeshalber den sleep-mode angeschaltet. Dann ging ESPEasy eine Weile, danach war Schluss. Vorhin habe ich aus- und wieder eingesteckt und den sleep-mode entfernt. Danach ging wieder alles wie gewohnt (die letzte halbe Stunde).
Gruß PeMue
Edit: Sorry, ich vergaß zu sagen, dass ich einen ESP-01 habe, der kein deep sleep kann ...
Bei mir läuft es mit ESPEasy R147 und DHT22/BH1750 problemlos im deep sleep mode.
Zitat von: dev0 am 03 Februar 2017, 22:06:25
Bei mir läuft es mit ESPEasy R147 und DHT22/BH1750 problemlos im deep sleep mode.
Nur mal eine kleine Frage im Internetz stand, das man beim ESP 2 Pins verbinden muss, muss ich das beim Node auch ????
Mit freundlichen Grüßen
Philipp ;D
Ja.
Hallo, erst einmal Gratulation für dieses Modul. Habe die ganzen 52 Seiten gelesen, aber keine Antwort gefunden und die große Kugel spuckte nix aus.
Mit dem Modul konnte ich in kurzer Zeit einen BMP180 und die WLAN-LED in Betrieb nehmen. Aber bekanntlich werden ja Begehrlichkeiten geweckt.
Ich hatte noch vom Arduino ein 2-fach Relais da, was geschalten wird, wenn der Pin auf GND gelegt wird. Klappt auch, aber es müssen viele on/off getauscht werden.
Wie habt Ihr dies mit dem Modul gelöst? im Moment sieht es z.Bsp. so bei mir aus:
Attributes:
IODev espBridge
Interval 300
devStateIcon .*on:rc_GREEN:off .*off:rc_RED:on .*absent:rc_BLUE .*gpio:rc_YELLOW:off
eventMap /gpio 14 on:off/gpio 14 off:on/status gpio 14:check/
group ESPEasy Device
presenceCheck 1
readingSwitchText 1
room ESPEasy
setState 6
In einem Lolin v3 ist das Relais als Switch mit dem Punkt "Inversed" und "Delay" 60 angelegt. Als Firmware läuft R146 - Mega.
Es ist absolut irritierent, wenn man ein "ESPEasy_ESP8266_Relay1:on.* set ESPEasy_ESP8266_Relay1 longpulse 14 0 10" anlegt, um nach einer gewissen Zeit auszuschalten.
Finde die Idee mit dem Relais inkl. Optokoppler nicht schlecht, alzo wie ist es bei Euch eingerichtet?
Alternativ wage ich den leisen Vorschlag, ob man dies mit einem attr-Befehl anpassen könnte.
Danke
Zitat von: privat58 am 06 Februar 2017, 20:53:29
Es ist absolut irritierent, wenn man ein "ESPEasy_ESP8266_Relay1:on.* set ESPEasy_ESP8266_Relay1 longpulse 14 0 10" anlegt, um nach einer gewissen Zeit auszuschalten.
Der gezeigte Befehl ist unvollständig, soll das ein Notify sein und was genau ist irritierend?
Wenn Du on-for-timer oder off-for-timer lieber verwenden möchtest, dann kannst Du das mit dem globalem eventMap Atrribut umsetzen. Ist hier im Thread (und in der Command Ref.) beschrieben.
ZitatAlternativ wage ich den leisen Vorschlag, ob man dies mit einem attr-Befehl anpassen könnte.
Was genau soll angepasst werden, ich verstehe es noch nicht.
Danke für die Antwort erst einmal.
Durch das arduino-Relais, was mit GND geschalten wird ist der Befehl 1=aus und 0=an, das ist irritierend. Die state-Meldung kann ich ja in ESPeasy mit inversed tauschen.
Ist ein notify:define ESPEasy_ESP8266_Relay1 ESPEasy 192.168.0.113 80 espBridge ESP8266_Relay1
attr ESPEasy_ESP8266_Relay1 IODev espBridge
attr ESPEasy_ESP8266_Relay1 Interval 300
attr ESPEasy_ESP8266_Relay1 devStateIcon .*on:rc_GREEN:off .*off:rc_RED:on .*absent:rc_BLUE .*gpio:rc_YELLOW:off
attr ESPEasy_ESP8266_Relay1 eventMap /gpio 14 on:off/gpio 14 off:on/status gpio 14:check/
attr ESPEasy_ESP8266_Relay1 group ESPEasy Device
attr ESPEasy_ESP8266_Relay1 presenceCheck 1
attr ESPEasy_ESP8266_Relay1 readingSwitchText 1
attr ESPEasy_ESP8266_Relay1 room ESPEasy
attr ESPEasy_ESP8266_Relay1 setState 6
# Relay1 Zeitschaltung
define TimerRelay1 notify ESPEasy_ESP8266_Relay1:on.* set ESPEasy_ESP8266_Relay1 longpulse 14 0 10
Es geht nicht allgemein um fhem etc. Es geht um die getauschten ON/OFF-Befehle.
Ich weiß es nicht, aber mit einem globalen eventMap Attribut werden doch bestimmt alle ON/OFF Befehle getauscht. Da ich noch vieles anderes laufen habe wäre dies nicht so gut.
Eventuell gibt es noch mehr Ideen oder muss halt den Konsum ankurbeln und passende Relais holen.
Zitat von: privat58 am 07 Februar 2017, 10:38:46
Ich weiß es nicht, aber mit einem globalen eventMap Attribut werden doch bestimmt alle ON/OFF Befehle getauscht.
Nein, global heißt in dem Zusammenhang nur, dass sie für jedes FHEM Device zur Verfügung stehen.
Hallo
Bin eigentlich eher der stille Leser hier im Forum und hab bisher alles dank der tollen User hier hinbekommen aber im Moment komme ich nicht weiter.
Ich probier mich auch gerade mit den NodeMCU und hab eins mit Firmata zum laufen gebracht und als nächstes ESPEasy probiert.
Der ESP ist geflasht mit der 147er Version und ist mit dem Wlan verbunden und ich hab soweit alles eingestellt.
In FHem hab das ganze so wie im 1.Post beschrieben definiert.
Da ich auch nur Ausgänge schalten möchte, sind natürlich keine Sensoren oder ähnliches angeschlossen also werden auch keine Device's in Fhem angelegt, zumindest denke ich mir das so.....
Also einfach mal zum testen einen Switch angelegt auf GPIO-16 (D0) und hab dann dort 3,3v angelegt und wollte sehen ob der Input funktioniert....
Naja auf jeden Fall hab ich inzwischen soviel getestet und rumgestellt, dass ich nicht mehr weiß was ich schon alles probiert habe.
Allerdings ist mir irgendwann mal aufgefallen dass ein Switch den ich angelegt hatte in Fhem automatisch eingebunden wurde, allerdings hatte ich den schon wieder im ESP entfernt und weiß auch nicht mehr was ich da alles ausprobiert habe.
Ziel ist auf jeden Fall einen Button anlegen und wenn ich den drücke soll fhem das registrieren und im nächten Schritt wollte ich über einen Ausgang ein Relais schalten per Fhem
So nun mal konkrete Fragen von mir.
Unter Config habe ich FHEM HTTP Ausgewählt, locate Controller steht auf IP.
Was muss jetzt unter IP und vor allem Port stehen. Ich habe es mit der IP vom FHEM Server probiert und dem Port 8083
Dann bei den Devices gibt es eine IDX/Variable, da darf nur nicht 0 drin stehen und es darf vermutlich keine doppelt vergeben werden, ist das so korrekt?
Ich danke schon mal im Voraus für hoffentlich hilfreiche Antworten.
Hi thx2k,
IP Adresse muss die vom FHEM Server sein, das Port ist das Port was man beim define vergibt und nicht das FHEMWEB Port!
Wenn Du also "abgeschrieben" define espBridge ESPEasy bridge 8383 hast dann ist das Port 8383.
Beim Index bin ich nicht sicher, ich vergebe immer einen Anderen.
Gruß Otto
Wie Otto schon schrieb müssen ESPEasy Bridge Port und Controller Port in der ESP Config übereinstimmen. Weiterhin muss die Controller IP der IP des FHEM Hosts entsprechen.
Der Index wird in FHEM nicht benötigt, sollte aber > 0 sein, da sonst ESP Devices (teilweise?) keine Daten senden. Laut ESPEasy Doku müssen die Indexe auch unterschiedlich sein.
Beispiele für Deine Relay/Tasterkombination findest Du zB. im Sonoff Wiki.
Hallo
Schon mal danke für die Antworten 🙂
Also Port hatte ich natürlich 8383 angegeben, war nur ein Schreibfehler oder vielleicht auch ne Angewohnheit in Verbindung mit Fhem.
Nur legt es eben das Device nicht automatisch an, hab auch schon nen Dummy probiert und da nen Temperatursensur simuliert.
Dass es generell funktioniert hatte ich ja gesehen, da nach Stundenlangem rumtesten ja ein angelegter testswitch definiert war aber ich weiss eben nicht mit welchen Einstellungen 😅
Werd mir aber heute mal das von dir erwähnte Wiki anschauen und komme dann hoffentlich weiter.
Gibt es denn noch ne andere Möglichkeit zu testen ob eine Verbindung zu ESPEasy besteht, initialisieren tut er es mit dem Befehl ja immer, egal ob ESPEasy erreichbar ist oder nicht.
Gruß Christian
Hallo Christian,
so hab ich das gemacht -> http://heinz-otto.blogspot.de/2017/01/esp8266-in-fhem.html
Gruß Otto
Vielleicht hab ich was übersehen, aber ggf. gäbe es noch einen Verbesserungsvorschlag für das Modul:
Der ESP wird eingerichtet (IP per DHCP wie wohl üblich), die Devices angelegt, alles läuft. Dann vergibt man für diesen ESP im Router eine fixe IP außerhalb des DHCP-Scopes für den Produktivbetrieb. Nun findet zwischen FHEM und dem ESP keine Kommunikation mehr statt, es werden komischerweise aber auch keine neuen Devices angelegt. Erst wenn in den Devices die Definition geändert und an die neue IP angepasst wird, passt wieder alles.
Es wäre gut, wenn das Modul erkennt, dass sich bei einem Device (IDENT bleibt ja gleich) die IP geändert hat und dies selbst anpasst. Oder kann man das schon wo einstellen und ich hab nur den Parameter übersehen?
Gruß
Michael
Gibt es schon. Einfach das Device löschen.
Es wird automatisch neu und mit der richtigen IP angelegt. ;)
Und diese "Problematik" mal umgemünzt auf eine klassische dynamische IP vom DHCP: Würde es laufen?
Oder müsste das Device allenthalben, wenn es gerade nicht mehr geht, wieder gelöscht werden?
Das Moduldesign ist auf statische IPs ausgelegt, das werde ich auch nicht mehr ändern. DHCP Server können auch statische IPs vergeben.
Wenn die IP eines ESPs geändert werden muss, dann kann man sie mit dem defmod Befehl anpassen.
Zitat von: dev0 am 16 Februar 2017, 15:40:17
Das Moduldesign ist auf statische IPs ausgelegt, das werde ich auch nicht mehr ändern. DHCP Server können auch statische IPs vergeben.
Ja, das ist im Prinzip richtig. Ich dachte nur, dass man hier ggf. die Nutzerfreundlichkeit verbessern hätte können. Üblicherweise vergeben DHCP-Server beim erstmaligen Kontakt ja eben eine dynamische IP aus dem eingerichteten Scope. Erst dann kann manuell eine fixe IP an diese MAC-Adresse gebunden werden.
Ist aber ok, man muss es nur wissen.
Gruß
Michael
Ich habe gerade die Modulversion 0.8.2 auf Github eingecheckt. Das wird die letzte Version sein, die über Github verteilt wird. Zum nächsten Wochende werde ich das Modul ins FHEM svn einchecken. Danach solltet ihr auch das ESPEasy Github Repository aus dem FHEM Update entfernen, wenn ihr es eingebunden habt:
update delete https://raw.githubusercontent.com/ddtlabs/ESPEasy/master/controls_ESPEasy.txt
Sobald das Modul über das normale FHEM Update ausgeliefert wird, werde ich das control file auf Github so anpassen, dass nur noch ein ESPEasy.txt ausgeliefert wird. Erkennt das Modul beim Laden, dass diese Datei vorhanden ist, dann wird eine Warnung ins Log geschrieben.
Hallo Leute,
hat jemand schon mit diesem espeasy ein Sonoff POW am laufen inkl. Verbrauch Messung?
Grüsse
Lewej
Zitat von: lewej am 21 Februar 2017, 20:34:13
Hallo Leute,
hat jemand schon mit diesem espeasy ein Sonoff POW am laufen inkl. Verbrauch Messung?
Grüsse
Lewej
Das geht nicht.
Grüße Jörg
Zitat von: JoWiemann am 21 Februar 2017, 20:43:47
Das geht nicht.
Grüße Jörg
Läuft das nur mit der MQTT Variante?
Gruss
Lewej
Zitat von: lewej am 21 Februar 2017, 21:02:47
Läuft das nur mit der MQTT Variante?
Gruss
Lewej
Möchtest Du Dir die Frage selber beantworten?!
Zitat von: lewej am 21 Februar 2017, 21:02:47
Läuft das nur mit der MQTT Variante?
der POW wird derzeit (nur) vom Arends Sketch Tasmota unterstützt und dieser benutzt das Protokoll MQTT und das nur mehr im JSON Format!
{"Time":"2017-02-22T09:18:45", "Yesterday":"2.286", "Today":"0.896", "Period":0, "Power":0, "Factor":"0.00", "Voltage":235, "Current":"0.000"}das ist so ein JSON String
Es gibt von dev0 sogar ein neues Modul welches aus dem JSON Format direkt die Readings erzeugt, also Null Aufwand (MQTT Installation ist Voraussetzung).
https://forum.fhem.de/index.php/topic,66761.msg590603.html#msg590603 (https://forum.fhem.de/index.php/topic,66761.msg590603.html#msg590603)
LG
Das ESPEasy Modul habe ich auf svn.fhem.de eingecheckt. Damit steht das Modul morgen ab 8:00 Uhr mit dem normalen Update bereit. Die Version habe ich auf 1.0 erhöht.
Bitte das Github Repository aus dem FHEM Update entfernen, wenn Ihr es eingebunden habt:
update delete https://raw.githubusercontent.com/ddtlabs/ESPEasy/master/controls_ESPEasy.txt
Wenn Ihr das Repository nicht entfernt, dann wird nach jedem Update und Neustart eine Meldung dazu ins Log geschieben.
Hi, wie kann ich denn den Analogen Eingang ADC (TOUT) in Fhem mit dem Modul auslesen ?
https://dl.dropboxusercontent.com/u/57368340/esp.PNG (https://dl.dropboxusercontent.com/u/57368340/esp.PNG)
Alle digitalen Eingänge wurden ansonnst per autocreate automatisch erzeugt.
beste Grüße
Der Wert muss von einem ESPEasy Device/Plugin gesendet werden. 'Analog Input'?
ja genau, der wert wird mittels des Device:Analog input abgefragt und im Webinterface auch angezeigt.
Laut Deinem Screenshot ist 'Send Data' nicht aktiv.
::) Ok alles klar völlig übersehen :D der Fehler sitzt meistens vor dem Computer.
Nachdem "Send Date" aktiviert ist bekommt Fhem auch Daten. ;D
Der Eintrag in Fhem musste allerdings manuell erzeugt werden und wurde nicht per autocreat generiert.
besten Dank.
Zitat von: dustin.t am 02 März 2017, 14:03:58
Der Eintrag in Fhem musste allerdings manuell erzeugt werden und wurde nicht per autocreat generiert.
Glaube ich nicht, ist aber auch egal, da es ja bei Dir jetzt funktioniert.
Stimmt du hast völlig Recht, habe die Fhem Config nochmal neu aufgesetzt und alle Geräte werden fehlerfrei erzeugt.
Nochmal besten Dank für die schnelle Hilfe und die geniale Integration durch das Plugin !
Habe da mal ne Frage.
Besteht die Möglichkeit, das Attribut "addValTrigger" einzubauen ?
Ich habe eine Seite, wo ich mir die RSSI Werte von allen Geräten, die es unterstützen (durch den Empfänger), anzeigen lasse.
Ich würde gerne die EPS´s die ich habe, mit anzeigen lassen.
Gruß
Sascha
Das Attribut sagt mir nichts.
Gehört zum CUL Modul:
addvaltrigger
Generiert Trigger für zusätzliche Werte. Momentan sind dies RSSI und RAWMSG für die CUL Familie und RAWMSG für FHZ.
Grüße Jörg
Gesendet von iPhone mit Tapatalk
Wenn RSSI Werte empfangen werden, dann werden dafür auch jetzt schon Events generiert. Ich verstehe den Sinn für das ESPEasy Modul (noch?) nicht.
Der Sinn ist, dass die rssi Werte mit in die gezeigt Übersicht einfließen. Wie zuvor geschrieben, ist das für die cul Familie.
Die Darstellung der rssi Werte ist eigentlich nur ein notify und ein paar dummies.
Werde mal mit dem Ersteller der rssi Tabelle kontakt aufnehmen.
Gruß und danke
Sascha
Gesendet von meinem E6653 mit Tapatalk
Zitat von: sash.sc am 02 März 2017, 17:58:09
Der Sinn ist, dass die rssi Werte mit in die gezeigt Übersicht einfließen.
Das ist klar. Mir hatte sich der Sinn Deiner Frage, nach einem neuen Attribut, nicht erschlossen, da die Funktionalität bereits gegeben ist.
Hi,
ich habe ein NodeMCU mit installierter ESPEasy. Konfiguriert und 5 angeschlossene DS18B20 Sensoren.
In Fhem hab ich dann eine ESPEasy Bridge angelegt.
Ebenso habe ich dann das Device per IP eingebunden.
Wie bekomme ich jetzt die Sensoren rein?
Das Device geht immer auf Absent und bleibt auch da.
Danke für Hilfen.
Schaue einfach mal in jedem device, ob du den Haken bei "senden data" gesetzt hast.
Welches version von espeasy benutzt du?
Ja, die Haken sind gesetzt.
Build: 120
Core Version: 2_3_0
Hab eben die Build: 147
Core Version: 2_3_0
geflasht, gleiches...
Wenn bei verbose 5 der Bridge keine empfangenen Daten im Log zu sehen sind, dann ist auf ESPEasy-Seite etwas falsch konfiguriert:
- Controller IP/Port
- Device Delay == 0
- send Data nicht aktiviert
- ...
Controller IP / Port ist die ip der fhem Instanz plus der Port der fhem Instanz?
Controller IP muß der IP des FHEM Host entsprechen. Der Controller Port muß dem Port der ESPEasy Bridge entsprechen.
Habe mir gerade Deine Anhänge näher angesehen und die Definitionen der ESPEasy Devices sind falsch. Lösch die manuell angelegten Devices besser wieder und benutze nur das Autocreate. Soll heißen: nur die Bridge definieren, die Devices werden automatisch angelegt, wenn Daten empfangen werden.
Nachdem ich user und pass definiert hab, ging es. Wusste nicht, das das vergeben werden muss
Zitat von: morph am 05 März 2017, 12:22:41
Nachdem ich user und pass definiert hab, ging es. Wusste nicht, das das vergeben werden muss
Wird aber auch im Log angezeigt, wenn dort etwas nicht stimmt. Wahrscheinlich sogar deutlicher als bei den meisten anderen Modulen...
Hi,
ich verwende einen NodeMcu mit ESPEasy als Wetterstation.
Ich habe GPIO16 mir Reset verbunden und der Node geht auch zuverlässig in den sleep-Mode und wacht auch alle 30sek wieder auf.
Wie kann ich sagen, dass der Node nur alle z.B. 180sek aufwacht ?
Mfg
Philipp ;D
Hallo,
du musst den Standard Sensor Delay in den allgemeinen Einstellungen ändern.
Zitat von: roelleke am 08 März 2017, 18:12:24
Hallo,
du musst den Standard Sensor Delay in den allgemeinen Einstellungen ändern.
Danke :D
Hallo,
nach >2 Wochen mit viel Trial & Error und der Suchfunktion stelle ich mein Problem mal hier mit ein:
Mein ESP-Platinchen läuft und wird mit dem ESPEasy-Modul erkannt. Ich habe einen funktionierenden Temperatursensor und sehe die Wifi-Signalstärke.
Zudem habe ich einen IR Sensor und 2 IR LED's. Wenn ich mit der Fernseher-FB darauf halte, kommen reproduzierbar Zahlenreihen, die ich allerdings nicht interpretieren kann.
Wenn ich "set ESPEasy_ESP_Module_1_WiFi irsend SONY 0xa90 12" in die Kommandozeile eingebe, blinken die IR-Leds und im Log kommt eine Bestätigung
Nur - nix reagiert. Ich habe gelesen, dass Sony den Code 3mal benötigt - (wie) macht das das Modul?
oder anders: Was mache ich falsch / wie gehts, dass ich meinen TV an/ausschalten kann?
bin um jede Hilfe dankbar!
tschennings
Hallo zusammen,
Ich wollte heute in die Welt des espeasy eintauchen. Der erste Versuch mit einem esp01 war recht gut. Ich konnte ohne Probleme einen dht22 in FHEM einbinden.
Nach einer halbem Stunde ca. Sagte mir fhem die Bridge sei absent.
Im log vom esp stand connectionsfailure. Also habe ich erst fhem, dann den esp neu gestartet. Leider hat das nichts gebracht. Dann wollte ich den esp neu flashen, weil es ja zuerst ging. Also alles von Anfang.
Ich komme so weit das der esp ein wlan öffnet. Ich verbinde mich damit, wähle im setup ein wlan aus und gebe das Passwort ein. Dann kommen die 20 Sekunden... Und nichts passiert. Das esp01 taucht im wlan nicht auf.
Ich dachte mir das Vll der esp kaputt gegangen ist, habe einen anderen probiert. Aber genau das selbe. Wlan Passwort eingegeben, 20 Sekunden gewartet und nichts passiert. Ich habe das gesamte Netzwerk neu gestartet, aber auch kein Erfolg.
Könnt ihr mir weiterhelfen?
Grüße
Edit: Achja. Die Version die zuerst lief war die 147. Als die nicht ging probierte ich die 120.
Es ist der schwarze esp 01 1024(kb?) flash size. Falls das wichtig wäre.
Ich dachte der ESP01 hat 512 kB kilo Byte bzw. 4096 Mbit
Gruß Otto
Es gibt blaue (512) und schwarze (1024)
Ich hatte das Problem, das ESP Easy nicht wirklich den kompletten Speicher löscht. D.h da kannst Du flashen wie Du willst, da änderst Du nichts.
ZitatWill man das Ganze in den Ursprungszustand versetzen (Reset) dann muss man sich mit einem seriellen Monitor verbinden und "blind" Reset (reset) eintippen. Man darf bei putty ctrl+m ctrl+j (CR LF) nicht vergessen.
Man hat leider kein lokales echo.
Es kann einen Moment dauern, bis der Vorgang mit FLASH: Erase Sector: ... quittiert wird.
Nach dem Abschluss des Löschens erfolgt ein normaler Boot im AP Modus.
Gruß Otto
Zitat von: tschennings am 08 März 2017, 22:35:07
Nur - nix reagiert. Ich habe gelesen, dass Sony den Code 3mal benötigt - (wie) macht das das Modul?
Gar nicht, das ist Sache des Plugins. Wenn ESPEasy oder ein Plugin etwas nicht beherrscht, dann muss das dort erweitert werden.
Hallo Otto,
Zitat von: Otto123 am 08 März 2017, 23:42:10
Ich dachte der ESP01 hat 512 kB kilo Byte bzw. 4096 Mbit
die ESP01 mit der schwarzen Platine haben 1024 kByte Speicher.
Gruß PeMue
KByte, MByte, MBit. Können wir uns aus was einigen?
Moin,
Nicht streiten, einfach andere die Vorgaben machen lassen:
https://www.letscontrolit.com/wiki/index.php/Tutorial_ESPEasy_Firmware_Upload
Aus meiner Sicht also 512kbit (blau) oder 1024kbit (schwarz)
Gruß Arnd
Raspi2 mit FHEM, CUL, MySensor, HomeBridge, Presence, Bravia, ...
Zitat von: xeenon am 09 März 2017, 08:11:03
KByte, MByte, MBit. Können wir uns aus was einigen?
Wieso, ist doch alles schon definiert:
1MBit = 1024 kBit, der Speicher ist angegeben in kBit (oder MBit) und ist als Byte (organisiert, d.h. man braucht für 1MByte in diesem Fall 8MBit Speicher ???
Zitat von: xeenon am 09 März 2017, 08:11:03
KByte, MByte, MBit. Können wir uns aus was einigen?
Da gibt es nichts zu einigen. Da heißt es nur die richtigen Werte und Angaben verwenden.
Leider wird gerade im Bereich ESP der Speicher sehr oft in Bit angegeben. Und bei der Verwendung von b und B wird auch geschlampt.
Besonders verwirrend ist sicher auch, dass die ESP01 4Mb haben und die ESP12 4MB - da kommt man schnell mal durcheinander.
Hier ist am Ende ein Tabelle mit den Speicher Größen. http://www.esp8266.com/wiki/doku.php?id=esp8266-module-family#esp-01
Gruß Otto
Wieso streiten? Ich war nur jetzt total verwirrt. Aber jetzt ist wieder alles klar.
Hallo xeenon,
ich flashe die Dinger immer mit der Arduino IDE und
starte vor dem Flashvorgang den seriellen Monitor,
dann sehe ich sofort, was das Ding nach dem flshen treibt.
Ausserdem kann ich die W-LAN-Parameter dort ganz einfach setzen!
Gruß
p99p
Wie setzt du denn die Parameter? Dann versuch ich es mal auf die Weise.
Schau mal auf https://www.letscontrolit.com/wiki/index.php/ESPEasy_Command_Reference (https://www.letscontrolit.com/wiki/index.php/ESPEasy_Command_Reference)
Da gibt es eine Liste von Befehle, die man auch über die serielle Schnittstelle schicken kann.
EDIT: Das save am Ende nicht vergessen!
Da es hier zusehends offtopic wird und der Thread unabhängig davon auch schon viel zu lang ist, schließe ich den Thread.
Supportanfragen zum ESPEasy Modul und FHEM HTTP Controller Plugin bitte in neuen Threads im Bereich Bastelecke/ESP8266 (https://forum.fhem.de/index.php/board,74.0.html) eröffnen.
Vielen Dank an alle, die sich an der Entwicklung des Moduls und des Controller Plugins beteiligt haben.