Soeben ist ein brandneues UNAS2 angekommen:
Unboxing muss leider bis zum Wochenende warten. Es wird in meinem Unifi Home-Setup das in die Jahre gekommene Synology NAS aus 2015 ablösen (Synology DS214play + 2x 4TB WD RED HDD) für einen Bundle-Preis von damals 652,00€.
Ich bin gerade echt von den Socken bzgl. Claude. Angefixt durch diesen Artikel habe ich mal einen interaktiven Dialog mit Claude gestartet, um ein API-Reverse-Engineering meines Heizungsreglers im Keller zu machen. Diesen kann ich per Webbrowser zur Konfiguration erreichen, als auch mit einer iOS App, um Betriebsart, Räume, Schaltzeiten aus Sicht eines Bewohners zu steuern:
Vor sechs(!) Jahren habe ich mir schon mal einen Man-In-The-Middle (MitM) Raspi konfiguriert und konnte alle/viele API-Endpoints identifizieren, die die Mobile-App anspricht. Gescheitert bin ich aber an der Signierung und mithin der Verschlüsselung der Parameter der HTTP-requests (User-token), die der MitM-raspi nur hat anzeigen können.
Es hat mit Claude und ein bißchen Copy und Paste in die Browser-Konsole keine drei Stunden gedauert, dann hatte ich
Nun mag ja Claude (Sonnet 4.6 benutzt) und mithin Claude Code ja auf Programmierung hin trainiert wurde sein. Es bestärkt meine Meinung, dass strukturierbare, Logiken folgende Aufgaben sicher weniger dem Halluzinieren unterliegen...
Bevor jemand fragt: nein, der Claude Chrome-Connectore war NICHT aktiviert. Soweit geht das Vertrauen dann doch nicht. Wenn ich Claude wohl gelassen hätte...
Hallo zusammen,
nutzt hier jemand einen [paperlesspaper](https://paperlesspaper.de) ePaper-Bilderrahmen?
Ich habe eine Home Assistant Integration dafür entwickelt und suche nach weiteren Nutzern zum Test bzw. Austausch. Die Integration ermöglicht es, den Bilderrahmen direkt aus HA zu steuern und per Automation mit Bildern zu bespielen.
In Simons HA-Community habe ich dazu bereits einen Thread eröffnet und suche Freiwillige. Falls jemand so ein Gerät hat und Interesse an der Integration hast, meldet Euch gerne.
Kurzes Update zur Integration - Was geht schon?
Was braucht man?
Das Repo ist aktuell noch privat – ich würde gern erst ein bisschen Feedback einsammeln, bevor ich es public mache. Wenn jemand Lust hat zu testen: einfach hier melden oder PN.
Die Beta-Version 0.1.0 ist schon ziemlich ziemlich leistungsfähig. Jedoch ist die API wohl noch nicht komplett und ich konnte bisher nur mit (m)einem OpenPaper 7 testen.
Sobald sich Bedarf abzeichnet geht das Repo natürlich öffentlich und dann auch sauber über HACS verfügbar.
…ich erspare euch die Details
Du sitzt nicht zufällig irgendwo um Kitzingen fest, wegen einer "behördlichen Maßnahme"?
Aber grundsätzlich ist das übergreifende Zusammenarbeiten von verschiedenen LLMs nur vorteilhaft
Das schaut mir schon ein sehr nach einer "Philosophischier-Gruppe", wenn ich mir die "Haluz" von mehreren und dann noch kombiniert anschauen und verifizieren muss...
Ich denke für strukturierte und logische Aufgaben (Coding, Kausalitäten) Audio, Video sind spezialisierte LLMs schon sehr sehr gut. Aber ein echte und zuverlässige Conglusio, wie sie echte Experten mit echter Erfahrung machen, da brauch es m. E. noch ein paar Trainings-Epochen...
Hmm... nicht, dass ich es tatsächlich benutzt hätte, aber..
Sich auf ein Modell zu fixieren wird dem volatilen Charakter LLM-Services und ihrer Anbieter aktuell haben sicher eh nicht gerecht...
einmal mehr tippen muss um die Updates der App‘s abzurufen
der fka 3D-Touch führt doch direkt dahin
Plant Apple eine eigene Siri-App mit Chatbot-Oberfläche?
Darüber hinaus plant Apple offenbar, die bisherige Suchfunktion Spotlight durch Siri zu ersetzen.
Hoffentlich nicht! Bin zwar kein Keyboard-Jünger, aber die Spotlight-Suche möchte ich nicht missen. Sowas ist immer noch schnelle als Siri fragen!!!
1,5 Zufahr-Stunden für 15km!
Nette Idee, nur kopiert man das Bild in ChatGPT und schwups weiß man wo das ist.
Nunja, ist wie beim Kneipen-Quiz: man freut sich, ob und was man weiss oder man betrügt sich eben selber.
Btw.: ohne das Thema dieses Thread sprengen zu wollen: https://www.welt.de/kultur/plus69b…rab-bringt.html
Meiner Meinung nach stellt Homebrew nur Softwarepakete zur Nutzung im Terminal bereit
Ich glaube, dem ist nicht so. qlmarkdown , syntax-highlight sind bspw. zusätzliche Quicklook add-ons
Allgemein möchte ich bei diesen vielen tollen Bildern mal anregen, dass man bei bspw. dem hier mal eine Quiz-Version hier fürs Forum draus machen sollte, und die geneigten Leser den Ort des Motives raten lässt...
Meine Nutzung von Homebrew beläuft such auf "gelegentlich". Homebrew ist (einer?) der inoffiziellen Paketmanager für macOS. Aus meiner Sicht quasi ein App Store für Entwickler und Power-User, der Programme installiert, aktualisiert und verwaltet, die Apple bspw. nie im Mac App Store aufnehmen würde.
Der App Store verlangt Sandboxing, Apple-Signierung und viele Einschränkungen. Kommandozeilen-Tools, Open-Source-Software oder spezialisierte Dev-Werkzeuge passen da schlicht nicht rein.
Wenn mich mal ein Tool oder eben auch ein GUI-basierte App interessiert, dann schaue ich i. d. R. immer auch bei Homebrew nach. Ist für mich beinahe eine erste empirische Prüfungsschwelle, bevor ich irgendwo auf ner Webseite was runterlade...
Meine bisher wichtigste Anwendung ist openjdk .Auch in Betrieb genommen damit sind blackhole-2ch , qlmarkdown , syntax-highlight.
Premiumklasse
Der fiel mir auch sofort ein! Da gibt es ja nicht mal Linien und Pfeile. Dass es da nicht mehr Kracht ist schon bemerkenswert. Aber scheinbar sind die Franzosen im allg. rücksichtsvoller als wie hier in D.
Sagrada Familia?
Yeap! Aber wohl noch Baustelle bis 2033…oder so
Ich muss gestehen: Deinem Beitrag habe ich inhaltlich erstaunlich wenig hinzuzufügen – viele der Punkte beschreiben ziemlich präzise, wo sich Apple gerade strategisch befindet. Was mich allerdings zunehmend umtreibt, ist eine andere, vielleicht etwas banalere, aber langfristig genauso problematische Entwicklung: die schleichende Transformation von macOS zu einem Software-Monster, das immer stärker an die Komplexität erinnert, die wir früher nur von Windows kannten.
Apple hat über viele Jahre davon profitiert, dass macOS im Kern vergleichsweise schlank, klar strukturiert und vor allem konsistent war. Systemdienste waren überschaubar, der Funktionsumfang wuchs moderat, und vieles folgte einer relativ klaren Designphilosophie. In den letzten Jahren habe ich jedoch zunehmend den Eindruck, dass sich auch hier eine Art Feature-Inflation entwickelt – getrieben durch Cloud-Dienste, AI-Integration, Hintergrundservices, Telemetrie, Sync-Mechanismen und immer neue System-Frameworks, die irgendwo „unter der Haube“ laufen.
Das Ergebnis ist ein Betriebssystem, das immer mehr Subsysteme und Abhängigkeiten mit sich herumschleppt. Genau das war historisch eines der Hauptprobleme von Windows: Jahrzehnte von Kompatibilitätslast, Service-Schichten, Hintergrunddiensten und APIs, die man aus Gründen der Rückwärtskompatibilität nie mehr wirklich loswird. Apple hat lange den Vorteil gehabt, regelmäßig alte Zöpfe abzuschneiden. Aber auch dort scheint inzwischen der Mut zu radikalen Schnitten begrenzt zu sein – vermutlich, weil das eigene Ökosystem inzwischen selbst zu groß und zu komplex geworden ist.
Der AI-Schub verstärkt diesen Effekt zusätzlich. Statt eines klaren, strukturellen Neubeginns entstehen vielerorts neue Schichten: lokale Modelle, Cloud-Modelle, Assistenz-Frameworks, Privacy-Layer, API-Gateways für Entwickler, Abo-Dienste für spezialisierte Funktionen. Alles einzeln plausibel – in Summe aber ein weiterer Ausbau der Systemkomplexität.
Und genau da sehe ich die eigentliche Ironie: Apple verkauft Stabilität zunehmend als Produktfeature, während gleichzeitig immer mehr Infrastruktur ins System wandert, die diese Stabilität langfristig schwieriger macht. Ein Betriebssystem, das immer mehr Dienste integriert, wird zwangsläufig auch immer mehr Fehleroberflächen haben.
Dein Punkt zur Lock-in-Strategie passt da sehr gut hinein. Wenn AI, Health-Features, Cloud-Dienste und Gerätefunktionen immer enger miteinander verzahnt werden – und dann noch über Abomodelle laufen – entsteht ein System, das technisch wie wirtschaftlich immer stärker geschlossen wird. Für Apple ist das rational: maximale Kundenbindung. Für Nutzer bedeutet es aber auch eine zunehmende Abhängigkeit von einem immer komplexeren Stack.
Was ich deshalb fast noch bedenklicher finde als das „AI-Trostpflaster“: die langfristige Entwicklung hin zu einem Betriebssystem, das seine ursprüngliche Eleganz und technische Klarheit verliert, weil ständig neue Schichten auf bestehende Strukturen gesetzt werden. Genau so entstehen über die Jahre die Software-Gebirge, die irgendwann kaum noch jemand vollständig überblickt.
Kurz gesagt: Wenn Apple nicht aufpasst, wird aus dem einst bewusst schlanken System irgendwann genau das, wovon viele Mac-Nutzer jahrzehntelang geflohen sind – ein hochkomplexes, schwer durchschaubares Plattform-Ökosystem, das eher verwaltet als gestaltet wird...
Ubiquiti bietet wohl ein Planungstool auf der Website an, eventuell sehe ich mir das mal näher an.
Damit hatte ich mich mal beschäftigt...aber die Rahmenbedingungen das zu nutzen ziehen ein Anwendungsszenario "Office, Gebäude, Plant" in Betracht und kein Privathaus?
Ich kann nur soviel sagen, ich mag mein Unifi Setup nicht mehr hergeben (Dream Machine Pro, 1 PoE Switch, 3 U7 Wall Accesspoints)...
UTM ist der Weg. https://mac.getutm.app
Habe lange selber mit Parallels "rumgemacht", bis mir auf der Desktop-Ebene die Use-Cases abhanden kamen. Gerüchteweise soll es ja Software gegeben haben, für die es am Mac keine Alternative gab 
...was machtvirtualisiert man heute auf dem Desktop so?
Meine Smarthome-Reise hat vor einigen Jahren eher experimentell angefangen und ist heute deutlich konsolidierter und vor allem stabiler geworden.
Am Anfang stand eine klassische Bastelphase: gestartet bin ich mit Homematic IP, Philips Hue und einigen Eve-Devices ohne Matter nur mit BlueTooth. Dazu kamen mit der Zeit eine ganze Reihe Aqara-Sensoren, die ich über Conbee per Zigbee eingebunden habe. Die Brücke in Apple Home / HomeKit lief über Node-RED, angebunden waren die HomematicIP-Geräte per MQTT mittels CCUJack auf der Homematic-Zentrale CCU3. Technisch hat das alles funktioniert – und es hat auch viel Spaß gemacht, die verschiedenen Systeme miteinander zu verheiraten.
Mit der Zeit st allerdings für mich das wohl typische Problem vieler Smarthomes aufgetreten: Der „Geräte-Varianten-Hersteller-Zoo“ wurde immer größer. Unterschiedliche Hersteller bedeuteten unterschiedliche Apps, Bridges und Integrationen. Dazu kamen Themen wie alternde Geräte (EVE), wechselnde oder eingeschränkte HomeKit-Kompatibilität und der generelle Wartungsaufwand. Irgendwann war der Punkt erreicht, an dem der Betrieb mehr Arbeit als Nutzen war.
Deshalb habe ich angefangen, das Setup bewusst zu vereinfachen und zu konsolidieren. Schrittweise sind dabei insbesondere Eve und Aqara aus dem System verschwunden. Übrig geblieben sind heute im Kern nur noch zwei Gerätekategorien, die sich für mich als zuverlässig und langlebig erwiesen haben:
Was ich sehr schätze an HomematicIP sind die Direktverknüpfungen. Es muss nicht immer eine Automation auf einem zentralen Hub sein! Nicht zu vergessen der WAF. Es muss halt alles laufen, ohne das das Smarthome dazwischen funkt oder ausfällt. Leider ist das nicht immer der Fall...
Seit etwa einem Jahr läuft außerdem Home Assistant als zentrale Plattform. Die Automationen, die früher fast ausschließlich in Apple Home (manches auch in Node-RED) lagen, sind nach und nach dorthin migriert. Das hat mehrere Vorteile: mehr Flexibilität, bessere Übersicht und deutlich stabilere Automationslogik.
Die Architektur ist heute entsprechend deutlich schlanker:
Node-RED nutze ich gelegentlich noch zum Experimentieren oder für Prototypen. Wenn sich eine Logik bewährt, portiere ich sie später meist nach Home Assistant, damit alles zentral gepflegt bleibt. Node-RED ist inzwischen eher eine Spielwiese als produktiver Kernbestandteil.
Ein weiterer Baustein, der sich über die letzten mehr als zwei Jahre bewährt hat, sind zusätzliche Edge- und Network-Services für Telemetrie, Analyse und Lokalisierung. Dazu gehören insbesondere InfluxDB und Grafana für Visualisierungsaufgaben. Während Home Assistant zwar grundlegende Historienfunktionen bietet, ermöglichen Influx und Grafana deutlich tiefere Analysen – etwa zur langfristigen Entwicklung von Temperaturverläufen, Heizzyklen, Luftqualität oder Energieverbrauch. Gerade für Optimierungen von Automationen oder zum Verständnis von Systemverhalten sind diese Auswertungen hilfreich.
Parallel dazu experimentiere ich seit längerem mit ESPHome-basierten Bluetooth-Beacons als dezentrale Bluetooth-Scanner und melden erkannte Geräte an Home Assistant. Damit lassen sich einfache Präsenz- oder Raum-Näherungslogiken umsetzen, ohne auf proprietäre Systeme angewiesen zu sein. Das Ganze läuft vollständig lokal und fügt sich gut in die bestehende Home-Assistant-Architektur ein.
Mein „strategisches Ziel“ für das Smarthome ist inzwischen auch klarer geworden: Ich möchte möglichst wenig aktiv steuern müssen. Das Haus soll weitgehend selbst reagieren, kontextabhängig handeln und nur dann Aufmerksamkeit verlangen, wenn es wirklich nötig ist. Idealerweise funktioniert das über eine Kombination aus:
Die Vision ist also ein Smarthome, das keine App zur Bedienung braucht, weil es im Alltag einfach richtig reagiert. Die Apps sollen dann nur noch für Konfiguration oder Ausnahmefälle bleiben.
Rückblickend war der Weg über viele Systeme zwar manchmal chaotisch, hat Lehrgeld gekostet aber auch sehr lehrreich. Heute weiß ich ziemlich genau, was für mich funktioniert: weniger Plattformen, stabile Kernsysteme und eine saubere zentrale Logik – ergänzt um lokale Datenanalyse und Edge-Services, die zusätzliche Einblicke und Automationsmöglichkeiten eröffnen.
