@laser sagte in Test Adapter rpi2 2.x:

Wo kann ich denn einen Anfangswert konfigurieren? Adapter V.2.3.2

Du musst in den Einstellungen der Instanz wo du Eingang und Ausgang definierst, Ausgang mit Anfangswert 0 /1 auswählen.

Also bisher läuft alles ohne BUG. Hier mal noch 2 Bilder wie das ganze aussieht. Alles mit dem 3D Drucker erstellt.
MinTemp (blau), aktuelle Temp(je nach Temp - gelb) und Max Temp. (rot).

Danke für Eure Unterstützung.

@mcm1957 Aus rechtlicher Sicht, sehr gut auf den Punkt gebracht. Der Fahrstuhl sollte nicht damit betrieben werden. Zur Auflösung ob der Bug schon behoben wurde, hilft der Beitrag aber leider nicht. Ich wollte hier keine Diskussion über den Einsatz meiner Steuerung lostreten.

@laser Gut gemeinter Hinweis, aber hilft nicht beim Problem, und wenn es nur die Gartenteichpumpe ist die nicht schaltet, dann könnten auch Fische sterben ;).
Der Iobroker übernimmt seit Jahren zuverläassig viele Sicherheitsrelevante Sachen, ohne Probleme. Man muss halt immer alles verifizieren, ich wusste ja hier dank der guten Info das das Update kritisch ist und hab mir dafür etwas Zeit eingeplant.

@Garfonso Ich hab jetzt die aktuellste Githubversion überinstalliert, die Fehler sind verschwunden. Warum auch immer, hoffe sie kommen nach dem nächsten Update nicht zurück.

https://github.com/iobroker-community-adapters/ioBroker.rpi2

@Garfonso @thomas-braun
Fall jemand eine Idee hat, bin für jeden Rat dankbar.
Ich hab jetzt ein sauberes - neu aufgesetztes System als Slave und kann mit der aktuellen Beta seit dem letzten Host Update im stable keine Gpio mehr sehen bzw. setzen. Der Host läuft auf Proxmoxx, der Slave ist ein Pi3 B. Falls ich noch irgendwie mit Daten beitragen kann sagt es.

@laser Ich kann in der 2.3.1 aktuell einfach umstellen. Dafür muss ich die GPIO nicht löschen.

@hasont

pi2.0
	2025-02-27 15:31:07.430	debug	Setting state for port 17 to false

Obowhl, hier ist doch mein false. Die anderen True kommen alle vom watch Befehl.
Hast du die Änderung der Datenpunkte in der Datenbank oder History geblockt? Da war garantiert das eine "false" bei - wenn der DEBUG es scho sagt.

@hasont sagte in Test Adapter rpi2 2.x:

en müsste ich 1sec den Taster drücken um ein True zu bekommen, oder?

Korrekt.

@hasont sagte in Test Adapter rpi2 2.x:
pullUpWarning/hidden

Hast du Pullup / Pulldown ein Haken gesetzt? Oder nur von True mal auf false geändert ? wenn ja, dann mit Bestätigung?

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

@hasont Also das hin und her ist verständlich, du hast kein Pull down Widerstand eingebaut nehme ich an - wenn du also die 3,3V am Ausgang ausschaltest ist das Signal undefiniert. Siehe auch einen meiner letzten Kommentare zum Thema PullUP/Pulldown.
oder hier: https://www.electronics-tutorials.ws/de/logische/pullup-widerstaende.html

Was meinst du mit neu gebootet? Den Adapter, oder den Pi?
Beim Pi Neustart könnte es natürlich sein, das wirklich keine 3,3V ankommen. Insbesondere wenn du die 3,3V vom Ausgang holst.

Interessant ist also im wesentlichen nur ob beim Start oder Neustart des Adapters der Wert mal auf False geht.
bitte als Ausgang aber die 3,3V Spannungsversorgung nehmen, und keinen Ausgang der auf True sitzt. Sicherheitshalber sollte man hier glaube ich einen kleinen Widerstand zwischen packen, falls vorhanden. Für einen kurzen Test sollte es aber auch ohne gehen.

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

@smallfeuer

                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

@Garfonso

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.

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

@garfonso Kein Stress. Sag bescheid wenn du soweit bist.