So - jetzt läuft alles. Noch mal Danke an alle. Ich glaube übrigens, dass meine Objects beim Wechsel auf die neue FW irgendwie einen Klatsch bekommen haben. Es hat am Ende erst zu 100% funktioniert, als ich beim Target nicht mit „object = Raspberry (mit 10.20.0.253) sondern einfach IP = 10.20.0.253 hinterlegt habe. Sehr mysteriös - aber am Ende auch egal.
Schönes WE zusammen.
gierig - erst mal herzlichen Dank für das wärmende Licht in dieser dunklen Zeit 
Und ja - ich sehe es. Interessant - warum sollte man auch Standardports definieren - Am Ende macht jeder Seins! Ganz stark
Aber danke für das Hintergrundwissen - again what learned
Ergo ändere ich diese "hart-definierten" Regeln jetzt einfach ab, in dem ich das bisherige DNS/DOT Object , was ich dafür angelegt habe, von den zwei festen Ports (53/853) auf die von dir erwähnte Ephemeral Ports Range (32768-65535) erweitere - und fertig?!?
Hört sich ja schon fast zu einfach an, um wahr zu sein. Aber schön, wieder ein neues Thema fürs Wochenende.
Dank dir!
Update für die Nachwelt - Vertraut nicht der App 
Sowohl auf iOS als auch auf iPadOS hat die App die o.a. FW-Regel VOR den Block-Regeln angezeigt.
War gerade nur durch Zufall auf der Web-GUI und stelle fest - die FW-Regel ist HINTER den Block-Regeln.
Ergo kurz die Reihenfolge angepasst - läuft.
Eine Sache bleibt aber noch. Normalerweise habe ich meine FW Regeln, wenn möglich, entsprechend detailliert.
Sprich kein Any:Any allowed to Any:Any, sondern auf konkrete Ziel-IPs (zb. Pi-Hole) oder auch konkrete Ports (53/853 für DNS/DOT)
So eine Regel habe ich ja schon im Betrieb, damit alle VLANs aus der „Untrusted Zone“ auch zum Pi telefonieren können.
In diesen Fällen klappt das auch, ABER
Wenn ich die identische Regel erneut anlege, nur eben anstatt „untrusted Zone“ die „VPN-Zone“ hinterlege, kann ich wieder den PI nicht erreichen bzw findet keine DNS Auflösung statt.
Anbei ein Screen, wo ihr sehen könnt, dass die Regeln bis auf die SOurce-Zone 100% identisch sind. Braucht es noch einen anderen Port innerhalb eines VPNs bzw speziell für Wireguard? Weil bei meinem vorherigen L2TP VPN Server, hatte die Regel ebenfalls tadellos funktioniert.
Screenshot ist jetzt aus der WebGUI um Anzeigefehler zu eliminieren
Hi zusammen,
Ich bin offensichtlich mal wieder auf beiden Augen blöd, aber ich komme nicht weiter.
Hab jetzt auch mal mein altes L2TP VPN gelöscht und ein neues Wireguard Profil angelegt.
Wenn ich ALLES bei der Einrichtung auf „Automatisch“ lasse, funktioniert es auch tadellos, aber natürlich möchte ich im VPN auch meinen eigenen DNS aka Pi-Hole nutzen.
Also habe ich mir gedacht, dass ich einfach bei Nameserver 1 die IP meines Pi-Hole (10.20.0.253) hinterlege - das gleiche im Wireguard-Profil auf dem iPhone mache - fertig.
Dummerweise sieht das Wireguard anders. 
Sobald ich das mache, wird zwar die Verbindung zum VPN erfolgreich aufgebaut, aber ich hab kein Internetzugriff bzw die Namensauflösung klappt nicht.
Wenn ich nur ne IP eingebe, komme ich immerhin bis zu etwaigen 403 Forbidden Seiten.
Ergo muss mein Problem daran liegen, dass der PI nicht aus dem VPN erreichbar ist.
In der FW ist der Wireguard-Server korrekt der Zone „VPN“ zugeordnet.
In der FW habe ich bereits zur Fehlersuche eine Regel erstellt, die sämtlichen VPN Traffic in Richtung „HOME VLAN“ (in diesem VLAN befindet sich der Pi) erlaubt inkl. Rückkanal.
Die Regel befindet sich in der Liste VOR allen Block-Regeln.
Ich habe die Konfiguration des Netzes (in Unifi - VPN - Gateway/Subnetz) auch mal auf das VLAN gelegt, was vorher für das L2TP VPN genutzt wurde.
Also vom Standard, den Wireguard automatisch setzt (192.168.3.1/24) zu VLAN (10.40.0.1/24). War auch keine Lösung 
Das einzige was mich wundert (aber vermutlich nur meiner Ahnungslosigkeit geschuldet ist) ist die Tatsache, dass mein iPhone bei den Details der VPN Verbindungbei „Serveradresse“ die localhost hinterlegt hat - also 127.0.0.1 - siehe screen.
Preisfrage - wo hab ich nen Knoten im Kopf?!
Wie immer - vielen Dank im Voraus für etwaige Ideen/Tipps/Lösungen.
Anbei ein paar Screenshots - bitte nicht wundern, dass die IPs mal 192.168.3.x und einmal 10.40.0.x sind. Ich habe beim Testen nicht aufgepasst und einmal Screens gemacht, als alles auf Standard (192.168.3.x) + eigenen DNS (10.20.0.253) stand und einmal zum Test auf 10.40.0.x + eigenen DNS (10.20.0.253). Daher die Abweichungen in den Screens.
Konfig Wireguard Generell
Konfig Wireguard Client
Firewall-Regel
IPhone - VPN - Verbindungsdetails
Nur zum Abschluss - Nach dem Reboot des SHM war der (positive) Spuk vorbei. Gerät nicht mehr erreichbar.
Thema kann geschlossen werden, da ich auf Grund des nicht vorhandenen Mehrwerts für mich persönlich, hier keine weiteren Maßnahmen ergreifen werde
gierig DAS habe ich mir auch gedacht, aber gemäß Mr. Spock, dass wenn man alles ausgeschlossen hat, das unglaubliche wahr sein muss, ist es das. Hab vorhin geladen - Resultat: EVCC macht das was man erwartet und das SuinyPortal ebenfalls - siehe Screenshots. 🤷
Ist mir jetzt auch egal - hätte sowieso darauf verzichtet, da der Mehrwert nicht gegeben ist.
iLion - das ist bezüglich der generellen Einbindung des SHM in EVCC.
Das hatte bei mir ja direkt von Beginn an tadellos funktioniert. Mit VLAN-Trennung, aktiviertem IGMP Snooping und all den anderen sinnvollen Einstellungen, die man NICHT deaktivieren sollte, um Geräte in Betrieb zu nehmen.
Hier gehts aber um die andere Richtung - von EVCC Richtung SHM - und das hatte nicht funktioniert.
ABER - deswegen auch "HATTE" - ich kann jetzt noch einen zur Verwirrung drauf setzen und bin gespannt, ob das einer erklären kann
Ich hatte ja die SMA Komponenten (WR und SHM) ins gleiche VLAN wie EVCC gehoben, um zu gucken, ob es daran lag.
Dem war ja wohl auch so, weil das SunnyPortal nach dieser Aktion die Wallbox bzw. Smart Appliance SOFORT gefunden und eingebunden hat.
Da ich aber jetzt den Mehrwert (=keiner) dieser Integration kenne, habe ich gestern die SMA Komponenten wieder zurück ins ordinäre, gekapselte VLAN gepackt. Und jetzt kommts - was glaubt ihr, was NICHT passiert ist?!?
Genau - die Smart Appliance ist lt. Sunny Portal auch jetzt noch (also fast 24h später) weiterhin aktiv, Status grün usw. (siehe screenshots)
Mehr kann man damit ja eh nicht machen. Und genau hier ist für meine Netzwerkkenntnisse "Schicht im Schacht". Wie kann sowas sein?
Wird diese Integration ggf. nur Initial via MultiCast gelöst und danach unterhalten sich die Geräte z.B. auf Basis des Netznamens oder Mac-Adresse?
Auf Basis der IP kann es ja nicht sein, da sich WR und SHM jetzt wieder im 10.30.0.0 Netz befinden und der Pi mit EVCC im 10.20.0.0.
Denn ich hatte ja schon vorher extra eine FW-Regel angelegt, die die Kommunikation (in beide Richtungen) zwischen den SMA Komponenten im 10.30.0.0 zum Pi/EVCC im 10.20.0.0-Netz erlaubt.
Würde mich mal interessieren, ob dazu jemand eine Idee hat.
So schauts... leider habe ich auch noch kein 100% klares Feedback, ob diese Integration überhaupt einen Mehrwert bringt außer Verbrauchsstatistiken zu empfangen. Sollte dem nämlich wirklich so sein, geht mir die Statistik am Pöppes vorbei und ich habe lieber ein sauber gekapseltes Netzwerk.
Ne. Zweiten Pi. Hab hier noch einen vierer rumfliegen. 🤪
Danke für die gute Erklärung. Und zack - wieder was neues auf der Taskliste - Raspberry zum MultiCast-Router machen 
Bigdog71 Hatte ich schon aktiviert. Daran lags nicht
Nutzer666 - bist du dir sicher? Wenn ich das UI korrekt verstehe, ist das schon "build in" in der UDM-Pro. Siehe Screen - rote Markierung.
Hier werde ich auch mal mit der Einstellung "Forward Unknown Multicast Traffic" rumspielen - gelbe Markierung.
Wenn die ÜBersetzung des Features korrekt ist, müsste das jedenfalls die Lösung sein, das MultiCast eben nicht gedropt wird sondern so gesteuert, dass es auch dort ankommt, wo ich es brauche.
Ich habe zwar eine „Block VLAN 20 zu VLAN 10“ Regel (damit die IoT Geräte mein privates Netz nichts ausspähen), aber die hatte ich bei der Fehlersuche ja extra pausiert.
Ich kann zwar in der Software von SMA eine andere IP als „Direkte Zählerkommunikation“ angeben - dort habe ich die IP vom Rasperry/EVCC eingetragen - aber das hat auch nichts gebracht.
Andersrum, also EVCC genau sagen, wo sich die SMA Komponente befindet, geht leider nicht
Mir sind noch zwei andere Sachen eingefallen
1) Die Ports, an denen die SMA Komponenten hängen, sind bei „VLAN Management mit Tag“ noch auf „alles blockieren“ gestellt.
Nur der Port vom Raspberry/EVCC steht auf „Alles zulassen“. Könnte das auch Teil des Problems sein? Hab das mit dieser Einstellung nie wirklich kapiert
2) Guck mal hier: https://my.sma-service.com/sfc/servlet.sh…ationContext=S1
Das läuft angeblich alles über das SEMP Protokoll. Port UDP 9765. Vielleicht kann ich damit die Paket ausschließlich zum richtigen Empfänger (SMA) schicken und er „erkennt“ endlich das Gerät
Hey zusammen,
Ich hätte da mal wieder eine Herausforderung. Mit der neuen PV Anlage, eAuto usw habe ich jetzt EVCC (Software für Energiemgmt) auf meinem Raspberry installiert.
Ich versuche das folgende Szenario so zu beschreiben, dass die Hersteller/Software die involviert sind, eigentlich für die Lösungsfindung nicht zwingend notwendig sind, da es hier um reine Kommunikationswege / MultiCast geht.
Der Raspberry mit der Software EVCC ist im VLAN 10 (privates Netzwerk)
Die SMA Komponenten (Wechselrichter und Sunny Home Manager) befinden sich im VLAN 20 (IoT Netzwerk)
Damit meine Wallbox im Sunny Portal (Administrations-Website für SMA) als neues Gerät erkannt wird, unterhalten sich beide Komponenten wohl über MultiCast.
Ob das jetzt nur von der Software EVCC oder nur von SMA oder von beiden kommt, konnte ich nicht herausfinden.
Jedenfalls erkennt das Sunny Portal beim Netzscan diese „Kommunikation“ und zeigt die Wallbox als „neues Gerät“ an. Passt!
Durch die VLAN-Trennung ist das aber ohne „spezielles Wissen“ offensichtlich nicht möglich.
Jedenfalls habe ich heute Stunden damit verbracht, das hinzubekommen.
Resultat: Selbst wenn ich alle Firewall-Regeln und IGMP Snooping deaktiviere, hat das Portal keine Geräte finden können.
Erst als ich die SMA Komponenten ins gleiche VLAN wie den Raspberry (mit EVCC) gepackt habe, wurde die Wallbox beim Scan sofort erkannt und konnte hinzugefügt werden.
Gemäß dem Ausschlußverfahren ist also das Problem = Geräte in unterschiedlichen VLANs!
Nun zur Frage - was muss man wie einstellen, damit diese Kommunikation auch VLAN übergreifend (also zwischen VLAN 10 und VLAN 20) funktioniert.
Aus meiner Sicht muss sowas doch technisch möglich sein, ohne die Geräte zwingend im selben VLAN zu betreiben.
Vielleicht hat einer ja das gleiche Konstrukt daheim oder kennt sich so gut mit Netzwerktechnik aus, um hierfür eine Lösung zu haben.
Vielen Dank im Voraus.
Hey DoPe
danke für das Feedback.
Zu Auto-Settings: LOL - einmal beim Start? Dann ist es weiterhin Bullshit - nur jetzt noch mit "AI" im Namen
Ich hatte ja damals schon alles manuell eingerichtet, aber als ich jetzt die neuen APs geholt habe, hatte ich die Hoffnung, dass die Technik endlich soweit ist - ist sie wohl nicht
Also mache ich die Channels weiterhin manuell und lasse die Channel Width auf den üblichen 20/40/160.
Bezieht sich deine Aussage auch auf die Transmit-Power? Also auch besser manuell auf "normal" lassen und nicht auf "Auto"?
Interessant, dass es vor kurzem einem TE mit identischem Problem gab. Das Problem ist auch nicht wirklich persistent - mal ja, mal nein.
Ich habe bei allen "mir bekannten Apple Geräte" sowieso diese ganzen "Hiding-Mechanismen" ausgeschaltet - z.B Private WLAN Adresse.
Sonst kann man kein Gerät mehr ordentlich prüfen und die Client-Liste ist voll von "unbekannten Geräten".
Das ist also nur im Gast-WiFi erlaubt (und da ist es das Problem der Gäste, nicht meins ).
Aber Geräte in meinem Home- und IoT-Netz haben das alle deaktiviert.
Bzgl. Zonenbasierte FW - ok, das hört sich danach an, als gäbe es keinen Migrationsassistenten sondern alles Neu macht der Mai?
Dann warte ich damit noch, bis ich Zeit habe, da ich tatsächlich damals sehr viele FW Regeln von den üblichen YT-Wissenden kopiert habe - jedenfalls die, wo die Erklärung dahinter für mich Sinn ergeben hat - wie z.B der Zugriff aus Gateway.
Bzgl. dieser Sperre - sehe ich genauso - lieber voller Log, als Probleme Ich habe das über eine Device-Gruppe gelöst - ist vermutlich nicht die sicherste Lösung, da Mac-Adressen ja easy dubliziert bzw. manuell gesetzt werden können, aber dazu müsste ein Angreifer zum einen die MAC-Adressen meines iPhones und MacMinis wissen UND in sich bereits in meinem Netzwerk befinden. Solange der ext. Zugang, den Unifi hier für die Konsole bereitstellt, kein Schlupfloch anbietet, sollte das also ein sehr, sehr geringes Risiko sein.
Hast du noch Wissen zu den Punkten 3, 4 und 5?
Dank dir noch mal und schönes Wochenende.
Hi zusammen,
oder anders - lange nicht gesehen
Hab mich auf Grund privater Umstände in den letzten fast 2 Jahren leider mit anderen Sachen beschäftigen müssen - sorry.
Freut mich aber, dass ich immer wieder mal Updates zu den von mir erstellten Guides usw. bekomme - schön, dass das alles weiter lebt
Meine Abstinenz vom Forum hat mittlerweile leider auch mein Wissen in Sachen Unifi reduziert bzw. habe ich viele Features und Änderungen nicht mitbekommen und stehe jetzt "gefühlt" genau da, wo ich vor 5 Jahren stand, als ich hier als Mod/Admin eingestiegen bin
Jetzt hoffe ich aber, dass ich wieder mehr Zeit für mein Netzwerk finde und habe daher direkt mal ein paar meiner APs ausgetauscht und upgegradet.
Neu dabei sind jetzt 2x U7-PRO, 1x U7-Lite und 1x USW Lite 8 PoE.
Kommen wir jetzt zu meinen Fragen, da sich in den letzten Jahren ja auch einiges an den Features geändert bzw. neue hinzugekommen sind.
Als Ausgangslage bitte beachten, dass wir ein Haus haben und KEIN Nachbar mit seinem WiFi auf unser Grundstück kommt.
Ich muss also nur meine eigenen APs im Auge behalten und keine externen Störfaktoren
1) Ist das Feature "Channel AI" mittlerweile in einem Zustand, wo man sagen könnte, dass es genauso gut oder sogar besser funktioniert, als die manuelle Konfiguration der APs in Bezug auf Channel und Channel Width?
Aktuell läuft es bei mir wie folgt:
Passt das noch? Bei mir soll das WiFi immer auf Stabilität und nicht auf Speed ausgelegt sein.
Alle Devices die hohe Transferraten brauchen, sind natürlich per Kabel verbunden
2) Ist die Aussage, APs immer bei TransmitPower auf "Medium" zu lassen weiterhin die Richtige oder funktioniert hier mittlerweile die "Auto"-Einstellung und es ist endlich ausgereift?
3) Schaut euch mal das Bild bzgl. der Advanced WiFi Settings an. Gibt es da mittlerweile Features, die man zwingend aktivieren sollte?
4) Hat einer das Feature "5 GHz Roaming Assistant" aktiviert?
Ich frage vor folgendem Hintergrund:
Seit einiger Zeit ist uns aufgefallen, dass Google suchen z.B. über iPhone, iPad beim ersten Mal grundsätzlich nicht ausgeführt werden. Sprich Browser öffnen, Suchbegriff in die Adressleiste eingeben - und es passiert GAR NICHTS. Wenn ich dann nur 1 sekunde die gleiche Suche erneut triggere, kommt innerhalb von Millisekunden das Ergebnis.
Es fühlt sich so an, als wüsste er bei der ersten Anfrage nicht, was er tun soll und sobald man ein zweites Mal sucht, läuft es, wie erwartet (Ich hab hier ne 600Mbit Fiber-Leitung - also mehr als ausreichend Bandbreite für ne Google-Suche
Hatte vielleicht schon mal einer dieses Problem bzw. hat eine Idee, was der Grund dafür sein könnte oder - wie man dem Problem auf die Spur kommen könnte?
5) Gab es in den letzten Jahren irgendwie neue / verbesserte Features (z.B. wie bei Punkt 6 erwähnt) die man zwingend aktivieren bzw. rekonfigurieren sollte?
6) Mir springt immer noch in der App folgender Hinweis vor die Augen:
Upgrade to the New Zone-Based Firewall - Simplify firewall management and reduce complexity. Click to upgrade
Ist die Firewall wirklich "einfacher" zu betreiben und sinnvoll, darauf umzustellen? Wenn ja, muss ich etwas besonderes beachten, wenn ich das Upgrade durchführe?
7) In diesem Kontext noch eine letzte Frage. Als ich mit Unifi angefangen habe, habe ich diverse FW-Einstellungen von "Wissenden" übernommen. Unter anderem z.B. dass nur 2 bestimmte Geräte (mein iPhone und mein Mac) überhaupt auf die UDM Pro bzw. das Gateway zugreifen dürfen. Das hat für mich damals auch Sinn gemacht, sodass z.b. ein Kompromittiertes "China-IoT-Gerät" eben gar keine Möglichkeit hat, die UDM (und somit das Management) erreichen zu können.
Allerdings ist mir jetzt mit dem "überarbeiteten Log" aufgefallen, dass das zu erheblichen "Error-Log-Spam" führt - siehe Screen.
Ist diese FW-Regel wirklich (noch) sinnvoll?
So - das wars auch "schon" Freue mich über jedwedes Feedback.
Danke vorab und allen ein schönes Wochenende.
Hier die (freche) Antwort von CG. Glücklicherweise haben die eine 45-Tage-Geld-zurück-Garantie, die ich jetzt natürlich ziehe.
Unglaublich mir als Kunden den Vorschlag zu unterbreiten, einen Dual-Router zu kaufen.
Ja, genau .-. um den non-standard von CG zu nutzen soll ich x-Euro für neue Hardware zahlen.
Und so ein Laden bezeichnet sich als "Pioniere von VPNs" ....
Hello Martin,
Thank you for contacting CyberGhost VPN Support.
I understand that you would like to receive a refund if you can't receive one file that contains all the necessary information for manual setup. Let me look into this for you.
Kindly note that we don't have one file that contains all the necessary information as they are split among the four files you receive.
What I can recommend is to try a dual router setup. By setting up a router that is compatible with our VPN and connecting it to your other router, you will be able to utilize your subscription with us.
We’d like to make sure you have the best experience with our service, so if there’s anything we can do to be able to keep you as a satisfied customer, please let us know and we’ll be glad to assist.
Have a wonderful day!
Regards,
Edric
CyberGhost VPN Support
defcon - danke. Dann packe ich den Anbieter auch mal als "Ansporn" wie es die Konkurrenz macht in meine Anfrage zu Cyberghost.
Frage mich immer wieder, warum es immer einen geben muss, der sich nicht an den "de facto" Standard hält.
Hi Maddeen der Aufbau von der certfile von CG ist komplett anders wie bei NordVPN & Co. Die nutzen sogar ein anderes Zertifizierungsverfahren, daher funktioniert das VPN nicht. Entweder muss CG das Zertverfahren abändern oder Unifi ermöglicht uns das uploaden der besagten 3 Files ansonnsten bon chance.
LG
Danke dafür. Ich werde meine aktuelle Trail-Time dazu nutzen, um etwas zu bewegen. Wenn die das nicht können/wollen - oder wegen mir für mich eine selbstangefertigte OVPN Datei bauen - mache ich halt von meinem Widerruf Gebrauch.
Mir ist das egal - gibt genug VPN Anbieter mit Zero-logging
Hi zusammen,
ich hole den alten Thread mal zurück. Ich versuche gerade auch Cyberghost als VPN client auf meine UDM zu bekommen.
Was bei NordVPN direkt funktioniert hat, funktioniert bei Cyberghost leider nicht (also einfach Datei hochladen, User+PW = fertig)
Den Grund dafür habe ich glaub ich gefunden - guckt euch mal den Inhalt der OVPN Datei an.
In den Dateien von NordVPN ist das Certifiate usw. inkludiert. In der File von Cyberghost NICHT. Hier gibt es separate Dateien für CA, client.key und client.crt
Gibt es eine Möglichkeit aus den vielen Dateien eine funktionsfähige OVPN Datei für die UDM zu erstellen?
Die einfache Lösung - daten irgendwie rauskopieren und ergänzen, funktioniert leider nicht. Bzw. finde ich nicht alle fehlenden Informationen aus der OVPN in den Einzeldateien.
Hat da irgendwer Ideen zu? Ich frage parallel mal bei CyberGhost an, weil ich diese "Configuration File" mit separaten Dateien für eine Sonderlösung halte.
Ich hatte auch schon mal VyperVPN - auch hier gab es nur eine Datei mit allen notwendigen Konfig-Infos und nicht x-Dateien mit Infos.
Danke schon mal und einen schönen Tag
Herzlich Willkommen bei uns 
Danke für den Bericht - bestätigt mich in meiner finalen Entscheidung die „smartifizierung“ hauptsächlich via Apples HomeKit zu lösen.
Hatte erst MagentaHome, dann den Homey inkl. kompletten Wildwuchs was die Hersteller angeht.
Fazit: Auf Grund des fehlenden gemeinsamen Standards die Hölle für jeden Smarthome begeisterten (der eine Frau daheim hat )
Ich hatte zwischenzeitlich auch mit Bosch geliebäugelt - wegen Rolladensteuerung.
Habe ich aber auf Grund der Kosten (Basis 180€ plus jede Steuerung auch 70€) wieder verworfen und dafür auf MEROSS gewechselt.
Fazit: Jede Steuerung inkl beleuchteten Schalter —> 30€.
Unterschied für unser Haus zwischen Bosch (1000€) und Meross (300€) also erheblich.
Somit ist meine einzige (fremde) Zentrale die Hue Bridge. Die demnächst auch eine Revision inkl. Matter bekommt.
Philipps hat aber direkt gesagt, dass die neue Basis natürlich auch alle „alten“ Geräte unterstützen wird.
P.S Zudem bin ich gerade von Bosch auch enttäuscht, was Haushaltsgeräte angeht. Haben hier einen Einbau-Kaffeevollautomat für geschmeidige 1400€! Dieser hat einer Fehler (in der Garantie - Gerät erst 10 Monate alt) mit dem Sensor und erkennt eine volle Tropfschale, auch wenn diese nicht voll ist.
Wer jetzt meint, dass Bosch zu einem nach Hause kommt und das Gerät direkt repariert —> Pustekuchen.
Termin ausmachen, Ausbau und Abholung durch LogIT 5 Tage später, Transport nach Nürnberg und (wenn alles gut läuft) ist die Reparatur nach 10 Tagen durch. Ergo 15 Tage keinen Kaffee.
Welcher Manager bei Bosch eine Einbaumaschine als „Kleingerät“ definiert hat, sollte definitiv einen Jobwechsel in Betracht ziehen. Unglaublich.
Im Vergleich - Problem mit der „Einbaumikrowelle“ von AEG. Anruf - 2 Tage später Techniker vor Ort - ausgebaut, repariert, eingebaut, gefahren.
