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