UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Smallfeuer]

@hasont Das Problem hab ich aktuell auch. Zwischenzeitlich wechselt er seit neuesten ohne Grund den Status. Dachte schon der Eingang hat den A...hoch gerissen, da bin ich ja jetzt beruhigt.

[Smallfeuer]

Jemand eine Idee, warum mein Admin Adapter jetzt ohne ersichtlichen Auslöser diese Meldung bringt?

	rpi2 has an invalid jsonConfig: [{"instancePath":"/items/_gpios/items/_pullUpWarning/hidden","schemaPath":"#/patternProperties/%5E.%2B/properties/hidden/type","keyword":"type","params":{"type":"string"},"message":"must be string"},{"instancePath":"/items/_gpios","schemaPath":"#/properties/items/patternProperties/%5E.%2B/allOf/9/if","keyword":"if","params":{"failingKeyword":"then"},"message":"must match \"then\" schema"},{"instancePath":"","schemaPath":"#/if","keyword":"if","params":{"failingKeyword":"then"},"message":"must match \"then\" schema"}]

[Smallfeuer]

@Hasont Das ein und ausschalten einer FritzDect Dose in dem Raum hat eben Augenscheinlich eine Änderung von False auf true bewirkt. Soeben validiert:
Ist ja die Frage, liegt der falsche Wert wirklich an, oder bewirkt die Scriptausführung ein neues Lesen des GPIO Zustands ?

javascript.0
2025-05-28 14:59:49.576	warn	script.js.Alarmanlage.GaragenTorÜberwachung: pushover: Garage geschlossenAktuelle Zeit: 14:59:49 DECT: Licht ist aus durch GPIO 17

fritzdect.1
2025-05-28 14:59:48.917	info	DECT ID: 116570542089 identified for command (state) : false

fritzdect.1
2025-05-28 14:59:47.917	info	DECT ID: 116570542089 identified for command (state) : true

[Hasont]

@smallfeuer
hallo die Fehlermeldung oben kommt bei mir auch wenn ich RPI2 Instanz aufrufe, auch ohne Änderung. Hab ich schon öffter mal gefragt und ignoriere das halt jetzt. Zum Thema mit den Eingängen hab ich lange probiert und auch immer wieder geschrieben, dass es diesen sporatischen Wechsel (bei mir manchmal auch mehrfach am Tag) gibt. Entprellen erhöht und kleinere Widerstände am Eingang mit Kondensator alles schon probiert aber alles ohne Erfolg. Schaltung seit 4 Jahren gleich. Der Eingang steuert meine Giesanlage vorm Haus für die Nachbarn. Damit gebe ich dann 3min Wasser frei. Ist nicht schlimm solange der Schlauch dicht ist. Ich bekomme über Telegram dann Hauswasser vorne ein gemeldet. Ich dachte anfangs auch, dass das nur bei Neonlicht ein, Wasserventile ein oder Heizung ein passiert. Ist da auch sehr häufig zu beobachten. Nachts um 2:00 passiert da aber definitiv nichts und auch da hatte ich schon diese Art von meldungen. Entprellung steht mittlerweile auf 1000ms und trotzdem ist das so. Auch beim hochfahren vom Raspie wird ein vorher fest auf High gelegter Kontakt nur sporatisch erkannt. Ich kann mich nur widerholen und würde hier keinesfalls RPI2 für Torsteuerungen oder sowas verwenden. Ich baue grad mit ESP32 und Tasmota eine Torsteuerung da meine Einhell kaputt gegangen ist. Alle meine ESP32 Projekte laufen seit Jahren problemlos. Wenn hier keine Verbesserung mehr kommt nutze ich den Raspie nur noch zur Virtuellen Steuerung.

[Smallfeuer]

@hasont Ja, ganz meiner Meinung. Ich werde mir jetzt ebenfalls einen WEMOS D1 Mini aufbauen, der spart gleich noch Strom. Dann bin ich die Updates los und schicke das über MQTT - fertig. Macht natürlich viel Arbeit -> hätte einfach auf dem alten Stand bleiben sollen, aber leider gehöre ich zu der Kategorie Mensch die gern auf dem neuesten Stand sind :(. Bleibt die Frage wer diese Fehler im Detail mal in der Bibliothek beräumt?

[Thomas Braun]

@smallfeuer sagte in Test Adapter rpi2 2.x:

Bleibt die Frage wer diese Fehler im Detail mal in der Bibliothek beräumt?

Als erstes würde ich dann mal Issues eröffnen. Ohne Feedback wird sich da vermutlich nichts oder erheblich langsamer was tun.

[Smallfeuer]

Ein Issue dazu gibt es wohl schon, das bestimmte GPIO nicht funktionieren.
Laut Grok3 Analysen und Probieren sämtlicher Lösungsansätze bin ich zum Schluss gekommen -> die GPIO Bibliothek muss für "Bookworm" 32Bit +64Bit für den Pi3B+ komplett überarbeitet werden - jedenfalls was die Ansteuerung über die GPIO Funktion des RPI Adapters angeht.

Hier gibt es ständig fehlerhafte Schaltvorgänge, teils ohne Einwirkungen wird der Eingang meiner GPIO 17 geschalten. Das kann man dann durch einfaches Aufwecken des Systems rückgängig machen. Sehr spaßig.

Jetzt zu meiner Lösung, die vorerst funktioniert und wo mich letztenendes die KI hingeführt hatte:
Node-Red greift direkt auf die GPIO zu (nur möglich in der 32Bit Version von Bookworm).

Über den Palettenmanager (aktivieren in den Adaptereinstellungen) habe ich die

node-red-node-pi-gpio
2.0.6

installiert.
Damit ist es mir jetzt möglich die GPIO wieder vernünftig zu steuern und auszulesen.
Im Node Red muss man nun natürlich die GPIO in mit Funktion und Iobroker out verbinden und
einen Funktion dazwischen packen. Hier der Inhalt für die Funktion beim GPIO Input. Beim Ausgang schalten habe ich (input 1 durch true ersetzt)

// Eingangswert aus msg.payload holen
let input = msg.payload;

// Bedingung prüfen
if (input === 1) {
    msg.payload = true; // Wenn Eingang true ist, Ausgang auf true setzen
} else {
    msg.payload = false; // Sonst Ausgang auf false setzen
}

// Nachricht zurückgeben
return msg;

[Axel21]

@smallfeuer Mich hat diese Meldung gestört, weil sie das einzige Warning in meinen iobroker-Protokollen erzeugt.

nodejs: V 20.19.1 rpi2: V 2.4.0

warn: admin.0 (19971) rpi2 has an invalid jsonConfig: [{"instancePath":"/items/_gpios/items/_pullUpWarning/hidden","schemaPath":"#/patternProperties/%5E.%2B/properties/hidden/type","keyword":"type","params":{"type":"string"},"message":"must be string"},{"instancePath":"/items/_gpios","schemaPath":"#/properties/items/patternProperties/%5E.%2B/allOf/9/if","keyword":"if","params":{"failingKeyword":"then"},"message":"must match \"then\" schema"},{"instancePath":"","schemaPath":"#/if","keyword":"if","params":{"failingKeyword":"then"},"message":"must match \"then\" schema"}]

Ich habe diese Warnings wie folgt ausgeschaltet: Auf meinem Raspi 4B gibt es die Datei:

/opt/iobroker/node_modules/iobroker.rpi2/admin/jsonConfig.json

In dieser gibt es ab Zeile 122 die Zeilen:

"_pullUpWarning": {
                    "type": "staticText",
                    "text": "pullupwarning",
                    "hidden": false,
                    "style": {

Hier habe ich hinter dem "hidden" das "false" in doppelte Anführungszeichen gesetzt.

"_pullUpWarning": {
                    "type": "staticText",
                    "text": "pullupwarning",
                    "hidden": "false",
                    "style": {

Das gleiche habe ich dann noch in der Datei

/opt/iobroker/iobroker-data/files/rpi2.admin/jsonConfig.json

gemacht.

Seither ist das Warning verschwunden.

Auf die Idee bin ich aufgrund der Fehlermeldung gekommen. Offenbar erwartet die Eigenschaft "hidden" den Typ "string", das sieht man korrekt auch einige Zeilen weiter unten in der json-Datei.

Welche der beiden Dateien wirklich wichtig ist, bleibt mir unklar. Zunächst sieht es so aus, als wäre nur die erste wichtig. Löscht man jedoch die zweite funktioniert es gar nicht.
Da es aber nur ein Workaround ist und dieser einen reboot überstanden hat bin ich soweit zufrieden.

Vielleicht kann der Developper @Garfonso dies ja bitte noch prüfen und ggf. richtig korrigieren.

@Garfonso als developper: Vielen Dank für den deutlichen Hinweis, dass man den Adapter deinstallieren muss und das dann zunächst die library zu installieren hat. Das Upgrade von 1.3 hat daraufhin auf Anhieb funktioniert.

[mcm1957]

@axel21
Gibts es issue zu diesem Thema im Adapterrepo? Wenn nicht leg bitte eins an.

[Axel21]

@mcm1957 : done,
https://github.com/iobroker-community-adapters/ioBroker.rpi2/issues/292
Tks für den Hinweis, hätte ich sonst nicht gemacht, weil ich dachte das hier ist das Forum, in dem soetwas reingehört.

[mcm1957]

@axel21
Danke für das Issue. Ja das Forum ist schon OK. In vielen Fällen liegt ja zunächst kein klarer Fehler vor sondern erst die Diskussion mit anderen zeigt ob ein Fehler im Code, ein Bedienungsfehler oder eine ganz spezieller Situation vorliegt. Insofern ist es gut ein Problem mal hier anzusprechen. Meist gibts auch hier im Forum rascher eine Rückmeldung da das mehr Leute sehen / lesen.

Sobald aber klar ist, dass etwas als Fehler (oder auch als Erweiterungswunsch) einzustufen ist ist ein Issue immer sinnvoll. Nur als Issue ist halbwegs sichergestellt dass das nicht untergeht. Auch lesen nicht alle Devs hier im Forum aktiv mit (was beim rpi2 definitiv NICHT der Fall ist).

Ich hoffee ich konnte das ein wenig erläutern.

Und vielen lieben DANK für deine MIthilfe / Fehleranalyse / Feedback.

[Basti97]

Ich habe auch das Problem mit opengpio Installation weiß jemand welchen Befehl ich eingeben muss. Bin langsam am verzwifeln. Ich habe schon nodejs aktualisiert das komische andere Adapter installation klappt nur nicht der rpi 2 Adapter.

iob install rpi2
NPM version: 10.8.2
Installing iobroker.rpi2@2.4.0... (System call)
npm error code 1
npm error path /opt/iobroker/node_modules/opengpio
npm error command failed
npm error command sh -c node-gyp rebuild
npm error make: Entering directory '/opt/iobroker/node_modules/opengpio/build'
npm error   CXX(target) Release/obj.target/opengpio/cpp/opengpio.o
npm error   SOLINK_MODULE(target) Release/obj.target/opengpio.node
npm error make: Leaving directory '/opt/iobroker/node_modules/opengpio/build'
npm error /usr/lib/gcc/arm-linux-gnueabihf/10/crtbeginS.o: file not recognized: file format not recognized
npm error collect2: error: ld returned 1 exit status
npm error make: *** [opengpio.target.mk:133: Release/obj.target/opengpio.node] Error 1
npm error gyp ERR! build error
npm error gyp ERR! stack Error: `make` failed with exit code: 2
npm error gyp ERR! stack at ChildProcess.<anonymous> (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:209:23)
npm error gyp ERR! System Linux 6.1.21-v7+
npm error gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
npm error gyp ERR! cwd /opt/iobroker/node_modules/opengpio
npm error gyp ERR! node -v v20.19.1
npm error gyp ERR! node-gyp -v v10.1.0
npm error gyp ERR! not ok
npm error A complete log of this run can be found in: /home/iobroker/.npm/_logs/2025-07-15T21_32_23_361Z-debug-0.log
host.raspberrypi Cannot install iobroker.rpi2@2.4.0: 1

pi@raspberrypi:~ $ cd /opt/iobroker && npm ls opengpio
iobroker.inst@3.0.0 /opt/iobroker
└── opengpio@1.0.18 extraneous

https://forum.iobroker.net/topic/81652/kann-den-rpi-adapter-auf-meinem-raspberry-nicht-installieren

[Thomas Braun]

@basti97

Auf meinem Systembaut der auch momentan nicht. Allerdings mit anderen Meldungen.
Du scheinst aber da auch mit einem nicht aktuellen Grundsystem unterwegs zu sein, macht es auch nicht wahrscheinlicher, das das funktioniert.

https://github.com/ExpeditionExploration/opengpio/issues/37

Edit:

Doppelposts sind nicht die feine Art...

https://forum.iobroker.net/topic/81652/kann-den-rpi-adapter-auf-meinem-raspberry-nicht-installieren

[Hasont]

Hallo, nachdem ich leider noch immer Fehlermeldungen an den Inputs bekomme (Ohne Tastendruck wird dieser immer wieder mal trotzdem erkannt) hab ich alle meine 6 Inputs (GPIO 17, 18, 22, 23, 24 und 27) nochmal abgeklemmt und so getestet. Beim messen der unbelegten Eingänge fällt auf, dass 18, 22, 24 und 27 gegen 3,3V richtig die 3,3V anzeigen. GPIO 17 und GPIO 23 aber 1,7V.
Ich verwende derzeit nur GPIO 23. Bei der Abfrage über raspi-gpio get werden die Eingänge auch als Input angezeigt (siehe Kopie der Ausgabe) Der Taster wird mit 3,3V vom Raspi gespeist und liegt 10m entfernt.
In der RPI2 Instanz hab ich derzeit 500ms Entprellen eingestellt da bei 100ms noch mehr Fehler vorkamen.
Der Input 24 und 27 werden bei 3,3V gar nicht erkannt und bei 24 geht 23 mit (alles ohne was angeschlossen zu haben). Die Eingänge 17 und 23 sind auch extrem empfindlich. Da reicht schon das Messen mit dem Vielfach aus um die zu aktivieren.

Ich probiere jetzt mal folgendes: Taster an GPIO 18 und 22 und dann schalte ich mein Relais erst wenn beide Eingänge erkannt werden und Berichte was dabei raus kam.

Ev. hat ja jemand eine Idee wo der Fehler noch sein könnte. Insbesonder warum die Eingänge 17 und 23 bei 10k gegen Masse 1,7 V haben gegenüber den anderen 4 Eingängen die sauber auf Masse liegen.
Meine weiteren Threads zum Thema sind auf Seite 433,435,468,476,479,484,493,495 und 509 zu finden.

pi@raspberrypi:/sys/class/gpio $ raspi-gpio get
BANK0 (GPIO 0 to 27):
GPIO 0: level=1 func=INPUT pull=UP
GPIO 1: level=1 func=INPUT pull=UP
GPIO 2: level=1 alt=0 func=SDA1 pull=UP
GPIO 3: level=1 alt=0 func=SCL1 pull=UP
GPIO 4: level=1 func=INPUT pull=UP
GPIO 5: level=1 func=INPUT pull=UP
GPIO 6: level=1 func=INPUT pull=UP
GPIO 7: level=1 func=OUTPUT pull=UP
GPIO 8: level=1 func=OUTPUT pull=UP
GPIO 9: level=0 alt=0 func=SPI0_MISO pull=DOWN
GPIO 10: level=0 alt=0 func=SPI0_MOSI pull=DOWN
GPIO 11: level=0 alt=0 func=SPI0_SCLK pull=DOWN
GPIO 12: level=0 func=OUTPUT pull=DOWN
GPIO 13: level=0 func=OUTPUT pull=DOWN
GPIO 14: level=1 alt=5 func=TXD1 pull=NONE
GPIO 15: level=1 alt=5 func=RXD1 pull=UP
GPIO 16: level=0 func=OUTPUT pull=DOWN
GPIO 17: level=0 func=INPUT pull=DOWN
GPIO 18: level=0 func=INPUT pull=DOWN
GPIO 19: level=0 func=OUTPUT pull=DOWN
GPIO 20: level=0 func=OUTPUT pull=DOWN
GPIO 21: level=0 func=OUTPUT pull=DOWN
GPIO 22: level=0 func=INPUT pull=DOWN
GPIO 23: level=0 func=INPUT pull=DOWN
GPIO 24: level=0 func=INPUT pull=DOWN
GPIO 25: level=0 func=OUTPUT pull=DOWN
GPIO 26: level=0 func=OUTPUT pull=DOWN
GPIO 27: level=0 func=INPUT pull=DOWN
code_text

Edit 5.08 Hab jetzt GPIO 18 genommen und es ist seit 7 Tage Ruhe.
Irgendwas stimmt mit 17 und 23 scheinbar nicht was ja auch der Pegel von 1,7V in Ruhe zeigt. Ev. hat ja einer hier noch eine Idee wie man das ev. mit einem Befehl im Editor zurechtbiegen könnte.

Edit 28.08 Leider noch immer nicht ganz weg. Hab jetzt im Trafoeingang, Trafoausgang und den 24V Ventilen 2,2uF Kondensatoren verbaut. Mal sehen ob es besser wird. Jetzt war es 1 x pro Woche, meist beim Trafo ausschalten,

Würde mich über eine Antwort freuen.