Empfehlung Gigabit SBC?

Begonnen von connormcl, 03 April 2018, 23:12:16

Vorheriges Thema - Nächstes Thema

connormcl

Hallo Zusammen,

vielleicht hat ja hier jemand eine Idee, was ich als neuen SBC für FHEM und Routing nehmen könnte.

Ich hatte bisher FHEM auf einem Raspberry Pi 3B laufen. Dieser läuft unter LEDE/OpenWRT, um das Routing von WLAN/LAN/DSL mit zu übernehmen.
Nach Upgrade auf 150mbit/s Leitung und in ca. einem Jahr vermutlich auf 400mbit/s Leitung ist der Raspberry Pi 3B mit seinen 100mbit/s Durchsatz der Flaschenhals.


Ich suche deshalb einen neuen SBC mit geringem Stromverbrauch (<15 Watt), der durchlaufen kann und die Aufgaben übernimmt.
Folgendes sollte er haben:

- geringer Stromverbrauch <15Watt
- zuverlässige Hardware
- 2+ GigaBit Ports oder 1 GigaBit Port + USB3.0
- 2+ USB Ports (3.0 nur benötigt, wenn er nur einen GigaBit Port hat)
- sollte LEDE/OpenWRT als Basissystem unterstützen

Was ich mir bisher angesehen habe:

- Raspberry Pi 3B+ -> LAN immernoch zu langsam, da gleich angebunden wie beim 3B...im Routingbetrieb keine Steigerung möglich
- Espressobin -> anscheinend thermisch instabil und unzuverlässig hinsichtlich SD Lesefehlern
- BananaPi R2 -> unklar, wieviel er verbraucht und ob die LEDE Unterstützung schon stabil ist
- Intel NUC: keine Übersicht, welchen Stromverbrauch welches Gerät hat und wie schnell es dann ist; bzw. was das kleinste ist und ob das ausreicht.

Vielleicht hat ja jemand schon was passendes im Einsatz und kann berichten...

Morgennebel

Ein Router routet.
Ein SmartHome-Server schaltet.

Zwei Funktionen, zwei Systeme. Behalte Deinen Pi fuer FHEM und kauf Dir nen richtigen Router.

Ciao, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

yersinia

Ich kann Morgennebel nur beipflichten. Ich würde auch Router und FHEM trennen.

Bezgl. Router und OpenWRT/LEDE habe ich mit TP-Link ganz gute Erfahrungen gemacht. Einfach im Gebrauchtbereich eines Onlinehändlers bzw. Kleinanzeigen etc. schauen und dann mit der OpenWRT/LEDE ToH abgleichen (wichtig: wesentlich mehr als 4MB Flash und 32MB RAM muss der Router haben).

Ich habe LEDE 17.01.4 auf drei TP-Link Routern laufen: TL-WR1043ND, TL-WDR4900 und MR3020 (allerdings ohne LUCI und IPv6 Unterstützung).
(an dem TLWR1043ND hängt auch ein nanoCUL, welcher via ser2net an FHEM angebunden ist; am TL-WDR4900 hängt ein USB Scanner und ist mit sane ins Netzwerk eingebunden)

FHEM läuft auf einem RPi 3 B mit Raspbian Lite in einem eigenen VLAN.
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

mark79

#3
Ich würde das auch lieber trennen....

Aber für Fhem habe mir vor einer Woche ein Rock64 bestellt.
Der hat 1x Gigabit, 1x USB3, Hardware AES Verschlüsselung und bis zu 4 GB DDR3 Ram und wird von armbian, dietpi etc. unterstützt.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

connormcl

Bisher läuft der interne Router und FHEM ohne Probleme auf derselben Kiste...nur halt mit dem 100mbit/s Problem...

Ich hab jetzt halt schon zig Geräte permanent bzw. standby laufen, da wollte ich soweit wie möglich konsolidieren.

- 1x Glasfaser Umsetzer Unitymedia
- 1x Router Unitymedia
- 1x Gigabit Switch
- 3x Raspberry Pi für FHEM und Funk-Module + WLAN auf drei Stockwerken
- 1x CCU2

+ alle möglichen Aktoren

Da kommen leider schon an die 100 Watt im Dauerlauf zusammen, so dass ein weiteres Gerät nicht optimal ist.

Welchen Stromverbrauch habt ihr so mit einer etwas umfangreicheren Hausautomatisierung durchgängig?

mark79

Zitat von: connormcl am 04 April 2018, 18:14:57
Bisher läuft der interne Router und FHEM ohne Probleme auf derselben Kiste...nur halt mit dem 100mbit/s Problem...

Ich hab jetzt halt schon zig Geräte permanent bzw. standby laufen, da wollte ich soweit wie möglich konsolidieren.

- 1x Glasfaser Umsetzer Unitymedia
- 1x Router Unitymedia
- 1x Gigabit Switch
- 3x Raspberry Pi für FHEM und Funk-Module + WLAN auf drei Stockwerken
- 1x CCU2

+ alle möglichen Aktoren

Da kommen leider schon an die 100 Watt im Dauerlauf zusammen, so dass ein weiteres Gerät nicht optimal ist.

Welchen Stromverbrauch habt ihr so mit einer etwas umfangreicheren Hausautomatisierung durchgängig?

Ich habe auch einen Hang dazu, Geräte zu minimieren um Strom zu sparen.. :) Ich habe schon ein paar 1ch Sonoffs durch 4ch Sonoffs ersetzt, um ein paar Watt einzusparen.  ;D
Aber wie viel das ganze verbraucht, weiß ich ehrlich gesagt nicht. Habe das noch nie im einzelnen Nachgemessen und ich habe nur ein Stockwerk zu versorgen...

Mein Plan war evtl. noch die Synlogy NAS durch den Rock64 zu ersetzen, aber ich schaue erstmal, wie stabil das ganze läuft.

100 Watt klingt schon viel, hast du das nachgemessen?

Die 3 RPis bzw. 2 davon könntest du auch mit ESPs ersetzen, wenn du die nur für HM brauchst (HM-MOD-UART mit ESP8266). Das bringt auch ein paar Watt Einsparung.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

frank

oder die ccu2 weg und eine virtuelle ccu2 auf einen rpi.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

connormcl

@mark79:
Den Stromverbrauch gibt leider der Stromzähler direkt aus...das sind also direkt die Gesamtwatt, die auch verrechnet werden...

@frank:
Setzt die virtuelle ccu2 den HM-MOD-RPI-PCB voraus? Der ist ja anscheinend abgekündigt bzw. nicht mehr lieferbar...soll aber wohl durch ein neues Modul mit RTC ersetzt werden, was aber noch nicht auf dem Markt ist...

frank

ich glaube man kann auch andere io nutzen.
es gibt aber auch wieder hmuart bei elv, das war eine fakenews. also mit hmuart sparst du dann noch etwas power.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

connormcl

Im Moment überlege ich an einer APU2 herum:

https://www.apu-board.de/produkte/apu2c4.html

Die ist wohl vergleichbar mit einem NUC, nur preislich und im Stromverbrauch interessanter.

mark79

So ein Teil hatte ich auch mal, vor 10 Jahren mit m0n0wall/pfsense: https://www.pcengines.ch/alix2c2.htm
Lief gut und bei x86 Hardware hat man auch weniger Probleme mit den Treibern, als bei ARM.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

DerBodo

Ich habe bei mir einen NUC eingesetzt, liegt bei Normallast bei ~9-14 Watt.

Darauf läuft ein ESXI. FHEM, Ubiquiti Controller und Testmaschinen laufen in jeweils einer eigenen VM.
Somit kann ich immer mal etwas neues ausprobieren ohne gleich die aktuelle Installation zu gefährden.

Backup ist mit GhettoVCB aufs NAS auch easy möglich.

Wenn du unbedingt die gleiche Hardware als Router nutzen willst gibts die auch mit 2 NICs (sind dann die ZOTAC Mini PCs).


Wernieman

Habe hier ein Zotac CI324 mit 2 NICs "uff Arbeit". Hatte mal Testweise mit beiden im routerbetrieb gespielt, läuft super.

Genau den habe ich jetzt nicht im Stromverbrauch gemessen, aber der direkte Vorgänger (CI320) läuft "zu Hause" bei ~7W im Normalbetrieb (FHEM + diverse Kleinserverdienste, ist aber praktisch IDEL) mit 8GByte Speicher und 240GByte SSD + 1 USB-Hub.

Auf der Kiste hatte ich auch mal VirtualBox und Docker am laufen ... hat also "alle Möglichkeiten".

Trotzdem würde ich Front-System (router) und Server trennen. Dann hast Du den Vorteil, das Frontsystem besser absichern zu können. An der Stelle würde ich Sicherheit VOR Stromverbrauch stellen.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

koldomon

ich nutze den OdroidC1 für mein FHEM.
Quad-Core CPU, 2GB RAM, GB-Netzwerk, 4xUSB

Der läuft jetzt seid 5 Jahren problemlos und superflott. Das GB-Interface merk ich schon beim Seitenaufbau im Browser. Demnächst werde ich nen HW-Refresh machen (zur Sicherheit) und werde wohl auf den C2 umsteigen.

Ich bin kein Freund von "1xHW"->"12Rollen". Dein Routing und FHEM sollte auf dem Odroid problemlos möglich sein. Alternativ kann ich dir sonst nur noch die ALIX Boards empfehlen. Damit lassen sich gute Firewall/Router Lösungen bauen, weil's die Teile auch gleich mit 3xGB gibt (LAN,DMZ,ganz böses INET). Darauf kannst auch gleich IPFIRE installieren oder Debain oder whatever. da läuft ganz normal Linux dann drauf. https://www.pcengines.ch/alix.htm

cu markus
OdroidC1 -> fhem
CUNO -> FS20
CUL -> HomeMatic
TCM310 -> enOcean
DUOFERN -> rademacher

connormcl

Danke für die Vorschläge.

Ich habe mir mittlerweile von PC Engines eine APU2C4 geholt und gestern in Betrieb genommen. Das Ding performt bisher super...3x Gigabit + WIFI Routing ohne Probleme und genug Reserven. Standard AMD64 Quad-Core 1 Ghz mit sehr geringem Stromverbrauch 6-12 Watt und 4GB ECC Ram.
Einziger Nachteil (für mich egal): man muss aufgrund der Kühllösung das vom Hersteller designte Gehäuse verwenden.

koldomon

Erstmal gratulation zu deinem Alix-Board (ein klein wenig neid kommt grad bei mir auf - sowas hätte ich gerne als "entry-Firewall")

Kannst du bitte noch ein paar Details erzählen, wie du jetzt den Dauerbetrieb sicherstellst? Backup, USV, WLAN.... Da du ja bis jetzt auf jedem Stockwerk einen eigenen RPi hattest und jetzt nur noch 1 Device? Wie sieht dein Umbau aus? Mich interessiert vor allem das USV-Thema. Da mein Odroid auf 5V läuft, hab ich eine Powerbank dazwischengeschaltet, die man gleichzeitig Laden und Entnehmen kann (ja sowas gabs mal). Bei 12V geht das nicht mehr?

danke im voraus
OdroidC1 -> fhem
CUNO -> FS20
CUL -> HomeMatic
TCM310 -> enOcean
DUOFERN -> rademacher

connormcl

@koldomon:
Die APU2C4 ersetzt den Raspberry Pi 3B im Untergeschoss; auf diesem lief bisher LEDE fürs Routing und obendrauf im chroot ein Debian für FHEM.
Im EG und OG stehen nochmal je ein Pi 3B mit diversen IOs...JeeLinks/nanoCULs/RFXCOM/Bluetooth/WLAN. Die Pis im EG/OG werden bisher noch nicht ersetzt. Die Pis und APU2C4 sind dann über LAN vernetzt.

Den Dauerbetrieb sicherzustellen war zunächst ziemlich herausfordernd. Ich hatte an allen drei Stationen eine USV stehen. Powerbank war nie sonderlich stabil bei mir; ausserdem musste noch der USB-Hub versorgt werden. Ich habe 50 EUR USVs verwendet (Fortron FSP Nano 800). Habe nie gemessen, wie lange der Pi dran läuft...müsste ca. 21-22 Stunden laufen. Die APU2C4 sollte um die 14 Stunden dran laufen.

Wenn aber der Strom ausfällt, sind eh fast alle Aktoren, sowie das Internet tot. Deshalb habe ich alle SD-Dateisysteme auf Read-Only-Mount gestellt und Log-Ausgaben auf USB-Stick. So können die einfach mit dem Strom ausgehen und fahren dann wieder hoch.

Die APU2 werde ich zunächst wieder mit USV betreiben, bis alles stabil läuft.

Eine Alarmanlage habe ich noch nicht realisiert; da müsste dann auch ein SMS-Gateway oder ähnliches her, dass die Komunikation bei Stromausfall ermöglicht.

Backup habe ich bisher über Kopieren der Dateien auf Share und per Image ziehen von SD-Karte gelöst. Mit Read-Only-Dateisystemen sollte es möglich sein, das Image auf dem laufen Gerät zu ziehen und direkt auf ein Share zu schreiben. Damit sollte dann keine Downtime für Image nötig sein.