Developer that contributes stuff to the ioBroker project
Dennoch berücksichtigt die SD Karte die freien Bereiche beim wear leveling auch.
Wenn alle 10 Sekunden ein Block wegen einer log Datei neu geschrieben werden muss wird er jedes Mal an eine andere Stelle der SD Karte geschrieben.
Technisch gesehen ersetzen die offizielle Reserveblöcke nur die wirklich komplett defekten.
Aber bei einer SD Karte sind die auch nicht so reichlich.
Bei SD Karten willst du immer möglichst viele Reserveblöcke übrig haben, damit die SD Karte nicht so schnell aufgibt.
Hatte überlegt auf SSD umzusteigen. Aber ehrlich gesagt reicht die Performance dicke aus so wie es ist.
Die SSD hat rein gar nichts mit "Performance" zu tun, sondern mit "Reliability".
Jein - "Performance" und "Reliability" gehören da durchaus zusammen. Letztendlich zerstört der Rechner ja nicht das Speichermedium selber, sondern das darauf liegende Dateisystem. Dieses passiert insbesondere wenn während wichtiger schreibvorgänge plötzlich der Strom weg ist. Das Gilt nebenbei für alle Rechnersysteme.
Wenn die Zeitfenster für diesen kritischen Punkt kleiner werden (höhere Performance) dann sinkt das Risiko das man sie trifft (höhere Reliability)
Aber auch die beste SSD kann nichts retten, wenn mitten während einem kritischen Schreibvorgang der Strom weg ist.
A.
Inzwischen soll es ja SD Karten geben, die explizit für die Anwendung im PI ausgelegt sein sollen - ist das "Schlangenöl"?
Die gibt es schon seit es die PI's gibt.
Schlangenöl war das meiner Meinung nach immer schon. Interessant ist primär das Verhalten (insbesonder das Zeitverhalten) der Karte beim Schreiben.
Seit dem Wechsel auf den PI4 / PI5 habe ich keine Probleme mit SD Karten mehr gehabt. Insgesamt hat sich da offensichtlich einiges getan - sowohl auf der OS Seite (Konfiguration) als auch bei den Zugriffszeiten, so das die Fenster in denen das System beschädigt wird immer kleiner werden.
A.
@maxclaudi Habe ich dir per PN geschickt
Wenn Du +750 angibst, dann werden bis zu 750W dauerhaft aus dem Netz entnommen, um den Ladevorgang (mit minimaler Stromstärke) aufrecht zu erhalten. Bei großer PV-Produktion ist das also wirkungslos.
Wenn Du es umgekehrt willst und ein Überschuss verbleiben soll, dann müsstest Du -750W angeben. Dann werden einfach 750W vom aktuellen Leistungsfluss (egal ob derzeit positiv oder negativ) 750W abgezogen und dann die Berechnung zum Ladeüberschuss durchgeführt.
@michihorn
Du kannst mit sowas mal probieren ob es geht:
https://help.router-for.me/ (github https://github.com/router-for-me/CLIProxyAPI )
Das lässt du irgendwo bei dir laufen und trägst das bei ioBroker dann als custom ein, wie ollama oder so. Und darin kannst du dann anscheinend dein OpenAI Zugangsdaten (oder auch Anthropic) konfigurieren und nutzen. Hab's selbst noch nicht ausprobiert. (Vermutlich ist das, zumindest bei Anthropic, am Ende auch ein TOS-Verstoß, nur zur Vollständigkeit)
@StephanH
Ja, hier:
https://forum.iobroker.net/post/1346018
Also device_class muss passen, da ist der sehr strikt. Kurz:
Für einen Zähler, der zB. verbrauchte kWh hochzählt muss die Geräteklasse auf "Energie" stehen. Für einen aktuellen Wert (Watt) muss dort "Leistung" stehen.
Und bitte im neuen Thread weiter schreiben. Vielleicht kann ein Moderator den alten Thread beerdigen mit einem Link auf den neuen? :-)
@amg_666
hast du den im 192.168.1.x aufgesetzt ?
dann mach mal im neuen Netz also in der 192.168.70.x
iob host this
Nach den gestrigen Meldungen weiterhin froh alles lokal laufen zu haben. Keinerlei Probleme gehabt ;-)
@maxclaudi Ich habe das Zertifikat per ioBroker Javascript Adapter erzeugt, da ich zu dem Zeitpunkt unterwegs war und keinen Zugriff per SSH hatte und nur einen Browser ;-) Das Script habe ich mir da auch schnell per Claude erstellen lassen. "Erstelle ein ioBroker Javascript das mir ein MQTT kompatibles Zertifikat erzeugt. Meine IP lautet XX.XX.XX.XX und mein interner DNS Name lautet XX.XX. default_bits = 2048". Oder so ähnlich.
