Willkommen im Loxone Community Forum. Um alle Funktionen nutzen und sehen zu können, registriere dich bitte zuerst. Dies gilt auch für das herunterladen von Dateien.
Bitte im Titel immer zuerst den Namen des Plugins hinschreiben
Hi Joerg,
habe das neue Pre-Release v2.0.5 auch gerade nochmal getestet. Funktioniert und auch die States nach LB Neustart sind immer noch da. Vielen Dank.
Hallo,
Kann man bei den Eingängen auch Tep. und Feuchtefühler anhängen?
m_ike
Willkommen hier im Forum m_ike,
kann man bestimmt. Es wäre aber gut, wenn Du das was Du vorhast etwas genauer beschreiben würdest.
Einen Temperatur- und/oder Feuchtesensor an einen GPIO macht wenig Sinn. Oder willst du einen 0-10V Analogsensor anschließen?
Hy joesie,
Spät aber doch die gewünschte Datei für dich. Hatte leider etwas Stress die letzten Tage!!
Hab die Relais mit den Jumpern gekauft da ich diese für besser empfunden hätte! Aber das Problem ist, dass bei einem Neustart vom Miniserver oder LB alle Relais angezogen haben und erst nach einem Ausgangsänderung vom Miniserver umschalten auf den richtigen Zustand. Ist halt teilweise im Programm etwas schwierig händeln.Gibt es eine Neustartmeldung vom LB? dann wäre das ganze einfacher.
Danke für eure Infos
LG Stefan
danke für das Log. Ich habe inzwischen den Fehler gefunden und behoben.
Da der letzte Zustand der Ausgänge nicht persistiert werden, verliert der LB die Information beim Neustart. Somit werden alle Ausgänge beim Start vom LB ausgeschaltet (3,3V am Ausgang). Wei gesagt, ich habe noch das invertieren auf der to do Liste. Wird aber sicherlich noch ein wenig dauern, bis es umgesetzt ist.
Aktiv sendet der LB soweit ich weiß keine Meldung.
Der Broker sendet aber eine Uptime als MQTT Message. Die könntest Du ggf. auswerten und entsprechend reagieren.
Da der letzte Zustand der Ausgänge nicht persistiert werden, verliert der LB die Information beim Neustart.
Das stimmt leider. Nur mal so eine Idee für die ToDo-Wunschliste.
Wenn alle States der konfigurierten GPIOs immer nach einem Statuswechsel den Zustand in eine "JSON-Konfig-Datei" schreiben, könnte dessen Inhalt nach einem LB-Neustart als "Default" eingelesen werden und somit ist der letzte Zustand wiederhergestellt.
Vielen Dank an alle, die mich durchs testen und beraten unterstützt haben.
Ich habe soeben die aktuelle Version 2.0.7 offiziell released.
Wenn Euch etwas fehlt, oder anders lösen möchtet, dann lasst uns das gerne hier diskutieren. Alle Themen die noch in der nächsten Zeit umgesetzt werden, stehen im issue Tracker https://github.com/joesie/GPIO/issues
Ich wünsche allen viel Spass mit der Version und viel Erfolg mit Euren Projekten.
Jörg
Hallo Jörg,
vielen Dank dafür.
Kann es sein, das Du die Release-Version nicht auf 2.0.7 hochgesetzt hast? Bei mir steht nach der Installation noch 2.0.6 in der Pluginübersicht. Oder besser deinstallieren und neu installieren?
Kannst Du meinen Wunsch aus #38 auch mit in die "Umsetzungsliste" mit aufnehmen? Oder geht das gar nicht?
Ich habe noch ein wenig geschaut und mich und mich mit ein paar LB-Entwicklern ausgetauscht.
Aktuell werde ich das speichern des letzten Schaltzustandes nicht mit auf die Umsetzungsliste nehmen.
Es gibt bereits eine Möglichkeit den Zustand zu merken. Mit "retain" gesendete Kommandos werden im Broker gespeichert und werden nach dem Starten des LB automatisch vom Plugin wieder eingesetzt.
Wichtig hierbei ist jedoch, dass der LB "sauber" herunter gefahren wird. Einfach Stecker ziehen funktioniert nicht.
Hallo Jörg,
vielen Dank für den Austausch, um dafür eine Lösung zu finden.
Das wäre zwar eine Möglichkeit, wie Du aber ja schon selber sagst, ist das keine wirkliche "Wiederherstellung". Je nachdem wie der LB abgeschaltet wurde.
Ich hatte eigentlich an etwas gedacht, wie z. B. im FHEM mit den Log-Dateien der Module. Hier wird z. B. nur nach jeder Änderung ein Statusaktualisierung in die Log-Datei geschrieben (Thema: "Device Readings"). Ob diese dann auch immer sofort gespeichert wird, kann ich nicht sagen. Könnte man ja einstellbar machen. Z. B. jede Minute, alle 15 min. stündlich etc.
Evtl. wäre natürlich auch eine Auslagerung des Speicherorts z. B. auf eine SSD oder zweite SD-Card (Über USB-Adapter) möglich, wenn die Gefahr einer zu schnellen Beschädigung der LB-SD Card bestünde. Die kosten ja heute kaum mehr Euros.
Wobei mir momentan noch nicht ganz klar ist, um wie viele Speichervorgänge bzw. Schreibvorgänge es sich eigentlich handeln würde. Müsste ja eigentlich gleich, zur Änderung mit der die GPIOs geschaltet werden, sein.
@Hesch@
Der Weg, den Jörg beschrieben hat, ist grundsätzlich der Richtige.
Am LB haben wir alles unternommen, Schreibvorgänge auf die SD zu verringern. Der MQTT Broker speichert seine Retain-Datenbank nur alle 24 Stunden.
Das wäre ein Weg, das konfigurierbar zu machen.
Die Broker-Datenbank wird natürlich bei jedem normalen Shutdown ebenso gespeichert, sei es per UI oder an der Shell (poweroff, shutdown,...).
Jörg kann nicht wissen, ob du alle drei Tage einen GPIO änderst, oder (überspitzt gesagt) ein PWM-Signal mit 20 Hz über die Leitung jagst.
Vorstellig wirst du aber bei uns (LB-Core), wenn dein LB nicht mehr bootet.
Der Miniserver speichert seine Zustände BTW nur alle 60 Minuten.
Dazuzufügen ist noch, dass das ext4 Filesystem des LB/Linux schon wesentlich stabiler ist als das von Windows, dennoch ist es immer noch ein Filesystem mit Schreibzugriffen auf eine Hardware. Wenn Du den LB meinst ständig einfach von der Spannungsversorgung zu trennen, geht Dir auch hier früher oder später das Filesystem den Bach runter. So ein OS sollte IMMER ordnungsgemäß heruntergefahren werden. Wo ist also das Problem?
Am LB haben wir alles unternommen, Schreibvorgänge auf die SD zu verringern. Der MQTT Broker speichert seine Retain-Datenbank nur alle 24 Stunden.
Das wäre ein Weg, das konfigurierbar zu machen.
Ich will auf keinen Fall PWM mit 20 Hz oder anderen Frequenzen auf dem LB betreiben. Dafür gibts andere, besser geeignete Boards (z. B. Arduino)
Ich hatte nur gedacht, dass ähnlich wie die FHEM-Log-Dateien fortlaufend geschrieben werden, dann z. B. alle 30 oder 60 min. der Status abgespeichert werden könnte.
Ich schalte die LB GPIOs derzeit nur max. 20 - 50 mal pro Tag. Aber das mit dem Retain ist wohl ein sehr guter Ansatz.
Ein ordentliches Herunterfahren des LB ist natürlich immer vorzuziehen und ist auch bei mir Standard. Ich dachte nur an eine harten Shutdown, wenn z. B. die Spannungsversorgung mal versagt.
Am LoxBerry landen die FHEM-Logs auch in der Ramdisk. Und weil FHEM seine Logs nie freigibt, sterben die LoxBerrys wegen voller Ramdisk.
FHEM würde seine Logs am normalen Raspberry bis in die Unendlichkeit auf die SD schreiben, und niemand kann sie aufräumen.
FHEM ist in keinem Maße für SD-Karten geeignet.
Hallo Christian und svethi,
vielen Dank für Eure detaillierten Infos. Das mit dem FHEM erklärt natürlich Eure Zurückhaltung.
Daraus ergibt sich aber für mich eine weitere Frage bezüglich des LB FHEM-Plugins. Hat dieses dann auch die beschriebenen Nachteile?
Ich hatte meine Log-Dateien monatlich erstellen lassen und "räume" diese immer alle 2- 3 Monate auf bzw. lösche diese.
joesie kommentierte 22.Mär.2021, 13:52
Wenn Du z,B. GPIO 20 ausschaltest, liegen an dem PIN 3,3V gegen Masse an. Wenn dieser eingeschaltet ist, liegen 0V gegen Masse an.
Hallo Jörg,
habe jetzt nochmal etwas getestet und leider auch erst jetzt gesehen, dass Du die Schaltzustände der GPIOs in Bezug auf den Befehl invertiert hast.
"On" > 0V - Low > MQTT State = 1
"Off" > 3,3 V - High > MQTT State = 0
Hatte das einen Grund bzw. kann das auch wieder relativ einfach invertiert werden? Ich frage nur, da meine bisherige Schaltung hinter den LoxBerry GPIOs an die bisherige Version GPIO v1 ausgelegt war und da war es nicht invertiert.
Edit 30.04.2021 23:55 Uhr:
Nachdem ich mir Dein Python-Script "gpio2mqtt.py" bezüglich meines Anliegens näher betrachtet habe, habe ich zumindest für mich folgende Lösung gefunden :
Zeile 212 > tausche "GPIO.HIGH" mit "GPIO.LOW"
Zeile 222 > tausche "GPIO.LOW" mit "GPIO.HIGH"
Zeile 225 > tausche "GPIO.HIGH" mit "GPIO.LOW"
Beim Austesten der einzelnen GPIOs ob der tatsächliche GPIO Schaltzustand auch mit dem MQTT-State übereinstimmt ist mir noch folgendes aufgefallen;
Es ist zwar möglich den GPIO 27 zu schalten, in der MQTT-Overview wird der "loxberry-3_gpio_set_27" auch auf 1 gesetzt, der GPIO-Pin selbst wird aber nicht auf 1 gesetzt. "loxberry-3_gpio_27_state" ändert sich auch nicht von 0 auf 1.
Erst nachdem ich in der Zeile 259 den GPIO Range-Bereich von "(0, 27)" auf "(0, 28)" erhöht hatte, wurde der GPIO 27 auch wirklich umgeschaltet und "loxberry-3_gpio_27_state" wird auf 1 gesetzt.
Kann aber nicht sagen, ob das Absicht war oder ein Bug.
danke fürs mitdenken Ich invertiere die Ausgänge nicht. Das ist das Standardverhalten des RPI bzw. der verwendeten Bibliothek.
Man kann es so wie oben von dir beschrieben machen, dann sind die Ausgänge jedoch programmatisch invertiert.
Ich habe es auf der TODO Liste, dass der Anwender die Ausgänge wahlweise invertieren kann. Leider bin ich aktuell wieder projektmäßig sehr ausgelastet.
Mit dem Ausgang 27 schaue ich mir an. Sieht aber wirklich nach einem Bug aus.
Wir verarbeiten personenbezogene Daten über Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen, Werbung zu personalisieren und Websiteaktivitäten zu analysieren. Wir können bestimmte Informationen über unsere Nutzer mit unseren Werbe- und Analysepartnern teilen. Weitere Einzelheiten finden Sie in unserer Datenschutzrichtlinie.
Wenn Sie unten auf "Einverstanden" klicken, stimmen Sie unserer Datenschutzrichtlinie und unseren Datenverarbeitungs- und Cookie-Praktiken wie dort beschrieben zu. Sie erkennen außerdem an, dass dieses Forum möglicherweise außerhalb Ihres Landes gehostet wird und Sie der Erhebung, Speicherung und Verarbeitung Ihrer Daten in dem Land, in dem dieses Forum gehostet wird, zustimmen.
Tweet
Kommentar