Support Thread für das GPIO Plugin

[Onkelandy]

Auf den Mode hätte ich jetzt auch getippt. Hasenradball möchtest nicht noch die Option, den Mode einzustellen, einbauen in deinem Plugin? Oder macht das keinen Sinn? Wäre es theoretisch auch möglich, beide Plugins zusammenzulegen?

[dafra]

kannst Du das GPIO Plugin mal auf BCM



stellen und testen?

Vielen Dank, Problem gelöst :-)

Für alle anderen, noch einmal zum Nachvollziehen:

plugin.yaml:

%YAML 1.1
---
database:
    plugin_name: database
    driver: sqlite3
    connect:
    -   database:./var/db/smarthomeng.db
    -   check_same_thread:0
GPIO:
    plugin_name: gpio
    plugin_enabled: true
    mode: bcm
rcs1000:
   plugin_name: rcs1000n
   rcs1000n_gpio: '17'
   rcs1000n_sendDuration: '0.1'​

items.yaml:

Schaltsteckdose1:
        schalten:
            type: bool
            rcs_SystemCode: 11010
            rcs_ButtonCode: 'A'
Relais1:
        name: Relais1
        schalten:
            type: bool
            gpio_out: 5
Relais2:
        name: Relais2
        schalten:
            type: bool
            gpio_out: 6

Vielleicht kann man das in der Doku noch ergänzen bzw. im Logger eine Warning ausgeben, wenn ein Plugin beim Init feststellt, dass die GPIOs bereits in einem anderen Modus betrieben werden.

[Hasenradball]

Auf den Mode hätte ich jetzt auch getippt. Hasenradball möchtest nicht noch die Option, den Mode einzustellen, einbauen in deinem Plugin? Oder macht das keinen Sinn? Wäre es theoretisch auch möglich, beide Plugins zusammenzulegen?

Lass mich mal drüber schlafen.
Theoretisch wären beide Ideen möglich.
😉

[Hasenradball]

Onkelandy,

Hi ich habe mir mal ein paar gedanken gemacht.

a) zum rcs1000n:

• aktuell sehe ich nicht unbedingt den Vorteil den "mode" (BCM oder BOARD) einzustellen. Funktional bleibt beides gleich nur es muss eine andere Nummer eingetragen werden. Wäre es nicht sogar gut nman einigt sich im SHNG Umfeld auf eine Referenz (BCM oder BOARD).
• Momentan sehe ich es von Vorteil die Plugins in kleine funktionale Einheiten zu kapseln daher würde ich es nach heutigem Stand erstmal so belassen und das rcs1000n nicht mit dem GPIO Plgn zusammenführen.

b) zum GPIO Plugin:

• aktuell entsteht der Fehler ja dadurch, dass das GPIO Plugin eine dauerhafte Instanz im Konstruktor erzeugt und dabei den Mode festlegt. Braucht es denn eine dauerhafte Instanz des Plugins? Ich bin der Meinung braucht es nicht.
  Beim rcs1000n wird die Instanz des Rdevice bzw. des RPI.GPIO plugin erst erzeugt, wenn gesendet (also der GPIO benutzt) wird. Nach dem Gebrauch wird die Instanz der wieder zerstört. Also die Instanz wird während der Update_item Funktion erstellt.
  Wäre das beim GPIO Plugin nicht auch möglich. Dann wäre es nämlich egal welches Plugin welchen mode nutzt.

So mal aktuell zu meinen Gedanken ich ich so hatte.

Grüße

[Onkelandy]

Aber wie ist es beim Lesen? Mit gpio_in ist das Problem wieder da.

ich würde dann einfach mal in der Doku zu gpio aufnehmen dass auf bcm gestellt werden sollte, falls es Probleme gibt

[Hasenradball]

Onkelandy, wie meinst Du beim lesen?
vielleicht habe ich es noch nicht ganz durchdrungen…

[Hasenradball]

@Onkelandy
Ich würde die folgende Fehlermeldung noch mal etwas klarer machen…

2023-04-08 19:55:15 ERROR root Error: during instantiation of object: A different mode has already been set!

Wie war noch mal die Methode den Instanznamen zu holen?

Oder noch mal Gegenfrage siehst Du nenVorteil durch Umstellen auf nen anderen Mode?

Oder mal andersrum gedacht, angenommen es gäbe x Plugins die RPI.GPIO nutzen. Dann müsste man aktuell x Plugins händisch abgleichen… Find ich bissle doof.
Wie wäre es man generiert eine shng globale Variable die für die RPI.GPIO lib den mode definiert.
Damit wird dann im Plugin.yaml file der mode für das jeweilige Plugin gesetzt.
=> Damit bräuchte man wieder eine Möglichkeit den Mode zu setzen. Werde es einbauen 😀

[Hasenradball]

Onkelandy
Um den GPIO.mode vorzugeben muss ich die dependend lib ändern.
Oder würdest Du dann lieber die dependend library direkt in shng plugin rein hängen.
Dann wäre das plugin quasi 100% self contained.

[Onkelandy]

Welche library bräuchtest du denn? würde keine python module mit ins Plugin nehmen.

[Hasenradball]

Welche library bräuchtest du denn? würde keine python module mit ins Plugin nehmen.

Ich bräuchte die rpi-rf lib.
https://github.com/milaq/rpi-rf/pull/71

[Hasenradball]

Onkelandy
Deine Antwort zu

#20

habe ich noch nicht ganz verstanden.
Wegen dem Problem beim Lesen.

[Onkelandy]

Man kann die GPIOs ja auch als Input Pins nutzen.. Also muss man dort dauerhaft "lauschen". Ein Beenden der Verbindung macht somit keinen Sinn.

[Hasenradball]

Dann wirds schwierig da gebe ich dir recht.
Ich guck mal wie schnell der PR in der lib durchgeht.
Was hällst Du von dem Vorschlag mit dem globalen „mode“ Parameter.

[tsb2001]

Hallo zusammen,

ich bin auf das Thema hier (https://knx-user-forum.de/forum/supp...05#post1646605) gestoßen, weil mich das grade selbst umtreibt. Eine Lösung konnte ich bisher nicht finden

Was bisher geschah...
...bis gestern hatte ich in der Doppelgarage nur einen Garagentorantrieb, den ich bisher über 2 SmarthomeNG mittels MQTT gekoppelt habe. Das läuft seit 5 Jahren stabil. Das linke Garagentor hatte bereits einen Antrieb, das rechte Tor ist jetzt gefolgt.
Ausführung:

• 1xSmarthomeNG auf QNAP Virtualisation Station (im Haus)
• der zweite läuft auf einem Raspberry 3 in der Garage und hat ein "Automation Hat" mit 3 digitalen Ausgängen (Relais) und 3 digitalen Eingängen (bis 24V maximal, ich nutze allerdings für die Torzustandsanzeige nur die 5V, die über das Relais des Toröffners geschaltet werden. Die minimale Abfragespannnung beträgt 3,3V, wird über einen 20kOhm-Widerstand und eine Zenerdiode mit 3,3V begrenzt. Die untere Schaltschwelle liegt bei 1,7V, d.h. alles was darunter liegt, wird als 0 gewertet.

Nun gab es Zuwachs; ein weiterer Antrieb hielt für Tor 2 Einzug in die Garage.
Auch dieser hat das Relais zur Torzustandsanzeige an Bord, folglich bekam dieser die exakt gleiche Beschaltung, lediglich auf Relaiskanal 2 und auf dem Eingangskanal 2 des Automation-Hat.

Was ich getan habe:
Ich erwartete also auf dem digitalen Eingang die Nachricht über MQTT "Garage_rechts_zu". der kommt aber nicht...
Am Bord selbst wechselt der Pegel ganz sauber von 5V zu 0V - regelmäßig, wenn sich der Torzustand ändert. Zwischendrin habe ich ihm auch mal die Hilfspannung aus dem Antrieb mit 24V/0V gegeben, aber das ist genau so unzuverlässig.
Das Tor öffnet jedoch einwandfrei, beide Relais werden ordnungsgemäß angesteuert.

Die Konfiguration hatte ich einfach verdoppelt und sieht so aus (HINWEIS: DA STEHT JETZT PIN 40, WAS DEM KANAL 3 ENTSPRICHT, das war ein Test, ob 2 nicht defekt ist):

%YAML 1.1
---
Garage:
    links:
        Taster:
            type: bool
            mqtt_topic_in: Garage_links_Taster
            autotimer: 2 = false
            gpio_out: '33'
        zu:
            type: bool
            gpio_in: '37'
            mqtt_topic_out: Garage_links_zu
    rechts:
        Taster:
            type: bool
            mqtt_topic_in: Garage_rechts_Taster
            autotimer: 2 = false
            gpio_out: '35'
        zu:
            type: bool
            gpio_in: '40'
            mqtt_topic_out: Garage_rechts_zu​

Eine weitere ITEM-Konfig gibt es nicht, da das Ding absolut nichts anderes macht, als den Torzustand abzufragen und den Befehl zum Öffnen zu geben (Relais brückt den Tastereingang vom Antrieb)

Das GPIO-Plugin ist so konfiguriert:
Unbenannt.jpg
Die plugin.yaml hat noch folgende Inhalte:

GPIO:
    plugin_name: gpio
    pullupdown: DOWN

MQTT:
    plugin_name: mqtt

Das war es auch schon.
Dann habe ich das Logging auf Debug gestellt und mal geschaut, was im GPIO-PLUGIN so alles passiert.

Hier mal der Neustart ohne Auffälligkeiten von den beiden Seiten:

2023-10-29 13:27:34 DEBUG plugins.gpio Mode set to BOARD, bouncetime is 300, global pulldown enabled
2023-10-29 13:27:34 DEBUG plugins.gpio Pin None, inverted: False, value:0
2023-10-29 13:27:34 DEBUG plugins.gpio Garage.links.Taster (output on pin 33) reads initial value 0
2023-10-29 13:27:34 DEBUG plugins.gpio Garage.links.Taster assigned to output on pin 33
2023-10-29 13:27:34 DEBUG plugins.mqtt (parsing result): item.conf '{'mqtt_topic_in': 'Garage_links_Taster', 'gpio_out': 33}'
2023-10-29 13:27:34 DEBUG plugins.gpio Garage.links.zu assigned to input on pin 37, global pulldown enabled
2023-10-29 13:27:34 DEBUG plugins.mqtt (parsing result): item.conf '{'gpio_in': 37, 'mqtt_topic_out': 'Garage_links_zu'}'
2023-10-29 13:27:34 DEBUG plugins.gpio Pin None, inverted: False, value:0
2023-10-29 13:27:34 DEBUG plugins.gpio Garage.rechts.Taster (output on pin 35) reads initial value 0
2023-10-29 13:27:34 DEBUG plugins.gpio Garage.rechts.Taster assigned to output on pin 35
2023-10-29 13:27:34 DEBUG plugins.mqtt (parsing result): item.conf '{'mqtt_topic_in': 'Garage_rechts_Taster', 'gpio_out': 35}'
2023-10-29 13:27:34 DEBUG plugins.gpio Garage.rechts.zu assigned to input on pin 40, global pulldown enabled
2023-10-29 13:27:34 DEBUG plugins.mqtt (parsing result): item.conf '{'gpio_in': 40, 'mqtt_topic_out': 'Garage_rechts_zu'}'
2023-10-29 13:27:34 DEBUG plugins.gpio run method called

Erst habe ich das rechte Garagentor mit dem NEUEN ANTRIEB getestet (also der, der keine Rückmeldung bringt):
Ablauf: Tor war geschlossen , Taster innen betätigt --> Tor fährt auf bis Endschalter --> kurze Wartezeit --> Taster innen erneut betätigt --> Tor fährt zu bis Endabschaltung

2023-10-29 13:31:36 DEBUG plugins.gpio Garage.links.Taster updated by Autotimer.
2023-10-29 13:31:36 DEBUG plugins.gpio Pin None, inverted: False, value:False
2023-10-29 13:31:36 INFO plugins.gpio Setting pin 33 to False for Garage.links.Taster
2023-10-29 13:31:36 DEBUG plugins.gpio Pin 33 successfully set to False
2023-10-29 13:32:41 INFO plugins.gpio Read pin 40 with value 0 after event_detection
2023-10-29 13:32:49 DEBUG plugins.gpio Garage.links.Taster updated by mqtt.
2023-10-29 13:32:49 DEBUG plugins.gpio Pin None, inverted: False, value:True
2023-10-29 13:32:49 INFO plugins.gpio Setting pin 33 to True for Garage.links.Taster
2023-10-29 13:32:49 DEBUG plugins.gpio Pin 33 successfully set to True
2023-10-29 13:32:52 DEBUG plugins.gpio Garage.links.Taster updated by Autotimer.
2023-10-29 13:32:52 DEBUG plugins.gpio Pin None, inverted: False, value:False
2023-10-29 13:32:52 INFO plugins.gpio Setting pin 33 to False for Garage.links.Taster
2023-10-29 13:32:52 DEBUG plugins.gpio Pin 33 successfully set to False

Dann folgte der alte Antrieb der immer noch funktioniert
Der Ablauf erfolgte analog zu oben:

2023-10-29 13:28:32 DEBUG plugins.gpio Garage.rechts.Taster updated by mqtt.
2023-10-29 13:28:32 DEBUG plugins.gpio Pin None, inverted: False, value:True
2023-10-29 13:28:32 INFO plugins.gpio Setting pin 35 to True for Garage.rechts.Taster
2023-10-29 13:28:32 DEBUG plugins.gpio Pin 35 successfully set to True
2023-10-29 13:28:34 INFO plugins.gpio Read pin 40 with value 0 after event_detection
2023-10-29 13:28:34 DEBUG plugins.gpio Garage.rechts.Taster updated by Autotimer.
2023-10-29 13:28:34 DEBUG plugins.gpio Pin None, inverted: False, value:False
2023-10-29 13:28:34 INFO plugins.gpio Setting pin 35 to False for Garage.rechts.Taster
2023-10-29 13:28:34 DEBUG plugins.gpio Pin 35 successfully set to False
2023-10-29 13:28:53 DEBUG plugins.gpio Garage.rechts.Taster updated by mqtt.
2023-10-29 13:28:53 DEBUG plugins.gpio Pin None, inverted: False, value:True
2023-10-29 13:28:53 INFO plugins.gpio Setting pin 35 to True for Garage.rechts.Taster
2023-10-29 13:28:53 DEBUG plugins.gpio Pin 35 successfully set to True
2023-10-29 13:28:55 DEBUG plugins.gpio Garage.rechts.Taster updated by Autotimer.
2023-10-29 13:28:55 DEBUG plugins.gpio Pin None, inverted: False, value:False
2023-10-29 13:28:55 INFO plugins.gpio Setting pin 35 to False for Garage.rechts.Taster
2023-10-29 13:28:55 DEBUG plugins.gpio Pin 35 successfully set to False
2023-10-29 13:29:13 INFO plugins.gpio Read pin 40 with value 0 after event_detection

Das fettgedruckte ist der Unterschied in den beiden Ausgaben des Logs.
Er erhält bei beiden seine 5 Volt, sobald das Tor den Zustand "geschlossen" verlässt, setzt auf Kanal 1 immer den richtigen Zustand mit "True", bei Kanal 2 (oder 3) jedoch permanent "False"


Auch wenn ich von Außen das Tor mit der Fernbedienung öffne, sieht er ein Event und triggert auch danach (sieht man auch in den Items - die Zeit seit dem letzten UPDATE setzt sich zurück, die Zeit seit dem letzten CHANGE läuft immer weiter - klar, es ändert sich ja auch nichts):

2023-10-29 13:46:20 INFO plugins.gpio Read pin 37 with value 1 after event_detection (Tor links mit Handsender geöffnet - funktioniert)
2023-10-29 13:48:31 INFO plugins.gpio Read pin 37 with value 0 after event_detection (Tor links mit Handsender geschlossen - funktioniert
2023-10-29 13:51:03 INFO plugins.gpio Read pin 40 with value 0 after event_detection (Tor rechts mit Handsender geöffnet - funktioniert nicht)
2023-10-29 13:51:51 INFO plugins.gpio Read pin 40 with value 0 after event_detection (Tor rechts mit Handsender geschlossen - funktioniert nicht)

Was kann das sein???
Meine Beobachtung: auf Kanal 2 oder 3 der digitalen Eingange ist der Pegel "false", wird aber "successfully set to false"...
Folglich: er reagiert auf jede Pegeländerung an jedem Eingang, gibt aber dauernd für Eingang 2 und 3 ein "False" aus.

PS: alles habe ich vorher auf den aktuellen Stand gebracht - die Plugins, SmarthomeNG selbst...

Danke für eure Mühe!

Gruß Torsten

[Onkelandy]

Auf die Schnelle hätte ich gesagt, stimmt bei deiner Loganalyse etwas nicht. Im oberen Fall hast du den Eintrag nach dem Autotimer hevorgehoben statt nach mqtt

2023-10-29 13:32:49 INFO plugins.gpio Setting pin 33 to True for Garage.links.Taster
2023-10-29 13:32:49 DEBUG plugins.gpio Pin 33 successfully set to True

Aber dein eigentliches Problem ist ja eh Pin 40, oder? Da fällt mir leider tatsächlich nicht viel ein dazu..