Test Adapter rpi2 2.x

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.

Moppedman

@garfonso

Ich stoppe den io-Broker ja über ssh mit "iob stop". Daher kann ich dir nicht sagen in welchem Zustand die States dann stehen. Der io-Broker läuft dann ja nicht mehr.

Habe aber festgestellt das beim Anhalten der Instanz des rpi2 Adapters die Relais das gleiche Verhalten zeigen und abfallen.

Ich gehe davon aus, das beim ordnungsgemäßem Runterfahren des io-Brokers eine Routine aufgerufen wird die alle konfigurierten Ausgänge auf "0" bzw. keinen Strom / Spannung schaltet. Denn alle geschalteten Relais fallen beim alten Adapter ab und die Kontroll-LED auf meiner Relaisplatine erlischt.

Habe mal das Verhalten getestet und in nachfolgende Tabelle eingetragen. Die States habe ich nach den Stoppen des rpi2 Adapters in den Objekten nachgeschaut und dann eingetragen. Man sieht das beim alten Adapter unabhängig vom Startwert "0" oder "1" beim Setzen auf FALSE das Relais anzieht. Beim neuen Adapter ist das Anziehen des Relais abhängig von Startwert. Bei "0" und FALSE ist das Relais AN. Bei "1" und FALSE ist das Relais aus.

Garfonso

@smallfeuer said in Test Adapter rpi2 2.x:

hoffe sie kommen nach dem nächsten Update nicht zurück.

Öhm... das hoffe ich auch.

Ich sehe da nichts, was dein Problem beheben würde. kopfkratz

@tobias78 said in Test Adapter rpi2 2.x:

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.

Danke für die Analyse. Aber welche Version des Adapters?
Wenn ich es richtig sehe, müsste dort seit 2.2.1 panel statt tabs stehen, was tatsächlich falsch war. table ergibt wenig Sinn. Funktioniert damit noch die Configurationsseite?

Garfonso

@moppedman said in Test Adapter rpi2 2.x:

Ich stoppe den io-Broker ja über ssh mit "iob stop". Daher kann ich dir nicht sagen in welchem Zustand die States dann stehen. Der io-Broker läuft dann ja nicht mehr.

Dann stoppe doch mal nur den Adapter?
Wobei ich nicht glaube, dass die States irgendwas mit dem Verhalten zu tun haben, wenn du den ganzen ioBroker stoppst...

Und ja, das kann sein, dass das Verhalten anders ist, weil die GPIOs anders angesprochen werden.

@moppedman said in Test Adapter rpi2 2.x:

Ich gehe davon aus, das beim ordnungsgemäßem Runterfahren des io-Brokers eine Routine aufgerufen wird die alle konfigurierten Ausgänge auf "0" bzw. keinen Strom / Spannung schaltet.

Interessant, dass du das erwartest. Ist das Konsensmeinung?
Ich würde zugegebenermaßen eher erwarten, dass nichts mehr passiert, wenn ich den ioBroker beende.

@moppedman said in Test Adapter rpi2 2.x:

Man sieht das beim alten Adapter unabhängig vom Startwert "0" oder "1" beim Setzen auf FALSE das Relais anzieht.

Das heißt, beim alten Adapter war "Startwert 1" fehlerhaft und hat einfach gar keinen Unterschied gemacht? Oder siehst du irgendeinen anderen Unterschied, den du nicht in der Tabelle hast?

Und zur Spalte "gpioinfo" wäre noch interessant, was die sagt, wenn der Adapter beendet wurde.

Smallfeuer

@moppedman

Hast du dabei mal die Datenpunkte getrakt, beim Start des Adapter?
Ich hatte den Wechsel auch nur in der Datenbank gesehen, bzw. am Torantrieb gemerkt, dem reicht ja ein kurzer Impuls zum Öffnen.
Das Endergebnis war bei mir ebenfalls korrekt auf die Voreinstellung, nur halt Signalflattern zwischendrin.
Vielleicht war es aber nur ein BUG bei meiner 1. Installation. Wie gesagt, jetzt läuft es wie immer.

NEWS

Test Adapter rpi2 2.x

Support us

749

32.4k

81.4k

1.3m