Neues Modul: ESPEasy [war: ESPEasy ohne MQTT]

[max333]

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?

[Shardan]

Hallo dev0,

der IRSEND funktioniert bis jetzt tadellos.

Vielen Dank für deine Mühe mit dem Modul und der Erweiterung.

Shardan

[Shardan]

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 )

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

[dev0]

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.

[max333]

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.

[dev0]

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.

[Shardan]

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

[max333]

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.

[Elektrofreak]

Hallo,

ich habe noch eine Frage:

Wenn ich den befehl longPulse verwenden möchte, bekomme ich folgende Meldung:

Command 'longpulse' is deactivated until attribute 'rgbGPIOs' is set.

Ich möchte aber keine rgb-LEDs verwenden  . Was muss ich machen? 

[dev0]

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.

[kadettilac89]

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

Code Auswählen Erweitern


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


[dev0]

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.

Kann es sein, dass R147 den Fehler aus R120 immer  noch hat?

Ich verstehe dein Problem nocht nicht. Was funktioniert denn jetzt konkret nicht?

[dev0]

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:

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?

[kadettilac89]

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

Code Auswählen Erweitern


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

Code Auswählen Erweitern


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


[kadettilac89]

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.