Posts by Bracew

    Danke für Deine Hilfe.


    Jedoch, schlägt der Watchdog nicht stündlich, täglich, ... o.ä. zu, sondern es war überraschend. Wie gesagt, läuft der Pi mit der selben Konfiguration seit längerem stabil.


    Um "verdächtige bzw. in Frage kommende" Dienste temporär zu beeinflussen müsste ich ja erst einmal verdächtige identifizieren.


    Zunächst einmal gehe ich davon aus, dass der Watchdog im weiteren nicht regelmäßig zuschlägt. Vielleicht hat im Pi-System auch nur ein zufälliger "Furz quer gelegen" und es ist daher zu einer Überlastung gekommen.


    Gibt es eine Watchdog-Einstellung, so dass der Watchdog kurz vorm Reboot noch ein Snapshot ähnlich "top -n 1" macht um zu sehen, welcher Dienst die Überlastung provoziert?

    Die swappiness ist im Moment 60:

    Code
    cat /proc/sys/vm/swappiness
    60

    Ich habe das mal gegoogle. Ist wohl der Standardwert

    Quote

    Der Wert kann zwischen 10 und 100 festgelegt sein.

    Höher bedeutet, unbenutzter Speicher wird schneller ausgelagert.

    Linux-Distributionen arbeiten meist mit einem Standardwert von 60. Dies ist eine gute Balance für verbreitete Systeme, egal ob Server oder Desktop, mit mechanischer Festplatte.

    Wie und warum kommst Du auf 2?


    Wie kann ich die Ursache finden? Gibt es keine Logs oder ähnliches von gestern, wo ich nachschauen könnte, was die hohe CPU-Last zum Auslösen des Watchdogs erzeugt hat?

    Code
    free -m
                  total        used        free      shared  buff/cache   available
    Mem:           3787         285        1037          38        2463        3306
    Swap:          1023           1        1022

    im Moment:

    15:38:28 up 17:39, 1 user, load average: 0,00, 0,01, 0,06


    Die /etc/watchdog.conf auf meinem pi ist vom Juli 2018. Leider weiß ich heute nicht mehr, warum ich die 'max-load-5 = 18' damals eingetragen habe. Vermutlich geschätzter Wert für 'Overload'.

    Normalerweise dümpelt der pi unter 1, so dass ich 18 schon sehr hoch finde für das 5 Minuten-Mittel.


    Aber, wie kann ich die Ursache finden?

    Die /etc/watchdog.conf meines pi ist:

    Hallo,


    mein RasPi läuft seit längerer Zeit sehr stabil. Heute Morgen hat er mich jedoch mit einer E-Mail wie folgt begrüßt:


    Wie kann ich rausfinden warum der watchdog einen reboot ausgelöst hat, warum er 'load average too high' hat, was ist Schuld?

    Welcher ist der richtige für das potenzialfreie Relais und wie kann ich hier eine Verzögerung einstellen?

    Am Shelly 1 Klemme I und 0.



    Kurzes An-Aus-Verhalten kann man über Pulsetime erreichen. Dazu öffnet man im Hauptmenü des Shelly 1 den Unterpunkt Konsole. Die einzelnen Konsolenbefehle sind im Tasmota Wiki erklärt.

    Zum Beispiel: PulseTime 5 {Enter}


    Einschaltzustand Tasmota damit das Tor bei Strom ein nicht von allein fährt:

    PowerOnState 0


    Die Einstellungen bleiben dauerhaft.

    ... Da brauche ich nur den FTDI Adapter, ...

    Ja.


    ...wird für eine einstellbare Zeit der potentialfrei Kontakt geschlossen und das Tor fährt runter oder fährt hoch oder bleibt stehen.

    In Tasmota kann man einstellen, dass mit einem Druck auf die Schaltfläche An/Aus das Relais für einige Sekunden (bei mir 3) anzieht und danach wieder abfällt. Es ist also ein einstellbarer "...kurzer Impuls...", wie ein Taster.


    Also, das sollte man wengstens so auslegen, dass es mit einem Knopfdruck im Auto getan ist - irgendwie über Bluetooth-Verbindung zum Handy und Weiterleitung des Steuersignals von dort übers Internet.

    So ist es. Ich fahre auf mein Grundstück, stehe vor der Garage, mein Smartphone bekommt WLAN aus dem Hausnetz und schalte dann erst am Smartphone. Auszutesten wäre noch, ob es auch am Autobildschirm mit zum Beispiel Android-Auto funktionieren würde.

    Das mit VPN muss ich mir noch überlegen. Ich hab zwar eine VPN Verbindung, aber nur mal "schnell" die Garage öffnen, das dauert dann doch zu lange, vor allem, bis die VPN Verbindung steht.


    Das geht bei meinem Smartphone via Wireguard-APP auf einen RasPi im Heimnetz mit PiVPN (IPV6-Wireguard) sehr schnell. Eine etwas unsichere Möglichkeit wäre die Weboberfläche direkt im Internet freizugeben und mit Passwort für die Weboberfläche zu sichern. Zugang auf die Weboberfläche nur per Passwort kann sowohl Tasmota als auch die Original-Firmware.



    Ich hab noch Fragen zum Flashen mit Tasmota. Hab das noch nicht gemacht.

    Was wird zu Flashen benötigt?

    Dazu gibt es genügend Anleitungen im Internet. Zum Beispiel: https://tasmota.github.io/docs/Getting-Started/ oder google befragen. Ist eigentlich nicht schwer. Oder gleich einen mit Tasmota kaufen (Affiliate-Link): https://www.amazon.de/Shelly-One-mit-Tasmota-Firmware/dp/B07NSZVYYL/ref=sr_1_6?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=tasmota&qid=1634111885&qsid=262-2223911-8458413&sr=8-6&sres=B0054PSES6%2CB07NSZVYYL%2CB086H1FRPZ%2CB07TCQ7BFN%2CB0872PFLJ5%2CB07SNGJ8GD%2CB083FF167K%2CB09BF9KNXC%2CB07SRRP7B1%2CB08C6KZFZK%2CB07X1H3NWF%2CB07B2H7XCZ%2CB08QYRTTTQ%2CB08N6KNG6H%2CB08VDYXTP7%2CB07L81GBQL%2CB097RZN1M1%2CB07RDL25F5%2CB08BL5YQQ8%2CB08BPD8FDL (Affiliate-Link)


    Ist die grundsätzliche Umsetzung mit Tasmota und dem Relais schwierig?

    Shelly 1 kann mit verschiedenen Versorgungsspannungen betrieben werden. Meine Garagentorsteuerung nutzt 12 Volt und diese kann auch der Shelly 1.


    Der Shelly bekommt bei mir 2 Kabel mit der Versorgungsspannung von 12 Volt direkt aus der Garagentorsteuerung und 2 Kabel für den potentialfrei Kontakt zu schalten. Also 4 Kabel am Shelly anschrauben und diese 4 Kabel an die (richtigen) Schraubkontakte der Garagentorsteuerung.


    Wenn man weiss wo anschließen nicht schwer. Ansonsten Elektriker fragen.


    Ich hab zb. ein Android Smartphone. Ist es möglich hier auf den Link, wenn es eine Webseite ist, direkt ein Widget auf den Hauptbildschirm zu legen?

    Dann müsste man nicht erst immer die Webseite aufrufen, sondern hat es sofort auf dem Hauptbildschirm.

    In meiner Familie nutzen wir Android und Apple. Beides kein Problem. Auch ein Link auf den Hauptbildschirm des Smartphone habe ich. Dieses ruft mit einem Tastendruck die Tasmota Website des Shelly im Android-Firefox auf. Ein zweiter Tastendruck bewegt das Tor.

    Alternativ mit der Original Shelly1 Firmware wäre es ggf. noch einfacher. Da der Shelly aus dem Internet über eine Hersteller-Website zu erreichen wäre. Ich möchte das nicht, deswegen für mich Tasmota. Muss halt jeder selber entscheiden.

    Hallo,


    bei meinen beiden Hörmann Garagentoren (ebenfalls 2 potentialfrei Kontakte) habe ich jeweils einen Shelly 1 angeschlossen. Damit diese nicht dauernd nach Hause funken sind diese mit Tasmota statt mit der original Firmware geflasht. Kann man auch gleich mit Tasmota kaufen oder auch mit der original Firmware betreiben.


    Beim Web-Zugriff im hauseigenen LAN/WLAN auf den Shelly generiert dieser eine Website. Sobald man dort z.B. auf dem Smartphone oder am PC auf An/Aus drückt:


    wird für eine einstellbare Zeit der potentialfrei Kontakt geschlossen und das Tor fährt runter oder fährt hoch oder bleibt stehen.


    Für eine Steuerung von Unterwegs gehe ich vom Smartphone per (gesichertem) VPN ins Heimnetz. Dies ist sicher und niemand fremdes kann in meine Garage.

    Gleich bestellt, Bestellbestätigung erhalten, aber kurz darauf:

    Hallo Andreas,


    würde ich gerne tun. Leider bin ich kein Programmier-Crack.


    Bisher habe ich einfach das Adafruit Beispiel in eine endlos Schleife gelegt und am Ende einen sleep(1) bzw. sleep(600) je nach Differenz von Temperatur und Taupunkt angefügt.

    Wie könnte ich Deinen Ansatz in Python-Programmcode umsetzten?

    Hast Du (oder jemand sonst) einen Tipp, wie ich diese Strategie in FHEM umsetzen kann?

    Hallo,


    im Moment teste ich einen getrennten Ansatz zur Umsetzung der Strategie von Andreas.


    FHEM bleibt unangetastet. Mit dem BME280-Sensor messen und protokollieren wie bisher alle 20 Minuten.


    Im Hintergrund habe ich zusätzlich ein Python-Programm in Dauerschleife aufgesetzt. Mit dem BME280-Sensor messen ohne Protokoll und Ausgabe. Nach jeder Messung wird die Differenz zwischen Temperatur und Taupunkt berechnet. Ist die Differenz < 5 °C wird eine Sekunde bis zur nächsten Messung gewartet und ansonsten mehrere Minuten.

    Die Messung ungefähr jede Sekunde soll dafür sorgen, dass der Sensor nicht den Kältepol in der näheren Umgebung darstellt.

    ...nur zu kritischen Zeitpunkten (z. B. aktuelle Temperatur - Taupunkt < 5 °C) dafür zu sorgen, dass der Sensor oder das Sensor-Modul nicht den Kältepol in der näheren Umgebung darstellt.

    und sich daher kein Kondensat im oder am Sensor bildet. Vereinfacht gesagt, der Sensor verbraucht durch häufigeres Messen mehr Strom und wird dadurch geringfügig wärmer als die Umgebung.


    Nur Versuch macht Kluch. Mal sehen, ob es klappt.

    Nein, meiner Meinung reicht es aus, nur zu kritischen Zeitpunkten (z. B. aktuelle Temperatur - Taupunkt < 5 °C) dafür zu sorgen, dass der Sensor oder das Sensor-Modul nicht den Kältepol in der näheren Umgebung darstellt.


    Insbesondere bedarf es keiner häufigen Messung, wenn

    - im Tagesverlauf die Temperatur steigt UND es nicht regnet, weil die Differenz Temperatur - Taupunkt ebenfalls steigt


    Es bedarf also Messungen, um die Lage zu sondieren, um dann die richtigen Messintervalle festlegen. zu können.

    Hast Du (oder jemand sonst) einen Tipp, wie ich diese Strategie in FHEM umsetzen kann?

    Meine Empfehlung ...im Abstand von 1 Sekunde zu messen. Das muss reichen. Mehr kannst Du eh nicht machen.

    Wie ich es sehe ist man mit einer Samplerate von 1 Sekunde schon mal auf gutem Kurs und es ist die Frage ob sich weiterer Aufwand lohnt.

    Verstehe ich es richtig, ihr seit der Meinung, die einfachste Möglichkeit wäre, den Sensor "warm" zu halten indem man ihn dauerhaft beschäftigt?

    Dies nur zu kritischen Taupunkt-Zeiten zu tun wäre zwar eine Einsparung von unnötigen Messungen und Strom, man könnte aber durchaus alle Sekunde (24/7) eine Messung machen, wenn man zu faul ist eine Taupunkt abhaengige adaptive Samplerate zu implementieren?


    Ich würde diesen Ansatz gerne bei meiner Konfiguration einstellen. Mein RasPi ist sowieso unterfordert und könnte gerne jede Sekunde messen.

    Mein RasPi misst per FHEM im Moment alle 20 Minuten. Dies kann ich auf 1 Sekunde einfach ändern, jedoch wird dann auch jede Sekunde ein Log-Eintrag generiert. Die Daten im Log-File schwellen dadurch unnötig an.


    Kann mir jemand einen FHEM-Tip geben, wie ich zwar jede Sekunde messen lassen kann, aber nur alle 20 Minuten ein Log-Eintrag generiere?

    Hallo Matsch1,


    ich betreibe den Sensor an einem RasPi, nicht an einem ESP. Der RasPi ist in der Hühnerhütte angebracht und dort für Licht und Hühnertür zuständig (Bilder siehe Link im Footer). Der Sensor ist dem Wetter ausgesetzt in einer eigenen Abzweigdose an der Aussenwand der Hühnerhütte, durch ein Kabel mit dem RasPi im inneren verbunden.


    Anfangs hatte ich eine Abzweigdose mit großen Löchern im unteren Bereich verwendet, Pink im nachfolgenden Bild markiert:

    Ich denke da ist genug Luft rein und raus und durchgesaust, so dass dort sich kaum Kondensat halten konnte. Für die Verbindung habe ich Wago-Klemmen genutzt.


    Nun also der 3. neue Sensor in einer größeren Verbindungsdose ohne große Löcher, wie zuvor beschrieben.


    Da kaum wärmende Elektronik in der Abzweigdose ist, könnte natürlich am empfindlichen Sensor, so wie Andreas es beschrieben hat, doch geringfügiges Kondensat die Feuchtemessung verfälschen und zum Defekt führen. Aber, da wo keine Eigenwärme ist, kann auch keine Eigenwärme die Temperaturmessung des BME280 verfälschen!

    Ob häufiger Betrieb des Sensors die Lösung ist?


    Es bleibt also spannend, die Eingangsfrage von framp: "Wie sollte man einen BME280 Sensor vor den Unbilden des deutschen Wetters schuetzen?" zu lösen