Schade, dass es unter Proxmox nicht gut genug läuft.
Wäre mit einem Google Coral eine Verbesserung möglich?
Habe hier noch einen, für den ich derzeit keine Verwendung habe.
Nein, das hilft leider nicht weiter. Wenn wir vom kleinen Google-Einplatinen-Computer für Entwickler sprechen (dem Coral Dev Board bzw. Coral Dev Board Mini), dann hat dieser – genau wie der Raspberry Pi – einen ARM-Prozessor und kann daher keine x86-Bibliotheken nativ kompilieren.
Prima, ich habe heute alle Sensoren auf DC umgestellt und was hat sich am Gesamtertrag heute verändert? nichts, aber ich habe jetzt regelkonforme Entitäten für meine 3 Strangs: sehe ich mal positiv.
Ertrag heute:
AC = 5,22 kWh
DC = 5,22 kWh
Prognose: 12,89 kWh
Und was ist daraus zu schließen?
das verstehe ich nicht, der DC Wert müßte eigentlich höher sein, als der AC Wert (bedingt durch die Verluste z.B. am Wechselrichter)
bei mir heute AC = 5,69 kWh und DC = 6,14 kWh
1 „Gefällt mir“
Kann ich bestätigen bei mir AC= 0,27 kWh und DC= 0,29 kWh.
Also selbst bei so niedrigem Ertrag sieht man schon einen Unterschied
Daraus ist zu schließen, dass Du einen Fehler im Riemann / Sensor / Messfehler / Rundungsfehler hast, da es physikalisch unmöglich ist 0% Umwandlungsverluste zu haben… Es sei denn Du hast einen Flux-Kompemsator 
und was weiterhin ein Punkt ist " Du hast heute im Laufe des Tages deine Sensoren korrigiert" das bedeutet das die letzten Tage falsche Werte gelernt wurden. Wie beschrieben ist es auch so, das die Prognose am Morgen gelocked wird. Es macht also keinen Unterschied ob du im Laufe des Tages irgendetwas änderst. Erst beim nächsten Lauf und nach 3 Tagen setzt eine erneute Korrektur ein.
Du hast völlig recht! Der Tageszähler DC liefert ja noch keine Daten. Mea culpa!
Den muss ich in meiner Anzeige noch ändern.
2 „Gefällt mir“
Den kriege ich zu Weihnachten; zwar nur ein Uhrarmband, aber immerhin
1 „Gefällt mir“
Bin dann mal auf die 12er gespannt?
Mit der 10.01 ist die Prognose von Tag zu Tag schlechter.
Heute liegt der Forecast 60% darüber. (13er Tag)
Ich vermute es hat was mit der Satelliten wolken Prognose hier im Südlichsten BW zu tun.
Gruss
Auch in NordWest Deutschland ist die Prognose nicht so cool 
Auch im Norden (Lübeck), total gedrehtes Wetter, nur die halbe Sonnenpower. Tom-HA´s Integration war noch am besten, aber auch weit drüber.
Ertrag Real war 1,6 kWh
Tom-HA = 3,1
Solcast = 5,8
OpenMeteo = 4,5
SunForecast = 4,1
Aber auch meine Handy-Apps und Wetterprognosen wie BlueMeteo haben viel mehr Sonne angekündigt. Da spielt vielleicht tatsächlich einer mit nem Fluxkompensator rum.
Hallo @Tom-HA
ich kann deine Aussage zu Proxmox nicht zustimmen. Nach Aussage vieler Virtualisierungsspezialisten liegt die Performance bei Proxmox nahe an einer Bare Metal Hardware. Eine Performance Einbuße von 15 bis 20 % ist abwegig:
Ich betreibe unterschiedlichste Server, vom Datenbank Server, Videorekorder für die Kameras, Paperless-ngx und mehrere ioBroker-Server. Performance Probleme oder Einschränkungen habe ich nicht beobachtet.
Meine Frage ist nun, veröffentlicht du den SFML nur für Bare Metal oder überlässt du die Auswahl der Hardware den Nutzern? Das du ARM ausschliesst verstehe ich, Proxmox ist aber nicht immer Proxmox. Hier kommt es auf auf die basierende Bare Metal Hardware an.
Ich fände es wirklich schade, wenn für SFML Proxmox ausgeschlossen werden würde.
Ich nutze nun seit 4 Tagen die Prognose. Bisher waren die Angaben nahe den ermittelten Werten. Heute lag die Prognose leider 35% daneben.
Gruß Martin
5 „Gefällt mir“
bei mir wird es scheinbar langsam etwas
Real 6,14 kWh
Prognose 5,67 kWh
Die Performance von Proxmox „zu verteufeln“ würde ich auch von abraten. Meine Proxmox-Cluster mit Core 9 Ultra und 22 Cores hat 96 GB RAM. Ich habe den ZFS-Cache massiv erhöht und somit laufen meine VMs fast vollständig im RAM. Die IO-Performance (gerade im Storage-Bereich) ist dadurch extrem gut und die Zugriffszeiten dürften durch den RAM-Cache unter denen von bare Metal liegen
3 „Gefällt mir“
Ich habe mal meine Umrechnungs-Templates ein wenig aktualisiert.
Am Sonntag nach Installation der V12 werden viele das grafische Statistikmodul ausprobieren wollen. Um alle Energieflüsse und Berechnungen ausführen zu können braucht dieses Modul natürlich Daten. Einige werden diese Daten haben. Bei einigen Daten weiß man gar nicht, wo man die hernehmen soll. Genauso ist es bei meiner Huawei-PV-Anlage. Allerdings kann man alle geforderten Werte mittels Template darstellen. Diese Formeln nutzen dann Werte aus dem Inverter, der Batterie (wenn vorhanden) und dem Powermeter. Die Formeln sehen auf den ersten Blick kompliziert aus, sind aber eigentlich nur Plus- und Minus-Rechnungen, und ein paar wenn/dann Abfragen. Die Einzelbuchstaben sind nur Abkürzungen. Z.B. rechnet man watt1 + watt2 in der Formel einfach w_1+w_2. Anpassen müßt Ihr natürlich die Entitätsnamen aus Eurer Anlage.
Die Formeln können aber auch noch an anderer Stelle nützlich sein.
Ich habe die ganze Liste einfach zu den Templates in meine configuration.yaml dazugefügt.
##Netzstrom zu Haus
- name: "grid to house"
unique_id: "grid_to_house"
unit_of_measurement: "W"
device_class: "power"
state_class: "measurement"
state: >-
{% set g_c = states('sensor.grid_consumption') | int(0) -%}
{% set g_t_b = states('sensor.grid_to_battery') | int(0) -%}
{{ (g_c-g_t_b) | int(0) }}
##Hausverbrauch
- name: "house consumption"
unique_id: "house_consumption"
unit_of_measurement: "W"
device_class: "power"
state_class: "measurement"
state: >-
{% set t = states('sensor.battery_to_house') | int(0) -%}
{% set u = states('sensor.grid_to_house') | int(0) -%}
{% set g = states('sensor.generation_to_house') | int(0) -%}
{{ ((t + u + g )| float(0)) |round(0) }}
##Netzstrom in Batterie
- name: "grid to battery"
unique_id: "grid_to_battery"
unit_of_measurement: "W"
device_class: "power"
state_class: "measurement"
state: >-
{% set ip = (((states('sensor.inverter_active_power')| int(0))) /1.08)-%}
{% set cdp = states('sensor.battery_charge_discharge_power')| int(0) -%}
{% if ip < 0 and cdp > 0 %}
{{ (ip *-1) | int(0) }}
{% else %}
{{ 0 }}
{% endif %}
##Netzverbrauch
- name: "grid consumption"
unique_id: "grid_consumption"
unit_of_measurement: "W"
device_class: "power"
state_class: "measurement"
state: >-
{% set u = states('sensor.inverter_active_power') | int(0) -%}
{% if u < 0 -%}
{{ (- u) | int(0) }}
{% else %}
{{ (0) | int(0) }}
{% endif %}
##Solarstrom zu Netz
- name: "generation to grid"
unique_id: "generation_to_grid"
unit_of_measurement: "W"
device_class: "power"
state_class: "measurement"
state: >-
{% set g2g = states('sensor.power_meter_active_power') | int(0) -%}
{% if (g2g) > 0 -%}
{{ (g2g) | int(0) }}
{% else %}
{{ (0) | int(0) }}
{% endif %}
##Solarstrom zu Haus
- name: "generation to house"
unique_id: "generation_to_house"
unit_of_measurement: "W"
device_class: power
state_class: "measurement"
state: >-
{% set pv = states('sensor.inverter_input_power') | int(0) -%}
{% set g_t_b = states('sensor.generation_to_battery') | int(0) -%}
{% set g_t_gr = states('sensor.generation_to_grid') | int(0) -%}
{% if (pv - g_t_b - g_t_gr) > 0 -%}
{{ (pv - g_t_b - g_t_gr) | int(0) }}
{% else %}
{{ (0) }}
{% endif %}
##Solarstrom zu Batterie/Akku
- name: "generation to battery"
unique_id: "generation_to_battery"
unit_of_measurement: "W"
device_class: power
state_class: "measurement"
state: >-
{% set b = states('sensor.battery_charge') | int(0) -%}
{% set ap = states('sensor.inverter_input_power') | int(0) -%}
{% if b > 0 and ap > 0 and b < ap -%}
{{ (b) | int }}
{% elif b > 0 and ap > 0 and b > ap -%}
{{ (ap) | int(0) }}
{% else %}
{{ (0) | int(0) }}
{% endif %}
##Batterieabgabe ins Haus
- name: "battery to house"
unique_id: "battery_to_house"
unit_of_measurement: "W"
device_class: "power"
state_class: "measurement"
state: >-
{% set u = states('sensor.battery_charge_discharge_power') | int(0) -%}
{% if u < 0 %}
{{ (- u) | int(0) }}
{% else %}
{{ (0) | int(0) }}
{% endif %}
##aktuelle Batterieladung
- name: "battery charge"
unique_id: "battery_charge"
unit_of_measurement: "W"
device_class: "power"
state_class: "measurement"
state: >-
{% set u = states('sensor.battery_charge_discharge_power') | int(0) -%}
{% if u > 0 %}
{{ (u) | int(0) }}
{% else %}
{{ (0) | int(0) }}
{% endif %}
##Batterieentladung
- name: "battery discharge"
unique_id: "battery_discharge"
unit_of_measurement: "W"
device_class: "power"
state_class: "measurement"
state: >-
{% if states('sensor.battery_charge_discharge_power') | int(0) < 0 -%}
{{(states('sensor.battery_charge_discharge_power') | float(0) *-1 ) | round(0)}}
{% elif states('sensor.battery_charge_discharge_power') | int(0) >= 0 -%}
{{(states('sensor.battery_charge_discharge_power') | float(0) * 0)| round(0) }}
{% endif %}
Die Überprüfung nach dem Neustart im Template-Editor zeigte keine Fehler, ein Backup vorher ist trotzdem nicht verboten. Ich habe einfach diese Templates in den Template-Editor eingegeben (Ihr müßt aber Änderungen nach Euren Gegebenheiten machen). Wenn dann überall Werte erscheinen, sollte alles funktionieren.
{{states('sensor.generation_to_house')}}
{{states('sensor.inverter_input_power')|float(0)}}
{{states('sensor.inverter_active_power')|float(0)}}
{{states('sensor.generation_to_battery')|float(0)}}
{{states('sensor.generation_to_grid')|float(0)}}
{{states('sensor.battery_charge_discharge_power')|float(0)}}
{{states('sensor.grid_to_battery')|float(0)}}
{{states('sensor.grid_consumption')|float(0)}}
{{states('sensor.power_meter_active_power')|float(0)*-1}}
{{states('sensor.grid_to_house')|float(0)}}
Vielleicht hilft es ja dem einen oder anderem hier im Forum.
3 „Gefällt mir“
Vielen Dank für eure Rückmeldungen – ihr habt technisch absolut recht: Proxmox/KVM verursacht bei reinen CPU-Workloads tatsächlich nur minimale Overhead-Verluste (oft unter 5 %).
Aber bei Home Assistant (HA) liegt das Problem an anderer Stelle, und es geht weit über bloße Leistung hinaus.
- Es geht nicht um reine Performance, sondern um Timing-Präzision und StabilitätDie SFML-Integration (und ähnliche zeitkritische Komponenten in HA) erfordert präzise Berechnungen und Zugriffe:
- Echtzeit-Energiemessungen und -verbrauchsanalysen
- Prognose-Algorithmen, die auf exakten Zeitstempeln basieren
- API-Calls mit strengen Timing-Abhängigkeiten (z. B. zu externen Sensoren oder Wetterdaten)
In virtualisierten Umgebungen wie Proxmox kann es zu unvorhersehbaren Problemen kommen:
- Timer-Jitter: Durch virtuelle NTP vs. echte Hardware-Uhr – das führt zu Abweichungen in Millisekunden, die Algorithmen durcheinanderbringen.
- I/O-Latenzschwankungen: Besonders bei Shared Storage (NFS, Ceph) oder Snapshots, die die SSD temporär blockieren und Zugriffe verzögern.
- CPU-Stealing: Wenn andere VMs aktiv sind, “stiehlt” der Hypervisor Ressourcen, was zu sporadischen Spikes führt (z. B. Deine beobachteten 35 %-Abweichungen).
Genau das sehe ich in der Praxis: Solche Ausreißer treten fast ausschließlich bei virtualisierten Setups, SD-Karten-basierten Systemen oder ARM auf.
SFML-Stats geht noch einen Schritt weiter – es greift auf SFML-erzeugte Daten zu, visualisiert sie live, zeigt Sensoren an und interagiert mit dem Recorder. Blocking-Effekte, Overhead durch VM-Layer, Snapshot-Blockaden oder Garbage-In-Garbage-Out (GiGO) im Recorder sind hier ein echtes Risiko, das ich nicht eingehen will.
Ich betone aber: Wer Proxmox meistert und es korrekt konfiguriert (z. B. mit dediziertem CPU-Pinning, isoliertem Storage und priorisierten Queues), kann SFML-Stats theoretisch nutzen.
Aber die Realität sieht anders aus, wie Bug-Tracker, Foren und Community-Berichte zeigen:
Viele Nutzer melden Crashes nach Updates, I/O-Errors oder plötzliche Instabilität nach Monaten der Laufzeit.
Nutzer-Erfahrungen bestätigen das – wenn man in HA-Foren und Reddit von regelmäßigen CPU-Spikes (alle 15 Minuten), die das System unresponsiv machen, oder von Verbindungsproblemen zum Add-on-Store, die durch die VM-Schicht verstärkt werden. Solche Issues sind bei Bare-Metal-Installationen extrem selten
Daher: Keine Kompromisse, keine Ausnahmen – zum Schutz derjenigen, die diesen Thread nicht kennen, Proxmox nicht beherrschen oder einfach ein “Set-and-Forget”-System wollen.
.)
- Debugging-Herausforderungen:
“Proxmox ist nicht immer Proxmox”
Genau das ist der Knackpunkt. Jedes Proxmox-Setup ist einzigartig:
- Unterschiedliche CPU-Pinning-Konfigurationen (manche pinnen nichts, andere alles)
- Verschiedene Storage-Backends (lokales ZFS, NFS, Ceph – jedes mit eigenen Latenz-Profilen)
- Diverse Netzwerk-Bridges und Firewall-Regeln, die API-Calls behindern können
Das macht Debugging bei Fehlern extrem zeitaufwendig.
Bei Bare-Metal weiß ich: Wenn etwas schiefgeht, liegt es am Code, an HA selbst oder an der Hardware – nicht an einer fehlerhaften Virtualisierungs-Schicht oder einer vergessenen Konfigurationsänderung.
In Proxmox muss man oft Layer für Layer debuggen: Ist es der Hypervisor? Der Gast? Der Host? Das führt zu Frust! Unabhängig von meiner Integration berichten viele HA-Nutzer von plötzlichen Crashes nach Proxmox-Updates, die den Host rebooten und HA offline nehmen. Oder von Speicherplatz-Problemen, bei denen HAOS-VMs unerwartet vollaufen, weil Snapshots oder Logs den Platz fressen – das ist bei dedizierten Systemen viel einfacher zu managen.)
3. Datensicherheit / Datenschutz und Risiken der Virtualisierung
Proxmox unterminiert aus meiner Sicht mein grundlegendes Verständnis von Datensicherheit, besonders in einem Smart-Home-Kontext:
- Sicherheitslücken im Hypervisor: Ein Bug in Proxmox kann das gesamte System kompromittieren – inklusive HA-Daten, Sensor-Logs und potenziell sensibler IoT-Zugriffe.
- Shared Ressourcen: Wenn andere VMs (z. B. ein Test-Container) kompromittiert werden, kann das auf HA übergreifen, z. B. durch Side-Channel-Attacken oder Ressourcen-Konflikte.
- Backup- und Restore-Probleme: Snapshots klingen toll, aber in der Praxis führen sie oft zu inkonsistenten Zuständen, besonders bei laufenden Datenbanken wie in HA (z. B. Recorder-Datenbanken werden korrupt).
Für Integrationen wie SFML-STATS, die sensible Energiedaten handhaben, ist das ein No-Go. Bare-Metal minimiert diese Risiken: Isoliert, direkt auf der Hardware, ohne VM-Overhead.
Berichte aus der Community zeigen, dass I/O-Errors unter Proxmox zu Datenkorruption führen können – z. B. bei SSDs, die durch VM-Layer überlastet werden.
Fazit:
Ich priorisieren Stabilität, Präzision und Einfachheit und Datenschutz, Zukunftssicherheit, .. Gleichwohl sage ich aber nicht, dass Proxmox ein schlechtes System ist, wenn man es beherrscht und 100% weiß was man macht und sich der Risiken bewusst ist.
Ein Kompromiss wäre denkbar
Wenn ihr beide das Debugging bei Proxmox-Systemen übernehmt z.B: bei Atomic-Write, ext4/ZFS-Korruption, Timer-Jitter, USB-Passthrough-Problemen nach Updates usw. eine klare und für Einsteiger verständliche Anleitung verfasst, was nötig ist um HA / meine Stats-Integration stabil, Datensicher und einfach auf Proxmox laufen zu lassen. Klarer Fokus muss aber zwingend sein" Datenschutz und wie man den unter Proxmox sicherstellt"
Deal oder kein Deal - dann können wir uns gern zusammensetzen und gemeinsam überlegen! Bis dahin bleibt Proxmox außen vor..
2 „Gefällt mir“
Also ich muss sagen, dass ich es auch sehr schade finde, dass Proxmox pauschal nicht unterstützt wird.
Mein Proxmox-Setup sieht ähnlich aus wie das von @Matt1. Trotz, dass ich HA noch mit SQLite betreibe, ist die Performance / Zugriffszeiten etc. extrem gut (trotz wirklich vieler Integrationen und Geräten- was natürlich erstens an der üppig dimensionierten Hardware und auch an der entsprechenden Config der VMs liegt.
Ich würde das einfach den Usern überlassen und Mindestanforderungen für Hardware bzw. die VMs definieren und das Thema Datenschutz sollte auch Sache der Anwender sein. Das Thema Datenschutz ist ja nicht nur in Proxmox eine Einstellungssache, sondern praktisch überall.
Hinzukommt, dass extrem viele HA-User Proxmox im Einsatz haben. Anleitungen, wie man mit Proxmox vernünftig umgeht / einrichtet / einstellt, gibts im Netz ebenfalls genügend 
Die Reichweite für SFML und dadurch auch der Support durch Anwender im Forum wäre mit Proxmox-Unterstützung im Übrigen auch wesentlich größer - gerade bei so Abweichungen durch virtuelle NTPs oder Ressourcenproblemen in Proxmox.
Ich verstehe natürlich auch, dass das Debugging / der Support ohne Virtualisierung bzw. mit Bare-Metal wesentlich einfacher ist, aber es entspricht nicht der Praxis.
Somit freue ich mich erstmal trotzdem auf die neue Version und lasse erstmal die Finger von SFML Stats - auch wenn ich es sehr gerne getestet hätte.
Ich finde es auch sehr schade, dass du Proxmox nicht unterstützen möchtest. Wir haben in der Firma Jahrzehnte ALLE Server auf einer VMware Plattform gefahren und keine Probleme damit gehabt. Im Gegenteil, wir haben nur Vorteile in einer hochverfügbaren Lösung erzielt.
Ich bin nicht so tief in der Materie eingetaucht, dass ich mit den Logs helfen kann. Ich kann nach Anleitung die Logs liefern.
Auch von mir die Frage an dich: Warum überlässt du den Anwendern nicht die Wahl? SD-Karten rauszunehmen ist verständlich, diese Systeme nicht nicht performant und aus Datensicherheit gesehen suboptimal.
Ich sehe auch ein, dass du den Support für solche Systeme (SD-Karten und Proxmox) nicht übernehmen kannst.
Das sollte doch das Risiko der Anwender sein.
Ich werde mit Sicherheit kein Bare Metal aufbauen, dass ist für mich Vergangenheit.
Edit:
Hier mal ein Bild der Konsole. Ich habe mich bemüht, den max. Wert für IO-Verzögerung (immer kleiner als 0,11) zu bekommen. Da ich drei Proxmox Host betreibe, kann ich HAOS auch auf einen Knoten separat betreiben, wenn der Test hilfreich wäre:
Bitte nicht Missverstehen, ich verstehe eure Argumentation! - Am Ende des Tages liegt es aber in meiner Verantwortung, bei allen schönen Worten, dem Nutzer ein sicheres, lauffähiges und datenschutzsicheres System kostenlos anzubieten.
Ich mache es umsonst, investiere zig 100 Stunden an privater Zeit und viel wichtiger ich sehe wo es Probleme und Schwierigkeiten gibt - das ist zu ca. 90% bei Proxmox. Das habe ich auch ausreichend begründet, warum das so ist. Natürlich kann man sagen " User Problem muss er sich drum kümmern" - die Realität ist aber doch, dass es auf mich zurückfällt. Ich habe mehrere Stunden damit verbracht Proxmox-Probleme zu debuggen (am häufigsten Schreib- , Performance- und Speicherfehler / Prognosen die nach Tagen immer noch unrealistisch waren) - ich glaube das ich vor diesem Hintergrund sehr genau beurteilen kann und es nicht auf Theorie beruht, wenn ich sage " Fehlerhafte Proxmox - Installationen" sind eines der Hauptpunkte warum einiges nicht läuft. Das Argument " Ja aber alles andere läuft doch bei mir" ist KEIN Argument, da ich sehr klar und deutlich logge und somit Fehler aufdecke die bei anderen “unerkannt” bleiben. Vielen ist bis zu den Zeitpunkt überhaupt nicht klar, was der Unterschied zwischen Proxmox, anderen VM und Bare Metal überhaupt ist.
@salmunia Ich sehe es übrigens nicht so, dass ich als Entwickler das Thema Datenschutz alleinig beim User lassen sollte - im Gegenteil! Wenn ich weiß, dass es Probleme geben kann (kann nicht muss), gleichzeitig auch weiß das viele das überhaupt nicht auf dem Schirm haben, dann liegt es sehr wohl an mir alles zu tun, das zu vermeiden. Das hat aus meiner Sicht etwas mit Ethik und Überzeugung zu tun. Nenne das meinetwegen Konservativ, oder Antiquiert, ich sehe es nunmal so und es ist meine Entscheidung.
Was das Thema Reichweite angeht, das Du angesprochen hast: Das wäre ein Argument wenn ich Geld damit verdienen wollen würde - das ist aber nicht Fall. Es hat mal einer zu mir gesagt " Am Ende machst Du etwas für dich, wenn es für andere Hilfreich ist, dann ist es super" Genau so ist es! Ich mache es nicht für andere, sondern ich mache es gemeinsam mit denen, die es spannend finden und that`s it. Ich benötige / ziele nicht die von Dir angemerkte " Reichweite" , ich bin ja nicht einmal ein " Entwickler" sondern eine Privatperson, .. meine Freude daran ist der Austausch und Herausforderung etwas völlig neues zu schaffen. Ich habe in den letzten Wochen soviel nette und freundlichen User z.T. auch per WhatsApp und Telefon kennengelernt, das hier meine Verantwortung liegt und nicht in der Gier nach Reichweite. Verwechsle das bitte nicht mit einem “Auftrags-Progamierer” .. im Übrigen denke ich auch, dass jeder der diesem Thema intensiv folgt eine Menge lernen konnte - inklusive mir selbst!
Ein letztes Wort noch zu Deinem Einwand " ich werde mit Sicherheit keinen Bare-Metal aufsetzen, dass ist für mich die Vergangenheit" .. das ist deine persönliche Meinung, deine Einschätzung die ich auch nicht beurteilen möchte! Vielleicht hast Du sogar recht.
Es bleibt dabei: KEIN PROXMOX (für SFML-STATS) es sei denn Du oder jemand anderes erklärt sich bereit all denen zu helfen und zu debuggen, die nur eine Anleitung / YouTube Video gefolgt sind ohne zu wissen was sie da eigentlich machen und was da im Hintergrund passiert.
Das Angebot habe ich Dir / euch gemacht, dazu stehe ich auch!
Meine Bedingung habe ich auch genannt: Fokus auf den Schutz Privater Daten und einer Vernünftigen leicht verständlichen Anleitung die jeder versteht und über Risiken und Probleme aufklärt. Wir können uns da super gern drüber austauschen - PN, Call, .. aber bitte nicht weiter hier es ist alles gesagt - meine Entscheidung steht. ARM (Pi und Co) ist da ein völlig anderes Thema und ich werde alles tun es zu ermöglichen!
6 „Gefällt mir“