Test Adapter rpi2 2.x
-
@smallfeuer sagte in Test Adapter rpi2 2.x:
@hasont sagte in Test Adapter rpi2 2.x:
pullUpWarning/hiddenHast du Pullup / Pulldown ein Haken gesetzt? Nein, alle ohne
Oder nur von True mal auf false geändert ? wenn ja, dann mit Bestätigung? NeinIch fasse kurz zusammen - heißt bei dir bleibt der Eingang die ganze Zeit auf True! Ich werde mal meinen Magnetschalter überbrücken um die Verbindung zu optimieren. Mal schauen ob der vielleicht zu viel Widerstand hat. Auch wenn ich mir das nicht vorstellen kann- da er ja sonst dauerhaft stabil ein True bringt.
Hab grad im Objekt nachgesehen und mein GPIO 17 war False. Bin in den Keller um zu sehen ob ich ev. die Krokoklemme schon abgeklemmt habe >> Nein war noch geschaltet.
Dann schau ich in den PC und der GPIO 17 ist wieder True (hab nur Licht eingeschaltet)
Ich bleib da mal für dich dran!Edit 27.02 21:00: Grad mal alle Eingänge auf 1000ms gesetzt um zu sehen ob der Eingang GPIO 23 beim Licht einschalten (Neon) noch kommen.
In Instanz rsp2 abgespeichert und jetzt ist GPIO 17 FALSE, Eingang noch an 3,3V Leider kein log!!
Edit:28.02 10:38 Gerade nachgesehen und GPIO ist wieder True > Log eingeschaltet und Instanz neu gestartet.
GPIO 17 war wieder False 2025-02-28 10:21:11.461 und ist dann 2025-02-28 10:28:55.677 auf True
Der GPIO 17 ist dauerhaft an 3,3VHier das Logfile von 10:21 - 10:36
02 Log-Größe: 25.2 MB Zeit rpi2.0 2025-02-28 10:36:57.654 debug Ignoring change event due to debounce: 7ms < 1000. rpi2.0 2025-02-28 10:36:57.653 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:36:57.647 debug Setting state for port 23 to false rpi2.0 2025-02-28 10:36:57.646 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:35:57.650 debug Ignoring change event due to debounce: 5ms < 1000. rpi2.0 2025-02-28 10:35:57.649 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:35:57.646 debug Setting state for port 23 to false rpi2.0 2025-02-28 10:35:57.645 debug GPIO change on port 23: false ebus.0 2025-02-28 10:35:06.748 info all history done ebus.0 2025-02-28 10:35:06.717 info all http done ebus.0 2025-02-28 10:35:06.661 info installed ebusd version is 24.1 rpi2.0 2025-02-28 10:34:57.652 debug Ignoring change event due to debounce: 5ms < 1000. rpi2.0 2025-02-28 10:34:57.651 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:34:57.649 debug Ignoring change event due to debounce: 2ms < 1000. rpi2.0 2025-02-28 10:34:57.648 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:34:57.647 debug Setting state for port 23 to false rpi2.0 2025-02-28 10:34:57.646 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:33:57.652 debug Setting state for port 23 to false rpi2.0 2025-02-28 10:33:57.651 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:32:57.652 debug Ignoring change event due to debounce: 11ms < 1000. rpi2.0 2025-02-28 10:32:57.651 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:32:57.651 debug Ignoring change event due to debounce: 10ms < 1000. rpi2.0 2025-02-28 10:32:57.650 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:32:57.649 debug Ignoring change event due to debounce: 8ms < 1000. rpi2.0 2025-02-28 10:32:57.648 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:32:57.641 debug Setting state for port 23 to false rpi2.0 2025-02-28 10:32:57.640 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:31:57.651 debug Setting state for port 23 to false rpi2.0 2025-02-28 10:31:57.651 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:30:57.653 debug Ignoring change event due to debounce: 7ms < 1000. rpi2.0 2025-02-28 10:30:57.652 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:30:57.646 debug Setting state for port 23 to false rpi2.0 2025-02-28 10:30:57.645 debug GPIO change on port 23: false ebus.0 2025-02-28 10:30:06.758 info all history done ebus.0 2025-02-28 10:30:06.725 info all http done ebus.0 2025-02-28 10:30:06.666 info installed ebusd version is 24.1 host.raspberrypi 2025-02-28 10:30:00.027 warn instance system.adapter.ebus.0 already running with pid 1127 rpi2.0 2025-02-28 10:29:57.653 debug Ignoring change event due to debounce: 11ms < 1000. rpi2.0 2025-02-28 10:29:57.652 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:29:57.645 debug Ignoring change event due to debounce: 3ms < 1000. rpi2.0 2025-02-28 10:29:57.644 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:29:57.642 debug Setting state for port 23 to false rpi2.0 2025-02-28 10:29:57.641 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:28:55.679 debug Setting state for port 23 to false rpi2.0 2025-02-28 10:28:55.679 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:28:55.678 debug Setting state for port 17 to true rpi2.0 2025-02-28 10:28:55.677 debug GPIO change on port 17: true rpi2.0 2025-02-28 10:27:57.653 debug Ignoring change event due to debounce: 9ms < 1000. rpi2.0 2025-02-28 10:27:57.652 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:27:57.644 debug Setting state for port 23 to false rpi2.0 2025-02-28 10:27:57.643 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:26:57.652 debug Ignoring change event due to debounce: 6ms < 1000. rpi2.0 2025-02-28 10:26:57.651 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:26:57.649 debug Ignoring change event due to debounce: 3ms < 1000. rpi2.0 2025-02-28 10:26:57.648 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:26:57.646 debug Setting state for port 23 to false rpi2.0 2025-02-28 10:26:57.645 debug GPIO change on port 23: false ebus.0 2025-02-28 10:25:06.851 info all history done ebus.0 2025-02-28 10:25:06.819 info all http done ebus.0 2025-02-28 10:25:06.751 info installed ebusd version is 24.1 rpi2.0 2025-02-28 10:24:57.639 debug Setting state for port 23 to false rpi2.0 2025-02-28 10:24:57.639 debug GPIO change on port 23: false rpi2.0 2025-02-28 10:21:11.627 debug Port 23 direction: in rpi2.0 2025-02-28 10:21:11.576 debug Setting state for port 22 to false rpi2.0 2025-02-28 10:21:11.575 debug Port 22 direction: in rpi2.0 2025-02-28 10:21:11.574 debug Port 21 direction: outlow rpi2.0 2025-02-28 10:21:11.573 debug Port 20 direction: outlow rpi2.0 2025-02-28 10:21:11.571 debug Port 19 direction: outlow rpi2.0 2025-02-28 10:21:11.521 debug Setting state for port 18 to false rpi2.0 2025-02-28 10:21:11.519 debug Port 18 direction: in rpi2.0 2025-02-28 10:21:11.461 debug Setting state for port 17 to false rpi2.0 2025-02-28 10:21:11.458 debug Port 17 direction: in rpi2.0 2025-02-28 10:21:11.457 debug Port 16 direction: outlow rpi2.0 2025-02-28 10:21:11.455 debug Port 13 direction: outlow rpi2.0 2025-02-28 10:21:11.454 debug Port 12 direction: outlow rpi2.0 2025-02-28 10:21:11.453 debug Got chip: class Default extends classes_1.Device {} rpi2.0 2025-02-28 10:21:11.453 debug Got 4 from Raspberry Pi 4 Model B Rev 1.2code_text host.raspberrypi 2025-02-28 10:21:04.831 info stopInstance timeout system.adapter.rpi2.0 killing pid 3483Edit 2.03 16:43 Musste IOB gestern und heute mehrfach starten. Mein GPIO 17 war danach immer False und ging nach unbestimmter Zeit dann auf True. Irgendwie scheint es so als würde er auf einen Trigger warten. Grad war es direkt nach einem VIS-Login.
rpi2.0 2025-03-02 16:40:18.648 debug Setting state for port 23 to false rpi2.0 2025-03-02 16:40:18.648 debug GPIO change on port 23: false rpi2.0 2025-03-02 16:40:18.648 debug Ignoring change event due to debounce: 0ms < 1000. rpi2.0 2025-03-02 16:40:18.648 debug GPIO change on port 17: true rpi2.0 2025-03-02 16:40:18.648 debug Setting state for port 17 to true rpi2.0 2025-03-02 16:40:18.647 debug GPIO change on port 17: true web.0 2025-03-02 16:40:16.242 info ==> Connected system.user.admin from ::ffff:192.168.1.104 web.0 2025-03-02 16:40:15.951 info <== Disconnect system.user.admin from ::ffff:192.168.1.104 vis.0 rpi2.0 2025-03-02 16:40:10.254 debug Ignoring change event due to debounce: 36ms < 1000. rpi2.0 2025-03-02 16:40:10.254 debug GPIO change on port 23: falseHab dann den Prozess neu gestartet GPIO 17 wieder False. Im VIS GPIO 25 geändert und sofort kam auch beim GPIO 17 ohne debounce ein True.
rpi2.0 2025-03-02 16:56:46.083 debug Setting state for port 23 to false rpi2.0 2025-03-02 16:56:46.082 debug GPIO change on port 23: false rpi2.0 2025-03-02 16:56:46.081 debug Setting state for port 17 to true rpi2.0 2025-03-02 16:56:46.081 debug GPIO change on port 17: true rpi2.0 2025-03-02 16:56:46.077 debug Written true into port 25 rpi2.0 2025-03-02 16:56:46.077 debug stateChange for rpi2.0.gpio.25.state found state = {"val":true,"ack":false,"ts":1740931006072,"q":0,"from":"system.adapter.web.0","user":"system.user.admin","lc":1740931006072} -
@hasont sagte in Test Adapter rpi2 2.x:
Hallo Garfonso,
die 2.3.2 habe ich nun an meinen 8 Ausgängen und 6 Eingängen getestet und bin für meine Anwendungen mit Ausgang, Ausgangswert 0 absolut zufrieden. Beim Hochfahren werden kurz alle Relais ein- und ausgeschaltet und damit kann ich leben. Die Anzeige in den Objekten ist danach korrekt.
Zur Info, ich bin noch immer auf der von Garfonso vorgeschlagenen 2.3.2 vom 9.02.2025.
Wie damals von mir bemerkt sollte bei der Weiterentwicklung ev. auch das Startverhalten vom Adapter bei den Ausgängen mal angesehen werden. Nach Reboot des Raspie und/oder der rpi2 Instanz werden immer alle Ausgänge für ne ms False/True/False gesetzt. Für mich nicht problematisch. Wenn da aber z.B. ein Garagentor mit Taster dran wäre dann ginge das auf. Warum die Relais hier kurz toggeln und ob das nur in der 2.3.2 ist weiß ich nicht.
In der damaligen 2.3.1 wurden ja alle Relais nach dem Start dauerhaft auf True gesetzt was aber ja nicht richtig sein kann. -
@hasont: False/True/False nach Systemstart, hier mal etwas Dramatik in 2.3.2. Nach reboot zieht bei mir ein 200A Batterie-Schütz lautstark an um nach ein paar ms mit einem Lichtbogen wieder in die bei Start eigentlich gewünschte Ruheposition zu gehen. Für GPIO-Ausgänge habe ich definierte true/false Zustände erst mal in Bookworm ohne rpi2 über Blockly und simple-ssh bash-Scripts mit pinctrl erreicht. Wieder mal so viel vergeudete Zeit. Mittlerweile bekomme ich ein flaues Bauchgefühl vor Updates auf den Raspberry's.
-
@dock07 sagte in Test Adapter rpi2 2.x:
@hasont: False/True/False nach Systemstart, hier mal etwas Dramatik in 2.3.2. Nach reboot zieht bei mir ein 200A Batterie-Schütz lautstark an um nach ein paar ms mit einem Lichtbogen wieder in die bei Start eigentlich gewünschte Ruheposition zu gehen. Für GPIO-Ausgänge habe ich definierte true/false Zustände erst mal in Bookworm ohne rpi2 über Blockly und simple-ssh bash-Scripts mit pinctrl erreicht. Wieder mal so viel vergeudete Zeit. Mittlerweile bekomme ich ein flaues Bauchgefühl vor Updates auf den Raspberry's.
Hallo dock07,
hättest du ev. noch ein paar Infos zum Thema simple-ssh-Scripts und Auszug vom Blockly bzw. Script.
Ev. kann ich das ja auch mal probieren. Das mit pinctrl klappt ja ganz gut. Angeblich kann man ja megrere GPIOs auf einmal abfragen was ich aber so nicht hinbekommen habe. Bei mir ging immer nur einer. -
@hasont
bash-Scripts mit pinctrl:
https://kofler.info/gpio-aerger-auf-dem-raspberry-pi-5/
Blockly-Script mit Javascript-Funktion:
https://www.machs-smart.de/iobroker-ssh-befehle-mit-blockly-ausfuhren/Habe für jeden GPIO zuerst einen Datenpunkt erzeugt. Darauf greifen sämtliche Scripte zu die den GPIO ändern möchten. Zusätzlich vereinfacht der Datenpunkt für mich die Abfrage des Zustandes.
Im Java-Blockly Script setze ich einen Trigger auf den Datenpunkt um dort je nach Schalterzustand den true oder false GPIO-Aktionsblock auszulösen.
Trotzdem ist das Schalten über SSH natürlich suboptimal für die Sicherheit falls das Netzwerk ausfällt,. Ich hoffe das der Adapter rpi2 irgendwann wieder wie früher funktioniert. -
@dock07 said in Test Adapter rpi2 2.x:
Für GPIO-Ausgänge habe ich definierte true/false Zustände erst mal in Bookworm ohne rpi2 über Blockly und simple-ssh bash-Scripts mit pinctrl erreicht.
Da würde mich interessieren, was das Skript anders macht. Wie hast du die Ausgänge definiert? Wenn die keinen Startwert haben, schaltet der Adapter da nichts.
-
@garfonso
lieber Garfonso, erst mal vielen Dank das du versuchst die Adapterfunktion zu verbessern.
Was das Skript eventuell anders macht kann ich dir leider mit meinen rudimentären Programmierkenntnissen die größtenteils aus paste and copy bestehen nicht beantworten.
Definierter Startwert ist meinerseits nicht ganz richtig formuliert.
nach Reboot dürfte ebenfalls da eine null stehen weil die boot-config die GPIO-Startwerte nicht mehr setzen kann. Ich denke ich liege richtig mit der Vermutung das rpi2 mit dem kurzem false true false genau diesen definierten Startwert erzeugt?
Wichtig ist halt für mich das die GPIOs die Füße bei reboot still halten und ein false, oder von mir aus auch Null, ausgeben. Danach schalten die o.g. Javascripts die GPIOs sauber auf true und später auch auf false.Außer dem Startverhalten funktioniert der rpi2 Adapter für mich. Lasse halt zur Zeit die GPIOs nicht durch RPI initialisieren bei welchen das kurze "true" für mich schädlich ist.
-
@dock07 said in Test Adapter rpi2 2.x:
Ich denke ich liege richtig mit der Vermutung das rpi2 mit dem kurzem false true false genau diesen definierten Startwert erzeugt?
Nein, es gibt kein false / true / false. Zumindest nicht im Adaptercode.
Du kannst im Adapter für einen Ausgang einstellen, ob er nur ein "Ausgang" ein "Ausgant, Startwert 0" oder ein "Ausgang, Startwert 1" ist. Bei nur "Ausgang" macht der Adapter beim start gar nichts (bzw. neuerdings fragt er beim System an, welchen Zustand der Ausgang hat und setzt den in iobroker). Bei "Startwert 0" bzw. "Startwert 1" wird fest dieser Wert beim Adapter-Start gesetzt.
Mehr kann ich an der Stelle nicht tun.
Mir ist irgendwie unklar, ob da was anderes im System an den GPIOs was schaltet... aber eigentlich müsste das dann auch ohne Adapter passieren. Oder es liegt an der node-Bibliothek, aber da hab ich bisher auch nichts zu gefunden, im Code oder der Beschreibung.Bei den Eingängen gibt es einen User, der berichtet, dass die am Anfang noch falsche Werte liefern. Das kann ich hier auch nicht nachstellen...
@dock07 said in Test Adapter rpi2 2.x:
Wichtig ist halt für mich das die GPIOs die Füße bei reboot still halten und ein false, oder von mir aus auch Null, ausgeben. Danach schalten die o.g. Javascripts die GPIOs sauber auf true und später auch auf false.
Hm.. das deutet darauf hin, dass es vielleicht doch ein Problem mit den Eingängen sein kann?
-
@garfonso >Bei nur "Ausgang" macht der Adapter beim start gar nichts|<
Kann ich so nicht bestätigen. In dem Moment beglückt mich der GPIO beim Start mit einem unerwünschten "true", eigentlich genau so wie bei eingestelltem Anfangswert 1
mit Ausgang Anfangswert 0 kommt es bei mir, und wahrscheinlich z.B. auch bei @Hasont, zu dem ungewünschten false true false bei Neustart.
Ohne die Initialisierung des jeweiligen GPIO durch den Adapter bleibt dieser auf null/ false, also so wie von mir gewünscht.
-
@dock07 sagte in Test Adapter rpi2 2.x:
@garfonso >Bei nur "Ausgang" macht der Adapter beim start gar nichts|<
Kann ich so nicht bestätigen. In dem Moment beglückt mich der GPIO beim Start mit einem unerwünschten "true", eigentlich genau so wie bei eingestelltem Anfangswert 1
mit Ausgang Anfangswert 0 kommt es bei mir, und wahrscheinlich z.B. auch bei @Hasont, zu dem ungewünschten false true false bei Neustart.
Ohne die Initialisierung des jeweiligen GPIO durch den Adapter bleibt dieser auf null/ false, also so wie von mir gewünscht.
@Garfonso
@dock07
Hallo, also bei mir in der 2.3.2 ist es genau so wie bei dock07.
Wie bereits weiter oben schon mal geschrieben sind mir folgende Dinge aufgefallen:
1.) Startverhalten mit false/true/false bei Ausgang = 0
2.) Wenn ich den rpi2 Prozess pausiere und den Raspie neu reboote bleibt alles false wie es sein soll!
Starte ich den rpi2 Prozess wieder gehen alle Relaise auf true/false.
3.) Wenn ich bei Ausgang = Ausgang 4 GPIOs der Relais 1-4 auf true stelle und 4 GPIOs der Relaise 5 - 8 auf false und dann die Instanz rpi2 neu starte werden erstmal alle Ausgänge auf true gesetzt und die GPIOs der Relais 1 - 4 bleiben true und die GPIOs der Relais 5 - 8 gehen true/false. Die GPIOs der Relais 5 - 8 werden somit auch erstmal falsch auf true gesetzt.
Meine Relaise sind true wenn an den GPIOs 3,3V anliegen. So ist es Standard beim Raspie.Bei den Eingängen ist es bei mir tatsächlich so, dass ein mit 3,3V dauerhaft auf true gesetzter Eingang manchmal für eine ganze Zeit lang nach Reboot vom Raspie oder der rpi2 Instanz als false im Objekt ansteht. Das ändert sich komischerweise erst wenn irgendein Trigger anliegt. Ich hab das bisher nur in den Objekten beobachtet. Trigger kann eine geschaltete Neonröhre oder ein Login über die App sein.
Ev. könnte ich da ja mal den Status mit pinctrl im Raspi selbst abfragen.Ich kann das leider nur schlecht beschreiben da es nicht sauber nachvollziehbar ist.
-
@garfonso leider keine Verbesserung in 2.4 bei Start des Adapters.
ich fasse meine Probleme noch mal zusammen:
"Ausgang Anfangswert 0" Adapter startet GPIO mit false true false
"Ausgang" Adapter startet GPIO mit true
ohne Initialisierung der GPIOs durch den Adapter startet Bookworm auf Rasp.4 die Ausgänge mit null/false, genau so wie es sein soll. -
@garfonso
Hallo Garfonso,ich habe die 2.4 jetzt auch zum testen installiert?
Habe wie dock07 keine Änderung zur 2.3.2 bei dem Startverhalten festgestellt.
Auch mein dauerhaft auf 3,3V gelegter Eingang GPIO17 ist erst false und wird erst später true.
Edit 11.03.25
Der Eingang blieb über 20min auf false obwohl eindeutig true.
Habe das 10 mal wiederholt. 9 mal falsch. Sobald ich die 3,3V wegnehme und wieder anlege funktioniert es sofort.
Nur beim Start der rpi2 Instanz und bereits vorher angelegten 3,3V wird der falsche Wert false anstatt true angezeigt.
Das ist auch auf allen meinen Eingängen so.
Wenn ich was testen soll sag Bescheid.LG
Horst
