Treppenstufenbeleuchtung

Wer hätte gedacht, dass das so ein kompliziertes Thema wird? Eigentlich dachte ich, das wäre alles ganz einfach. Ich wollte gerne in der Wand kleine Lampen haben, die die Treppe anleuchten. In etwa so:

Quelle: nikolaus-lueneburg.de

Die kleinen Lampen sollen dann noch dimmbar sein, damit sie einem nachts auf dem Weg nach unten nicht die Augen weg-blitz-dingsen. Aber genau das scheint ein Problem zu sein. Ich finde einfach keine LED Lampen mit dimmbaren LED Treibern.

Ich habe jetzt noch die SLV Flat frame basic entdeckt und werde versuchen diese mit dimmbaren LEDs passend für die G4 Fassung auszustatten, sodass ich diese dann über den RGBW Dimmer (6 Lampen auf 4 Kreisen) steuern kann. Die Bestellung für die Lampen und Leuchtmittel ist heute rausgegangen – ich bin gespannt ob das ganze funktioniert 🙂

KNX vs. Loxlink

KNX ist _der_ Standard rund um Gebäudeautomatisierung und stammt aus 2002. Es ist der verbreitetste Standard überhaupt, wenn es darum geht Logik in elektrische Gebäudeschaltungen zu bringen.

Loxone bietet im Miniserver eine KNX Schnittstelle um KNX Komponenten zu integrieren. Damit erweitert sich das Spektrum an möglichen Komponenten um ein vielfaches. Vor allem macht dies Sinn bei speziellen Aktoren oder Sensoren.

In meinem Fall werde ich im Bereich der Relais für Stromkreise oder Jalousien auf KNX Aktoren von MDT setzen. Der Grund ist vorallem der Preis. Ein kurzer Vergleich gefällig?

Jalousieaktoren

 

Schaltaktoren

 


 

Der Preis pro Kanal ist also bei Loxone generell höher, dafür ist der Aufwand für die Integration in Loxone natürlich geringer. Die Relay Extension wird out of the box erkannt und die KNX Aktoren müssen umständlich über die ETS programmiert und anschließend händisch in Loxone eingebunden werden.

Übrigens ist die Auswahl der Bewegungsmelder auch erheblich höher. So werde ich mal auf die Suche nach einem KNX Bewegungsmelder für eine UP Dose gehen, den ich dann im Treppenbereich nutzen kann. Relativ schnell habe ich den BWM55.01 ebenfalls von MDT gefunden… hier mehr sobald ich etwas testen kann. 

Hausbau…oh je

Anfang des Jahres haben wir uns entschlossen, uns ein bisschen zu vergrößern. Das Hausbauen an sich ist ja schon eine spannende Geschichte. Man muss mit diversen Gewerken allerlei Details klären – wenn man mal soweit ist, dass man einen Bauträger oder Architekten und dann einen Grundriss hat. Täglich flattern Rechnungen von Notaren, der Stadt oder Bauunternehmen ins Haus.

Aber da es schon ca. 100 Bau-Blogs zu diesen normalen Themen gibt, überspringe ich das hier mal und komme direkt zu spannenden Teil: Smart Home.

Smart Home

Ganz genau, wir (und damit meine ich vor allem mich) wollen ein Haus, das etwas mit denkt. Und unter Smart Home verstehen wir hier nicht „ich kann mit dem Handy meine Lampen steuern“ sondern wirkliche Intelligenz die einem Arbeit ab nimmt.

Ein paar Beispiele gefällig?

  • automatische Beschattung: Sonne aussperren wenn es zu warm ist und Sonne hereinlassen wenn es zu kalt ist – so kann man die Heizkosten senken
  • intelligente Heizungssteuerung: nur heizen wenn es nötig ist und jemand anwesend ist
  • Beleuchtungs-Szenen die sich bei bestimmten Aktionen aktivieren: beim Fernsehen gehen die Rolläden etwas runter, das Licht wird gedimmt und Lampen die sich im TV spiegeln, gehen ganz aus

Planung

Die Planung eines solchen Smart Homes ist aber gar nicht so trivial. Es gibt hunderte von Punkten die Bedacht werden müssen, damit es auch zukunftssicher ist und Flexibilität bietet.

Alle Gewerke im Haus, Beleuchtung, Heizung, Multimedia, müssen zusammen spielen und sich verstehen. Drittanbieter Anwendungen wollen integriert werden und das ganze muss natürlich von der Frau akzeptiert werden (Stichwort: WAF)

Los geht’s

Ich habe mir zunächst Gedanken gemacht, was ich eigentlich steuern will. Daraus ergibt sich dann auch warum und wie man dieses steuert. Wenn man sich das überlegt, ergeben sich schnell eine Reihe an Sensoren die man benötigt um alles ohne Schalter zu steuern. Fenstersensoren, Bewegungs- bzw. Präsenzmelder, Temperatursensoren, Wettersensoren, Stromverbrauchsmessungen… Und man darf natürlich nicht nur an das Innere des Hauses denken – auch der Garten und die Garage wollen einbezogen werden! Bodenfeuchtesensoren, Tor-Sensoren oder auch Kameras wollen wohl überlegt werden bevor der erste Stein des Hauses steht.

Anschließend muss man sich noch für ein System entscheiden – kleiner Witz. Man muss sich für seine primären Systeme entscheiden. Denn mit nur einem System kommt man nicht weit. In meinem Fall wird es eine Mischung aus:

  • Loxone
    • Tree (Loxone BUS-System)
  • KNX
  • 1-Wire
  • Netzwerk
  • proprietäre Drittsysteme z.B. GIRA Rauchwarnmelder

werden. Diese Liste mit Möglichkeiten könnte man noch ewig weiter führen. Alleine für die Lichtsteuerung könnte man noch auf DALI und DMX zurückgreifen. Aber je mehr BUS Systeme man hat, desto unübersichtlicher wird das ganze System.

Und nun?

Jetzt wo wir wissen, welche Komponenten wir nutzen können, müssen wir uns ein Raumbuch erstellen. Ein Raumbuch listet für jeden Raum in eurem Haus auf, welche Komponenten oder Anschlüsse er bekommt. Dieses Raumbuch wird sehr schnell sehr groß. Am besten ist, ihr fertigt eine Excel Tabelle an.

Nach meiner ersten Planung ergeben sich bei mir z.b. 25 dauerstrom Steckdosen, 40 schaltbare Steckdosen ohne und 2 Steckdosen mit Leistungsmessung. 13 Rolläden, eine Markise etc… Von manchen der Zahlen war ich dann doch etwas überrascht. Dieses Raumbuch werdet ihr in der Planung immer wieder brauchen, um den Kabelplan zu erstellen (wo brauche ich KNX, wo brauche ich 1-Wire?) oder auch einfach nur Ein- und Ausgänge zu zählen. Für 42 schaltbare Steckdosen brauche ich also mindestens zwei 20-Fach Schaltaktoren etc.

Wir werden bei uns eine Mischung aus richtigen KNX Schaltern und herkömmlichen Schaltern mit Binär-Eingang am Loxone System verwenden. Und hier fängt dann auch das Kopfzerbrechen schon an. Ich brauche pro Raum ca. 5 Binär-Eingänge für die vier Schalter und den Fenstersensor. Da macht es ja schon Sinn einen 6-fach UP Nano-DI Tree in jedem Raum zu verteilen. Aber damit schaffe ich mir natürlich Fehlerquellen überall im Haus… alle Kabel in den Schaltschrank zu führen ist aber auch nicht optimal… und nu? 🙂 An diesem Punkt landet man relativ oft… und da hilft nur eins: noch mehr planen. Meistens ergibt sich dadurch dann die Lösung in Verbindung mit einem anderen Gewerk o.ä. das betrachtet werden muss.

Die Qual der Wahl

Quelle: https://www.ovnblog.com/

Oft hat man mehrere Möglichkeiten das gleiche Problem zu lösen. Unser Badezimmer z.B. ist geplant mit 4 weißen LED Spots und 1-2 RGBW Spots. Jetzt könnte ich

a) alles mit Loxone Tree Spots bauen. Vorteil: jeder Spot ist einzeln steuerbar.

b) alle Spots über zwei Loxone RGBW Dimmer ansteuern. Damit wären aber die RGBW Spots nicht unterschiedlich steuerbar.

Variante a) ist natürlich teuer, ca 500€ für 6 einzeln steuerbare Spots. Variante b) kostet nur ca. 370€ kostet mich aber auch Flexibilität. Die goldene Mitte wären 4 weiße Spots über einen zentralen Dimmer und 2 RGBWs über Tree für ca. 420€. Allerdings muss man dann natürlich 7×2,5mm2 für die weißen Spots und noch Tree-Leitung für die RGBWs vorsehen. Doppelter Aufwand in der Verkabelung. Auch hier warte ich erstmal ab, was die anderen Gewerke um das Badezimmer herum so an Leitungen mit sich bringen.

Probleme?

Multi Room Audio

Ich muss ganz ehrlich gestehen: mein größtes Problem aktuell ist Multi Room Audio. Es gibt keine optimale Lösung. Ich habe einfach keine gefunden! Der Loxone Music-Server kostet mindestens 1.500€ und kann dafür gar nicht sooo viel. Als kostenfreie Alternative gibt es die OpenSource Entwicklung MusikServer4Lox – aber dieser ist nicht so gut integriert in Loxone.

Sonos? Alles Kabellos, funktioniert eigentlich ganz gut. Ist für mich im Neubau aber keine echte Alternative zumal die Anbindung von kabelgebundenen Verbrauchern (z.B. Wohnzimmer HiFi Anlage) mit dem 300€ Sonos-Connect auch schon wieder unverschämt teuer ist. Ein Selbstbau-System hatte ich ja schonmal mehr oder weniger Erfolgreich in Betrieb und möchte ich eigentlich nicht mehr. Vor allem der WAF war nicht zufriedenstellend. Daher wird dieser Punkt bei mir vorerst offen bleiben. Ich ziehe Leitungen für die Lautsprecher nach draußen und in Räume wie die Küche, Schlafzimmer oder Kinderzimmer und das wars.

Türklingel

Außerdem ist das Thema Türklingel noch offen. Es soll natürlich eine Türsprechstelle mit Integration in das Smart Home werden. Eine Kamera ist uns wichtig und auch das öffnen der Tür per Knopfdruck. Wer will schon immer zur Tür rennen?Aber auch hier ist die Suche wieder nicht so einfach. Generell kann man sogar die Kamera und die Sprechstelle trennen. Eine IP Cam unter dem Dach zeigt den Eingang und die Sprechstelle ist per SIP mit der Loxone Umgebung verbunden. Aber eine vernünftige, günstige SIP Klingel sucht man vergebens. Schnell landet man bei der Loxone Intercom (hässlich und viel zu teuer) oder der Doorbird. Alternativ kann man ein Selbstbauprojekt starten und die SIP Verbindung über den anlogen Eingang einer Fritzbox herstellen… aber das ist ja auch wieder nur Gebastel…

Fazit

Ihr seht, das ganze Thema ist relativ komplex und offensichtlich gibt es nicht ohne Grund Leute die das hauptberuflich machen. Aber die Herausforderung nehme ich gerne an und werde mich weiter durch den Dschungel kämpfen und euch auf dem laufenden halten.

IP Adresse eines ToughSwitch via CLI ändern

Ich habe letzte Woche einen ToughSwitch eingebaut.. Etwas naiv war ich der Meinung, er würde sich eine DHCP IP ziehen – nö. Also musste ich die IP an das vorhandene Subnetz anpassen.

Dazu habe ich auf einer Linux-Maschine vor Ort ein zweites Interface eröffnet:

iface eth0:1 inet static
address 192.168.1.252
netmask 255.255.255.0

Nun konnte ich via SSH auf den Switch zugreifen:

ssh ubnt@192.168.1.20

Anschließend kann man in der Datei ‚/tmp/system.cfg‘ die IP sowie das Gateway anpassen:

Danach einmal die Konfiguration speichern, damit sie nach dem Reboot noch vorhanden ist:

save

Nun kann man entweder Neustarten oder einfach die neue Konfiguration laden – das geht etwas schneller:

 /usr/etc/rc.d/rc.softrestart save

VCenter 6 Installation schlägt fehl

Ich habe heute in meiner Testumgebung ein VCenter 6 Installieren wollen. Frische Installation, keine Migration o.ä.
Dazu habe ich einen neuen Windows Server 2016 aufgesetzt und durchgepatcht. Anschließend die Installation des VCenters mit der embedded Datenbank gestartet und nach einiger Zeit kam folgendes:

"Vmware VirtualCenter failed fistboot. 
VirtualCenter registration with Component Manager failed. 
Please referer to vSphere documentation to troubleshoot or Please contact VMWare Support"

Nach ein bisschen Suchen hier und da stellt ich dann heraus, dass auf dem virtuellen Server keine VMWare Tools installiert sein dürfen. Also die Tools deinstalliert, neugestartet und schon lief die Installation ohne Probleme durch…

Unifi RADIUS Authentifizierung mit VLAN Zuordnung

­In der aktuellen Beta des Unifi Controllers (v5.5.5+) ist das erste Mal ein Radius Server enthalten, sodass man kein Drittsystem benötigt. Dieser läuft dann auf der USG und ist z.B. für die WLAN Authentifizierung verfügbar.

Zugegeben, meistens hat man einen Windows Server mit NAP und AD Anbindung, aber eben nicht immer. In meinem Fall möchte ich guten Bekannten einen persistenten Internetzugang geben (also keinen Gäste-Voucher) aber diese dennoch nicht in meinem Netzwerk haben. Hier steht, wie es geht:

Vorarbeiten – VLAN Anlegen

Damit man WLAN Clients in verschiedene VLANs zuordnen kann, müssen natürlich VLANs existieren. Dazu in den Settings unter Networks ein neues Netzwerk anlegen und VLAN ID, IP Range sowie DHCP Scope angeben – fertig! Jetzt noch nach belieben Firewallregeln festlegen.

Aktivierung des RADIUS Servers

Zunächst in die Settings und dort den neuen Menüpunkt Services auswählen und dort im Bereich RADIUS die Servereinstellungen wählen. Dort Enable RADIUS Server auf ON setzen – fertig.

Danach im RADIUS Profil (Profiles -> Default) das drahtlose VLAN Tagging aktivieren:

Zuletzt noch dem WLAN Profil das RADIUS Profil zuweisen:

User anlegen

Jetzt können User angelegt werden. Gibt man kein VLAN an, wird auch keines gesetzt und der User landet im Default / untagged VLAN:


Möchte man hingegen ein VLAN mitgeben, muss die ID eingetragen und die Optionen 13 sowie 6 gesetzt werden:


Wenn man sich nun verbindet und mit dem  „friend1“ anmeldet bekommt man eine IP aus dem VLAN341:

Aus der Serie…

Site-to-Site VPN: Unifi USG <-> Ubitquiti Edge Router

Wie ich in meinem letzten Artikel schon erwähnt habe, werkelt bei meinen Eltern ein EdgeRouter. Aktuell hatte ich für das StS VPN immer einen Debian Server mit OpenVPN als VM laufen – mit dem USG sollte sich das ändern. Also habe ich mich heute mal an die Konfiguration gemacht.

Mein erster Gedanke war: Ab in den Unifi Controller und flux das Remote-Netzwerk anlegen… leider falsch Gedacht. Dort geht das zwar theoretisch, aber eigentlich nur mit IPSec VPN. Die Besonderheit an meinem VPN ist, dass nur eine Site eine IPv4 Adresse hat, daher auch immer von der anderen Site initiiert werden muss.
Trotzdem kann man es aber auf dem USG einrichten, wie erfahrt ihr hier:

Vorbereitungen

Als erstes braucht ihr natürlich die Konfiguration auf der Edge-Router Seite. Das ist realtiv einfach und auch gut von Ubiquiti beschrieben. Also per SSH auf den EdgeRouter verbinden, den Shared Key erstellen und das OpenVPN Interface anlegen:

generate vpn openvpn-key /config/auth/secret

set interfaces openvpn vtun1
set interfaces openvpn vtun1 mode site-to-site
set interfaces openvpn vtun1 local-port 1195
set interfaces openvpn vtun1 remote-port 1195
set interfaces openvpn vtun1 local-address 10.99.99.3
set interfaces openvpn vtun1 remote-address 10.99.99.4
set interfaces openvpn vtun1 shared-secret-key-file /config/auth/secret
set interfaces openvpn vtun1 openvpn-option "--comp-lzo"
set interfaces openvpn vtun1 openvpn-option "--float"
set interfaces openvpn vtun1 openvpn-option "--ping 10"
set interfaces openvpn vtun1 openvpn-option "--ping-restart 20"
set interfaces openvpn vtun1 openvpn-option "--ping-timer-rem"
set interfaces openvpn vtun1 openvpn-option "--persist-tun"
set interfaces openvpn vtun1 openvpn-option "--persist-key"
set interfaces openvpn vtun1 openvpn-option "--user nobody"
set interfaces openvpn vtun1 openvpn-option "--group nogroup"
set protocols static interface-route 192.168.15.0/24 next-hop-interface vtun1
Wichtig ist, dass ihr euch die Datei /config/auth/secret bzw. den Inhalt kopiert.
Anschließend speichern und abmelden
commit
save
exit
Als nächstes müssen wir auf dem Unifi Controller manuelle Konfigurationen des USG erlauben. Dazu per SCP z.B. verbinden und die Datei config.gateway.json in der Site Configuration (/var/lib/unifi/sites/<SiteName>/) anlegen
Der Inhalt der Datei legt fest, wo die OpenVPN Konfiguration für das Interface vtun0 liegt:
{
	"interfaces": {
                "openvpn": {
                        "vtun0": {
                                "config-file": "/config/ovpn/site1-udp-1195.ovpn"
                        }
                }
	}
}

Konfiguration des USG

Nun können wir uns dem USG zuwenden – hier via SSH oder SCP die OpenVPN Config anlegen


# Remote server to connect to. Can be domain name or IP address.
remote site1.mydyn.domain.de

# Protocol and Port - Must be the same on both server and client.
proto udp
port 1195

ifconfig 10.99.99.4 10.99.99.3
secret /config/auth/secret
route 192.168.17.0 255.255.255.0

# Use a persistent key and tunnel interface.
persist-tun
persist-key

# keeping a connection through a NAT router/firewall alive, andfollow the DNS name of the server if it changes its IP address.
#keepalive 10 60
ping-timer-rem
float
ping 10

# Compresssion
comp-lzo

Wichtig ist, dass ihr anschließend das Secret von oben nach /config/auth/secret kopiert.

Das war’s! Nun muss das USG neu provisioniert oder neugestartet werden. Hierzu könnt ihr z.B. eine Portweiterleitung anlegen. Anschließend wird der Tunnel aufgebaut.

Falls es nicht funktioniert, werden die Fehler im Syslog protokolliert:


tail -f /var/log/messages

Aus der Serie…

Netzwerkupgrade: Ubiquiti USG und APs

Ich habe aktuell eine Fritz!Box. Leider. Diese Box ist ja echt ein Wunderwerk der Technik, kann alles, macht alles. Aber sie ist bei mir auch ultra langsam. Das WLAN ist nicht der Knaller und mein OpenVPN für zwei Site-to-Site Tunnel ich muss extra auf einer VM laufen lassen. Also würde es mal Zeit für ein Upgrade: ein Ubiquiti Security Gateway und zwei UAP-AC-PRO AccessPoints sind es geworden. Erst hatte ich überlegt einen Edge Router zu nehmen (habe ich schon bei meinen Eltern im Einsatz), aber die USGs werden nach und nach immer besser… also mal die (meiner damaligen Meinung nach) einfache USG – Variante genommen.

Die Konfiguration über die Unifi Software ist easy – über eine Oberfläche kann man das USG, die APs sowie eventuelle Switche konfigurieren. Übergreifende Konfigurationen wie VLANs sind auf allen Geräten verfügbar und können einfach verwendet werden.

Mein Setup wird relativ einfach sein: 2 SSIDs (intern und Gast) und 3 VLANs. Das Gast WLAN wird mit einem Captive Portal mit Voucher Codes geschützt um nur meinen Gästen den Zugriff zu gestatten.

Unifi Konfiguration

Da ich von Natur aus ungeduldig bin, habe ich schon am Mittwoch und Donnerstag die Unifi Software installiert und komplett durch konfiguriert. Die wichtigsten Punkte:

Unter „Networks“ müssen die Netzwerke, also euer LAN und ggf Gäste-Netz definiert werden:

Mein LAN sieht dabei so aus:

Wichtig ist hier das „Gateway“ – diese IP wird später das USG bekommen. Das Gast-Netz ist äquivalent – nur mit dem Purpose „Guest“ und der VLAN ID 330. Diese könnt ihr natürlich wählen wie ihr wollt – bei mir ist WLAN immer ab 300 und 330 das Gast-Netz.

Anschließend unter „Wireless Networks“ die WLAN-Netze erstellen:

Ich habe dort mein Default-WLAN per WPA-PSK und das offene Gast-Netz. Dazu noch ein WPA2 Enterprise Test-Netz (dazu später mehr). Zu guter Letzt noch unter „Guest-Control“ den Hotspot konfigurieren. Eigentlich ist alles selbsterklärend, wichtig ist, dass Voucher aktiviert sind und die IP des Unifi-Servers freigegeben ist für „Pre-Authorization Access“ – das heißt auch ohne Anmeldung darf man diese IP aus dem Gast-Netz aufrufen. Das ist notwendig, weil der auf dem Unifi Server das Portal gehosted wird.

Um den Gäste nicht meine ganze Leitung zur Verfügung zu stellen sondern nur 4 Mbit habe ich eine neue User-Gruppe angelegt und dieser die entsprechende Bandbreiten-Einschränkung zugewiesen

und diese anschließend im WLAN Netzwerk eingetragen

Das wars – ab dem Moment wartete ich nur noch auf die Hardware…

Einrichtung der Hardware

Am Freitag war es dann endlich soweit: das USG und der erste Accesspoint waren da!

Also fix alles ausgepackt:

Kabel dran, in der Software auf Adopt geklickt und…

„Adoption Failed“ – ging nicht. Was für ein Dreck! Klingt ja auch logisch – das USG hat die IP 192.168.2.1 – mein Unifi-Server hat die 192.168.15.252, die kommen nicht zueinander. Für die Adoption wird SSH genutzt, und da muss die Netzwerkroute natürlich funktionieren.
Also mal fix geschaut: laut Ubiquity soll man sich direkt an das USG verbinden und die IP des LAN-Ports auf das Ziel-Subnetz ändern. Gesagt getan – ohne Erfolg. Also habe ich es dann umgedreht und dem Unifi-Server eine virtuelle Netzwerkkarte im Subnetz 192.168.1.0/24 gegeben. Ja richtig, 192.168.1.0 – auch wenn das USG laut Unifi Software die 192.168.2.1 hat, in Wirklichkeit ist es die 192.168.1.1.

iface eth0:1 inet static
address 192.168.1.252
netmask 255.255.255.0
Anschließend habe ich das „Adopt-Form“ von Hand ausgefüllt und die Daten
IP: 192.168.1.1
User: ubnt
Password: ubnt
Inform-URL: 192.168.1.1:8080/inform
Siehe da – die Adoption lief ohne Probleme durch und das USG wurde erkannt:
Ab dem Moment war es einfach. Die Konfiguration für den WAN Port kann man direkt im „Configure“-Menü auf der rechten Seite durchführen:
Bei mir hängt das USG hinter der Fritz!Box – durch die VOIP-Konten von Vodafone/KabelDeutschland kann ich leider nicht ganz auf die Box verzichten. Aber nachdem ich alle unnötigen Funktionen (WLAN, FritzNAS, FritzMediaServer, DHCP etc.) deaktiviert hatte, lief sie etwas schneller und ist jetzt nur noch Gateway. Das USG ist als ExposedHost in der FritzBox definiert.
Jetzt gab es schonmal wieder Internet – wenn man mit dem Kabel verbunden war. Also als nächstes den WLAN Accesspoint in Betrieb nehmen. Hier war dann aber wirklich alles „straightforward“. Anschließen, adoptieren, fertig.
Schon gab es WLAN, alle SSIDs waren da und auch das Gast-Portal funktionierte – wunderbar!
Das USG und der Accesspoint sind in meinem Wohnzimmer (da ist auch die Kabeldose – leider!) und unsere Wände bestehen gefühlt aus Blei und Stahl. Im Wohnzimmer hatte ich super Empfang (-40db) und im Arbeits- bzw. Gästezimmer war es schon wieder grausam mit -78db. Außerdem hatte ich noch eine kleine Herausforderung: im Arbeitszimmer hatte ich einen FritzRepeater mit LAN Port um alle Geräte über die WLAN-(B/K)rücke per Kabel zu verbinden. Dieser Repeater wollte aber nicht gut mit dem Unifi-Accesspoint arbeiten. Also habe ich schnell bei Amazon noch einen bestellt – dieser sollte als Mesh-Accesspoint genutzt werden.

Mesh WLAN

Unifi bietet die unglaublich geile Funktion Mesh WLANs aufzubauen. Das heißt ich kann AccessPoints dort wo kein Kabel ist anschließen und sie arbeiten als Repeater – für alle SSIDs mit VLAN Tagging etc. Und wenn der AccessPoint zwei LAN Interfaces hat – wie mein UAP-AC-PRO dann gibt er dort auch wieder das Netzwerk aus. Übrigens kann man mit den richtigen Mesh-AccessPoints sogar die per WLAN angebunden AccessPoints als Uplink für weitere nutzen.

Also dann – AccessPoint ausgepackt, POE dran (wichtig: nichts in den LAN Port des POE Adapters stecken) und schon wurde er angezeigt:

Nach der Adoption wird er als ISOLATED angezeigt und muss einem Uplink-AccessPoint zugewiesen werden:

Anschließend wird er provisioniert und strahlt die WLAN SSIDs  aus.

Das wars – zwei AccessPoints und ein USG verrichten jetzt hier Ihren Dienst. Die WLAN Verbindung ist erheblich besser als vorher- ich erreiche in der ganzen Wohnung (sogar auf dem Balkon) im Speedtest mindestens 75 MBit/s – früher waren es mit Ach und Krach 20 MBit/s.

Zukunftsausblick

Ich denke ich werde noch meine zwei „Öko-Switche“ von D-Link gegen Unifi Switche tauschen – nicht das ich die Funktionen wirklich brauche, aber im Wohnzimmer kann ich mir durch POE eine Steckdose sparen und generell ist es dann einheitlich.

Aus der Serie…

FHEM Wecker weckt nicht mehr

Seit einiger Zeit (ich glaube schon länger als eine Woche) hat mein Wecker nicht mehr funktioniert. Ich hatte bis jetzt noch keine Zeit mich aktiv damit auseinanderzusetzen. Nun habe ich eben alles auseinander genommen und dabei folgendes im Log entdeckt:

3: RESIDENTStk rr_Henning_wakeuptimer1: Another wake-up program is already being executed for device rr_Henning, won’t trigger Macro_rr_Henning_wakeuptimer1

Sowohl ein


set rr_Henning_wakeuptimer1 stop

noch ein


set rr_Henning_wakeuptimer1 end

haben geholfen. FHEM war stehts der Meinung mein Wecker würde noch laufen. Irgendwann bin ich dann im Thread des Moduls sowie in einem extra-Thread auf die Info gestoßen, dass wohl im Bewohner-Device das Reading „wakeup = 1“ noch „hängt“.

Nach einem


deletereading rr_Henning wakeup

lief wieder alles wie gewohnt.

Exchange 2010: Dieser Computer ist für das Erweitern der Mitgliedschaft von 1 Verteilergruppe(n) zuständig

Heute habe ich einen Exchange 2010 nach einer Migration aus der Organisation entfernen wollen. Bei der Deinstallation wurde ich von folgendem Fehler angelacht:

bildschirmfoto-2016-09-24-um-14-44-01

Dieser Computer ist für das Erweitern der Mitgliedschaft von 1 Verteilergruppe(n) zuständig. 

Freundlicherweise hat Microsoft einen Hilfe-Link beigefügt um das Problem zu lösen. Blöd nur, dass dieser Link auf einen 404 führte… Hier nun die Lösung aus dem Technet-Forum:

get-distributiongroup -resultsize unlimited | ft name,expansionserver
get-dynamicdistributiongroup -resultsize unlimited | ft name,expansionserver
get-distributiongroup -resultsize unlimited | set-distributiongroup -expansionserver $null
get-dynamicdistributiongroup -resultsize unlimited | set-dynamicdistributiongroup -expansionserver $null

Die ersten beiden Befehle zeigen die Gruppen inkl. Erweiterungsserver an und die letzten beiden Befehle löschen den Server aus den Gruppen.