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?
Ankündigung
Einklappen
Keine Ankündigung bisher.
Support Thread für das GPIO Plugin
Einklappen
X
-
Zitat von Hasenradball Beitrag anzeigenkannst 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:
Code:%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:
Code: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
Kommentar
-
Zitat von Onkelandy Beitrag anzeigenAuf 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?
Theoretisch wären beide Ideen möglich.
😉
Kommentar
-
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.
Grüße
Kommentar
-
@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!
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 😀Zuletzt geändert von Hasenradball; 13.04.2023, 14:32.
Kommentar
-
Zitat von Onkelandy Beitrag anzeigenWelche library bräuchtest du denn? würde keine python module mit ins Plugin nehmen.
https://github.com/milaq/rpi-rf/pull/71Zuletzt geändert von Hasenradball; 16.04.2023, 12:44.
Kommentar
-
Onkelandy
Deine Antwort zuCode:#20
Wegen dem Problem beim Lesen.Zuletzt geändert von Hasenradball; 16.04.2023, 12:46.
Kommentar
-
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.
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):
Code:%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
Das GPIO-Plugin ist so konfiguriert:
Unbenannt.jpg
Die plugin.yaml hat noch folgende Inhalte:
Code:GPIO: plugin_name: gpio pullupdown: DOWN MQTT: plugin_name: mqtt
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
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
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
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)
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ß TorstenZuletzt geändert von tsb2001; 29.10.2023, 15:07.
Kommentar
-
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..
Kommentar
Kommentar