CCU2 Tweaks (experimentell !!!)

Die CCU2 läuft stabil, die Nächte sind lau und die WM ist vorbei … Zeit, einen kleinen Umbau zur Geisterstunde zu wagen! :wink:

Da es, mehr oder weniger, ein reines HM-Thema ist, werfe ich es mal hier hinein. Wenn der geneigte Moderator es in der „Bastelecke“ für sinnvoller erachtet, möge er/sie/es bitte dorthin verschieben.

Wunschvorstellung war wie folgt:

  • CCU2 und LAN-GW sollen über die im Keller befindliche USV abgesichert sein
  • möglichst wenig Modifikation an den Originalteilen, speziell der CCU2
  • unauffällige Optik, da man ja nicht immer einen UP-Schaltschrank am gewählten/günstigsten Einbauort zur Verfügung hat
  • kein sichtbarer Kabelsalat
  • leicht zugängliche Komponenten
  • Umbau (eingeschränkt) reversibel

Da bereits POE im Haus-LAN genutzt wird drängte sich das als Stromquelle förmlich auf. Ein Satz POE-Splitter lag auch noch im Regal, jetzt war nur die Frage: wie vernünftig umsetzen?
Als erstes mal ein passendes Gehäuse besorgen: meine Wahl fiel auf die „StationBox InSpot“ (Bild 1, 2, 3, 4), da genug Raum, variabel, durchdachte Kabelführung, vielseitige, einfache Montagemöglichkeiten und weit entfernt von einem „optischen Foul“ wie CCU2 + POE-Splitter direkt an der Wand.

Von den beiden beiliegenden Komponententrägern (Bild 2) habe ich denjenigen mit 4 Befestigungsnippeln (Bild 4 ) gewählt und entsprechend zurecht ge-dremelt. Das Ergebnis inkl. den vorgebohrten Löchern für die Verschraubung des CCU2-Gehäuses sieht man in Bild 5.

Nach Ausbau der CCU2-Platine bekommt die Unterschale des Gehäuses 3 Löcher wovon 2 mit den Original-Gehäuseschrauben als Befestigung am Komponententräger genutzt werden. Der Halbmond vor den Schnittstellen fällt zur Platzgewinnung der Kunststoff-Trennscheibe zum Opfer (Bild 6). Der Befestigungsnippel oben rechts dient als Führung, der unten links nur als Auflage. Die beiden Schrauben wurden um ca. 3 mm gekürzt, da diese sonst aus der Rückseite des Trägers herausschauen und das einfache Ein- und Ausbauen in der Unterschale der „StationBox“ behindern. Ein weiteres Loch oder ein Schlitz sorgt für eine gerade aus dem Gehäuse ragende Antenne (Bild 7). Ob das nötig oder sinnvoll ist überlasse ich den RF-Spezialisten und dem ästhetischen Empfinden des Betrachters. Perfektionieren könnte man die Optik noch durch Austausch gegen ein Kabel mit weißem Mantel.
Per leichter Drehung im Gehäuse arretiert (Bild 8) kommt jetzt noch der Splitter hinzu, der „saugend“ zwischen CCU2-Gehäuse und Außenwand der „StationBox“ sitzt (Bild 9). Eine eigene Befestigung am Gehäuseboden schien hier übertrieben.

E voilá … fertig ist das neue Heim für die POE-CCU2. An dieser Stelle sei angemerkt, dass der Gehäusedeckel der „StationBox“ recht lichtdurchlässig ist. Einen Eindruck vermittelt das verrauschte Bild 10 (ohne Blitz in der dunklen Ecke des Raumes). Wenn man das nicht mag, gibt es sicherlich genügend Möglichkeiten die kleine Lightshow zu unterbinden. Den herumstreunenden Fellwecker wird es mit Sicherheit begeistern, spätestens bei der 1. auftretenden Servicemeldung :smiley:

Bei Anbringung an der Wand sollte man sich noch kurz überlegen wo man den Kabelausgang (Bild 3) haben will, vor allem wenn man Wert darauf legt ob der Schriftzug auf dem Deckel horizontal sein soll … Feinheiten …
Ein CAT5e-Flachkabel macht das Leben ebenfalls einfacher, trägt nicht sehr auf und schickt für 100 MBit/full + POE völlig (Leistungsaufnahme: CCU2 - ca. 2 Watt, LAN-GW neu - ca. 1,6 Watt).

Wenn man sich nicht in die Finger bohrt und die Komponenten durch Verpolung oder falsche Spannungswahl am POE-Splitter in die ewigen Jagdgründe befördert (5 V !! - die CCU1 z.b benötigt 7,5 V) ist der Umbau in 30-40 min. erledigt. Der Splitter ist übrigens ein „LevelOne Pos-1001“ bzw. „DigitalData Pos-1002“. Der Hersteller/Typ ist nicht wirklich kriegsentscheidend, Hauptsache er liefert stabile 5 V. Je nach Verfügbarkeit liefert auf der Gegenseite der Switch selbst (802.3af) oder ein POE-Injektor den Saft. Wenn es ein „manageable“ Switch ist kann man jetzt als zusätzlichen Benefit z.B. per Skript durch einfaches up/down des Ethernet-Ports der CCU2 eine Kaltstart verpassen … sollte das jemals nötig sein :rolleyes:

Das böse Wort „Garantieverlust“ spare ich mir an dieser Stelle. Der Trend geht sowieso zum CCU2-Bausatz und ein im direkten Zugriff befindliches Ersatzgerät ist je nach Ausmaß der Hausautomation ja sowieso fast schon Pflicht.

Cheers
/Jens

Über die Funkeigenschaften der CCU2 ist ja bereits viel diskutiert worden und es sind ja auch einige Lösungen zur Verbesserung im Netz zu finden (z.B. HIER). „So sehr extern“ wollte ich es jetzt nicht zwingend haben, deswegen habe ich mich für die etwas mehr Gehäuse-integrierte Version ohne Groundplane entschieden (eine Kaufversion zum verlinkten Bauvorschlag findet man z.B. HIER).

Die Antenne meiner Version ist dieses Modell und war recht einfach im Mod-Gehäuse zu integrieren. Von außen habe ich in die Lamellen der „Stationbox“ mit einem konischen Schleifaufsatz ein passend großes Loch gefräst, genau so tief, dass die Antenne ohne das Gummi-Kondom durchgesteckt werden kann, mit dem Überzieher aber noch fest im Gehäuse sitzt. Auf diese Art kann man bei Bedarf die Innereien komplett entfernen ohne die Antenne ablöten zu müssen.
Auf dem angehängten Bild ist die fertig verlötete und montierte Antenne im Detail zu sehen. Zur besseren Entstörung habe ich dem Antennenkabel noch einen kleinen Ferritkern spendiert. Besser wäre sicher noch eine zusätzliche Wicklung um den Ferritkern gewesen, die Länge des Kabels lässt das bei dieser Version aber nicht zu. Wahlweise hätte es auch ein Ringferrit getan.
Das rote Kabel dient der Erdung und ist an einem der Lötpunkte des Sendermodul-Gehäuses verbruzzelt. Der Schirm des Antennenkabels ist mit dem 2. seitlichen Lötpunkt ebenfalls an Masse verbunden.

Das Konstrukt läuft jetzt seit ca. 3 Wochen in 2 x CCU2 und 2 x LAN-GW und ich muss sagen: erheblich weniger Servicemeldungen und gefühlt bessere Reaktionszeiten.
Wer jetzt erwarten würde, dass sich die RSSI-Werte erheblich verbessern, liegt da leider falsch. Alleine schon durch den Gummi-Überzieher war das nicht zu erwarten. Manche Devices zeigen 1-2 dB bessere Werte, andere wieder etwas schlechtere. RSSI ist ja auch zu einem guten Teil eine Interpretationsfrage. Fakt ist: die Antenne liegt jetzt ein ganzes Stück weiter weg von den Störeinflüssen der Elektronik und wie im richtigen Leben sind ja oft Zentimeter entscheiden :smiley:

Cheers
/Jens

Hallo zusammen,

da die Möglichkeiten über die WebUI der CCU2 ja sehr eingeschränkt, oder eher -nicht vorhanden- sind wenn es um systemnahe Parameter/Einstellungen geht, dachte ich mir „mach doch 'nen Fred auf in dem man so etwas sammeln kann“.

Anm. d. Red.: wie der Titel schon sagt - es ist als EXPERIMENTELL zu betrachten - d.h. in Software-Sprache weder RTM, noch BETA, wenn überhaupt: ALPHA! Wer sich also nicht auf „Command Lines“ wohlfühlt, „VI“ für die römische Zahl „6“ hält, „Ping“ nur aus „Urmel aus dem Eis“ kennt und keine CCU2-Hardware als Backup im Schrank hat, für denjenigen sei empfohlen: vor einer Adaptierung besser 3 x überlegen ob man es sich leisten kann aus der weißen Schachtel einen (viel zu leichten) Briefbeschwerer zu machen. Ich denke es versteht sich von selbst, dass man vor Änderungen an irgendwelchen Dateien ein Backup des Originals durchführt :wink:
Es sei noch erwähnt, dass die Änderungen bei einem Firmware-Update mit an Sicherheit grenzender Wahrscheinlichkeit wieder überschrieben werden.

Here goes …

Die CCU2 hat ja die Angewohnheit ohne funktionierende Internet-Verbindung zeitweise recht seltsam zu (re-)agieren.

Wie wird festgestellt ob eine Internet-Verbindung besteht?

Recht simpel und hinreichend unglücklich, wie ich finde. Im Verzeichnis „/etc/network/if-up.d“ liegt ein Skript „eQ3StartNetwork“ - der Name spricht für sich. U.a. werden damit die IP, DNS-Server, etc. konfiguriert, wenn manuell über die WebUI eingetragen. Die Abfrage „Bist Du da, Internet?“ ist durch einen einfachen „ping“ realisiert, der bei positivem Ergebnis die Datei „/var/status/hasInternet“ anlegt. Als Prüfziel nutzt eq3 die IP 87.230.102.12. Warum? Das lag wohl nah … ein Reverse Lookup ergibt „www.iatsky.com“ (siehe: Impressum).

Unglücklich ist das deshalb, da es ja durchaus vorkommen kann, dass der Internet-Schnuddel durch andere Aktivitäten ausgelastet ist, der Provider mal nicht will, „www.iatsky.com“ Urlaub macht oder einfach zu träge antwortet, o.ä.
Warum sollte ich die CCU2 mit solchen Problemen „belasten“?

Schneller Fix durch Ersetzen der Prüf-IP:

  • per SSH als „root“ auf die Kommandozeile der CCU2 verbinden (zum Editieren wahlweise auch WinSCP, wer’s eher grafisch mag)

  • das Filesystem der CCU2 beschreibbar mounten:

mount -n -o remount,rw /
  • in der Datei „/etc/network/if-up.d/eQ3StartNetwork“ die IP 87.230.102.12 ersetzen (aktuell an 2! Stellen im Skript; um die Funktion nicht komplett obsolet zu machen bietet sich hier z.B. das Default Gateway aus dem eigenen Netz an → die Abfrage ist erwartungsgemäß schnell und wenn der eigene Router nicht will, ist auch definitiv kein Internet da).

  • Datei speichern

  • das Filesystem mit

mount -n -o remount,ro /

wieder „nur lesend“ mounten

  • Neustart

EDIT: der gleiche Check wird noch an einer anderen Stelle verwendet, hier allerdings mit „ping“ auf „homematic.com“. Bin nur durch Zufall darüber gestolpert, da ich bei den CCUs kein DHCP nutze -> im Skript „/bin/dhcp.script“ kann gleichermaßen „homematic.com“ durch eine sinnvollere IP ersetzt werden

[b]
EDIT: mit dem aktuellen FW-Stand der CCU2 ergibt sich mit Anpassung von „txqueuelen“ keinerlei spürbarer Geschwindigkeits- oder Zuverlässigkeitsgewinn. Interessanter sind deswegen eher die Parameter aus dem Beitrag „Eine gut geölte CCU2 …“

[/b][i]Gefühlt ist die WebUI ja generell etwas „zäh“, obwohl es ja mit der V2.9.12 schon entscheidend besser geworden ist. Zumindest der Teil, der nicht von nachgeschalteter Logik abhängig ist, lässt sich durch ein Vergrößern des (Netzwerk-)Sendepuffers noch etwas beschleunigen:

  • wie gehabt: per SSH mit „root“ auf die CCU2-Konsole und ein
ifconfig eth0 txqueuelen 5000

absetzen - Fertig! Puffer von 1000 auf 5000 erhöht!

Benötigt keinen Neustart, ist aber nach einem solchen wieder auf den Default-Wert „1000“ zurückgesetzt. Das lässt sich mit „ifconfig“ einfach prüfen.

Will man, dass es einen Neustart überlebt bietet sich UDEV an:

  • zuerst wieder auf die Konsole und
mount -n -o remount,rw /
  • im Verzeichnis „/etc/udev/rules.d“ eine Datei namens „60-custom-txqueuelen.rules“ anlegen (die Zahl am Beginn und die Endung „.rules“ sind wichtig!)

  • mit folgendem Inhalt füllen:

# Setzt die Groesse des Sendepuffers fuer das Interface eth0
# sobald es verfuegbar ist auf 5000
# Standardwert ist 1000
#
KERNEL=="eth[0]", RUN+="/sbin/ifconfig %k txqueuelen 5000"
  • da es sich um Parameter für „fest verbaute“ Hardware handelt noch ein
udevadm trigger

hinterher

  • schreibschützend mounten:
mount -n -o remount,ro /

Nach dem Neustart bzw. immer dann wenn eth0 aktiv wird, wird der Puffer jetzt automatisch auf 5000 gesetzt.

Die WebUI „an sich“ wird um einiges fixer. Ein sehr schöner Test ist das Anzeigen der RSSI-Werte über „devconfig“.
Ob es sich positiv oder negativ auf die Stabilität oder die Verbindung zu IPS auswirkt wage ich nach 2 Tagen Laufzeit noch nicht zu beurteilen.[/i]

Das „devconfig“-Menü bzw. die Webseite existiert ja schon seit CCU1-Zeiten und im Netz findet sich auch die entsprechende Beschreibung. Da ich es aber vorher erwähnt habe hier zusammengefasst die 2 Möglichkeiten des Aufrufs:

Die „auf-Dauer-anstrengend“-Methode:

  • die WebUI aufrufen und aus der URL die SID mit den beiden „@“ herauskopieren
  • die „devconfig“-URL setzt sich dann zusammen aus „http://<CCU-IP>/tools/devconfig.cgi?sid=“ und dem vorher kopierten Teil aus der WebUI-URL

Bsp.: WebUI ->

"http://1.2.3.4/pages/index.htm?sid=@12345ABCDE@&client=3"

… ergibt für DevConfig →

"http://1.2.3.4/tools/devconfig.cgi?sid=@12345ABCDE@"

Die Komfort-Variante:

Man kann sich auch permanent einen Knopf in der Systemsteuerung der CCU einblenden.

  • mit „root“ auf die Konsole der CCU und
echo CP_DEVCONFIG=1 >> /etc/config/tweaks

ausführen. Jetzt lässt sich devconfig über den plötzlich aufgetauchten (it’s magic!) Knopf in der Systemsteuerung bequem aufrufen.

Auf den ersten Blick passt AES nicht wirklich zum Thema des Freds, da war aber doch noch die 1%-Regel …!!!
(ein wenig theoretischer und historischer Hintergrund zu AES selbst ist HIER recht zugänglich zusammengefasst)

Wenn die heimische HM-Installation einen gewissen Umfang erreicht hat und der Automatisierungsgrad weiter steigt, lohnt es sich darüber nachzudenken wo und wieviel „gesicherter Übertragungsmodus“ Sinn macht (<- hier ist der Tweak versteckt!). Hinweise findet man „en masse“ im Netz und im Forum. Ich versuche es mal so detailreich wie möglich, aber noch knackig zusammenzufassen:

Nehmen wir als gegeben hin, dass eq3 sich bei der HM-Implementierung strikt an die Vorgaben der Bundesnetzagentur hält:

  • vorgeschrieben ist im Frequenzbereich 868,000 bis 868,600 MHz eine „maximale relative Frequenzbelegungsdauer“ von ≤ 1 Sek.
  • praktisch betrachtet sind das höchstens 36 Sekunden Sendedauer je Stunde
  • macht Sinn, klingt sehr wenig -> ist es auch :wink:

Wie nutze ich meine Sendezeit am effektivsten ohne die Vorgabe zu verletzen?

Drei gebräuchliche Verfahren (in der Aufwendigkeit der Implementierung absteigend):

  1. Token -> wer das herumgereichte Pfand (=Token) gerade hat, darf senden
  2. LBT -> vergleichbar einer von Vernunft geprägten, menschlichen Konversation (erst lauschen ob kein anderer palavert und dann erst losquasseln - „Listen-Before-Talk“)
  3. Zeitbeschränkt -> funktioniert auch nur bei einem einigermaßen disziplinierten Auditorium - jeder muss sich so kurz wie möglich fassen um den anderen Teilnehmern die bestmögliche Chance zu geben zufällig einen freien Kanal zu treffen.

Gerade bei 3. muss man sich natürlich überlegen: was tun, wenn ich jetzt gerade meine Nachricht nicht sofort loswerden kann?. Hier kommt jetzt wieder HM ins Spiel, da genau dieses Verfahren genutzt wird. Vereinfacht gesagt ist es so gelöst, dass die Übertragung nach einer -wie auch immer- generierten Zeitspanne wiederholt wird - „Hallo, Licht! …welches sich bei Bewegung nicht einschaltet! … 2 Minuten später … äähh … Licht!!“

Wie macht HM „Verschlüsselung“?

Gleich vorab: wenn man den „System-Sicherheitschlüssel“ über die WebUI nicht selbst vergibt macht es ungefähr soviel Sinn den „gesicherten Übertragungsmodus“ für einen HM-Kanal zu aktivieren bzw. aktiviert zu lassen (bei Fensterkontakten, Keymatic, u.a. ist das „default“), wie den mit allen Sicherheits-Features ausgestatteten Haustürschlüssel von außen im Schloss stecken zu lassen. Ab Werk ist der Standard-Schlüssel in ALLEN HM-Geräten identisch. (Attacking Homematic). Weiterhin sei erwähnt, dass der Funkverkehr selbst NICHT verschlüsselt wird. HM nutzt AES(cr), d.h. es wird eine Challenge-Response mit dem System-Sicherheitsschlüssel generiert. Hier kommt jetzt wieder der Tweaking-Gedanke ins Spiel …

Das eben beschriebene Verfahren setzt also voraus, dass der Sender als „berechtigt“ erkannt wird. Ergo: ein Kommando wird nicht sofort ausgeführt, der Empfänger fragt erst einmal beim Sender nach, ob er überhaupt den passenden Schlüssel hat. Der Sender nimmt diese Anfrage, kodiert sie mit dem ihm bekannten Key und schickt sie zurück. Wenn’s passt ruft der Empfänger dann „Yo!“ zurück und der Befehl kann ausgeführt werden. Das wiederum schlägt die Brücke zur 1%-Regel: die Übertragungszeit wird im Vergleich zu unverschlüsseltem Transfer ungefähr verdoppelt. Wenn man sich z. B. bei den Fensterkontakten die „orangene Leuchtphase“ genau anschaut, wird man auch mit bloßem Auge erkennen, dass die Übertragungszeiten unterschiedlich sind. -> hypothetisches Beispiel: ich kann also pro Tag nur 400 statt 1000 Mal die Haustür öffnen und schließen ohne dass die Funkübertragung bis auf weiteres eingestellt wird.
Das soll jetzt in keinster Weise heißen, dass der Kram nicht funktioniert. Er tut es! (von einigen Ausnahmen bestimmter Devices mit älteren FW-Ständen abgesehen; da wurden Kommandos teilweise ausgeführt, bevor das signierte Päckchen angekommen ist).

Und jetzt??

Im Endeffekt ist es sehr von den Spezifika jeder einzelnen Umgebung abhängig was AES mir an Mehrwert bringt oder ob es eher Probleme verursachen könnte. Man kann sich ja durchaus auch eine Vorstellung machen wie der Standard-Einbrecher daherkommt: hat der eher den Kuhfuß unter dem Mantel oder das Laptop samt zugehörigem Wissen und der notwendigen „Attacking-Homematic“-Hardware?!? - sehr platt, ich weiß!

Zusammenfassung / Praxis & eigene Erfahrungen:

  • die Reaktionszeiten sind ohne AES generell spürbar besser

  • bei hartnäckigen Kommunikationsstörungen auch einfach einmal, sofern vorhanden, im Objektbaum unter „MAINTENANCE“ nach dem Wert von „DUTYCYCLE“ schauen

  • gesicherte Verbindung nur da, wo es offensichtlich sensitive Bereiche betrifft (z.B. Haustür, Bewegung im Außenbereich, Selbstschußanlage…)

  • lieber 1 x mehr durchatmen und am Kopf kratzen bevor man am Sicherheitsschlüssel „dreht“

  • den selbst vergebenen Schlüssel unbedingt sicher und „unvergessbar“ aufbewahren

  • (mehr) Geduld beim An-/Ablernen -> ein Gerät, welches aus der CCU entfernt wurde und noch einen Schlüssel trägt, den keiner kennt (Backup? Was für’n Backup?), ist ein Kandidat für die Tonne oder zur Einsendung an E*V (gebührenpflichtig!)

  • in seltenen Fällen hilft seeeeeeeeehr langes Warten ohne Stromzufuhr und das Teil ist wieder mit dem Werksschlüssel oder ungesichert ansprechbar

  • soweit möglich CCU-Programme / und Direktverknüpfungen vermeiden bzw. möglichst eine klare Aufgabentrennung umsetzen - das ist jetzt kein eq3-Bashing, mir persönlich fällt es nur wesentlich leichter Kontrolle über die Anzahl gewollt ausgelöster Aktionen zu behalten, wenn ein php-Skript der einzige Auslöser ist. Gerade bei den KlickiBunti-WebUI-Programmen hat man schnell mal unbeabsichtigt „auf Änderung“ mit „auf Aktualisierung“ verwechselt oder einen „Loop“ eingebaut und der ganze Kram funkt völlig sinnlos in der Weltgeschichte umher

  • in der Theorie wird der „duty-cycle“-Status bei einem Neustart zurückgesetzt - der Effekt bleibt allerdings aus, da nach dem Neustart die CCU überdurchschnittlich viel per Funk zu tun hat

  • OTA-Firmware Updates möglichst durchführen, wenn sehr wenig sonstiger Funkverkehr zu erwarten ist

P.S.: sollte jemand eine Methode kennen einen unbekannten Key auf einem „herrenlosen“ Device zurückzusetzen - ich habe hier noch welche aus Verschlüsselungs-Versuchsreihen liegen, an denen man die Methode auf Funktionalität testen könnte :rolleyes:

Irgendwann Mitte letzten Jahres gab es ja dieses Problem bereits schon einmal. Ausgelöst wurde es damals durch einen schlichten Typo in der „crontab“:

Statt

14 4 * * * /bin/[b]S[/b]etInterfaceClock 127.0.0.1:2001

war da ein

14 4 * * * /bin/[b]s[/b]etInterfaceClock 127.0.0.1:2001

mit kleinem „S“ eingebaut.

Zwischenzeitliche trat der gleiche Fehler mit irgendeinem der letzten FW-Updates ja wieder auf und ich habe mich einigermaßen gewundert, dass ich das Problem nicht hatte. Ob die Ursache wieder der Typo war? Keine Ahnung … jedenfalls hatte ich vor gut einem Jahr die „crontab“ zusätzlich so angepasst, dass der Sync zweimal am Tag stattfindet (2 x täglich „Uhrenvergleich“ schadet ja nicht) und habe diese auch mit jedem FW-Update mitgezogen. Das hat mich in diesem Fall wohl vor dem erneuten Auftreten des Fehlers bewahrt :slight_smile:

Wie auch immer, die angepasste crontab sieht jedenfalls so aus (zu finden unter „/usr/local/crontabs“ oder einfach per „crontab -l“ anzeigen lassen):

12 4 * * * /bin/setHWClock.sh
12 16 * * * /bin/setHWClock.sh
14 4 * * * /bin/SetInterfaceClock 127.0.0.1:2001
14 16 * * * /bin/SetInterfaceClock 127.0.0.1:2001

Editieren am besten per „crontab -e“. Wenn man den Sync zum Test manuell starten will vorher das FS beschreibbar mounten, da die Datei „/etc/adjtime“ bei der Ausführung geändert wird.

Das Problem der falschen Uhrzeit (nur nach „erstmaligem“ Neustart der CCU2) besteht aktuell immer noch. Daher muss die CCU nach dem ersten Start nochmals neu gestartet werden. Dann ist alles wieder richtig.

Oder meinst Du einen anderen Fehler?

Gruß
Bruno

Den Fehler, als die Uhrzeit nach gewisser Laufzeit auf allen WTs gleich falsch angezeigt wurde. Wie gesagt, nach der manuellen Typo-Behebung (+ dem damals erschienenen FW-Update … frag mich nicht mehr welche Version das war!) hatte ich bis heute keine falsche Zeit mehr (auch nicht nach dem erstmaligen Neustart).

Um die Verwirrung zu komplettieren: Ich hatte den Fehler mit den falschen Uhrzeiten nach dem Neustart der CCU ausschließlich in Konstellationen in denen das Funk-LAN-Gateway aktiv war.

Wenn dieses aus der Konfiguration wieder raus war (nur noch LAN-Adapter) trat das Uhrzeitproblem nicht mehr auf. Das war (zumindest bei mir) reproduzierbar. Das Funk-LAN-Gatesway liegt bei mir seit dem auf Halde in der Grabbelkiste.

Eine synchrone Zeit, speziell auf den Komponenten der Hausautomation, ist eine Grundvoraussetzung um eine einwandfreie Funktion zu gewährleisten. Beispiele wie und warum es nicht funktioniert haben wir ja bereits in epischer Breite diskutiert und erlebt. Somit ist es natürlich erstrebenswert hier die Kontrolle zu haben und sich nicht auf eine funktionierenden Internetverbindung oder die Verfügbarkeit irgendeines NTP-Servers im Netz verlassen zu müssen. Ein paar Hintergrundinformationen zu NTP und der Implementation auf der CCU hatte ich hier vor einiger Zeit zusammengetragen.

Die Implementation auf der CCU:

Wie im Link oben erwähnt wir das Tool „ntpclient“ genutzt. Auch mit der aktuellen FW wird der Parameter „-t“ nicht verwendet, was mit diversen NTP-Servern Probleme bereitet. Beispiele sind diverse FW-Versionen bei den Kameraden aus der Fritz-Fraktion, ein mit Standardeinstellungen konfigurierter NTP-Server unter Windows, u.a.
Wenn ein NTP-Server über die WebUI konfiguriert wurde ist nicht wirklich sofort zu sehen, ob dieser auch korrekt funktioniert. Als „Fail-Safe“ ist im entsprechenden Start-Skript auf der CCU „ntp.homematic.com“ hinterlegt (-> „/etc/init.d/S50SetClock“).

Wie stelle ich fest ob der konfigurierte NTP-Server der CCU auch eine Zeit liefert?

  • per SSH auf die Konsole und
ntpclient -h <IP_des_NTP-Servers> -l

eingeben

Sieht der Output so oder ähnlich aus

41904 35878.468    1031.0      0.0  -261977.8  24719.2   -528130

ist alles i.O. Sollte die Zeile mit „rejected packet“ enden, funktioniert der Sync nicht.

Wenn es nicht funktioniert:

Lösungsansätze: 1. auf der CCU selbst oder 2. auf dem (eigenen) NTP-Server

  1. besteht darin an sämtlichen Stellen wo ein Aufruf des „ntpclient“ erfolgt, dem Befehl ein „-t“ anzuhängen.

  2. RFC4330-Konformität“ auf dem NTP-Server herstellen.

Am Beispiel des bordeigenen Windows NTP-Servers ist das schnell erledigt: In der Registry zum Key „HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config“ navigieren und den Wert von „LocalClockDispersion“ auf „0“ ändern (DWORD, default: „A“ hex). Neustart mit „net stop w32time && net start w32time“ und schon synchronisiert auch die CCU … und die anderen 114 Nicht-Windows-Geräte, die das vorher ebenfalls nicht taten :wink:
Am sinnvollsten ist hierbei natürlich, wenn der eigene NTP-Server die Zeit per GPS oder DCF-77 empfängt (ein serielles oder USB-Empfängermodul kostet nicht die Welt).

Ein kleiner, aber feiner zum Wochenende :wink:

Bei jeder Aktion in der WebUI wird ein Eintrag in das Access-Log des CCU-Webservers geschrieben. Da dort sowieso NIE jemand reinschaut (es sei denn, die CCU wurde gehackt, dann ist aber sowieso schon an ganz anderer Stelle etwas elementar schiefgelaufen…) und es unnötig das UBI-Device belastet, den WebUI-Zugriff verlangsamt und die Datei, je nach Nutzungsintensität der WebUI, relativ schnell recht groß wird, kann man auf diesen Teil des Loggings entspannt verzichten:

  • mit FS-Schreibberechtigung die Datei „/etc/lighttpd/conf.d/access_log.conf“ öffnen

  • den beiden Zeilen

[b]#[/b]server.modules += ( "mod_accesslog" )
...
[b]#[/b]accesslog.filename          = log_root + "/lighttpd-access.log"

das bis dahin nicht vorhandene „#“ voranstellen

  • den „Lighty“ neu starten; am besten über das zugehörige Start-Skript, dann muss man sich das Kommando nicht umständlich zusammenbauen
/etc/init.d/S50lighttpd restart
  • die vorhandene Log-Datei „/var/log/lighttpd-access.log“ bei der Gelegenheit gleich löschen

Fertig!

Das Folgende hat weniger direkt mit der CCU zu tun, eher generell mit Netzwerk-Performance. Mein Ausgangspunkt war allerdings die Verbesserung der Reaktionszeit wenn es um die Kommunikation IPS <-> CCU geht, deswegen werfe ich es einfach mal hier rein.

Einigermaßen aktuelle Hardware unterstützt Features, die nicht zwingend per Default vom entsprechenden OS genutzt werden. Man versucht hierbei aus (Abwärts-)Kompatibilitätsgründen einen Parametersatz zu wählen, der auf einer Vielzahl an Kombinationen aus unterschiedlichster Hardware und Software hinreichend gut und schnell funktioniert - als Stichworte: Receive-Side-Scaling, Chimney-Offload, etc. - es geht also nicht um irgendwelche versteckten Voodoo-Tweaks :wink:

Je nach OS-Version weichen die Grundeinstellungen voneinander ab - es kamen Parameter hinzu, wurden angepasst oder der Befehl für die Konfiguration hat sich geändert. Ein Server-OS auf Server-Hardware und/oder ein HyperVisor sind hier nochmals eine eigene Geschichte.

Die TCP-Standardeinstellung unter Win8.x sehen z.B. so aus (netsh interface tcp show global bzw. netsh interface tcp show heuristics):

Globale TCP-Parameter--------------------------------------------------------------------
Zustand der empfangsseitigen Skalierung   : enabled
Chimney-Abladezustand                     : disabled
NetDMA-Zustand                            : disabled
Direkter Cachezugriff (DCA)               : disabled
Autom. Abstimmungsgrad Empfangsfenster    : disabled
Add-On "Überlastungssteuerungsanbieter"   : none
ECN-Funktion                              : disabled
RFC 1323-Zeitstempel                      : disabled
RTO (anfänglich)                          : 3000
Zustand der Empfangssegmentzusammenfügung : disabled
Nicht-SACK-RTT-Widerstandsfähigkeit       : disabled
Maximale SYN-Neuübertragungen             : 2

TCP-Parameter für die Fensterskalierungsheuristik
----------------------------------------------
Fensterskalierungsheuristik         : disabled
Qualifizierende Zielschwelle  : 3
Profiltyp unknown              : normal
Profiltyp public               : normal
Profiltyp private              : normal
Profiltyp domain               : normal

Die Einstellungen, die ich aktuell auf meiner IPS-Maschine und den übrigen Clients (Win8.x, Win10 [10041]) nutze, sind wie folgt:

Globale TCP-Parameter--------------------------------------------------------------------
Zustand der empfangsseitigen Skalierung   : enabled
Chimney-Abladezustand                     : [b]enabled[/b]
NetDMA-Zustand                            : disabled
Direkter Cachezugriff (DCA)               : disabled
Autom. Abstimmungsgrad Empfangsfenster    : [b]highlyrestricted[/b]
Add-On "Überlastungssteuerungsanbieter"   : none
ECN-Funktion                              : [b]enabled[/b]
RFC 1323-Zeitstempel                      : [b]enabled[/b]
RTO (anfänglich)                          : 3000
Zustand der Empfangssegmentzusammenfügung : [b]enabled[/b]
Nicht-SACK-RTT-Widerstandsfähigkeit       : [b]enabled[/b]
Maximale SYN-Neuübertragungen             : 2

TCP-Parameter für die Fensterskalierungsheuristik
----------------------------------------------
Fensterskalierungsheuristik         : [b]enabled[/b]
Qualifizierende Zielschwelle  : 3
Profiltyp unknown              : normal
Profiltyp public               : normal
Profiltyp private              : normal
Profiltyp domain               : normal

U.a. zeigt diese spezifische Parametrisierung positive Effekte beim Surfen, Dateitransfer, etc. Alle Optionen hier im einzelnen zu erklären würde den sowieso schon langen Post weiter unnötig in die Länge ziehen. Es gibt dazu etliche TechNet-Artikel, die wunderschöne Erklärungen der einzelnen Punkte liefern.

Das Schicke an „netsh“ ist, dass sich das ganze mit nur 2 Befehlszeilen lösen lässt. Diese Variante lässt sich auch entspannt per GPO als lokaler Scheduler-Task verteilen und stellt so sicher, dass beim Systemstart alle Parameter entsprechend gesetzt werden. Mit dem passenden Commandlet geht es natürlich auch prima mit PowerShell.

Für einzelne PCs ist es schnell in einer Admin-CMD realisiert:

netsh interface tcp set global rss=enabled chimney=enabled netdma=disabled autotuninglevel=highlyrestricted ecncapability=enabled timestamps=enabled nonsackrttresiliency=enabled rsc=enabled

netsh interface tcp set heuristics enabled

Sollten sich negative Auswirkungen zeigen, lässt sich alles wieder mit 2 kurzen Befehlen rücksetzen:

netsh interface tcp reset global

netsh interface tcp set heuristics disabled

Wenn es denn ruckelt kann man einzelne Optionen (de-)aktivieren. Der Befehl wird dann entsprechend verkürzt, z.B.:

netsh interface tcp set global chimney=enabled

Als „Basisausstattung“ empfiehlt sich:

  • OS mit den aktuellsten Patches
  • min. 1 GbE NIC mit Offloading-Funktionalität (bei 10 GbE lassen sich noch andere „Schweinereien“ anstellen)
  • aktuelle NIC-Treiber

Der Effekt wird bei einer sowieso schon vernünftig laufenden Maschine mit solidem „Netzunterbau“ nicht dramatisch sein, im Sinne von „ich kann jetzt statt mit 110 MB/s mit 200 MB/s Dateien kopieren“ - irgendwo gibt es da physikalische Grenzen :rolleyes:
Einfach eine Weile nutzen und man wird hier und da positive Effekte feststellen können.

Es sei noch angemerkt, dass sich die Befehle auf ALLE vorhandenen Netzwerkschnittstellen für TCP-Verbindungen (der Löwenanteil des Datenverkehrs) auswirken. U.U. wirkt es sich z.B. bei einem Laptop auf Verbindungen über die Kabel-NIC positiv, auf die über den WLAN-Adapter nicht oder negativ aus - entsprechend könnte man in einem solchen Fall die Befehlszeile(n) anpassen und nur die entsprechende Schnittstelle konfigurieren.

Beste Grüße
/Jens

Update (18.11.2015):

Die Aktivierung der „TCP Window Heuristics“ hat sich als eher kontraproduktiv herausgestellt, da dann u.U. „Receive Window Scaling“ wieder angepasst wird. Außerdem hat „RFC1323 Timestamp“ sowohl im LAN als auch im WAN kaum feststellbare Auswirkungen.
Somit fahre ich aktuell mit den folgenden Einstellungen (Win8.x, Win10):

netsh interface tcp set heuristics [b]disabled
[/b]
netsh interface tcp set global autotuninglevel=[b]restricted[/b] rss=enabled chimney=enabled ecncapability=enabled timestamps=[b]disabled[/b] nonsackrttresiliency=enabled rsc=enabled

… hat noch nie geschadet :wink:

Achtung! Funktioniert in dieser Form NICHT mit der RaspBerryMatic!

Ein bisschen TCP-Tuning geht auch auf der kleinen Krawallschachtel und hilft doch hier und da die „Schaltzeiten“ zu verkürzen - gerade bei Einsatz des LAN-GWs bzw. zwischen CCU und IPS (… siehe vorheriger Post).

3 Parameter haben sich hierbei als hilfreich herausgestellt. Diese sind per „sysctl“ auf der CCU2 zu setzen:

sysctl -w net.ipv4.tcp_mtu_probing=1
sysctl -w net.ipv4.tcp_rfc1337=1
sysctl -w net.ipv4.tcp_low_latency=1

Die Einstellungen „ziehen“ sofort - also perfekt für Testzwecke. Rücksetzen funktioniert durch Setzen des entsprechenden Default-Wertes - oder durch Reboot (die Parameter finden sich im proc-FS unter „/proc/sys/net/ipv4“ wieder).

Hat man ausreichend getestet will man natürlich auch nach einem Reboot die Einstellungen wieder wie gesetzt vorfinden. Es gibt mehrere Möglichkeiten - für Pinguin-Dompteure nichts Neues - ich habe mich in diesem Fall für die Variante über „sysctl.conf“ entschieden. Alles in einer Datei - so verliert man nicht den Überblick.

Wie geht’s? So:

  • die Datei „sysctl.conf“ erstellen und wie folgt befüllen …
## mitigates a well know issue described in RFC 2923
## 'black hole router detection'
## 0: disabled (default)
## 1: enabled when black hole detected
## 2: always enabled
net.ipv4.tcp_mtu_probing=1


## enables a fix for 'time-wait assassination hazards in tcp', described in RFC 1337
## if enabled, this causes the kernel to drop RST packets for sockets in the time-wait state
## default: 0
net.ipv4.tcp_rfc1337=1


## setting this to 1 tells the stack you prefer more packets vs more bandwidth
## default: 0
net.ipv4.tcp_low_latency=1

… RW-mount nicht vergessen …

mount -n -o remount,rw /

… und (z.B. per WinSCP) im Verzeichnis „/etc“ abwerfen - die Kommentare und Leerzeilen kann man sich natürlich auch sparen

  • „manuelles Einlesen“ geht per „sysctl -p“
  • genau dieses „sysctl -p“ soll jetzt natürlich beim Start der CCU2 ausgeführt werden - ich habe mir dafür die „S00eQ3SystemStart“ im Verzeichnis „/etc/init.d“ ausgesucht. Der Befehl lässt sich prima ziemlich am Anfang der Datei einfügen:
.....

# info led fast    echo timer > /sys/class/leds/info/trigger
echo 255 > /sys/class/leds/info/brightness
echo 100 > /sys/class/leds/info/delay_off
echo 100 > /sys/class/leds/info/delay_on

[b]# ipv4 tcp tweaks[/b]
[b]sysctl -p[/b]
    
chmod 775 /var
mkdir /var/log
chmod 775 /var/log
mkdir /var/tmp
chmod 775 /var/tmp

.....
  • das übliche …
mount -n -o remount,ro /

… zum Abschluß - und fertig ist die Laube!

Happy Tweaking!

Da es in DIESEM Thread ja bereits einige Diskussionen zum Funkmodul und der entsprechenden Unterstützung gab beschreibe ich hier mal kurz und knackig wie es fix mit dem (halb)fertigen „RaspBerryMatic“-Image zum Laufen gebracht werden kann.

Zuerst stehen zwei Downloads an:

  • „RaspBerryMatic“ selbst (Beta 1, ca. 168 MB) LINK
  • Java SE Embedded (ca. 115 MB, Registrierung notwendig!) LINK

Java wird für die Gruppen und andere Funktionalitäten benötigt. Die Version im roten Kasten ist die, die wir brauchen:

JavaSEEmbedded.jpg

Jetzt eine frische MicroSD (Class10, ich hatte hier noch eine 32 GB Transcend rumfliegen) mit dem Image (raspberrymatic-2.15.2-5.img) aus dem Download (.zip) beschreiben. Tools hat es da ja reichlich. Ich habe dafür Win32DiskImager genutzt.
Wenn das erfolgreich abgeschlossen ist hat man bereits ein bootfähiges OS mit CCU2-Firmware V2.15.2 inklusive Unterstützung des Funkmoduls.

Wer hier schon testen mag einfach das Funkmodul auf den RPI stecken, MicroSD rein und los geht’s! Wenn im Netz ein funktionierender DHCP-Server vorhanden ist, kann man sich sogar das Anschließen eines Monitors am RPI sparen - einfach die IP der „neuen“ CCU2 im DHCP-Server „nachschlagen“ und auf die WebUI per Browser verbinden - sieht aus wie man es gewohnt ist :wink:
Das Erste was man jetzt tun sollte ist [1] einen funktionierenden, zuverlässigen NTP-Server einzutragen (also nicht den vorkonfigurierten) und [2] SSH zu aktivieren. Die in regelmäßigen Abständen auftauchenden Fehlermeldung einfach wegklicken, die verschwinden sobald Java installiert ist - dazu später.

Schaut man sich auf der Konsole das FS an, wird man schnell feststellen, dass da recht wenig Platz ist. Das rohe Image besteht aus einer 10 MB, Fat16 Bootpartition, 256 MB „root“ und 256 MB „blockFS“ (das dient wohl als „Ersatz“ für die in einer Standard-CCU2 evtl. vorhandenen SD-Karte).

Um Java ans Rennen zu bekommen sind die Verhältnisse sehr beengt, deshalb RPI aus, MicroSD in eine geeignete Maschine stöpseln und die Partitionen vergrößern. Eine Boot-CD oder Boot-Stick mit GPartEd ist das Tool für den Job. Ich habe root (sde2) auf 8 GB und sde3 auf 20 GB aufgezogen. Die FAT-Partition (sde1) sollte man nicht anfassen - macht auch wenig Sinn.

Nachdem jetzt genug Spielraum vorhanden ist den RPI wieder booten und per SSH auf die Konsole verbinden. Das Filesystem wird mit

mount -n -o remount,rw /

beschreibbar gemacht. Jetzt z.B. mit WinSCP unser heruntergeladenes Java-Archiv (ejdk-8u51-linux-armv6-vfp-hflt.tar.gz) im Verzeichnis /opt ablegen.
Mit der folgenden Reihe an Befehlen wird ein Verzeichnis /opt/jre angelegt (hier erwartet die CCU2 ihr JRE), das Archiv entpackt und der benötigte Teil an die richtige Stelle kopiert:

cd /opt

mkdir ./jre

tar -zxvf *.gz

cd /opt/ejdk1.8.0_51/linux_armv6_vfp_hflt

cp -r ./jre/* /opt/jre

Das war’s - Java-Installation fertig! (das Verzeichnis /opt/ejdk1.8.0_51 und die ejdk-8u51-linux-armv6-vfp-hflt.tar.gz könnte man jetzt löschen)

Ein schnelles

mount -n -o remount,ro /

und damit die neue CCU2 Java auch nutzen kann einfach noch einen Reboot hinterher - fertig ist die Laube - eine voll funktionsfähige CCU2 auf dem RasPi2!

WICHTIG! - Anmerkungen:

  • bevor man ein Backup seiner „alten“ CCU2 einspielt unbedingt darauf achten, dass Datum/Uhrzeit stimmen
  • die „alte“ CCU vor dem Einspielen des Backups AUSSCHALTEN
  • ein Restore wird nur richtig funktionieren, wenn das Backup OHNE installierte Addons wie z.B. CuxD erstellt wurde
  • es werden beim ersten Start ein Haufen Servicemeldungen anstehen - nicht nervös werden - wer schon einmal eine CCU restored hat kennt das. Die SMs verschwinden nach und nach - Geräte, die sich nicht oft von selbst melden (z.B. Fensterkontakte, Rauchmelder) brauchen etwas länger oder werden durch Bedienung gezwungen „Hallo!“ zu sagen
  • war ein LAN-GW (neu) in Benutzung wird dies nicht mehr vorhanden sein. Keine Ahnung warum, aber ich musste es bei jedem Restore-Versuch neu anlegen / das RS485-GW hingegen war sofort vorhanden und einsatzbereit

Alles in Allem eine feine Sache und richtig schnell der Apparat! Bin gespannt wie sich das weiterhin entwickelt.

Beste Grüße
/Jens

EDIT(1): Die Sende-/Empfangsqualität bzw. -Leistung scheint um einiges schlechter zu sein als die der CCU2 (ein User berichtet das auch im „anderen“ Forum), zumindest in der aktuellen Konfiguration. Ob das in einem späteren Release besser wird, wird man sehen. Sollte es an der HW an sich liegen habe ich da auch bereits einen netten Einfall - demnächst in diesem Kino :wink:

EDIT(2): Wem die händische Java-Installation zu anstrengend ist, der kann jetzt auf ein CCU2-Installationspaket zurückgreifen. Das Paket in Version 1.0 gibt es HIER inkl. dem Projekt auf GitHub.

EDIT(3): Aktualisierte Version V1.1 des HM-JRE Pakets

EDIT(4): Mittlerweile ist auch CUxD in der Version 1.4a für RaspBerryMatic verfügbar.

EDIT(5): mit dem Erscheinen des aktuellen 8er Java-Update 65 wurde auch die Embedded-Version aktualisiert. Sobald das finale RaspBerryMatic-Image verfügbar ist werde ich dazu noch etwas detaillierter posten

EDIT(6): Einspielen eines Backups, welches mit einer höheren Version der CCU2-Firmware erstellt wurde, ist nicht möglich!

Hallo r4m3u5,

wenn ich den Beitrag „Eine gut geölte CCU2“ genau nach Anleitung versuche umzusetzen, flippt meine CCU völlig aus… (40 Geräte finden keine Verbindung mehr, Befehle via IP-Symcon können nicht mehr abgesetzt werden…)Wenn ich die Änderungen wieder rückgängig mache, läuft alles wie gut geölt :wink:
Just 4 info…

Danke für die Rückmeldung!

Aber … seltsam!? Hier läuft es auf 2 x Original-CCU2 seit Monaten und 2 x RaspBerryMatic im Dauerbetrieb völlig problemlos :wink:
Da Du sowohl auf der Netz-Seite, als auch auf der RF-Seite Probleme hast vermute ich stark, dass sich evtl. irgendwo ein Typo (Leerzeichen, Zeilenumbruch, o.ä.) eingeschlichen hat. Sollte es auch auftreten wenn Du die Parameter direkt per Befehlszeile setzt (kann man ja problemlos stufenweise testen), läuft in Deiner Infra etwas „anders“ als erwartet.
Solltest Du herausfinden welcher der 3 Parameter es verursacht bin ich sehr daran interessiert!

Beste Grüße
/Jens

Da der RPI ja eher ungünstig für Wand- oder Deckenbefestigung ausgelegt ist und die Antenne des Funkmoduls bereits seine Schwächen gezeigt hat, musste ein neues Zuhause für die RaspBerryMatic her.
Die Antennen-Thematik hat ja schon für Diskussionen gesorgt und entsprechende Lösungen hervorgebracht (z.B. HIER). Was mir daran nicht wirklich gefällt ist, dass diese Ausführung weder kompakt ist, noch ausreichend Spielraum für eine leichte Modifikation bietet. Man hat auch nicht unbedingt immer Möglichkeiten dieses Antennenmonstrum angenehm zu verstecken - definitiv ein optisches Foul :wink:

Als Basis dient wieder das aus dem CCU2-Mod V1 bekannte Gehäuse. Um den RPI vernünftig auf dem herausnehmbaren Geräteträger zu befestigen wurde der Träger formschön zurechtgedremelt (Bild 1 - 3) und das RPI-Gehäuse mit einer M4 Kunststoff-Schraube an der vorhandenen, leicht angepassten Nase befestigt (völlig ausreichend, da keine großartigen mechanische Belastungen wirken). Um ohne Demontage von der Träger-Platte die Micro-SD wechseln zu können, wurde ein ausreichend großer Ausschnitt auf der entsprechenden Gehäuseseite gefräst.
Die Stromversorgung bewerkstelligt ein 5V-POE-Splitter. Gibt’s für ein paar Kröten bereits mit dem passendem Micro-USB-Stecker und ist leistungsmäßig völlig ausreichend (der Switch zeigt im Betrieb auf dem Port zwischen 2 und 4 Watt an). Sowohl am Kabel der Stromzufuhr als auch am Antennenkabel wurde zwecks Entstörung ein Ferritkern angeklippst und das Antennenkabel mit einer zusätzlichen Schlaufe um den Kern versehen. Ein wenig Heißkleber sorgt für rutschfesten Sitz. Als Antenne dient hier ein 4dB Pigtail (verschraubbar, drehbar um 90°). Sollte man also doch „mehr“ Antenne benötigen, wird diese einfach direkt oder per Kabel mit dem am Träger verschraubten SMA-Stecker verbunden - die Halterung am Geräteträger ist vorhanden (ursprünglich sind es 2 - eine ist der Trennscheibe zum Opfer gefallen).

Fertig! RaspBerryMatic + Stromversorgung und Antenne im Gehäuse, vernünftige Sende- und Empfangsleistung, kein sichtbarer Kabelsalat und nur eine Ethernet-Strippe zum Gerät hin.

Bilder sagen mehr als 1000 Worte …

Stückliste:

[ul]
[li]Raspberry Pi 2 B, 1 GB, ca. € 38[/li][li]Satz Kühlkörper Alu f. RPI2, ca. € 4[/li][li]microSDHC, 32 GB, Class10, ca. € 12[/li][li]HM Funkmodul für RPI, ca. € 20[/li][li]Gehäuse RF Elements „StationBox InSpot“, ca. € 14[/li][li]Raspberry Pi PoE Splitter (IEEE802.3af), ca. € 20[/li][li]Gehäuse für Raspberry Pi 2 B, schwarz, ca. € 7[/li][li]Kunststoffschraube M4x12 + U-Scheibe + Mutter M4[/li][li]Delock WLAN Antennenkabel. SMA/I-PEX, 20cm, ca. € 7[/li][li]2 x Ferrit-Ringkern Clip 3,5mm, schwarz, rund, ca € 1[/li][li]H-Tronic HT110A Antenne, 868 MHz, 4 dB, ca. € 10[/li][/ul]

Gesamt: ca. € 133 für eine „Luxus-CCU2“

Was ist denn das für ein Gehäuse? Haste Deiner Frau die Salatschleuder gemopst? [emoji3]