NEWS
Test Adapter rpi2 2.x
-
@smallfeuer said in Test Adapter rpi2 2.x:
Das bedeutet das es wohl Grundlegend geändert wurde. Vor Bookworm war es definitiv andersrum und für mich logischer.
Das kann ich ehrlich gesagt im Code nicht nachvollziehen. Also wenn dann kommt das von der Bibliothek. Aber ich hab jetzt mal das invertieren eingebaut.
@smallfeuer said in Test Adapter rpi2 2.x:
Dieses Problem tritt auf wenn ich den Adapter, oder PI Neustarte - > er schreibt den Eingang 17 auf false und prüft ihn nicht vorher. Meiner Meinung nach müsste der State vom Eingang "schreibgeschützt" sein und müsste sich - selbst wenn er manuell geändert in kürzester Zeit zurück ändern. Normalerweise sind doch alle aktiven GPIO überwacht und wenn der Datenpunkt nicht dem GPIO entspricht muss er sofort umgeschrieben werden.
Also beim Adapter start wird der Wert aller Eingänge ausgelesen und in ioBroker entsprechend gesetzt. Wenn du oder ein Skript daran rumfummelst, passiert nichts (außer eine Fehlermeldung im Log). Da bist du mE dann aber auch etwas selber schuld, der Adapter repariert das gefummel nicht. ;-) Wenn sich der Zustand ändert, wird es wieder korrigiert.
Aber ok, ich habe eingebaut, dass er nach der Fehlermeldung den Wert nochmal ausliest.Und ich hab jetzt eingebaut, dass er auch den Wert von GPIO-Ausgängen beim starten liest. Falls das geht, sollten die ioBroker states dann abbilden, was bei den GPIOs an / aus ist. Wobei das für die GPIOs mit definiertem Startwert auch vorher schon der Fall gewesen sein sollte.
@garfonso sagte in Test Adapter rpi2 2.x:
Also beim Adapter start wird der Wert aller Eingänge ausgelesen und in ioBroker entsprechend gesetzt
Na genau das funktioniert bei mir nicht. Nach einem Neustart des Adapters geht der Eingang von True auf False obwohl das Signal weiterhin anliegt. Wenn ich den Adapter dann beende und auslese wird mir auch eine 1 angezeigt.
-
@smallfeuer said in Test Adapter rpi2 2.x:
Das bedeutet das es wohl Grundlegend geändert wurde. Vor Bookworm war es definitiv andersrum und für mich logischer.
Das kann ich ehrlich gesagt im Code nicht nachvollziehen. Also wenn dann kommt das von der Bibliothek. Aber ich hab jetzt mal das invertieren eingebaut.
@smallfeuer said in Test Adapter rpi2 2.x:
Dieses Problem tritt auf wenn ich den Adapter, oder PI Neustarte - > er schreibt den Eingang 17 auf false und prüft ihn nicht vorher. Meiner Meinung nach müsste der State vom Eingang "schreibgeschützt" sein und müsste sich - selbst wenn er manuell geändert in kürzester Zeit zurück ändern. Normalerweise sind doch alle aktiven GPIO überwacht und wenn der Datenpunkt nicht dem GPIO entspricht muss er sofort umgeschrieben werden.
Also beim Adapter start wird der Wert aller Eingänge ausgelesen und in ioBroker entsprechend gesetzt. Wenn du oder ein Skript daran rumfummelst, passiert nichts (außer eine Fehlermeldung im Log). Da bist du mE dann aber auch etwas selber schuld, der Adapter repariert das gefummel nicht. ;-) Wenn sich der Zustand ändert, wird es wieder korrigiert.
Aber ok, ich habe eingebaut, dass er nach der Fehlermeldung den Wert nochmal ausliest.Und ich hab jetzt eingebaut, dass er auch den Wert von GPIO-Ausgängen beim starten liest. Falls das geht, sollten die ioBroker states dann abbilden, was bei den GPIOs an / aus ist. Wobei das für die GPIOs mit definiertem Startwert auch vorher schon der Fall gewesen sein sollte.
@garfonso sagte in Test Adapter rpi2 2.x:
Wobei das für die GPIOs mit definiertem Startwert auch vorher schon der Fall gewesen sein sollte.
Bei definiertem Startwert braucht er sie ja nicht auslesen. Da muss er sie ja einfach nur setzen. ;)
Nur bei nicht definiertem Startwert, wäre es korrekt den Wert beizubehalten der vorher da war.
-
@smallfeuer said in Test Adapter rpi2 2.x:
Das bedeutet das es wohl Grundlegend geändert wurde. Vor Bookworm war es definitiv andersrum und für mich logischer.
Das kann ich ehrlich gesagt im Code nicht nachvollziehen. Also wenn dann kommt das von der Bibliothek. Aber ich hab jetzt mal das invertieren eingebaut.
@smallfeuer said in Test Adapter rpi2 2.x:
Dieses Problem tritt auf wenn ich den Adapter, oder PI Neustarte - > er schreibt den Eingang 17 auf false und prüft ihn nicht vorher. Meiner Meinung nach müsste der State vom Eingang "schreibgeschützt" sein und müsste sich - selbst wenn er manuell geändert in kürzester Zeit zurück ändern. Normalerweise sind doch alle aktiven GPIO überwacht und wenn der Datenpunkt nicht dem GPIO entspricht muss er sofort umgeschrieben werden.
Also beim Adapter start wird der Wert aller Eingänge ausgelesen und in ioBroker entsprechend gesetzt. Wenn du oder ein Skript daran rumfummelst, passiert nichts (außer eine Fehlermeldung im Log). Da bist du mE dann aber auch etwas selber schuld, der Adapter repariert das gefummel nicht. ;-) Wenn sich der Zustand ändert, wird es wieder korrigiert.
Aber ok, ich habe eingebaut, dass er nach der Fehlermeldung den Wert nochmal ausliest.Und ich hab jetzt eingebaut, dass er auch den Wert von GPIO-Ausgängen beim starten liest. Falls das geht, sollten die ioBroker states dann abbilden, was bei den GPIOs an / aus ist. Wobei das für die GPIOs mit definiertem Startwert auch vorher schon der Fall gewesen sein sollte.
Ich bekomm die aktuelle Github Version 2.3.2 nicht zum laufen, 2.3.1 läuft:
Grad komplett gelöscht mit allen Einstellungen und neu gezogen.
Do not restart adapter system.adapter.rpi2.0 because restart loop detected -
Ich bekomm die aktuelle Github Version 2.3.2 nicht zum laufen, 2.3.1 läuft:
Grad komplett gelöscht mit allen Einstellungen und neu gezogen.
Do not restart adapter system.adapter.rpi2.0 because restart loop detectedUnd die Meldungen im Log sehen so aus. Zumindest bei mir...
2025-02-23 11:53:08.571 - info: rpi2.0 (279931) starting. Version 2.3.2 (non-npm: iobroker-community-adapters/ioBroker.rpi2) in /opt/iobroker/node_modules/iobroker.rpi2, node: v23.7.0, js-controller: 7.0.6 2025-02-23 11:53:08.981 - error: rpi2.0 (279931) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). 2025-02-23 11:53:08.981 - error: rpi2.0 (279931) unhandled promise rejection: value.toFixed is not a function 2025-02-23 11:53:08.983 - error: rpi2.0 (279931) TypeError: value.toFixed is not a function at parser (/opt/iobroker/node_modules/iobroker.rpi2/main.js:454:58) at async main (/opt/iobroker/node_modules/iobroker.rpi2/main.js:327:9) at async Rpi2.onReady (/opt/iobroker/node_modules/iobroker.rpi2/main.js:58:9) 2025-02-23 11:53:08.984 - error: rpi2.0 (279931) value.toFixed is not a function 2025-02-23 11:53:08.990 - info: rpi2.0 (279931) terminating 2025-02-23 11:53:08.992 - warn: rpi2.0 (279931) Terminated (UNCAUGHT_EXCEPTION): Without reason 2025-02-23 11:53:09.490 - info: rpi2.0 (279931) terminating 2025-02-23 11:53:09.603 - error: host.chet instance system.adapter.rpi2.0 terminated with code 6 (UNCAUGHT_EXCEPTION) 2025-02-23 11:53:43.092 - info: rpi2.0 (279987) starting. Version 2.3.2 (non-npm: iobroker-community-adapters/ioBroker.rpi2) in /opt/iobroker/node_modules/iobroker.rpi2, node: v23.7.0, js-controller: 7.0.6 2025-02-23 11:53:43.532 - error: rpi2.0 (279987) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). 2025-02-23 11:53:43.533 - error: rpi2.0 (279987) unhandled promise rejection: value.toFixed is not a function 2025-02-23 11:53:43.535 - error: rpi2.0 (279987) TypeError: value.toFixed is not a function at parser (/opt/iobroker/node_modules/iobroker.rpi2/main.js:454:58) at async main (/opt/iobroker/node_modules/iobroker.rpi2/main.js:327:9) at async Rpi2.onReady (/opt/iobroker/node_modules/iobroker.rpi2/main.js:58:9) 2025-02-23 11:53:43.535 - error: rpi2.0 (279987) value.toFixed is not a function 2025-02-23 11:53:43.543 - info: rpi2.0 (279987) terminating 2025-02-23 11:53:43.545 - warn: rpi2.0 (279987) Terminated (UNCAUGHT_EXCEPTION): Without reason 2025-02-23 11:53:44.043 - info: rpi2.0 (279987) terminating 2025-02-23 11:53:44.160 - error: host.chet instance system.adapter.rpi2.0 terminated with code 6 (UNCAUGHT_EXCEPTION) 2025-02-23 11:53:44.161 - warn: host.chet Do not restart adapter system.adapter.rpi2.0 because restart loop detectedVersion: iobroker.rpi2@2.3.2 (git+ssh://git@github.com/iobroker-community-adapters/ioBroker.rpi2.git#c75795660b15fec21ffda74db9263f94f3e341a1)
-
Ich bekomm die aktuelle Github Version 2.3.2 nicht zum laufen, 2.3.1 läuft:
Grad komplett gelöscht mit allen Einstellungen und neu gezogen.
Do not restart adapter system.adapter.rpi2.0 because restart loop detectedAllerdings läuft die iobroker.rpi2@2.3.2 aus dem Repo.
Lass halt die Finger von GitHub-Installationen, wenn du nicht dazu aufgefordert wurdest das zu tun.
Da kann halt jeder Code-Stand angespült werden. -
Allerdings läuft die iobroker.rpi2@2.3.2 aus dem Repo.
Lass halt die Finger von GitHub-Installationen, wenn du nicht dazu aufgefordert wurdest das zu tun.
Da kann halt jeder Code-Stand angespült werden.@thomas-braun sagte in Test Adapter rpi2 2.x:
Lass halt die Finger von GitHub-Installationen, wenn du nicht dazu aufgefordert wurdest das zu tun.
Da kann halt jeder Code-Stand angespült werden.Na eigentlich wird nur der letzte Stand der in Github hochgeladen wurde installiert.
Hatte mir die Comparing changes vorher angeschaut - bin schon groß ;) -
@thomas-braun sagte in Test Adapter rpi2 2.x:
Lass halt die Finger von GitHub-Installationen, wenn du nicht dazu aufgefordert wurdest das zu tun.
Da kann halt jeder Code-Stand angespült werden.Na eigentlich wird nur der letzte Stand der in Github hochgeladen wurde installiert.
Hatte mir die Comparing changes vorher angeschaut - bin schon groß ;)@smallfeuer sagte in Test Adapter rpi2 2.x:
Na eigentlich wird nur der letzte Stand der in Github hochgeladen wurde installiert.
Richtig. Das kann aber was komplett anderes sein, als das was (mit gleicher Versionsnummer!) in den Repos landet.
-
@smallfeuer sagte in Test Adapter rpi2 2.x:
Na eigentlich wird nur der letzte Stand der in Github hochgeladen wurde installiert.
Richtig. Das kann aber was komplett anderes sein, als das was (mit gleicher Versionsnummer!) in den Repos landet.
Dieser Hinweis ist wichtig an der Stelle, daher hatte ich die Version und aus Github geschrieben. Aber korrekt und wichtig für alle da zu unterscheiden.
Ich such jetzt im Programm mal nach dem Fehler der mir beim Neustart des Adapters meinen Eingang auf false setzt, obwohl dieser definitiv true ist.
@Garfonso
Problem gefunden und hätte hier eine Lösung. Die Initialisierung geht nicht schnell genug.
Habe eine Delay Funktion nach dem GPIO watch Befehl integriert - jetzt wird der Eingang korrekt auf True gesetzt.function delay(ms) { return new Promise(resolve => setTimeout(resolve, ms)); } // Füge eine kurze Verzögerung hinzu, um sicherzustellen, dass der Pin initialisiert ist 121 this.gpioInputPorts.push(gpioSetting.gpio); // neu await delay(100); // Verzögerung von 100 Millisekunden 122 await this.readValue(gpioSetting.gpio);im DEBUG Log zeigt er mir damit aber eine lange liste true. Das "false" am Anfang kommt leider immer noch durch. Er korrigiert es jetzt aber. Kannst du beim 1. lesen des Eingangs den Inhalt verwerfen? Das liegt sicher an der Debounce Abfrage - richtig?
2025-02-23 17:43:25.161 - debug: rpi2.0 (34903) GPIO chip undefined initialized 2025-02-23 17:43:25.161 - debug: rpi2.0 (34903) Port 17 direction: in 2025-02-23 17:43:25.164 - debug: rpi2.0 (34903) Setting state for port 17 to false 2025-02-23 17:43:25.221 - silly: rpi2.0 (34903) States user redis pmessage rpi2.0.*/rpi2.0.gpio.17.state:{"val":false,"ack":true,"ts":1740329005219,"q":0,"from":"system.adapter.rpi2.0","user":"system.user.admin","lc":1740329005219} 2025-02-23 17:43:25.225 - debug: rpi2.0 (34903) Port 22 direction: outhigh 2025-02-23 17:43:25.227 - debug: rpi2.0 (34903) Adding event listener for port 17 2025-02-23 17:43:26.792 - debug: rpi2.0 (34903) GPIO change on port 17: true 2025-02-23 17:43:26.793 - debug: rpi2.0 (34903) Setting state for port 17 to true 2025-02-23 17:43:26.795 - debug: rpi2.0 (34903) GPIO change on port 17: true 2025-02-23 17:43:26.797 - debug: rpi2.0 (34903) Setting state for port 17 to true 2025-02-23 17:43:26.800 - debug: rpi2.0 (34903) GPIO change on port 17: true 2025-02-23 17:43:26.801 - debug: rpi2.0 (34903) Setting state for port 17 to true 2025-02-23 17:43:26.803 - debug: rpi2.0 (34903) GPIO change on port 17: true 2025-02-23 17:43:26.804 - debug: rpi2.0 (34903) Setting state for port 17 to true 2025-02-23 17:43:26.806 - debug: rpi2.0 (34903) GPIO change on port 17: true -
Dieser Hinweis ist wichtig an der Stelle, daher hatte ich die Version und aus Github geschrieben. Aber korrekt und wichtig für alle da zu unterscheiden.
Ich such jetzt im Programm mal nach dem Fehler der mir beim Neustart des Adapters meinen Eingang auf false setzt, obwohl dieser definitiv true ist.
@Garfonso
Problem gefunden und hätte hier eine Lösung. Die Initialisierung geht nicht schnell genug.
Habe eine Delay Funktion nach dem GPIO watch Befehl integriert - jetzt wird der Eingang korrekt auf True gesetzt.function delay(ms) { return new Promise(resolve => setTimeout(resolve, ms)); } // Füge eine kurze Verzögerung hinzu, um sicherzustellen, dass der Pin initialisiert ist 121 this.gpioInputPorts.push(gpioSetting.gpio); // neu await delay(100); // Verzögerung von 100 Millisekunden 122 await this.readValue(gpioSetting.gpio);im DEBUG Log zeigt er mir damit aber eine lange liste true. Das "false" am Anfang kommt leider immer noch durch. Er korrigiert es jetzt aber. Kannst du beim 1. lesen des Eingangs den Inhalt verwerfen? Das liegt sicher an der Debounce Abfrage - richtig?
2025-02-23 17:43:25.161 - debug: rpi2.0 (34903) GPIO chip undefined initialized 2025-02-23 17:43:25.161 - debug: rpi2.0 (34903) Port 17 direction: in 2025-02-23 17:43:25.164 - debug: rpi2.0 (34903) Setting state for port 17 to false 2025-02-23 17:43:25.221 - silly: rpi2.0 (34903) States user redis pmessage rpi2.0.*/rpi2.0.gpio.17.state:{"val":false,"ack":true,"ts":1740329005219,"q":0,"from":"system.adapter.rpi2.0","user":"system.user.admin","lc":1740329005219} 2025-02-23 17:43:25.225 - debug: rpi2.0 (34903) Port 22 direction: outhigh 2025-02-23 17:43:25.227 - debug: rpi2.0 (34903) Adding event listener for port 17 2025-02-23 17:43:26.792 - debug: rpi2.0 (34903) GPIO change on port 17: true 2025-02-23 17:43:26.793 - debug: rpi2.0 (34903) Setting state for port 17 to true 2025-02-23 17:43:26.795 - debug: rpi2.0 (34903) GPIO change on port 17: true 2025-02-23 17:43:26.797 - debug: rpi2.0 (34903) Setting state for port 17 to true 2025-02-23 17:43:26.800 - debug: rpi2.0 (34903) GPIO change on port 17: true 2025-02-23 17:43:26.801 - debug: rpi2.0 (34903) Setting state for port 17 to true 2025-02-23 17:43:26.803 - debug: rpi2.0 (34903) GPIO change on port 17: true 2025-02-23 17:43:26.804 - debug: rpi2.0 (34903) Setting state for port 17 to true 2025-02-23 17:43:26.806 - debug: rpi2.0 (34903) GPIO change on port 17: trueJetzt verstehe ich es nicht mehr. Nachdem ich alles gelöscht hatte ändert er aktuell den Status wieder automatisch von false auf true - bei 2.3.1 jedenfalls auch ohne mein Delay.
Das 1. false müsste man aber abfangen. Kein Plan was sich jetzt wieder geändert hat zwischenzeitlich :(.
-
Ich bekomm die aktuelle Github Version 2.3.2 nicht zum laufen, 2.3.1 läuft:
Grad komplett gelöscht mit allen Einstellungen und neu gezogen.
Do not restart adapter system.adapter.rpi2.0 because restart loop detectedähm.. ja.. die github Version hab ich auch noch nicht getestet. Kann sein, dass da noch fehler drin sind. Die Tests laufen ja auch nicht durch. ;-)
Bin am Freitag nur dazu gekommen neuen Code zu produzieren, ausprobieren und Fehler glatt bügeln, dafür hat die Zeit nicht mehr gereicht. Insofern, was @Thomas-Braun sagt: Bitte erstmal bei der Version aus dem repository bleiben. Ich bitte um tests, wenns soweit ist.Und ja, eigentlich wollte ich das Freitag noch schaffen, aber ging halt nicht. Aber im Forum wollte ich halt auch noch kurz antworten. ;-)
-
ähm.. ja.. die github Version hab ich auch noch nicht getestet. Kann sein, dass da noch fehler drin sind. Die Tests laufen ja auch nicht durch. ;-)
Bin am Freitag nur dazu gekommen neuen Code zu produzieren, ausprobieren und Fehler glatt bügeln, dafür hat die Zeit nicht mehr gereicht. Insofern, was @Thomas-Braun sagt: Bitte erstmal bei der Version aus dem repository bleiben. Ich bitte um tests, wenns soweit ist.Und ja, eigentlich wollte ich das Freitag noch schaffen, aber ging halt nicht. Aber im Forum wollte ich halt auch noch kurz antworten. ;-)
@garfonso Kein Stress. Sag bescheid wenn du soweit bist.
-
Dieser Hinweis ist wichtig an der Stelle, daher hatte ich die Version und aus Github geschrieben. Aber korrekt und wichtig für alle da zu unterscheiden.
Ich such jetzt im Programm mal nach dem Fehler der mir beim Neustart des Adapters meinen Eingang auf false setzt, obwohl dieser definitiv true ist.
@Garfonso
Problem gefunden und hätte hier eine Lösung. Die Initialisierung geht nicht schnell genug.
Habe eine Delay Funktion nach dem GPIO watch Befehl integriert - jetzt wird der Eingang korrekt auf True gesetzt.function delay(ms) { return new Promise(resolve => setTimeout(resolve, ms)); } // Füge eine kurze Verzögerung hinzu, um sicherzustellen, dass der Pin initialisiert ist 121 this.gpioInputPorts.push(gpioSetting.gpio); // neu await delay(100); // Verzögerung von 100 Millisekunden 122 await this.readValue(gpioSetting.gpio);im DEBUG Log zeigt er mir damit aber eine lange liste true. Das "false" am Anfang kommt leider immer noch durch. Er korrigiert es jetzt aber. Kannst du beim 1. lesen des Eingangs den Inhalt verwerfen? Das liegt sicher an der Debounce Abfrage - richtig?
2025-02-23 17:43:25.161 - debug: rpi2.0 (34903) GPIO chip undefined initialized 2025-02-23 17:43:25.161 - debug: rpi2.0 (34903) Port 17 direction: in 2025-02-23 17:43:25.164 - debug: rpi2.0 (34903) Setting state for port 17 to false 2025-02-23 17:43:25.221 - silly: rpi2.0 (34903) States user redis pmessage rpi2.0.*/rpi2.0.gpio.17.state:{"val":false,"ack":true,"ts":1740329005219,"q":0,"from":"system.adapter.rpi2.0","user":"system.user.admin","lc":1740329005219} 2025-02-23 17:43:25.225 - debug: rpi2.0 (34903) Port 22 direction: outhigh 2025-02-23 17:43:25.227 - debug: rpi2.0 (34903) Adding event listener for port 17 2025-02-23 17:43:26.792 - debug: rpi2.0 (34903) GPIO change on port 17: true 2025-02-23 17:43:26.793 - debug: rpi2.0 (34903) Setting state for port 17 to true 2025-02-23 17:43:26.795 - debug: rpi2.0 (34903) GPIO change on port 17: true 2025-02-23 17:43:26.797 - debug: rpi2.0 (34903) Setting state for port 17 to true 2025-02-23 17:43:26.800 - debug: rpi2.0 (34903) GPIO change on port 17: true 2025-02-23 17:43:26.801 - debug: rpi2.0 (34903) Setting state for port 17 to true 2025-02-23 17:43:26.803 - debug: rpi2.0 (34903) GPIO change on port 17: true 2025-02-23 17:43:26.804 - debug: rpi2.0 (34903) Setting state for port 17 to true 2025-02-23 17:43:26.806 - debug: rpi2.0 (34903) GPIO change on port 17: true@smallfeuer said in Test Adapter rpi2 2.x:
im DEBUG Log zeigt er mir damit aber eine lange liste true. Das "false" am Anfang kommt leider immer noch durch. Er korrigiert es jetzt aber. Kannst du beim 1. lesen des Eingangs den Inhalt verwerfen? Das liegt sicher an der Debounce Abfrage - richtig?
Hä? Welches Problem hat das denn jetzt gelöst?
In deinem log sehe ich, dass der Port initialisiert wurde, dann wurdefalseeingelesen, nach dem timeout, den du dort hinzugefügt hast und danach meldet die library von "außen" mehrere Veränderungen zu true. Wenn da nur einmal true rauskommen soll, könntest du das mit debounce timer lösen.Was genau hat der delay jetzt bei dir behoben, wenn es nicht das initiale lesen war?
-
@garfonso Kein Stress. Sag bescheid wenn du soweit bist.
@smallfeuer said in Test Adapter rpi2 2.x:
@garfonso Kein Stress. Sag bescheid wenn du soweit bist.
Jetzt kannst du von github mal ausprobieren und gucken, ob es einen Unterschied macht. Der initiale Zustand der Eingäge wird jetzt erst gelesen, nachdem der Eventlistener hinzugefügt wurde.
Wenn da immer noch das falsche bei rum kommt, weiß ich nicht mehr so richtig weiter.
In dem Fall, könntest du mir deine Konfiguration mal zukommen lassen? Weiß zwar nicht, ob ich da ohne Hardware hier weiter komme, aber vielleicht fällt mir was ein. ;-)Ultimativer Lovelace Leitfaden: https://forum.iobroker.net/topic/35937/der-ultimative-iobroker-lovelace-leitfaden-dokumentation
Lovelace UI Beispiele: https://forum.iobroker.net/topic/35950/zeigt-her-eure-lovelace-visualisierung
-
@smallfeuer said in Test Adapter rpi2 2.x:
@garfonso Kein Stress. Sag bescheid wenn du soweit bist.
Jetzt kannst du von github mal ausprobieren und gucken, ob es einen Unterschied macht. Der initiale Zustand der Eingäge wird jetzt erst gelesen, nachdem der Eventlistener hinzugefügt wurde.
Wenn da immer noch das falsche bei rum kommt, weiß ich nicht mehr so richtig weiter.
In dem Fall, könntest du mir deine Konfiguration mal zukommen lassen? Weiß zwar nicht, ob ich da ohne Hardware hier weiter komme, aber vielleicht fällt mir was ein. ;-)@garfonso
Ich hab ja auf Raspi 4 Bookworm die rpi2 v 2.3.2 und wenn du da Hilfe bei Tests brauchst sag Bescheid.
Habe 8 Ausgänge am Raspie mit High aktiv und 6 Eingänge (Pull down) die ich kurzfristig auch für Tests mit 3,3V beschalten könnte. Derzeit verwende ich GPIO 23 mit einem Taster.Was mir im Thread auffällt ist, dass viele von Ihren Relaiszustand schreiben. Dieser kann aber je nach verwendeter Relaiskarte auch invertiert sein. Es wäre hier sinnvoll sich immer auf high oder low an den Pins am Raspie zu beziehen. Weiter sollte auch immer in der ersten Zeile benannt werden ob es schon die 2.3.2 ist.
Zum Thema GPIO mit Raspie 5 hab ich grad was im Netz gesehen. Ev. hilft euch das!
https://kofler.info/gpio-aerger-auf-dem-raspberry-pi-5/
https://kofler.info/gpio-reloaded-ii-bash/#more-7796Dort ist auch eine Abfrage der GPIOs mit z.B. pinctrl get 23 für GPIO 23 beschrieben die bei mir prima funktioniert.
pinctrl get [gpionr] ermittelt den aktuellen Status aller GPIOs bzw. des angegebenen GPIOs. pinctrl funcs [gpionr] ermittelt, welche alternativen Funktionen der angegebene GPIO bzw. alle GPIOs erfüllen können. pinctrl set gpionr options verändert den Status des angegeben GPIOs. Mögliche Optionen sind: ip = Input op = Output dl = Zustand Low (Drive Low) dh = Zustand High (Drive High) pu = Pull-up-Widerstand aktiv pd = Pull-down-Widerstand aktiv pn = keine Pull-up/down-Funktion a0 bis a7 = alternative Funktion n aktivieren no = Deaktivieren (no function) Soweit sich sinnvolle Kombinationen ergeben, dürfen mehrere der obigen Optionen auf einmal übergeben werden, jeweils getrennt durch Leerzeichen. Welche alternative Funktionen ein GPIO unterstützt und wie sie nummeriert sind, geht aus pinctrl funcs hervor.code_text -
@smallfeuer said in Test Adapter rpi2 2.x:
im DEBUG Log zeigt er mir damit aber eine lange liste true. Das "false" am Anfang kommt leider immer noch durch. Er korrigiert es jetzt aber. Kannst du beim 1. lesen des Eingangs den Inhalt verwerfen? Das liegt sicher an der Debounce Abfrage - richtig?
Hä? Welches Problem hat das denn jetzt gelöst?
In deinem log sehe ich, dass der Port initialisiert wurde, dann wurdefalseeingelesen, nach dem timeout, den du dort hinzugefügt hast und danach meldet die library von "außen" mehrere Veränderungen zu true. Wenn da nur einmal true rauskommen soll, könntest du das mit debounce timer lösen.Was genau hat der delay jetzt bei dir behoben, wenn es nicht das initiale lesen war?
@garfonso
Naja, ich dachte es hätte was geändert. Deshalb hatte ich ja drunter geschrieben gestern Abend - ich verstehe es nicht mehr :)Vorher war es so, dass beim Rebooten "false" stehen geblieben ist und der Eingang gar nicht auf true ging. Nun hatte ich ja die Github Version installiert die nicht lief, dann meine komplette Instanz + Adapter gelöscht und neu auf 2.3.1 gespielt.
Danach blieb von meinem Problem nur noch über, das der 1. Befehl false war und es dann auf true wechselte obwohl ein Signal anliegt. Kurz gesagt - vergiss mein Delay - ich teste jetzt mal die Github Version.
-
@smallfeuer said in Test Adapter rpi2 2.x:
@garfonso Kein Stress. Sag bescheid wenn du soweit bist.
Jetzt kannst du von github mal ausprobieren und gucken, ob es einen Unterschied macht. Der initiale Zustand der Eingäge wird jetzt erst gelesen, nachdem der Eventlistener hinzugefügt wurde.
Wenn da immer noch das falsche bei rum kommt, weiß ich nicht mehr so richtig weiter.
In dem Fall, könntest du mir deine Konfiguration mal zukommen lassen? Weiß zwar nicht, ob ich da ohne Hardware hier weiter komme, aber vielleicht fällt mir was ein. ;-)@garfonso Getestet - läuft, Fehler mit falschen "False" Befehl ist aber identisch. Hast du ne Idee wie wir den 1. Befehl der vom Ausgang gelesen wird verwerfen können?
-
@garfonso Getestet - läuft, Fehler mit falschen "False" Befehl ist aber identisch. Hast du ne Idee wie wir den 1. Befehl der vom Ausgang gelesen wird verwerfen können?
sogar die debounce funktion funktioniert im nachhinein. Was meintest du mit meiner Konfiguration? Ist ja einfach nur ein Eingang der spannung high hat und dauerhaft als true durchgereicht werden sollte.
@Hasont Kannst du das mal nachstellen? Einfach mal einen Eingang auf True bringen über die Pi Spannung und schauen was beim reboot passiert?
DeBUG auf alles - > Dann sollte es sich identisch verhalten.rpi2.0 2025-02-24 20:12:27.178 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.177 debug Ignoring change event due to debounce: 15ms < 500. rpi2.0 2025-02-24 20:12:27.176 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.175 debug Ignoring change event due to debounce: 13ms < 500. rpi2.0 2025-02-24 20:12:27.174 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.174 debug Ignoring change event due to debounce: 12ms < 500. rpi2.0 2025-02-24 20:12:27.173 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.173 debug Ignoring change event due to debounce: 11ms < 500. rpi2.0 2025-02-24 20:12:27.172 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.172 debug Ignoring change event due to debounce: 10ms < 500. rpi2.0 2025-02-24 20:12:27.171 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.171 debug Ignoring change event due to debounce: 9ms < 500. rpi2.0 2025-02-24 20:12:27.171 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.170 debug Ignoring change event due to debounce: 8ms < 500. rpi2.0 2025-02-24 20:12:27.170 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.169 debug Ignoring change event due to debounce: 7ms < 500. rpi2.0 2025-02-24 20:12:27.169 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.168 debug Ignoring change event due to debounce: 6ms < 500. rpi2.0 2025-02-24 20:12:27.168 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.167 debug Ignoring change event due to debounce: 5ms < 500. rpi2.0 2025-02-24 20:12:27.167 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.166 debug Ignoring change event due to debounce: 4ms < 500. rpi2.0 2025-02-24 20:12:27.166 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.165 debug Ignoring change event due to debounce: 3ms < 500. rpi2.0 2025-02-24 20:12:27.164 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.162 debug Setting state for port 17 to true rpi2.0 2025-02-24 20:12:27.162 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:25.826 silly States user redis pmessage rpi2.0.*/rpi2.0.gpio.27.state:{"val":true,"ack":true,"ts":1740424345823,"q":0,"from":"system.adapter.rpi2.0","user":"system.user.admin","lc":1740424345823} rpi2.0 2025-02-24 20:12:25.770 debug Written true into port 27 rpi2.0 2025-02-24 20:12:25.769 debug Setting initial value for port 27 to true rpi2.0 2025-02-24 20:12:25.767 silly States user redis pmessage rpi2.0.*/rpi2.0.gpio.24.state:{"val":true,"ack":true,"ts":1740424345764,"q":0,"from":"system.adapter.rpi2.0","user":"system.user.admin","lc":1740424345764} rpi2.0 2025-02-24 20:12:25.711 debug Written true into port 24 rpi2.0 2025-02-24 20:12:25.710 debug Setting initial value for port 24 to true rpi2.0 2025-02-24 20:12:25.706 silly States user redis pmessage rpi2.0.*/rpi2.0.gpio.23.state:{"val":true,"ack":true,"ts":1740424345703,"q":0,"from":"system.adapter.rpi2.0","user":"system.user.admin","lc":1740424345703} rpi2.0 2025-02-24 20:12:25.650 debug Written true into port 23 rpi2.0 2025-02-24 20:12:25.650 debug Setting initial value for port 23 to true rpi2.0 2025-02-24 20:12:25.646 silly States user redis pmessage rpi2.0.*/rpi2.0.gpio.22.state:{"val":true,"ack":true,"ts":1740424345643,"q":0,"from":"system.adapter.rpi2.0","user":"system.user.admin","lc":1740424345643} rpi2.0 2025-02-24 20:12:25.591 debug Written true into port 22 rpi2.0 2025-02-24 20:12:25.590 debug Setting initial value for port 22 to true rpi2.0 2025-02-24 20:12:25.586 silly States user redis pmessage rpi2.0.*/rpi2.0.gpio.17.state:{"val":false,"ack":true,"ts":1740424345583,"q":0,"from":"system.adapter.rpi2.0","user":"system.user.admin","lc":1740424345583} rpi2.0 2025-02-24 20:12:25.528 debug Setting state for port 17 to false rpi2.0 2025-02-24 20:12:25.528 debug Read false from port 17. -
sogar die debounce funktion funktioniert im nachhinein. Was meintest du mit meiner Konfiguration? Ist ja einfach nur ein Eingang der spannung high hat und dauerhaft als true durchgereicht werden sollte.
@Hasont Kannst du das mal nachstellen? Einfach mal einen Eingang auf True bringen über die Pi Spannung und schauen was beim reboot passiert?
DeBUG auf alles - > Dann sollte es sich identisch verhalten.rpi2.0 2025-02-24 20:12:27.178 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.177 debug Ignoring change event due to debounce: 15ms < 500. rpi2.0 2025-02-24 20:12:27.176 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.175 debug Ignoring change event due to debounce: 13ms < 500. rpi2.0 2025-02-24 20:12:27.174 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.174 debug Ignoring change event due to debounce: 12ms < 500. rpi2.0 2025-02-24 20:12:27.173 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.173 debug Ignoring change event due to debounce: 11ms < 500. rpi2.0 2025-02-24 20:12:27.172 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.172 debug Ignoring change event due to debounce: 10ms < 500. rpi2.0 2025-02-24 20:12:27.171 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.171 debug Ignoring change event due to debounce: 9ms < 500. rpi2.0 2025-02-24 20:12:27.171 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.170 debug Ignoring change event due to debounce: 8ms < 500. rpi2.0 2025-02-24 20:12:27.170 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.169 debug Ignoring change event due to debounce: 7ms < 500. rpi2.0 2025-02-24 20:12:27.169 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.168 debug Ignoring change event due to debounce: 6ms < 500. rpi2.0 2025-02-24 20:12:27.168 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.167 debug Ignoring change event due to debounce: 5ms < 500. rpi2.0 2025-02-24 20:12:27.167 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.166 debug Ignoring change event due to debounce: 4ms < 500. rpi2.0 2025-02-24 20:12:27.166 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.165 debug Ignoring change event due to debounce: 3ms < 500. rpi2.0 2025-02-24 20:12:27.164 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:27.162 debug Setting state for port 17 to true rpi2.0 2025-02-24 20:12:27.162 debug GPIO change on port 17: true rpi2.0 2025-02-24 20:12:25.826 silly States user redis pmessage rpi2.0.*/rpi2.0.gpio.27.state:{"val":true,"ack":true,"ts":1740424345823,"q":0,"from":"system.adapter.rpi2.0","user":"system.user.admin","lc":1740424345823} rpi2.0 2025-02-24 20:12:25.770 debug Written true into port 27 rpi2.0 2025-02-24 20:12:25.769 debug Setting initial value for port 27 to true rpi2.0 2025-02-24 20:12:25.767 silly States user redis pmessage rpi2.0.*/rpi2.0.gpio.24.state:{"val":true,"ack":true,"ts":1740424345764,"q":0,"from":"system.adapter.rpi2.0","user":"system.user.admin","lc":1740424345764} rpi2.0 2025-02-24 20:12:25.711 debug Written true into port 24 rpi2.0 2025-02-24 20:12:25.710 debug Setting initial value for port 24 to true rpi2.0 2025-02-24 20:12:25.706 silly States user redis pmessage rpi2.0.*/rpi2.0.gpio.23.state:{"val":true,"ack":true,"ts":1740424345703,"q":0,"from":"system.adapter.rpi2.0","user":"system.user.admin","lc":1740424345703} rpi2.0 2025-02-24 20:12:25.650 debug Written true into port 23 rpi2.0 2025-02-24 20:12:25.650 debug Setting initial value for port 23 to true rpi2.0 2025-02-24 20:12:25.646 silly States user redis pmessage rpi2.0.*/rpi2.0.gpio.22.state:{"val":true,"ack":true,"ts":1740424345643,"q":0,"from":"system.adapter.rpi2.0","user":"system.user.admin","lc":1740424345643} rpi2.0 2025-02-24 20:12:25.591 debug Written true into port 22 rpi2.0 2025-02-24 20:12:25.590 debug Setting initial value for port 22 to true rpi2.0 2025-02-24 20:12:25.586 silly States user redis pmessage rpi2.0.*/rpi2.0.gpio.17.state:{"val":false,"ack":true,"ts":1740424345583,"q":0,"from":"system.adapter.rpi2.0","user":"system.user.admin","lc":1740424345583} rpi2.0 2025-02-24 20:12:25.528 debug Setting state for port 17 to false rpi2.0 2025-02-24 20:12:25.528 debug Read false from port 17.if (value === undefined) { value = this.gpioPorts[port].value; this.log.debug(`Read ${value} from port ${port}.`);Also ich habe es jetzt soweit analysiert, hier wird der Wert beim 1. Durchlauf false gesetzt, ein delay ändert das Ergebnis aber hier nicht.
Liest der Befehl
value = this.gpioPorts[port].value;den Wert direkt aus? Dann muss der Fehler weiter vorn in dieser Funktion verankert liegen :(
-
if (value === undefined) { value = this.gpioPorts[port].value; this.log.debug(`Read ${value} from port ${port}.`);Also ich habe es jetzt soweit analysiert, hier wird der Wert beim 1. Durchlauf false gesetzt, ein delay ändert das Ergebnis aber hier nicht.
Liest der Befehl
value = this.gpioPorts[port].value;den Wert direkt aus? Dann muss der Fehler weiter vorn in dieser Funktion verankert liegen :(
@smallfeuer
Ja, genau, das .value liest den Wert aus. Daher hab ich dort das debug log ergänzt, was man bei dir auch sieht:
2025-02-24 20:12:25.528 debug Read false from port 17.
Die restlichen Änderungen kommen über den onChange listener beim "watch", also da wird der Adapter über Änderungen am Pin informiert, sieht dann leicht anders aus:
2025-02-24 20:12:27.162 debug GPIO change on port 17: trueEs könnte sein, dass da noch eine Initialisierung läuft, und daher das false am Anfang kommt. Dazu hab ich aber in der Bibliothek bisher nichts finden können. :-/
Bei meinem Test-System kommen am Anfang auch keine Change-Events. -
@smallfeuer
Ja, genau, das .value liest den Wert aus. Daher hab ich dort das debug log ergänzt, was man bei dir auch sieht:
2025-02-24 20:12:25.528 debug Read false from port 17.
Die restlichen Änderungen kommen über den onChange listener beim "watch", also da wird der Adapter über Änderungen am Pin informiert, sieht dann leicht anders aus:
2025-02-24 20:12:27.162 debug GPIO change on port 17: trueEs könnte sein, dass da noch eine Initialisierung läuft, und daher das false am Anfang kommt. Dazu hab ich aber in der Bibliothek bisher nichts finden können. :-/
Bei meinem Test-System kommen am Anfang auch keine Change-Events.@garfonso Kannst du mir sagen wo ich die aktuell genutzte GPIO - Bibliothek vom Bookworm finde? Kann mich gern mal durch den Code suchen - etwas C- Verständnis hab ich mittlerweile.
Alternativ würde ich jetzt folgendes Tun. Ich werde den GPIO INPUT einfach als Trigger nutzen und prüfen wie lange die Instanz "True" ist -> dementsprechend dann das Script starten über einen eigenen Datenpunkt. Ist zwar ein wenig aufwand, aber so werde ich die Falschmeldung bei Updates/Stromausfall los.
Support us
996
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge