ESPEasy Modul 2.1 - neu: deepsleep, attrTemplate

[dev0]

Im Anhang findet sich die aktualisierte ESPEasy Modul Version 2.1 und ein erstes attrTemplate. Mag jemand diese Version bzw. das Template testen bevor ich es einchecke? Hat jemand noch Ideen für weitere ESPEasy Templates?

Neu in dieser Version:

• attrTemplate Unterstützung:
  siehe Ankündigung hier.
  
  
• Erweiterte Deep Sleep Unterstützung:
  Set Befehle können nun auch an ESP Easy Knoten geschickt werden, der sich im 'deep sleep' befinden. Die Befehle werden erst in eine Warteschlange gestellt und nach dem Erwachen gesendet. Um erkennen zu können, ob ein ESP erwacht ist, muss dieser mindestens einen Wert an FHEM schicken. Weiterhin muss eine "halbwegs" aktuelle ESP Easy Mega Version auf dem ESP geflashed sein, die die Option "Config -> Sleep Mode -> Sleep awake time" bereitstellt.
  Ab welcher Version das genau der Fall ist habe ich nicht herausfinden können. Weiß das jemand?
  Die "Sleep awake time" muss so groß eingestellt werden, dass nach dem Senden der normalen (Sensor-)Werte der Befehl noch abgearbeitet werden kann. Wie lang das ist hängt vom Befehl und der ESP Hardware ab. Kann ein Befehl nicht mehr gesendet werden, dann wird die Warteschlange beim nächsten Erwachen weiter abgearbeitet.
  Das Device Reading sleepState zeigt je nach Status: "sleeping", "sleep awaited" oder "awaked until <unixtime>" an.
  Weiterhin ist der ESP Easy nosleep Befehl nun bekannt.
  
  
• 
  Erweiterung der command reference:
  
  Device Attribut maxCmdDuration:
  

  
  Only used if an ESP Easy node works in deep sleep mode. This attribut defines the amount of seconds your ESP node needs to work off a single command. In other words: This value defines how much time must be left to send a command to your ESP node before it goes into deep sleep mode. Commands that are not send will be queued und worked off when the node awakes again.
  ESPEasy Mega with option to set sleep awake time (Config -> Sleep awake time) is required to use this feature.
  Possible values: secs >= 0, but < awake time
  Default: 3
  

  
  Device Attribut deepsleep:
  

  
  This attribut defines the default deep sleep state that is assumed if the ESP has not sent its status to FHEM. Eg. directly after a FHEM restart. If the ESP has sent its status, this value is ignored. Useful if you want to be sure that a set command would be queued and sent when the ESP awakes after a restart/rereadcfg of FHEM.
  ESPEasy Mega with option to set sleep awake time (Config -> Sleep awake time) is required to use this feature.
  Possible values: 0,1
  Default: 0
  

  
  Device set attrTemplate:
  

  
  See global attrTemplate. Attribute useSetExtensions must be activated or the command is unavailable.
  

Edit: Modul aus dem Beitrag entfernt, da ich es bereits ins svn repository eingecheckt habe.

34_ESPEasy.pm nach ./FHEM kopieren
ESPEasy.template nach ./FHEM/lib/AttrTemplate kopieren

[duke-f]

Ich habe die beiden Files in mein entsprechendes ESPEasy-Testsystem eingebaut und es scheint ohne Probleme zu funktionieren. Konkret ist dies mein FHEM als App auf dem QNAP TVS-882 mit x86-Prozessor. Ich hoffe, diese Rückmeldung ist hilfreich. Was es mit den Templates genau auf sich hat, muss ich natürlich erst selber noch recherchieren, fürchte ich.

Besten Dank für das Modul, hilft mir wirklich sehr!

[duke-f]

Weiß jetzt nicht, ob ich mich hier in diesem Thread in einer Sackgasse befinde. Dennoch habe ich was dazu passendes noch beizutragen, denke ich.
Ich nutze gerade das Modul weiterhin ja unter anderem für einen WeMos, den ich mit deepsleep betreibe. Immer um **:05 wird per Rules darauf ein gewisser Prozess durchgeführt, an dessen Ende Daten auf FHEM übertragen werden. Dann wird der WeMos auch durch die Rules für 50 Minuten in Tiefschlaf versetzt. Innerhalb der Konfiguration des WeMos wird hinsichtlich Sleep nichts definiert, also auch keine Awake-Zeit. Ich habe jetzt immer zu jeder vollen Stunde ca. 10 Minuten Zeit, zu der ich ggf. in die Programmierung eingreifen kann. Soweit so gut.

Jetzt hatte ich die Hoffnung, ich könne den Befehl nosleep nutzen, um ggf. mal auch mal dann zugreifen zu können, wenn ich die volle Stunde verpasst habe. Also habe ich den FHEM-Befehl

nosleep 3300

abgesetzt in der Hoffnung, dies würde ja in der Warteschlange gehalten, bis der WeMos dann aufwacht und dann den deepsleep eben mal für länger aussetzen.

Hat so nicht funktioniert. Entweder kam der nosleep doch nicht an oder der sleep-Befehl innerhalb der Rules war stärker. Oder ich habe alles komplett falsch verstanden.

[dev0]

Ich denke, dass dieser Thread schon passt.

ein gewisser Prozess durchgeführt, an dessen Ende Daten auf FHEM übertragen werden

Wenn die Daten via "FHEM HTTP" Controller Plugin und nicht via httpsend gesendet werden, dann würde es funktionieren. Allerdings muß dazu noch die "Awake Time" auf dem ESP größer 1 Sekunde definiert sein. Wenn Du diese Option nicht hast, dann ist die Firmware zu alt. Ich habe leider nicht herausfinden können ab welcher Version das genau der Fall ist. Zum Testen würde ich vielleicht sogar mit 5 Sekunden awake time anfangen.

Wenn das ESPEasy Modul einmal Werte von einem ESP empfangen hat, auf dem die awake time definiert ist, dann wird diese Zeit im Device unter dem Internal SLEEP angezeigt: "0" bedeutet, dass deepsleep nicht verwendet wird, 1 bedeutet dass deepsleep eingeschaltet ist (oder eingeschaltet und awake time auf 1 sec gesetzt ist). Ein Wert >1 bedeutet, dass deepsleep aktiv ist und awake time auf den entsprechenden Wert gesetzt ist.

Befehle, die an den ESP geschickt werden, werden solange zwischengespeichert bis der ESP sich meldet. Ab diesem Zeitpunkt werden Befehle für diesen ESP rausgeschickt, die während des DeepSleeps gequeued wurden. Die Queue wird nicht weiter abgearbeitet, wenn die awake time (minus maxCmdDuration) erreicht ist. Der Defaultwert von maxCmdDuration habe ich zwischenzeitlich auf 1 Sekunde gesenkt.

[duke-f]

Vielleicht kann ich meine Situation nochmal etwas näher erläutern.
Ich weiß auch nicht, ab welcher Version das möglich ist, aber diejenige, die ich betreibe ist verhältnismäßig neu. Ich hatte erst den Sleep über die Konfiguration definiert, also über die Sleep- und Awake-Time. Das hat soweit auch funktioniert, aber leider nicht immer wirklich so zuverlässig wie ich wollte. Daher und auch einfach mal als Versuch habe ich es jetzt mal so versucht, dass der WeMos wirklich immer dann erst schlafen geht, wenn er seine Aufgabe erledigt hat. Vorteil ist, dass ich jetzt auch längere Awake-Zeiten habe als über die Konfiguration, wo maximal 255 s möglich sind. Das war für manche Abläufe zu knapp. Jetzt fürchte ich, wenn ich in der Konfiguration eine Awake Time eingebe, dass diese dann wieder für das Schlafengehen maßgebend würde - also wieder maximal 255 s statt der 10 Minuten, die ich jetzt habe.
Ich sende die Daten auch per FHEM HTTP Controller und nicht (mehr) per httpsend.

Soweit habe ich das mit dem Sleep dann verstanden. Es wird bei mir, da so nicht konfiguriert, eben auch kein Internal SLEEP angezeigt. Ist mir nun klar, das wird eben in den Rules erst ausgelöst und ist nicht Teil der Konfiguration, folglich auch kein Internal.

Was nosleep nun aber wirklich (auch ESPEasy-seitig) bewirken sollte, habe ich noch nicht festgestellt. Ich werde mal einen anderen Befehl austesten, dann muss das mit der Queue während des sleeps ja funktionieren - oder eben doch nicht, weil der sleep-Modus ja gar nicht wirklich gemeldet wird?

[dev0]

Ich werde mal einen anderen Befehl austesten, dann muss das mit der Queue während des sleeps ja funktionieren

ja, aber nur wenn die awake time > 1, in der ESP Easy Firmware, konfiguriert ist. sonst nicht. mwn muss auch die sleep time konfiguriert sein.

Edit: Es geht darum, dass der ESP via FHEM HTTP Controller einen SLEEP > 1 in dem JSON String liefert. Das kannst Du via "attr <bridge> verbose 5" genau im Log sehen. Wenn das so ist, dann sollte es funktionieren, sonst nicht.

[Beta-User]

@dev0:
Magst du das ESPEasy.template auch noch ins svn hochladen?

[duke-f]

Ok, soweit verstanden. Besten Dank!

[dev0]

Magst du das ESPEasy.template auch noch ins svn hochladen?

Im Moment eher nicht, da es bisher keine Resonanz gab, ob das Template überhaupt funktioniert oder sinnvoll ist und benötigt wird. Ich müßte mich damit erst auch noch einwenig intensiver beschäftigen. Aber vielleicht findest sich ja jemand, der das übernehmen möchte

[Beta-User]

Im Moment eher nicht, da es bisher keine Resonanz gab, ob das Template überhaupt funktioniert oder sinnvoll ist und benötigt wird. Ich müßte mich damit erst auch noch einwenig intensiver beschäftigen. Aber vielleicht findest sich ja jemand, der das übernehmen möchte

Keine stimmt nicht :

Ich habe die beiden Files in mein entsprechendes ESPEasy-Testsystem eingebaut und es scheint ohne Probleme zu funktionieren. Konkret ist dies mein FHEM als App auf dem QNAP TVS-882 mit x86-Prozessor. Ich hoffe, diese Rückmeldung ist hilfreich. Was es mit den Templates genau auf sich hat, muss ich natürlich erst selber noch recherchieren, fürchte ich.

Besten Dank für das Modul, hilft mir wirklich sehr!

Was das "vielleicht findet sich jemand" angeht, ist das na ja... Ich habe sowas von keinem Plan von ESPEasy und auch sehr wenigst Neigung, mich da einzudenken. Ich habe ganze zwei ESP's im Einsatz: einen als Milight-Hub mit der Sidoh-Firmware, einen mit einer modifizierten IR-MQTT-firmware. Den zweiten würde ich vielleicht sogar mit ESPEasy betanken, soll für IR ja ganz gut sein und spräche auch MQTT (wenn ich wüßte, welche firmware bzw. wie bauen, MQTT kenne ich jetzt halt ganz gut ), aber das war's und das soll auch so bleiben.

Das template selbst sieht für meine Begriffe ganz gut aus, ich würde ggf. nur noch ein attr model xy ergänzen, damit man ggf. im list sieht, was da (vermutlich) ist und einen Überblick zur Verbreitung über die fhem-Statistik bekommt.

Vielleicht können wir das so machen: Ich trage uns beide als Maintainer ein, wir schauen uns das an, was an Rückmeldungen kommt. "Einfache" fixes kann ich dann eine Zeitlang (6 Monate+) machen, will mich dann aber auch beizeiten wieder zurückziehen dürfen. Da das ja jeweils nur auf ausdrückliche User-Anweisung wirksam wird, sind auch vorübergehende "Fehler" nicht dramatisch und können dialogisch mit den Interessierten geklärt werden, war jedenfalls meine Erfahrung bei mqtt2template...

Meldungen zu den templates entweder dann nur in diesem Thread oder wie bei HTTPMOD über einen separaten mit Ankündigung/kurzer Erläuterung?

[dev0]

Danke für das Angebot mich zu unterstützen, das nehme ich gerne an. Mir war allerdings nicht klar, dass Du ESPEasy nicht so gut kennst, sonst hätte ich nicht indirekt gefragt.

Ich schaue mir das Template in den nächsten Tagen noch einmal an und überlege mir ggf. noch ein paar Szenarien, bei denen ein Template helfen könnte. Dann checke ich es ein und schreibe eine Ankündigung incl. Support-Thread dazu. Vielleicht schaust Du dort mal mit mitrein...

Über ein model Reading/Internal hatte ich auch schon einmal nachgedacht, allerdings eher um die verwendete ESP Easy Firmware Version darzustellen. Ich vermute, dass das Template eher Spezialfälle abdecken wird und nicht wirklich oft verwendet werden wird. Es sei denn, jemand pushed das im Forum.

@all: Falls jemand weitere Ideen hat, was man bei der Einrichtung, durch ein Template, vereinfachen könnte, darf sich gerne auch zu Wort melden.

[Beta-User]

Kein Problem...
Eilt ja alles auch nicht .

Hier evtl. gleich ein (ungetesteter) Vorschlag, ein paar "Basics" aufzunehmen, die sich m.E. halbwegs bewährt haben, z.B.
- Beschreibung einschl. Link, wo weitere Info herzunehmen ist,
- zur ID, model und
- eine gewisse Sortierung.

Code Auswählen Erweitern

#############################################################
# $Id: ESPEasy.template $
#
# Comments start with #. Empty lines are ignored.
# Syntax of one entry: name: line, one optional filter: line, zero or more par: lines,  FHEM-Commands
# filter:INTERNAL=VALUE (optional)
# par: name of the parameter; comment; perl_code (optional)
# perl_code returns a value for the parameter, or undef.
# If undef, the user has to specify them (the comment is shown to the user)

name:01_ESPEasy-single_gpio_switch
filter:TYPE=ESPEasy
desc: Device representing a single GPIO-pin as motion sensor.<br><a href="https://forum.fhem.de/index.php/topic,93604.msg910666.html#msg910666">Further information in our forum</a>
par:GPIO-NO;used GPIO port;{undef}
attr DEVICE stateFormat {ReadingsVal($name,"presence","") eq "absent" ? "absent" : ReadingsVal($name,"GPIOGPIO-NO","")}
attr DEVICE devStateIcon on:ios-on-green:off off:ios-off:on absent:10px-kreis-rot:statusRequest
attr DEVICE eventMap /gpio GPIO-NO on:^on/gpio GPIO-NO off:^off/
attr DEVICE useSetExtensions 1
attr DEVICE webCmd :
#attr DEVICE model 01_ESPEasy-single_gpio_switch

name:09_ESPEasy_demo_setUserCmds
filter:TYPE=ESPEasy
desc: Example device activating two plugins for RGB+CT controll + switch.<br><a href="https://forum.fhem.de/index.php/topic,93604.msg910666.html#msg910666">Further information in our forum</a>
attr DEVICE userSetCmds \
( \
plugin_a => { \
    args  => 2, \
    url   => "/control?cmd=", \
    usage => "<rgb|ct> ", \
    cmds  => { \
       rgb => { args => 1, usage => "<rrggbb>", widget => "colorpicker,HSV" }, \
       ct  => { args => 1, usage => "<colortemp>", widget => "colorpicker,CT,2000,10,4000" } \
    } \
  }, \
plugin_b => { \
    args  => 1, \
    url   => "/foo?bar", \
    usage => "<on|off|bri> [bri_value]", \
    cmds  => { \
       on  => { widget => "noArg" }, \
       off => { widget => "noArg" }, \
       bri => { widget => "knob,min:1,max:100,step:1,linecap:round", usage => "<0..255>", args => 1 } \
    } \
  } \
)
attr DEVICE useSetExtensions 1
attr DEVICE devStateIcon { ESPEasy_devStateIcon($name) }
attr DEVICE webCmd ct:pct:rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:toggle:on:off
#attr DEVICE model 09_ESPEasy_demo_setUserCmds

Ob/was man da braucht, kann ich nicht sagen. Mein Eindruck ist, dass das mit den templates zwischenzeitlich nicht mehr die ganz großen Fragezeichen hervorruft. Grade bei MQTT, wo praktisch alles an Konfiguration irgendwie in den Attributen steckt, wird das nach meinem Eindruck gerne angenommen. Interessant ist es uU. auch, wenn man nur einmalig eine Reihe von Befehlen zur Konfiguration des Geräts benötigt. Ob man es für ESPEasy benötigt bzw. ob oder wie es hilfreich ist, kann ich nicht sagen, das mögen die User entscheiden.

Mal anknüpfend an die Aufforderung @all mal noch ein paar Gedanken zum Ganzen:
Es wurde in der Vergangenheit ganz im Allgemeinen (nicht unbedingt bezogen auf ein spezielles Modul, aber die tasmota-MQTT-Geschichten sind da ein gutes Beispiel) oft voneinander abgeschrieben, aber nicht immer wurde der eigentlich beste Weg (so es denn einen gibt) gewählt, sondern der, der "irgendwo" -aus welchen Gründen auch immer - propagiert wurde/bekannt war.

Mit den attrTemplates hat man einen "Ort", um vieles zu diskutieren und ggf. auch gute Varianten zentral bereitzustellen, die man dann "live" ausprobieren kann (man muß deswegen ja nicht alles gut finden). Da man es innerhalb jeder FHEM-Installation recht direkt findet, ist auch die Doku/Fundstelle nicht irgendwo auf S. 20 irgendeines Mega-Threads vergraben, sondern man hat direkten Zugriff auf "geronnene Erfahrung".
Mir kommt das positiv vor, aber darüber kann man natürlich streiten, und wie jede Doku will es gepflegt werden, wenn sich tote Links usw. ergeben (oder neue Möglichkeiten, wie neulich mit den mehreren devStateIcons ).

Das mit dem "model" wäre nur ein zusätzlich erlaubtes Attribut, ist also nicht aufwändig zu implementieren; aber wozu es sein soll, bestimmt der Modulautor .

Gerne setze ich mir ein Lesezeichen, wenn es denn dann "live" geht und/oder diskutiere hier mit, wenn Fragen dazu sind, ob/wie man evtl. manches im template lösen kann.

Danke jedenfalls für die Rückmeldung!

[duke-f]

Im Moment stelle ich mich wohl gerade etwas blöd an: Ich hatte die Templates doch vor einigen Wochen mal testhalber erfolgreich aktiviert, konnte nur erst mal nicht wirklich was damit anfangen. Durch Eure Diskussion animiert habe ich das jetzt am WE nochmal versucht. Und siehe da: Ich bekomme es nicht mehr hin.

Die Datei ist im richtigen Verzeichnis, habe ich kontrolliert,
die Aktivierung durch das Attribut useSetExtensions habe ich beim betreffenden ESP-Device gesetzt,
trotzdem erscheint der Set-Befehl nicht.

Hat einer einen Tipp? Bin jetzt aber wieder im Büro und kann nicht ganz spontan testen.

[Beta-User]

Wenn die akutallisierte Datei mit den richtigen Rechten vorhanden ist:
FHEM neu gestartet oder die templates neu geladen mit "{ AttrTemplate_Initialize() }"?

[duke-f]

Ich hatte schon FHEM komplett neu gestartet, und da es schon mal lief bin ich davon ausgegangen, die Rechte sind richtig. Nun gut, werde das heute abend - so dann die Zeit vorhanden ist - nochmal prüfen.
Danke.