Eine Datenbank auf einer SD-Karte ist nicht so gut, da man je nach Komplexität ziemlich viel IO hat.
Ich gehe davon aus, dass die Last durch die Optimierung der DB erzeugt wird.
Hier ist die Quelle: https://github.com/volkszaehle…blob/master/bin/aggregate
Theoretisch sollte die Last irgendwann nach unten gehen, sobald der mit der Optimierung der Tabellen fertig ist.
Gibt es auch RFID-Tags, die keine Feste eindeutige ID haben? Ich habe bisher nur die Tags von Siemens genutzt und die haben alle eine feste ID, die man auch nicht ändern kann.
Alternativ ist es möglicherweise ein Programmierfehler. Darüber kann man aber nur Aussagen treffen, wenn du den Code postest.
Was hat das nun mit deinem Circuit-Python zu tun ?
Das war ein alternativer Vorschlag, die Hardware zu nutzen, bzw zusätzlich einen Mikrocontroller zu verwenden.
Witzigerweise gibt es das auch für den RPi4. Bringt aber nichts, da er OpenHabian nutzen möchte, geht das nicht.
Beachtlich ist die Boot-Zeit. Die beträgt ca. 8 Sekunden auf einem alten Rpi0W.
Ich bin kein Fan von CircuitPython, aufgrund der Vorgeschichte mit CPython. Die kritischen Module sind direkt in C umgesetzt: https://github.com/adafruit/ci…ared-bindings/busio/I2C.c
Das ist bei Micropython auch so und CircuitPython ist ein inkompatibler Fork von Micropython.
Einzige gute Nachricht: Die Micropython-Entwickler arbeiten an einer Kompatibilitätsschicht für Adafruit-Treiber.
Wenn der Rpi mehr als einen Hardware I2C hat, könnte man den ja nutzen. Nur das mit dem Stromverbrauch der ADC stellt ein Problem dar. Wenn der zusätzliche I2C-Port nicht nutzbar wäre, kann man immer noch einen I2C-Portexpander nehmen.
Ein "Überprüfen" würde vermutlich auch nichts nützen. Denn es war möglich, dass ich eine Datei über den Dateimanager neu anlege, diese mit Daten fülle, den Dateimanager schließe, den Dateimanager neu starte und dann diese Datei einlese. Die Daten waren vorhanden.
Ja, sie waren wahrscheinlich noch im Cache. Das Dateisystem greift aber eine Ebene tiefer auf das Block-Gerät zu und greift nicht direkt auf den Cache zu, um z.B. einen neuen Block zu schreiben.
BTRFS hat man genau wegen dieser Probleme (Bit Rot) entwickelt. Das ZFS konnte man aufgrund der Lizenz nicht im Linux-Kernel einsetzen. Die GPLv2 ist inkompatibel mit der CCDL. Aber leider ist BTRFS nicht für alle Anwendungen geeignet. Datenbanken hassen BTRFS.
Eigentlich hätte ein klares: "Ja, ich habe selbst schon einmal Circuit-Python Bare Metal eingesetzt und kann deswegen eine fundierte Aussage treffen" oder "Nein, ich habe Circuit-Python noch nie Bare Metal eingesetzt und kann deswegen keine Aussage darüber treffen." hätte ausgereicht.
Ich wollte nichts über die Theorie erfahren, sondern über gesammelte Erfahrung mit CircuitPython.
Wie I2C funktioniert, weiß. Was ich nicht wusste, dass bitbangio gar nicht Bare Metal auf dem RPi Zero W zu funktionieren scheint. Es geht einfach nicht.
QuoteTimeoutError: Clock stretch too long
Wenn ich eins gelernt habe, ist: Wenn jemand einfach behauptet, dass etwas nicht geht, kommt jemand anderes und setzt das einfach um.
Das ist schon oft genug passiert.
Das dumme ist nur dass der Flashspeicher keinen Fehler ans OS meldet wenn nicht mehr geschrieben werden kann
BTRFS kann damit z.B. umgehen, da nach dem Schreiben überprüft wird, ob das Geschriebene wirklich dem entspricht, was geschrieben werden sollte.
Falls man keine Datenbank betreibt, wäre BTRFS eine Option, um Bit Rot zu vermeiden.
Ich bin von der Shelly-Doku positiv überrascht. Also wenn man einen MQTT-Broker (mosquitto) bereits hat, weil man z.B. die Daten sammelt, kann man MQTT auch beim ESP8266 nutzen.
Wenn du in C/C++ entwickeln willst, gibt es sicherlich auch Bibliotheken für: MQTT und JSON
Via MQTT werden die Nachrichten empfangen und mittels JSON wird der Payload (die Daten) deserialisiert.
Wenn MQTT beim Shelly EM3 aktiviert wird, sendet der die Daten automatisch alle 30 Sekunden (meine ich gelesen zu haben).
Ich bin ein Fan von Micropython, weiß aber auch, dass umqtt ziemlich problematisch auf dem ESP8266 ist, da der RAM nicht so groß ist.
Mit C wird man da sicherlich bessere Ergebnisse erzielen, da es weniger RAM benötigt.
Alternativer Controller: https://www.berrybase.de/seeed…cu-board-mit-wlan-und-ble
Der hat 400 KB RAM, anstatt nur 96 KB RAM beim ESP8266.
Mir ist da z.B. ein Schaltbild von einem Taster aufgefallen, der gegen 3V3 schalten würde. Macht man ja eigentlich nicht, aber immerhin war dort ein 10K Pulldown und ein 1K am GPIO, was die Sache schon wieder relativiert.
Seite 33, Abbildung 1.19: Verschaltung des Tasters
Beides ist legitim, aber ein PULL_UP ist robuster gegen Störungen.
Dafür verbraucht er z.B. bei Mikrocontrollern Strom (beim RPi macht man sich darüber kaum Gedanken).
Worst Case: GPIO22 als Ausgang geschaltet, auf Low gesetzt und den Taster betätigen. Es würden dann 3.2 mA in den GPIO22 fließen. Hat das schon mal jemand probiert?
Ich weiß nicht wie herum mir das einmal passiert ist. 3.3V gegen GPIO und den auf Low gesetzt oder GPIO auf High und gegen Masse. Jedenfalls hat der RPi (und sogar der GPIO) das durch den Absturz überlebt. Ich gehe davon aus, dass die 3.3V zusammengebrochen sind und dadurch ein Reset (Brown Out) ausgelöst worden ist.
Ach schade, ich dachte zuerst, dass das eine Anleitung für Wayland ist.
Mit "ohne X" ist ohne Displayserver gemeint, was Mir und Wayland auch ausschließt.
Steht auch im Dokument.
eine sehr langsame API.
Im Vergleich mit Python und SMBus sind diese Adafruit Treiber im Verhältnis zur direkten Nutzung von SMBus, SPIDEV bis zu 8 mal langsamer.
Also hast du schon mal CircuitPython Bare-Metal auf dem RPi0 laufen lassen? Oder wie kommst du zu dem Schluss, dass das 8 Mal langsamer ist? Das scheint einigen noch nicht so ganz bewusst zu sein, dass es zwei unterschiedliche Versionen gibt. Einmal die Python-Module von Adafruit und dann der Fork von Micropython, der Bare-Metal läuft, sprich kein OS ist dazwischen.
Ein Mikrocontroller wäre da flexibler. Eine weitere Möglichkeit wäre die Verwendung von CircuitPython (bare metal) auf dem RPi Zero (W2). Laut Doku wird bitbangio unterstützt und damit lässt sich I2C auch via Software ansteuern.
Ich persönlich mag CircuitPython nicht so, aber gerade für Anfänger scheint das eher geeignet zu sein, als Micropython.
Die meiste Arbeit haben die in die Vereinheitlichung der APIs gesteckt. Das hat man bei Micropython noch nicht.
Ich weiß aber nicht, ob auch WLAN unterstützt wird.
Grüße, sagen Sie mir, warum beim Einschalten des Broadcast-Obs-Studios die Prozessorlast bis zu 60% beträgt, Rasberry Pi4.
Wahrscheinlich wird der Stream per Software transcodiert, was die CPU belastet.
Kannst du bei OBS einen Hardware-Encoder auswählen?
Ich weiß nicht, wie gut mittlerweile die Unterstützung ist.
In anderen Foren wird darauf hingewiesen, dass ffmpeg die Hardware-Encoder der RPi GPU unterstützen soll.
Geste stet habe ich das nie.
Registrar: Beijing Sanfront Information Technology Co., LtdWenn man ein wenig sucht, findet man heraus, dass Huawei diesen Dienstleister nutzt, um die Cloud-Angebote zu hosten.
Der Name kam mir aber auch bekannt vor, da ich selbst diese Meldung bekomme, dass ich meine Daten seit mehr als 500 Tagen nicht mehr in der HiCloud gesichert habe.
Welche Komponenten brauche ich bzw sind dafür geeignet diese Magnetventile mit Impulsen zu steuern und diese mehrere Sekunden zu öffnen/ zu schließen?
Wenn es keine Bastellösung werden sollte, dann:
So macht man das in der Industrie. Falls es eher ein Bastelprojekt sein, dann hör nicht auf mich und mach das mit dem RPi / RPi0 oder mit Mikrocontroller (ESP32, RP Pico (ARM), STM32, SAMD, Atmel ....). Für die Ansteuerung benötigst du dann passende Relais ggf. mit I2C/SPI Busanbindung oder mit einem Transisor/Mosfet die Ventile schalten. Zu beachten ist auch, dass die Ventile Freilaufdioden benötigen.
Ich hätte bei CRT gelacht. Jeder kennt irgendeine Abkürzung für irgendwas.
Mit dem Datendurchsatz hätte ich auch meine Bedenken. Man kann so viele Displays am SPI-Bus anschließen, wie man noch freie verfügbare GPIOs hat, die als Ausgänge betrieben werden können. Der ChipEnable muss dann für die entsprechenden Displays auf True gesetzt werden.
Wenn man zwei Displays hat, steht für jedes Display nur noch die Hälfte der Zeit zur Verfügung, wenn man bei der gleichen Bildwiederholrate bleiben will.
Wenn man die Displays z.B. nur jede Sekunde aktualisiert, würde das sicherlich besser gehen.
Probiers mal einfach aus und berichte.
Das wüsste ich auch gerne 
Der Code ist schrecklich. Den Code fast niemand an. Neu schreiben, ist einfacher. Das sieht nach einem Script aus, dass irgendjemand mal geschrieben hat und von anderen dann nachträglich erweitert worden ist. Derjenige, der angefangen hat, hatte noch Python 2.7 im Kopf.
sh:1 : syntax error : redirection unexpected
Diese Meldung habe ich noch nie gesehen.
Es gibt andere Meldungen z.B. wenn man einen nicht existierenden Interpreter.
Ohne Quelltext und Traceback können wir nur raten.
QuoteLeitungswasser hat, abhängig vom regionalen Härtegrad, einen Wert von 1.000–4.000 Ohm.
Habs mit einem ESP32 getestet. Digital geht nicht und das wird auch nicht mit dem RPi funktionieren.
Hier mein Versuch: https://asciinema.org/a/rdsyoFgGHXIsZEJmhjsW4cLiv
Die Wert bis 500 ist Wasser aus der Umkehrosmose (16 µS/cm).
Der Wert bei 4095 (12 Bit) ist bei Leitungswasser (354 µS/cm).
Als Elektroden habe ich Jumper-Kabel verwendet. Einen an 3.3V angeschlossen, den anderen an einem ADC-Fähigen Pin (26).
Ich bin auch faul, kenne aber from shlex import split.
Aber nicht diejenigen, die die falschen Anleitungen lesen.
