Das bringt aber überhaupt nichts. Man kann zwar sicherlich wie bei den vorherigen Modellen die Sprache umstellen, die NFC-Funktionen sind aber auf ein staatliches System in China ausgelegt und funktionieren dem entsprechend mit nichts, was es für den europäischen Markt interessant machen könnte.
Selbst wenn eine globale Version mit Visa- oder Mastercard-Unterstützung raus kommt, bedeutet das nicht, dass diese Funktion in der Chinavariante per update nachgerüstet wird. Selbst wenn man es irgendwie manuell erzwingen könnte, die Globale Firmware zu installieren, wäre es nicht unüblich, wenn Xiaomi hier in der China-Variante ein komplett anderes NFC-Chipset verbaut, das eben andere Protokolle (in Hardware) unterstützt, als die Global-Variante.
Ich würde abraten, auf bloßen Verdacht die NFC-Variante zu bestellen. Das sind verschenkte 20€
zigbee2mqtt Kompatibilitätstest wäre mal was. Das gilt dann effektiv gleich für alle anderen, weil auch bei HA die meisten das Z2M-Addon benutzen.
Allerdings würde Aqara dann schlecht abschneiden als andere Firmen. Aqara hat bekanntermaßen immer Probleme mit Bindings und unterstützt die Standards der anderen Firmen nicht. Über HomeAssistant Automatisierungen geht es dann, aber direkte Zigbee-Bindings z.B. über Zigbee2MQTT haben bei mir bei noch keinem Aqara-Produkt funktioniert.
Schade, dass das Teil doch technisch ziemlich mies ist, für heutige Verhältnisse. Die alten Mi A1-A3 waren Jahrelang meine Go-To Empfehlung für Familienmitglieder, die 'ein preiswertes Smartphone' brauchten. Billig, aber ausreichend und dank dem Android One Programm konnte ich damals garantieren, dass die Teile noch eine Weile mit Updates versorgt werden, kein Bloat nachinstalliert wird und auch langfristig generell gut in Software unterstützt werden. Ansonsten hat (besonders damals) Xiaomi oft nur ihre Flagships mit angemessenen Updates versorgt, während die Budgetgeräte oft schon veraltet ausgeliefert wurden und keine Updates bekamen.
Und für Oma Erna und Onkel Horst reichten die Teile eben aus, ohne sie arm zu machen und ohne dass ich mir große Sorgen machen musste.
Aber diese Hardware vom Redmi A1 würde ich heute echt nicht mehr empfehlen. Da ist doch die baldige Obsoleszenz in der App-Unterstützung vorprogrammiert.
Bei Zigbee wird der Hub nicht für Automatisierungen benötigt. Zigbee kann über normale Bindings genau das, was laut deinem Kommentar nur WLAN Aktoren können sollen. Zigbee ist wirklich vollständig ausfallsicher. Sogar noch besser als WLAN-Aktoren, denn WLAN benötigt immernoch einen separaten Router mit WLAN-Accesspoint. Fällt Router/Accesspoint aus, dann funktioniert auch keine WLAN Automatisierung mehr.
Zigbee-Agenten ("Agent" = Sensor, Aktor, etwas dazwischen, auch "Zigbee-Endgerät") hingegen können gleich mehrere Dinge (komplett ohne Hub) und sind dadurch deutlich ausfallsicherer. Die meisten Zigbee-Agenten mit festem Stromanschluss haben auch eine Routing-funktion. Sie bilden voll autonom ein Zigbee-Mesh-Netzwerk bzw. Ad-hoc-Netz das sich selbst heilen kann, wenn einzelne Router ausfallen.
Bei Zigbee werden Sensoren (z.B. Schalter) direkt über ein Binding mit einem Aktor (z.B. Lampe) gekoppelt. Der Sensor versucht dann direkt an den Aktor ein Signal zu senden. Erreicht das Signal den Aktor nicht, wird es durch das Zigbee-Mesh verstärkt und weitergeleitet, bis es den Aktor erreicht. Der Hub wird dabei garnicht benötigt.
Der Hub wird _nur_ bei der Einrichtung gebraucht. Der Hub legt sozusagen die Mesh-Addresse fest, teilt Router mit, wenn es einen neuen Agenten gibt und gibt dem neuen Agenten Zugang zum Netzwerk. Der Hub wird oft auch benutzt, um die Bindings (also die Automatisierungen) festzulegen und diese in den Sensoren und Aktoren zu speichern. Einige Zigbee-Geräte (z.B. Ikea Tradfri Fernbedienungen) können Bindings sogar per Knopfdruck auch ohne Hub lernen. Auf jeden Fall: ein mal gespeicherte Bindings funktionieren immer auch ohne Hub. Der Hub erleichtert nur die Einrichtung, anschließend kann man ihn ausschalten.
Im laufenden Betrieb dient der Hub nur noch als Kombigerät. Er ist einer (von vielen) Mesh-Routern, er dient als Sensor z.B. für zeitgesteuerte Bindings und kann als Gateway z.B. die Schnittstelle zum (W)LAN sein. Er wird aber nicht wirklich benötigt.
Was etwas für Verwirrung sorgt, sind schlechte Zigbee-Geräte, die Bindings schlecht bzw. unvollständig unterstützen. Besonders Aqara hat da echte Probleme. Aqara hat ein eigenes, nicht standardisiertes Protokoll für Bindings, das kaum mit anderen Herstellern zusammen funktioniert. Sogar das Routing über Aqara-Geräte funktioniert teilweise nicht. Dann muss der Hub effektiv smarten Streitschlichter spielen und alle Automatisierungen laufen über den Hub, was eigentlich nicht so sein sollte. Andere Marken z.B. Philips, Ikea und Tuya spielen aus meiner Erfahrung gut miteinander und kommen auch gut ohne Hub aus, wenn sie erst mal eingerichtet sind.
Ein weiteres Problem ist ein Missverständnis, z.B. von vielen Homeassistant nutzern. Oft werden statt Zigbee-Bindings einfach HA-Automatisierungen eingerichtet. Dann senden die Sensoren an den Hub, der Hub macht Automatisierung und senden an die Aktoren. Das sorgt für unnötige Verzögerungen und dabei wird dann selbstverständlich der Hub benötigt. Z.B. Zigbee2MQTT kann aber auch einfach nachZigbee-Standard Bindings und Gruppen einrichten. Wenn man das nutzt, kann z.B. der Homeassistant mit Zigbee2MQTT-Hub komplett abgeschalten werden und die Bindings funktionieren trotzdem.
Das neue an Zigbee Direct mit BLE wäre, dass ein Zigbee Direct Gerät im Zigbee-Mesh ausreicht, um effektiv komplett ohne "Hub" (das Zigbee Direct Gerät wäre dabei kurz der Hub) neue Bindings einzurichten. Das Smartphone muss danach nicht verbunden bleiben. Auch das Zigbee Direct Gerät müsste nicht unbedingt verbunden bleiben. Mit mehreren Zigbee Direct Geräten im Mesh könnten diese vermutlich als BLE Gateway agieren.
Auch die Besorgnis über erhöhten Stromverbrauch ist unbegründet. BLE ist, wie der Name schon sagt, Low Energy. Solange keine Signale übertragen werden, also solange kein Smartphone ein Wake-Up-Signal sendet, braucht BLE keinen zusätzlichen Strom. Bluetooth, ZigBee und WiFi b/g (nicht a, n, ax) benutzen alle das 2.4GHz-Spektrum, weshalb eine Antenne für alle Protokolle ausreicht, sofern das Chipset die Protokolle unterstützt. Der beliebte ESP32 z.B. kann Bluetooth, BLE und Wifi gleichzeitig. Die Antenne in einem Zigbee Direct Gerät wäre also sowieso dauerhaft an, da über sie ZigBee läuft. Kommt ein BLE wakeup, wird das Bluetooth-Protokoll aktiviert und eine Verbindung aufgebaut. Dennoch denke ich, dass Zigbee Direkt zunächst nur in Geräten mit Zigbee Routing verfügbar sein wird. Das sind üblicherweise Geräte, die sowieso einen festen Stromanschluss haben, z.B. Glühbirnen und Lüfter.
Technisch gesehen ist das nichts neues. Der große Vorteil von Zigbee gegenüber anderen Protokollen ist doch dass alle Bindings peer2peer im Mesh passieren und auch ohne Hub funktionieren. Ein Schalter sendet z.B. direkt an die Lampe das Signal zum einschalten oder Farbe wechseln. Der hub wird nur für die Einrichtung bzw. das orchestrieren komplexerer Bindings benötigt und kann danach auch wegfallen. Z.B. Ikea Tradfri hat sogar (schon immer) Knöpfchen um Bindings direkt vorzunehmen, ohne Hub.
Einzige Ausnahme: Aqara Der Kram von Aqara kann kein richtiges Zigbee und vor allem keine standardisierten Zigbee-Bindings. Bei Aqara sendet alles immer zum Hub und der Hub macht die Automatisierung. Meiner Meinung nach ein absoluter dealbreaker an den ansonsten hervorragenden Aqara Geräten.
Das hier vorgestellte ZigBee Direct ist soweit nur neu, dass neuere ZigBee-Chipsets jetzt auch BLE können. ZigBee und Bluetooth laufen beide auf 2.4GHz und sind damit technisch sowieso schon dicht beieinander. Das neue Matter Protokoll sieht sogar eben neue cross-compatible Geräte vor, die gleichzeitig BLE und Zigbee nutzen. Daher wohl auch die neuen Chipsets, die effektiv genutzt werden können, um normale, direkte ZigBee-Bindings über eine Bluetooth-App anstatt von Knöpfchen (wie bei Tradfri) einzurichten.
Aus persönlicher Erfahrung mit Zigbee-Geräten würde ich zudem sagen, dass ich Tuya aktuell immer Aqara vorziehen würde. Aqara hat ein eigenes Protokoll für Gruppen und Bindings auf Zigbee implementiert und nutzt nicht Standard Zigbee 3.0 Bindings. Außerdem werden Eigenschaften generell 'seltsam' bereitgestellt, als würde man bei Aqara prinzipiell immer versuchen, einen eigenen Standard zu etablieren.
Im Fall von Heizkörpertermostaten brauche ich wahrscheinlich keine Bindings zu Zigbee-Buttons oder Lichtgruppen, allerdings hätte ich mittlerweile Bedenken, ob dann nicht doch irgendwas wieder seltsam implementiert ist und im Homeassistant wieder eine Extrawurst über Zigbee2MQTT braucht.
Der NAS hier hat eine andere Zielgruppe als z.B. Synology. Besonders im "Homeserver"-Bereich sind viele Technik- und Open-Source-Enthusiasten unterwegs und für die sind überteuerte Fertiglösungen wie Synology einfach nichts.
Stell es dir vor wie Profiköche, denen du Maggi (Synology) Tütensuppe verkaufen möchtest, mit den Argumenten, dass Tütensuppe einfach ist und im Gegensatz zu anderen Zutaten Vakuumverpackt kommt und viel weniger Energie beim Kochen verbraucht! Das Produkt hier entspricht hingegen eher einem Service wie HelloFresh, das dir richtige Zutaten mit Rezept zum selber Kochen liefert. der Profi wird vielleicht trotzdem lieber die Zutaten einzeln kaufen, aber das hier nimmt Arbeit ab und sieht gut aus und für Zuhause reicht es.
Einen NAS auf Open-Source Basis zu entwickeln braucht definitiv nicht so viele Leute, das habe ich auch allein geschafft. Und nicht nur ich. Projekte wie TrueNAS und OpenMediaVault sind riesig und haben sehr viele Nutzer. Alles was man dafür braucht, ist ein sparsamer 'low-end' Intel PC und eben ein Gehäuse in das viele Festplatten passen.
Genügend Nutzern reicht der Kram, den Synology anbietet auch einfach nicht aus. Viele wollen eigene Lösungen, auf denen sie einfach zusätzliche Software installieren können und nicht durch proprietäre Vorgaben komplett von einer Firma abhängig sind.
Das eigene NAS-System ist dann eben genau das, was man daraus macht. Es kann Strom sparen oder auch nicht – dann kann es aber auch noch viel mehr sein und nebenbei z.B. Nextcloud oder Homeassistant betreiben, Mediaencoder laufen lassen oder das eigene VPN einbinden.
Bei dem Projekt das hier vorgestellt wurde, bietet der Hersteller eben dafür gut passende Hardware an. Im Grunde nicht schwer. Eine einfaches, fertiges Intel-Mainboard für Thinclients in einem schicken Gehäuse gemeinsam mit einem freien Routermainboard für mehr Anschlüsse. Die Software kommt von den Nutzern bzw. der Community und muss garnicht vom Anbieter entwickelt werden. Allgemein sind das alles fertige Teile mit fertiger Software, die nur zum Gesamtpaket zusammengesetzt wurden. So ein Projekt schafft auch ein winziges Team mit z.B. 1-3 Ingenieuren, 1-2 Industriedesignern und einem Crowdfundingmanager.
Weitere Inhalte laden
Einloggen
Registrieren
Gadget einsenden
Leider ist etwas schief gelaufen. Bitte versuche es später nochmal.
Danke für deine Einsendung!
Wir schauen so schnell wie möglich über das User-Gadget und vielleicht siehst du es schon bald auf unserer Seite.
anaeijon
Die gibt es bei Aliexpress für etwas über 50€.
Das bringt aber überhaupt nichts. Man kann zwar sicherlich wie bei den vorherigen Modellen die Sprache umstellen, die NFC-Funktionen sind aber auf ein staatliches System in China ausgelegt und funktionieren dem entsprechend mit nichts, was es für den europäischen Markt interessant machen könnte.
Selbst wenn eine globale Version mit Visa- oder Mastercard-Unterstützung raus kommt, bedeutet das nicht, dass diese Funktion in der Chinavariante per update nachgerüstet wird. Selbst wenn man es irgendwie manuell erzwingen könnte, die Globale Firmware zu installieren, wäre es nicht unüblich, wenn Xiaomi hier in der China-Variante ein komplett anderes NFC-Chipset verbaut, das eben andere Protokolle (in Hardware) unterstützt, als die Global-Variante.
Ich würde abraten, auf bloßen Verdacht die NFC-Variante zu bestellen. Das sind verschenkte 20€
anaeijon
Bin mal gespannt, ob er wie seine Vorgänger auch recht schnell Valetudo-Unterstützung bekommt.
https://valetudo.cloud/pages/general/supported-robots.html#dreame
anaeijon
Theoretisch alles mit Zigbee.
Also IKEA Tradfri, Phillips Hue, Tuya, Aqara und weitere. Zigbee ist ein gängiger Standard.
anaeijon
zigbee2mqtt Kompatibilitätstest wäre mal was. Das gilt dann effektiv gleich für alle anderen, weil auch bei HA die meisten das Z2M-Addon benutzen.
Allerdings würde Aqara dann schlecht abschneiden als andere Firmen. Aqara hat bekanntermaßen immer Probleme mit Bindings und unterstützt die Standards der anderen Firmen nicht. Über HomeAssistant Automatisierungen geht es dann, aber direkte Zigbee-Bindings z.B. über Zigbee2MQTT haben bei mir bei noch keinem Aqara-Produkt funktioniert.
anaeijon
Schade, dass das Teil doch technisch ziemlich mies ist, für heutige Verhältnisse.
Die alten Mi A1-A3 waren Jahrelang meine Go-To Empfehlung für Familienmitglieder, die 'ein preiswertes Smartphone' brauchten. Billig, aber ausreichend und dank dem Android One Programm konnte ich damals garantieren, dass die Teile noch eine Weile mit Updates versorgt werden, kein Bloat nachinstalliert wird und auch langfristig generell gut in Software unterstützt werden. Ansonsten hat (besonders damals) Xiaomi oft nur ihre Flagships mit angemessenen Updates versorgt, während die Budgetgeräte oft schon veraltet ausgeliefert wurden und keine Updates bekamen.
Und für Oma Erna und Onkel Horst reichten die Teile eben aus, ohne sie arm zu machen und ohne dass ich mir große Sorgen machen musste.
Aber diese Hardware vom Redmi A1 würde ich heute echt nicht mehr empfehlen. Da ist doch die baldige Obsoleszenz in der App-Unterstützung vorprogrammiert.
anaeijon
Meine Empfehlung:
die 6€ Xiaomi BLE Sensoren mit freier Software drauf.
https://github.com/pvvx/ATC_MiThermometer
Für alle, die das in irgendeinem Smart Home integrieren wollen, die einfachste und billigste Lösung.
Das ganze an eine App zu koppeln verstehe ich nicht ganz. Dann muss ich mit dem Smartphone regelmäßig alle Sensoren einzeln auslesen?
anaeijon
Das ist überwiegend falsch.
Bei Zigbee wird der Hub nicht für Automatisierungen benötigt. Zigbee kann über normale Bindings genau das, was laut deinem Kommentar nur WLAN Aktoren können sollen. Zigbee ist wirklich vollständig ausfallsicher. Sogar noch besser als WLAN-Aktoren, denn WLAN benötigt immernoch einen separaten Router mit WLAN-Accesspoint. Fällt Router/Accesspoint aus, dann funktioniert auch keine WLAN Automatisierung mehr.
Zigbee-Agenten ("Agent" = Sensor, Aktor, etwas dazwischen, auch "Zigbee-Endgerät") hingegen können gleich mehrere Dinge (komplett ohne Hub) und sind dadurch deutlich ausfallsicherer. Die meisten Zigbee-Agenten mit festem Stromanschluss haben auch eine Routing-funktion. Sie bilden voll autonom ein Zigbee-Mesh-Netzwerk bzw. Ad-hoc-Netz das sich selbst heilen kann, wenn einzelne Router ausfallen.
Bei Zigbee werden Sensoren (z.B. Schalter) direkt über ein Binding mit einem Aktor (z.B. Lampe) gekoppelt. Der Sensor versucht dann direkt an den Aktor ein Signal zu senden. Erreicht das Signal den Aktor nicht, wird es durch das Zigbee-Mesh verstärkt und weitergeleitet, bis es den Aktor erreicht. Der Hub wird dabei garnicht benötigt.
Der Hub wird _nur_ bei der Einrichtung gebraucht. Der Hub legt sozusagen die Mesh-Addresse fest, teilt Router mit, wenn es einen neuen Agenten gibt und gibt dem neuen Agenten Zugang zum Netzwerk.
Der Hub wird oft auch benutzt, um die Bindings (also die Automatisierungen) festzulegen und diese in den Sensoren und Aktoren zu speichern. Einige Zigbee-Geräte (z.B. Ikea Tradfri Fernbedienungen) können Bindings sogar per Knopfdruck auch ohne Hub lernen. Auf jeden Fall: ein mal gespeicherte Bindings funktionieren immer auch ohne Hub. Der Hub erleichtert nur die Einrichtung, anschließend kann man ihn ausschalten.
Im laufenden Betrieb dient der Hub nur noch als Kombigerät. Er ist einer (von vielen) Mesh-Routern, er dient als Sensor z.B. für zeitgesteuerte Bindings und kann als Gateway z.B. die Schnittstelle zum (W)LAN sein. Er wird aber nicht wirklich benötigt.
Was etwas für Verwirrung sorgt, sind schlechte Zigbee-Geräte, die Bindings schlecht bzw. unvollständig unterstützen. Besonders Aqara hat da echte Probleme. Aqara hat ein eigenes, nicht standardisiertes Protokoll für Bindings, das kaum mit anderen Herstellern zusammen funktioniert. Sogar das Routing über Aqara-Geräte funktioniert teilweise nicht. Dann muss der Hub effektiv smarten Streitschlichter spielen und alle Automatisierungen laufen über den Hub, was eigentlich nicht so sein sollte.
Andere Marken z.B. Philips, Ikea und Tuya spielen aus meiner Erfahrung gut miteinander und kommen auch gut ohne Hub aus, wenn sie erst mal eingerichtet sind.
Ein weiteres Problem ist ein Missverständnis, z.B. von vielen Homeassistant nutzern. Oft werden statt Zigbee-Bindings einfach HA-Automatisierungen eingerichtet. Dann senden die Sensoren an den Hub, der Hub macht Automatisierung und senden an die Aktoren. Das sorgt für unnötige Verzögerungen und dabei wird dann selbstverständlich der Hub benötigt.
Z.B. Zigbee2MQTT kann aber auch einfach nachZigbee-Standard Bindings und Gruppen einrichten. Wenn man das nutzt, kann z.B. der Homeassistant mit Zigbee2MQTT-Hub komplett abgeschalten werden und die Bindings funktionieren trotzdem.
Das neue an Zigbee Direct mit BLE wäre, dass ein Zigbee Direct Gerät im Zigbee-Mesh ausreicht, um effektiv komplett ohne "Hub" (das Zigbee Direct Gerät wäre dabei kurz der Hub) neue Bindings einzurichten. Das Smartphone muss danach nicht verbunden bleiben. Auch das Zigbee Direct Gerät müsste nicht unbedingt verbunden bleiben. Mit mehreren Zigbee Direct Geräten im Mesh könnten diese vermutlich als BLE Gateway agieren.
Auch die Besorgnis über erhöhten Stromverbrauch ist unbegründet. BLE ist, wie der Name schon sagt, Low Energy. Solange keine Signale übertragen werden, also solange kein Smartphone ein Wake-Up-Signal sendet, braucht BLE keinen zusätzlichen Strom. Bluetooth, ZigBee und WiFi b/g (nicht a, n, ax) benutzen alle das 2.4GHz-Spektrum, weshalb eine Antenne für alle Protokolle ausreicht, sofern das Chipset die Protokolle unterstützt. Der beliebte ESP32 z.B. kann Bluetooth, BLE und Wifi gleichzeitig. Die Antenne in einem Zigbee Direct Gerät wäre also sowieso dauerhaft an, da über sie ZigBee läuft. Kommt ein BLE wakeup, wird das Bluetooth-Protokoll aktiviert und eine Verbindung aufgebaut.
Dennoch denke ich, dass Zigbee Direkt zunächst nur in Geräten mit Zigbee Routing verfügbar sein wird. Das sind üblicherweise Geräte, die sowieso einen festen Stromanschluss haben, z.B. Glühbirnen und Lüfter.
anaeijon
Technisch gesehen ist das nichts neues.
Der große Vorteil von Zigbee gegenüber anderen Protokollen ist doch dass alle Bindings peer2peer im Mesh passieren und auch ohne Hub funktionieren.
Ein Schalter sendet z.B. direkt an die Lampe das Signal zum einschalten oder Farbe wechseln. Der hub wird nur für die Einrichtung bzw. das orchestrieren komplexerer Bindings benötigt und kann danach auch wegfallen. Z.B. Ikea Tradfri hat sogar (schon immer) Knöpfchen um Bindings direkt vorzunehmen, ohne Hub.
Einzige Ausnahme: Aqara
Der Kram von Aqara kann kein richtiges Zigbee und vor allem keine standardisierten Zigbee-Bindings. Bei Aqara sendet alles immer zum Hub und der Hub macht die Automatisierung. Meiner Meinung nach ein absoluter dealbreaker an den ansonsten hervorragenden Aqara Geräten.
Das hier vorgestellte ZigBee Direct ist soweit nur neu, dass neuere ZigBee-Chipsets jetzt auch BLE können. ZigBee und Bluetooth laufen beide auf 2.4GHz und sind damit technisch sowieso schon dicht beieinander. Das neue Matter Protokoll sieht sogar eben neue cross-compatible Geräte vor, die gleichzeitig BLE und Zigbee nutzen. Daher wohl auch die neuen Chipsets, die effektiv genutzt werden können, um normale, direkte ZigBee-Bindings über eine Bluetooth-App anstatt von Knöpfchen (wie bei Tradfri) einzurichten.
anaeijon
Danke für den Vergleich!
Aus persönlicher Erfahrung mit Zigbee-Geräten würde ich zudem sagen, dass ich Tuya aktuell immer Aqara vorziehen würde. Aqara hat ein eigenes Protokoll für Gruppen und Bindings auf Zigbee implementiert und nutzt nicht Standard Zigbee 3.0 Bindings. Außerdem werden Eigenschaften generell 'seltsam' bereitgestellt, als würde man bei Aqara prinzipiell immer versuchen, einen eigenen Standard zu etablieren.
Im Fall von Heizkörpertermostaten brauche ich wahrscheinlich keine Bindings zu Zigbee-Buttons oder Lichtgruppen, allerdings hätte ich mittlerweile Bedenken, ob dann nicht doch irgendwas wieder seltsam implementiert ist und im Homeassistant wieder eine Extrawurst über Zigbee2MQTT braucht.
anaeijon
Der NAS hier hat eine andere Zielgruppe als z.B. Synology. Besonders im "Homeserver"-Bereich sind viele Technik- und Open-Source-Enthusiasten unterwegs und für die sind überteuerte Fertiglösungen wie Synology einfach nichts.
Stell es dir vor wie Profiköche, denen du Maggi (Synology) Tütensuppe verkaufen möchtest, mit den Argumenten, dass Tütensuppe einfach ist und im Gegensatz zu anderen Zutaten Vakuumverpackt kommt und viel weniger Energie beim Kochen verbraucht!
Das Produkt hier entspricht hingegen eher einem Service wie HelloFresh, das dir richtige Zutaten mit Rezept zum selber Kochen liefert. der Profi wird vielleicht trotzdem lieber die Zutaten einzeln kaufen, aber das hier nimmt Arbeit ab und sieht gut aus und für Zuhause reicht es.
Einen NAS auf Open-Source Basis zu entwickeln braucht definitiv nicht so viele Leute, das habe ich auch allein geschafft. Und nicht nur ich. Projekte wie TrueNAS und OpenMediaVault sind riesig und haben sehr viele Nutzer. Alles was man dafür braucht, ist ein sparsamer 'low-end' Intel PC und eben ein Gehäuse in das viele Festplatten passen.
Genügend Nutzern reicht der Kram, den Synology anbietet auch einfach nicht aus. Viele wollen eigene Lösungen, auf denen sie einfach zusätzliche Software installieren können und nicht durch proprietäre Vorgaben komplett von einer Firma abhängig sind.
Das eigene NAS-System ist dann eben genau das, was man daraus macht. Es kann Strom sparen oder auch nicht – dann kann es aber auch noch viel mehr sein und nebenbei z.B. Nextcloud oder Homeassistant betreiben, Mediaencoder laufen lassen oder das eigene VPN einbinden.
Bei dem Projekt das hier vorgestellt wurde, bietet der Hersteller eben dafür gut passende Hardware an. Im Grunde nicht schwer. Eine einfaches, fertiges Intel-Mainboard für Thinclients in einem schicken Gehäuse gemeinsam mit einem freien Routermainboard für mehr Anschlüsse. Die Software kommt von den Nutzern bzw. der Community und muss garnicht vom Anbieter entwickelt werden. Allgemein sind das alles fertige Teile mit fertiger Software, die nur zum Gesamtpaket zusammengesetzt wurden.
So ein Projekt schafft auch ein winziges Team mit z.B. 1-3 Ingenieuren, 1-2 Industriedesignern und einem Crowdfundingmanager.