ESPEasy und externe GPIO Module

Begonnen von clumsy, 30 Juli 2018, 16:27:16

Vorheriges Thema - Nächstes Thema

clumsy

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

dev0

ZitatDies 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.

dev0

ZitatWenn 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?

clumsy

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...

dev0

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.

clumsy

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...

dev0

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.

clumsy

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..

dev0

Zitat von: clumsy am 02 August 2018, 12:39:57
aber dann werden ja deine änderungen auch in meinem diff sein wenn ichs gegenüber der aktuellsten version diffe?
Einen Tod muss mun sterben :)

clumsy

Zitat von: dev0 am 02 August 2018, 13:10:38
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....


clumsy

Zitat von: dev0 am 02 August 2018, 07:46:05
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...)

clumsy

Hallo
Zitat von: dev0 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.

@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

dev0

Zitat von: clumsy am 20 August 2018, 11:29:02
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

clumsy

Zitat von: dev0 am 21 August 2018, 12:32:25
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...

dev0

Zitatwäre cool wenn du kurz hier schrieben würdest wenns die neue version gibt
Die neue Version ist eingecheckt, ab morgen früh 8:00 via Update verfügar oder jetzt schon im svn.

clumsy

Hallo
Zitat von: dev0 am 22 September 2018, 14:12:35
Die neue Version ist eingecheckt, ab morgen früh 8:00 via Update verfügar oder jetzt schon im svn.

Super, danke!

Soeben wurde auch noch mein PR von SENSOR_TYPE_SINGLE zu SENSOR_TYPE_SWITCH bei den PCF und MCP GPIO Boards in den mega-branch von ESPEasy übernommen. Sollte also ab sofort auch bei allen funktionieren!

dev0

@clumsy, @all:

Ich denke gerade darüber nach, das jetzt schon 2-stufige ESPEasy FHEM Modul dahin gehend zu erweitern, dass man für jedes ESP Easy Plugin ein eigenes logisches Device Modul Modul definieren/schreiben kann. Einen Prototypen für ein solches Modul würde ich zur Verfügung stellen. Man könnte dann zB. auch graphisch in FHEMWEB die Zustände von Ports etc darstellen oder pfiffigen Anwendern die Möglichkeiten geben, Dinge zu implementieren, die ich nicht in das allgemeine ESPEasy Modul integrieren möchte...

Dazu wäre es nötig, dass das "ESP Easy FHEM HTTP" Controller Plugin (_C009.ino) die PLUGIN_ID an FHEM, zu den entsprechenden Werten, überträgt.

Hast Du/jemand eine Idee welche Variable man benutzen muss (genaue Syntax), die man in der _C009.ino verwenden muss, um auf den DeviceVector Device.Number zugreifen zu können?

clumsy

Hallo

Könnte ich dir so direkt auch nicht beantworten, musste ich erst mal nachsehen! Mach ich aber gerne (bin nur grad etwas beschäftigt damit das layer 2 problem zu analysieren / lösen)....

Evtl. versteh ich dich falsch, aber das ist doch bereits jetzt so, indem man für jedes Plugin einfach einen eigenen Task-Namen vergibt? Man kann ja pro Task eigentlich "nur" ein Plugin verwenden, dann wirds durch den Task-Namen spezifiziert. Für die Zustände eines einzelnen Ports, kann ich ja jeweils einen Task definieren welcher den entsprechenden Port überwacht?

Für die einzelnen Werte innerhalb eines Tasks muss man halt Proxy-devices machen...

dev0

Ich benötige die eindeutige Kennung/ID um unterscheiden zu können von welchem Plugin (zB. '9' -> MCP2307, '19' -> PC8574) die Daten gesendet wurden. Wenn die Daten bspw. von einem RGB Plugin stammen, dann könnte man beim Autocreate entweder das logische Device mit passenden Attributen bzw. FHEM Widgets vorbelegen oder eben sogar ein eigenständiges logisches Modul laden und verwenden. Damit diese Zuordnung eindeutig ist würde ich die Nummer des Plugins verwenden wollen.