Test Adapter rpi2 2.x

[Moppedman]

@garfonso

Ich kann natürlich in der Config das von Ausgabe, Anfangswert 1" auf Anfangswert 0 umstellen. Erschien mir aber nicht logisch, da ich davon ausgegangen bin das die gesamte Konfiguration gleich bleibt.

Wolle mich erst mal versichern bevor ich das in der Config ändere. Von dem Problem hatte sonst keiner berichtet und ich hatte Sorge das etwas bei der Installtion falsch gelaufen ist.

Habe jetzt getestet und bin der Meinung das da was nicht stimmt. Wenn ich die Ausgänge bei alte PI gesetzt habe und dann über SSH den IOB anhalte schalten sich sofort ale Ausgänge weg. Das sollte auch so sein. Beim neuen PI5 bleiben die Ausgänge anstehen, auch wenn ich den IOB anhalte.

Kann es sein das ich in der CONFIG.TXT die beim Booten vom Pi angezogen wird den GPIO irgendwie configurieren muss.

[Moppedman]

@garfonso

Beim Testen ist mir noch aufgefallen das in dem "alten" Adapter es zwei Auswahlfelder gab Tasten bzw. Eingabe "hochgezogen"
Die Auswahl bei der Ausgabe gibt es im neuen Adapter nicht mehr. Es gibt aber den Hinweis das Pull-Up/Down nicht wirklich unterstüzt wird. Wo kann ich das denn heute in deinem Adapter einstellen?

Ich hatte aber einmal die Warnmeldung beim Booten vom admin.0 Adapter bekommen

2024-11-24 14:56:40.286 - warn: admin.0 (1298) rpi2 has an invalid jsonConfig: [{"instancePath":"/items/_monitoring/type","schemaPath":"#/definitions/componentType/enum","keyword":"enum","params":{"allowedValues":["accordion","alive","autocomplete","autocompleteSendTo","certificate","certificates","checkLicense","checkbox","chips","color","coordinates","cron","custom","datePicker","deviceManager","divider","file","fileSelector","func","header","icon","image","imageSendTo","instance","interface","ip","jsonEditor","language","number","objectId","panel","password","pattern","port","qrCode","room","select","selectSendTo","sendTo","setState","slider","state","staticImage","staticLink","staticText","table","text","textSendTo","timePicker","user","uuid"]},"message":"must be equal to one of the allowed values"},{"instancePath":"","schemaPath":"#/if","keyword":"if","params":{"failingKeyword":"then"},"message":"must match "then" schema"}]

Kannst du das Zuordnen ?

[Garfonso]

@moppedman said in Test Adapter rpi2 2.x:

Ausgabe, Anfangswert 1

Ah, der Ausgang steht auf "Anfangswert 1" und stand es auch schon und das Verhalten sich jetzt geändert? Das war mir beim Lesen deines ursprünglichen Post nicht ganz klar. (Warum auch immer, scheinbar hab ich das überlesen, nun lese ich es da sehr klar. )

Dann müssen wir da nochmal gucken... bin mir nicht ganz sicher, ob ich das gewünschte Verhalten des Adapters richtig verstanden habe.

Mein Verständnis bisher ist:

• Anfangswert 0 (bzw. nur "Ausgang"):
  • true im Objekt rpi2.0.gpio.X.state führt zu 1 am GPIO, also Strom da.
  • false im Objekt rpi2.0.gpio.X.state führt zu 0 am GPIO, also kein Strom da.
• Anfangswert 1:
  • true im Objekt rpi2.0.gpio.X.state führt zu 0 am GPIO, also kein Strom da.
  • false im Objekt rpi2.0.gpio.X.state führt zu 1 am GPIO, also Strom da.

So ist es implementiert (zumindest sollte es so sein). Gerne mal das debug log anmachen. Da sollte bei einem GPIO mit "Ausgangswert 1" eine Debug-Nachricht kommen, dass er den Wert rumdreht.

Was dazu gekommen ist, ist, dass der Adapter bei Start alle Zustände bei ioBroker ausliest und die GPIOs entsprechend setzt. Führt das vielleicht zu Verwirrung?

@moppedman said in Test Adapter rpi2 2.x:

Die Auswahl bei der Ausgabe gibt es im neuen Adapter nicht mehr

Das ist korrekt, weil der komplette Support für GPIO als "Taster" weggefallen ist. Für einen einfachen Klick war das eh das gleiche, wie ein GPIO als Eingang. Und für die Mehrfachklicks hätte ich da viel nach implementieren müssen, was vorher eine Bibliothek gemacht hat, daher wollte ich vor dem Aufwand erstmal Use-Cases sammeln. Da ist bisher nichts zusammen gekommen.

@moppedman said in Test Adapter rpi2 2.x:

Es gibt aber den Hinweis das Pull-Up/Down nicht wirklich unterstüzt wird. Wo kann ich das denn heute in deinem Adapter einstellen?

Aktuell gar nicht, aber das ist auch keine Änderung gegenüber der alten Adapterversion. Der Adapter konnte Pull-up/Pull-Down noch nie wirklich und hat einfach die Booleans rumgedreht (also dann 1->false usw.).
Für die neue Adapterversion steht das in Aussicht, sobald die Bibliothek, die er nutzt (oder eine Alternative) das kann. Da gibt es aktuell Probleme mit dem bauen des Moduls und es ist noch nicht ganz klar, wie das gelöst werden kann.

Grundsätzlich kannst du das "Software" Pull-up aber pro GPIO einstellen. Also in der Tabelle in der Spalte "Hochziehen" anhaken. Pull-Down macht gar nichts, daher habe ich "Herunterziehen" zwar vorgesehen, aber nicht aktiv, um nicht irgendwas zu suggerieren, was nicht passiert.

@moppedman said in Test Adapter rpi2 2.x:

Kannst du das Zuordnen ?

Ja, da war ein Fehler im Code der Konfigurationsoberfläche. Das ist aber behoben (und hatte auf die Funktionalität, also was gespeichert wird usw.) keinen Einfluss.

[Moppedman]

@garfonso

Hi und erst mal vielen Dank das du so schnell antwortest. Echt Klasse.

Ja, jetzt hast du es richtig verstanden.

Wenn man sich die Doku auf Rasperry.com zum GPIO anschaut steht da folgendes:

The gpio directive allows GPIO pins to be set to specific modes and values at boot time in a way that would previously have needed a custom dt-blob.bin file. Each line applies the same settings (or at least makes the same changes) to a set of pins, addressing either a single pin (3), a range of pins (3-4), or a comma-separated list of either (3-4,6,8).

The pin set is followed by an = and one or more comma-separated attributes from this list:

ip - Input
op - Output
a0-a5 - Alt0-Alt5
dh - Driving high (for outputs)
dl - Driving low (for outputs)
pu - Pull up
pd - Pull down
pn/np - No pull

gpio settings apply in order, so those appearing later override those appearing earlier.

Examples:

# Select Alt2 for GPIO pins 0 to 27 (for DPI24)
gpio=0-27=a2

# Set GPIO12 to be an output set to 1
gpio=12=op,dh

# Change the pull on (input) pins 18 and 20
gpio=18,20=pu

# Make pins 17 to 21 inputs
gpio=17-21=ip

The gpio directive respects the "[…​]" conditional filters in config.txt, so it is possible to use different settings based on the model, serial number, and EDID.

GPIO changes made through this mechanism do not have any direct effect on the kernel. They don’t cause GPIO pins to be exported to the sysfs interface, and they can be overridden by pinctrl entries in the Device Tree as well as utilities like pinctrl.

Note also that there is a delay of a few seconds between power being applied and the changes taking effect - longer if booting over the network or from a USB mass storage device.

Dabei ist das dh / dl sprich Driving High und Driving Low des Ausgangs dafür verantwortlich ob der Transistorausgang as Sink or Source aggiert (also Spannung setzen oder auf Masse ziehen) . Die Standardeinstellung beim Pi GPIO ist "source" wenn er auf HIGH steht "sink" wenn LOW.

Diese Konfiguration würde über die config.txt beim Booten geladen werden wenn ich das da eintrage. Was ich nicht weis ob dann der RPi Adapter diese Basiseinstellung "überschreibt" bzw. "umkonfiguriert".

Nachfolgend ein Auszug vom DEBUG log. beim Starten des Adapters. Beim Lesen von unten nach oben wurde erst (exemplarisch) vom Adapter Ausgang 5 & 6 auf "OutHigh" gesetzt. Das sollte dem dl Driving High entsprechen.

Und dann wird das Signal von FALSE auf TRUE invertiert und schlußendlich der Ausgang auf FALSE gesetzt

rpi2.0
	2024-11-25 19:43:17.160	debug	Written false into port 6
rpi2.0
	2024-11-25 19:43:17.160	debug	Inverting value from false to true for port 6 because set to outhigh
rpi2.0
	2024-11-25 19:43:17.151	debug	Written false into port 5
rpi2.0
	2024-11-25 19:43:17.150	debug	Inverting value from false to true for port 5 because set to outhigh
rpi2.0
	2024-11-25 19:43:17.142	debug	Port 6 direction: outhigh
rpi2.0
	2024-11-25 19:43:17.142	debug	Port 5 direction: outhigh
rpi2.0
	2024-11-25 19:43:17.142	debug	GPIO chip undefined initialized
rpi2.0
	2024-11-25 19:43:17.142	debug	Got chip: class DefaultDevice extends classes_1.Device { }
rpi2.0
	2024-11-25 19:43:17.141	debug	Using GPIO chip 4 for Raspberry Pi 5 or newer.
rpi2.0
	2024-11-25 19:43:17.141	debug	Got 5 from Raspberry Pi 5 Model B Rev 1.0

MOD-EDIT: Code in code-tags gesetzt!

Mache doch bitte mal bei dir den Test wenn du den Ausgang gesetzt hast und das Relais ist angezogen und du den IOB über SSH anhälst ob dann die Relais abfallen.

Final noch der Hinweis das ich im Adapter KEIN Kästchen habe einen "Haken" für den pull.up / pull down zu setzen.

Sorry, ist jetzt recht lang geworden aber ging nicht anders.

[stenmic]

@garfonso sagte in Test Adapter rpi2 2.x:

Das ist korrekt, weil der komplette Support für GPIO als "Taster" weggefallen ist. Für einen einfachen Klick war das eh das gleiche, wie ein GPIO als Eingang. Und für die Mehrfachklicks hätte ich da viel nach implementieren müssen, was vorher eine Bibliothek gemacht hat, daher wollte ich vor dem Aufwand erstmal Use-Cases sammeln. Da ist bisher nichts zusammen gekommen.

Danke erstmal für deine (eure) Arbeit!
Bevor ich den Adapter teste, noch eine Frage.

Ich nutze aktuell einen Eingang der GPIOs mit einem Reed-Kontakt (Gaszähler)
Für mich ist das ein Taster. Funktioniert das mit dem neuen Adapter.
Eventuell habe ich da eine Verständnisproblem

[Garfonso]

@stenmic

Am Ende kommt es darauf an, wie du den Adapter Konfiguriert hast. Wenn du da nicht "Eingang" sondern "Button" (oder so) eingestellt hast, dann wird die neue Version den wie einen "Eingang" behandeln, was am Ende heißt, dass sich der state-Name ändert, von click oder sowas nur noch auf "state".

Wenn du den aber auch jetzt schon als "Eingang" im Adapter konfiguriert hast, ändert sich da nichts.

[stenmic]

@garfonso ok, aktuell ist der Sensor als Eingang deklariert. Dann werd ich die Tage mal umstellen.

[searcher57]

@garfonso
Auch ich möchte mich für Deine (Eure) Mühen bedanken, dass der RPI2 Adapter wieder zu nutzen ist.
Ich nutze ihn unter anderem auch um den Gaszähler-Stand auszulesen. Hier habe ich das Problem, dass jeden Tag zu viel gezählt wird. Ich habe sowohl im Adapter mit der Entprellung, als auch mit dem anhängenden Script versucht das in den Griff zu bekommen. Leider ohne Erfolg. Hast Du noch eine Idee?

[Garfonso]

@searcher57
Warum stellst du den trigger auf "wird aktualisiert"? Damit müsstest du doch jeden Impuls zweimal zählen, weil der state sich zu true und dann auf wieder auf false ändert, also zwei "Aktualisierungen".

Sonst hab ich keine Idee, hab aber selber auch noch keine Impulszähler (erfolgreich) gebaut.

[searcher57]

@garfonso said in Test Adapter rpi2 2.x:

@searcher57
Warum stellst du den trigger auf "wird aktualisiert"? Damit müsstest du doch jeden Impuls zweimal zählen, weil der state sich zu true und dann auf wieder auf false ändert, also zwei "Aktualisierungen".

Sonst hab ich keine Idee, hab aber selber auch noch keine Impulszähler (erfolgreich) gebaut.

Ich habe es auf "ist wahr" gestellt und werde es beobachten. Danke!

[searcher57]

@searcher57 said in Test Adapter rpi2 2.x:

@garfonso said in Test Adapter rpi2 2.x:

@searcher57
Warum stellst du den trigger auf "wird aktualisiert"? Damit müsstest du doch jeden Impuls zweimal zählen, weil der state sich zu true und dann auf wieder auf false ändert, also zwei "Aktualisierungen".

Sonst hab ich keine Idee, hab aber selber auch noch keine Impulszähler (erfolgreich) gebaut.

[Moppedman]

Hi @garfonso,

ich habe das eben noch einmal getestet. Wenn ich die Einstellung auf Startwert 0 ändere funktioniert mein Bewässerungsprogram wie es soll bzw. es früher unter dem alten Apapter auch gemacht hat. Auch wenn mir das nicht logisch erscheint das jetzt die gpio Einstellungen gegenüber früher nun "invertiert" konfiguriert werden mussten um mit dem unveränderten Programm arbeiten zu können.

Eins jedoch funktioniert noch nicht was m.E. wichtig wäre zu korrigieren. Wenn ich beim alten Adapter über SSH den IO-Broker angehalten habe wurden alle gesetzen Ausgänge auf "NULL" gesetzt. Das sollte aus Sicherheitsgründen auch so sein.

Kannst du das bitte mit in den Entwicklungsplan aufnehmen und mit einem der nächsten Releases anpassen.

[searcher57]

@garfonso said in Test Adapter rpi2 2.x:

@searcher57
Warum stellst du den trigger auf "wird aktualisiert"? Damit müsstest du doch jeden Impuls zweimal zählen, weil der state sich zu true und dann auf wieder auf false ändert, also zwei "Aktualisierungen".

Sonst hab ich keine Idee, hab aber selber auch noch keine Impulszähler (erfolgreich) gebaut.

Also, ich habe es auf "wurde geändert" gestellt und sowohl im Script, als auch in der Instanz, eine Verzögerung von 200 ms eingegeben. Seit drei Tagen stimmt der Wert exakt überein.

[Garfonso]

@moppedman said in Test Adapter rpi2 2.x:

wurden alle gesetzen Ausgänge auf "NULL" gesetzt.

Hm? Was bedeutet das genau? Wurden die states auf null gesetzt? Gingen die GPIOs dabei auch aus (oder an?)?

[Smallfeuer]

@garfonso

Ich habe mich jetzt getraut die aktuellste Version 2.2.1 zu installieren auf einem RPi 3.
Dieser dient unter anderem zum Öffnen einer Tür mittels Relais -Steuerung.

Nun aktuell folgendes Problem. Der Ausgang schaltet bei Adapter-Neustart kurzzeitig mehrfach von True auf False. In dem Moment schaltet er das Relais. Der Ausgang muss dazu beim mir auf 1 stehen bei Start. Eine andere Steuerung ist nicht möglich, da sonst das Relais bei Stromausfall am Pi schalten würde und das Tor öffnet.
Geht er auf 0, schaltet das Relais und das Tor geht auf.

Aktuell also Tür auf bei Stromausfall und bei Adapter Neustart. Kannst du das checken? In den 1.x er Versionen haben wir den Fehler damals behoben.

[Laser]

@smallfeuer Irgend etwas sicherheitsrelevantes würde ich nicht über IO Broker machen. (Mache ich auch nicht). Da kann immer etwas quer hängen...

[Smallfeuer]

@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

[mcm1957]

@smallfeuer said in Test Adapter rpi2 2.x:

Der Iobroker übernimmt seit Jahren zuverläassig viele Sicherheitsrelevante Sachen, ohne Probleme.

Ich glaube ich verstehe deine Aussage durchaus. Dennoch muss auch ich betonen, dass das ioBroker System NICHT für sicherheitsrelevante Aufgaben designed und geeignet ist.

Natürlich kann jeder User selbst entscheiden was er wie löst. Eine Steuerung der Teichpumpe würde ich auch nicht als sicherheitsrelevant sehen (auch wenn Fische gefährdet sind) - es wird wohl kaum jemand redundante Pumpen installieren weil eine normale Teichpumpe ja wohl auch ausfallen kann. Andrerseits ist ioBroker definitiv ungeeignet die Heizleistung eines Kessels zu steuern - oder genauer gesagt, einen geprüften Überhitzungsschutz zu ersetzen.

Ob nun das Öffnen / Entriegeln eines Tors sicherheitskritisch ist hängt wohl vom Anwendungsfall ab. Ein Zauntor wird kaum ein Problemdarstellen wenn es versehentlich offen steht - die Eingangstüre eines Juweliers würde ich nicht via ioBroker steuern.

Also generell ist die Aussage "ioBroker ist NICHT für sicherheitskritische Anwendungen geeignet" vollkommen richtig.

[Smallfeuer]

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

[Tobias78]

Kurze Frage:

Ich bekomme beim Start der aktuellen Version die Fehlermeldung ins log:

rpi2 has an invalid jsonConfig: 
[{"instancePath":"/items/_monitoring/type","schemaPath":"#/definitions/componentType/enum","keyword":"enum","params":{"allowedValues":["accordion","alive","autocomplete","autocompleteSendTo","certificate","certificates","checkLicense","checkbox","chips","color","coordinates","cron","custom","datePicker","deviceManager","divider","file","fileSelector","func","header","icon","image","imageSendTo","instance","interface","ip","jsonEditor","language","number","objectId","panel","password","pattern","port","qrCode","room","select","selectSendTo","sendTo","setState","slider","state","staticImage","staticLink","staticText","table","text","textSendTo","timePicker","user","uuid"]},"message":"must be equal to one of the allowed values"},{"instancePath":"","schemaPath":"#/if","keyword":"if","params":{"failingKeyword":"then"},"message":"must match \"then\" schema"}]

Editiere ich die Datei mit

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

Steht dort:

"i18n": true,
    "type": "table",
    "items": {
        "_monitoring": {
            "type": "tabs",
            "label": "Monitoring",
            "items": {
                "_explanation": {
                    "type": "staticText",
                    "text": "MonitoringExplanation",
                    "newLine
": true
                },
...

Richtig müsste in Zeile 5 statt:

"type": "tabs",

also

"type": "table",

sein, oder?

Damit kommt die Fehlermeldung nicht und der Adapter funktioniert. Falls das richtig ist, könnte / müsste dies im Quellcode angepasst werden.
Der Fehler tritt auch bei einer "frischen" Installation des Adapters auf.