Autor Thema: ESPEasy und externe GPIO Module  (Gelesen 442 mal)

Offline clumsy

  • Jr. Member
  • **
  • Beiträge: 82
ESPEasy und externe GPIO Module
« am: 30 Juli 2018, 16:27:16 »
Hallo

Bisher unterstützt ESPEasy via pollGPIOs die internen GPIO's des ESP8266 via "status,gpio<PIN>". Ich verwende meist jedoch externe via I2C angebundene GPIO Module (z.b. PCF's). Deshalb mein Vorschlag für eine Mögliche Erweiterung des ESPEasy Moduls für externe GPIO Module (z.B. "status,pcf,<PIN>). Evtl. verwenden das ja auch andere...

EDIT: @dev0 was mir auch noch aufgefallen ist, ist dass wenn viele GPIO's abgefragt werden kriegt die Node jenachdem irgendwann ein Problem und kommt in ein undefinierten Zustand. Dies passiert wenn die Abfragen (HTTP-Requests) zu schnell hintereinander gesendet werden... Passiert aber wohl nur bei vielen externen GPIO's... Ich denke man könnte hier einfach ein delay ca. 100ms einbauen... (see also: https://github.com/letscontrolit/ESPEasy/pull/1618)

Grüsse aus der grad übermässig heissen Schweiz!

STefan
« Letzte Änderung: 31 Juli 2018, 10:24:42 von clumsy »

Offline dev0

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3361
    • _.:|:._
Antw:ESPEasy und externe GPIO Module
« Antwort #1 am: 02 August 2018, 07:46:05 »
Zitat
Dies passiert wenn die Abfragen (HTTP-Requests) zu schnell hintereinander gesendet werden...
Vmtl. wirst Du das "Überrennen" des ESPs auch mit dem Bridge Attribut maxHttpSessions in den Griff bekommen. Die Befehle werden ge-queued und nacheinander geschickt. Wenn Du das Attribut auf 1 setzt, dann wird die nächste Verbindung erst aufgebaut, wenn die vorgehende beendet wurde.

Damit wären wir aber auch schon beim Thema Polling. Aus meiner Sicht sollte man auf Polling verzichten wenn es möglich ist, in dem ESP Easy die Daten selbständig schickt. Wenn man simple GPIOs schaltet ist das mittlerweile auch überflüssig, wenn man einen "Switch Input" für den Pin definiert. Dann werden die Werte auf Wunsch hin perodisch und bei jeder Änderung über die in ESP Easy definierten Controller verschickt. Ein Pollen ist damit nicht mehr notwendig.

Wenn das PCF Plugin die Zustände nicht selbst verschickt, wäre es dann nicht sinnvoller das Plugin um die Funktion zu erweitern statt mit Polling zu hantieren?
Das Handling der JSON Rückmeldung vom 'status' Befehl im ESPEasy Modul ist mir ein Dorn im Auge (und vmtl. auch nicht zu Ende gedacht), da dieses JSON mWn auch nicht klar definiert ist.

@clumsy: Siehst Du das auch so und wenn, würdest Du bei den ESP Easy Leuten nachfragen ob das möglich ist oder vielleicht sogar selbst die Erweiterung in die Hand nehmen?

In dem Zusammenhang würde mich auch interessieren, ob es noch Anwender gibt, die das Polling der GPIO Zustände nutzen (Attribut pollGPIOs) und wenn wozu genau.

Offline dev0

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3361
    • _.:|:._
Antw:ESPEasy und externe GPIO Module
« Antwort #2 am: 02 August 2018, 08:09:21 »
Zitat
Wenn das PCF Plugin die Zustände nicht selbst verschickt
Wie wird denn der Zustand gemeldet, wenn man MQTT verwendet. Da gibt es auch kein Polling, oder?

Offline clumsy

  • Jr. Member
  • **
  • Beiträge: 82
Antw:ESPEasy und externe GPIO Module
« Antwort #3 am: 02 August 2018, 08:22:05 »
Hallo

Ich hab MQTT noch nie verwendet, kanns nicht sagen.

Meines Wissens versendet das PCF Plugin nicht "automatisch" die Zustände sondern muss eben mit "status,pcf,<PIN>" gepollt werden. Es wird zwar im 100ms Abstand geprüft und ein Event ausgelöst, jedoch natürlich nur dann an den Controller gesendet, wenn dazu auch ein Task definiert ist.

Genau da kommt auch das eigentlich "Problem" resp. weshalb eben ein Polling praktisch ist. Da (standardmässig) "nur" 12 Tasks definiert werden können ist man mit GPIO Extendern relativ rasch am Anschlag, wenn man für jeden GPIO den man überwachen möchte ein Task definieren muss! Insbesondere da bisher Statuswechsel nciht aktiv gemeldet werden, erhält man die Rückmeldung nur bei einem Sttatuswechsel oder in (relativ) grossen Abständen...

Die Entwickler sind jedoch dran (und ich versuche zu helfen) die GPIO Geschichte anzusehen und irgendwann neu abzuhandeln (internes Polling, resp. interrupt und Register basiert, s. https://github.com/letscontrolit/ESPEasy/issues/1620. Das dürfte jedoch noch etwas dauern. Es gibt da verschiedene Lösungsvorschläge dazu. Z.b. könnte man alle Zustände eines PCF's in einem Byte zurückgeben, dann bräuchts nur ein Task pro PCF... Das würde aber die ganze Definition über den haufen werfen.. Mal sehen was da rauskommt...

Offline dev0

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3361
    • _.:|:._
Antw:ESPEasy und externe GPIO Module
« Antwort #4 am: 02 August 2018, 10:14:04 »
Dann lass uns doch so verbleiben, dass wir das pcf Polling erst einmal einbauen und und Du dran bleibst, dass das zukünftig im Plugin oder generell in ESP Easy erweitert wird. Bytes zu schicken ist ein guter Ansatz, der mir auch gestern abend unabhängig davon durch den Kopf gegangen ist.

Magst Du diesen Patch und den Patch für das Invertieren der Zustände, incl. command reference, getrennt voneinander hier anhängen? Die beiden Patches bitte jeweils als svn diff gegen die offizielle SVN Version erstellen.

Btw: hilft das serielle senden der HTTP Requests Dir ersteinmal weiter oder hat das nichts gebracht? Wenn ich den ESP Easy Code richtig verstanden habe, dann sollte das so sein.

Offline clumsy

  • Jr. Member
  • **
  • Beiträge: 82
Antw:ESPEasy und externe GPIO Module
« Antwort #5 am: 02 August 2018, 10:25:16 »
Ok, passt so für mich, bez. dem ESPEasy GPIO's bin ich ja eh auch mit dran..

Bez. des Patches: einerseits kenn ich mich so gut wie gar nicht aus mit SVN (da ich ausschliesslich GIT verwende) und da ich die updates immer aus dem fhem gemacht hab ists bei mir lokal nicht im SVN, anderseits kann halt so der "normale" User die Änderungen nicht mittesten, solange du keine neue Version bereitstellst. Command reference hab ich natürlich (im Modul) upgedated.

Aber ich werd mich dem mal annehmen und versuchen patches zu machen, aber beide in einem wenn das OK ist, sonst muss ich ja die änderungen wieder selektiv rückgängig machen... Wäre das ok?

Bez. den HTTP Requests schau ich noch, ich hab vorerst mal das polling abgeschalten, da ich den letzten PR im ESPEasy ein wenig auf stabilität und kompatibilität am testen bin...

Offline dev0

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3361
    • _.:|:._
Antw:ESPEasy und externe GPIO Module
« Antwort #6 am: 02 August 2018, 12:31:05 »
Dann warte bitte mit dem all-in-one Patch bis ich die nächste Version eingecheckt habe, dann kann ich ihn zur Not ggf. wieder komplett wieder entfernen, wenn es ein Problem damit geben sollte.

Offline clumsy

  • Jr. Member
  • **
  • Beiträge: 82
Antw:ESPEasy und externe GPIO Module
« Antwort #7 am: 02 August 2018, 12:39:57 »
hmm... ok, aber dann werden ja deine änderungen auch in meinem diff sein wenn ichs gegenüber der aktuellsten version diffe?

Aber sonst drösle ich das wieder auseinander, ist ja nicht sooo viel, eben, ca 10-20 zeilen...

ich wart mal auf den nächsten update in dem fall..

Offline dev0

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3361
    • _.:|:._
Antw:ESPEasy und externe GPIO Module
« Antwort #8 am: 02 August 2018, 13:10:38 »
aber dann werden ja deine änderungen auch in meinem diff sein wenn ichs gegenüber der aktuellsten version diffe?
Einen Tod muss mun sterben :)

Offline clumsy

  • Jr. Member
  • **
  • Beiträge: 82
Antw:ESPEasy und externe GPIO Module
« Antwort #9 am: 02 August 2018, 13:37:17 »
Einen Tod muss mun sterben :)
auch wahr  ;)

das ist der vorteil von GIT, man kann es recht gut mit verschiedenen parallellen commits lösen...(wobei das evtl auch im SVN gehen würde)...

der vorteil ist, dass beim ersten kurzen verusch die beiden änderungen auseinander zu nehmen ich auch gleich noch ein paar typos gefunden hatte... welche zwar keinen einfluss auf die funktionalität hatten aber trotzdem unschön waren...

da ich für das modul vorübergehend ein no-update gesetzt habe (damit meine änderungen bleiben), wäre cool wenn du kurz hier schrieben würdest wenns die neue version gibt, dann kann ich die einzeln ansehen und meine änderungen da drin (einzeln) verbauen... sofern bis dahin meine tastatur nicht geschmolzen ist....


Offline clumsy

  • Jr. Member
  • **
  • Beiträge: 82
Antw:ESPEasy und externe GPIO Module
« Antwort #10 am: 02 August 2018, 21:27:28 »
Vmtl. wirst Du das "Überrennen" des ESPs auch mit dem Bridge Attribut maxHttpSessions in den Griff bekommen. Die Befehle werden ge-queued und nacheinander geschickt. Wenn Du das Attribut auf 1 setzt, dann wird die nächste Verbindung erst aufgebaut, wenn die vorgehende beendet wurde.
kleiner update: das setzen des maxHttpSessions auf 1 in der bridge hat incht geholfen. der esp hat nach ca. 2Std. aufgegeben... (soferns deshalb war... da er aber vor dem setzen der pollGPIOs attribut schon 10Std. up war nehm ich an es ist deswegen...)

Offline clumsy

  • Jr. Member
  • **
  • Beiträge: 82
Antw:ESPEasy und externe GPIO Module
« Antwort #11 am: 20 August 2018, 11:29:02 »
Hallo
Dann warte bitte mit dem all-in-one Patch bis ich die nächste Version eingecheckt habe, dann kann ich ihn zur Not ggf. wieder komplett wieder entfernen, wenn es ein Problem damit geben sollte.

@dev0: Etwas das mir (sowohl in der alten wie auch der RC4 Version) aufgefallen ist, ist dass der Check für das readingsSwitchText lediglich auf den Typ 10 gemapped wird ($vType). Der PCF hat jedoch Typ 1, somit werden die Redings nie zu on/off gemapped. Evlt. kannst du dir das mal noch ansehen?

beste grüsse

STefan

Offline dev0

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3361
    • _.:|:._
Antw:ESPEasy und externe GPIO Module
« Antwort #12 am: 21 August 2018, 12:32:25 »
Etwas das mir (sowohl in der alten wie auch der RC4 Version) aufgefallen ist, ist dass der Check für das readingsSwitchText lediglich auf den Typ 10 gemapped wird ($vType). Der PCF hat jedoch Typ 1, somit werden die Redings nie zu on/off gemapped. Evlt. kannst du dir das mal noch ansehen?

Wenn ich den ESP Easy Quellcode (Firmware) richtig verstehe, dann sollte ein ESP Easy Device, dass 0/1 Zustände liefert, den Type "Switch" haben, wenn nicht, dann kann "irgendetwas" geliefert werden. Von daher empfinde ich das Verhalten des ESPEasy Modul als korrekt. Das Attribut 'readingSwitchText' ermöglicht bisher die Abschltung der "Übersetzung" nach on/off, bzw. das inverse Verhalten (auf Deinen Wunsch hin).

Meinst Du nicht, dass es sinvoller wäre das PCF Plugin dann anzupassen?

#define SENSOR_TYPE_NONE                    0
#define SENSOR_TYPE_SINGLE                  1
#define SENSOR_TYPE_TEMP_HUM                2
#define SENSOR_TYPE_TEMP_BARO               3
#define SENSOR_TYPE_TEMP_HUM_BARO           4
#define SENSOR_TYPE_DUAL                    5
#define SENSOR_TYPE_TRIPLE                  6
#define SENSOR_TYPE_QUAD                    7
#define SENSOR_TYPE_TEMP_EMPTY_BARO         8
#define SENSOR_TYPE_SWITCH                 10
#define SENSOR_TYPE_DIMMER                 11
#define SENSOR_TYPE_LONG                   20
#define SENSOR_TYPE_WIND                   21

Offline clumsy

  • Jr. Member
  • **
  • Beiträge: 82
Antw:ESPEasy und externe GPIO Module
« Antwort #13 am: 21 August 2018, 12:53:53 »
Meinst Du nicht, dass es sinvoller wäre das PCF Plugin dann anzupassen?

Klar! Macht Sinn... soweit hab ich nicht gedacht... ich schau mir das an... sind ja eben eh dran das modul evtl. anzupassen...