Beiträge von psychofaktory

    Kodi kann im Funktionsumfang über Add-Ons erweitert werden.

    Das geschieht in der Regel in Form von .zip-Dateien.
    Über den Dateimanager kann man den Speicherort der .zip-Datei angeben, und dann unter "AddOns" via "Aus Zip Datei installieren" das AddOn vom angegebenen Speicherort aus installieren, sofern man zuvor wie SkyBird ja schon erwähnt hat, die Installation von AddOns aus fremden Quellen zugelassen hat.

    Die AddOns können den Funktionsumfang in verschiedenen Bereichen erweitern. Das kann man an der Bezeichnung der zip-Datei erkennen.
    repository.*.zip fügt Kodi z.B. ein weiteres Repository zu
    skin.*.zip fügt Kodi ein weiteres Skin hinzu
    plugin.*.zip fügt Kodi ein weiteres Plugin hinzu
    usw

    Die zip-Datei zu entpacken und/oder der Kodi-Installation manuell Ordner oder Dateien hinzuzufügen ist nicht erforderlich.
    In deinem Screenshot sieht das so aus als hättest du die .zip-Datei entpackt. Das war dann ein Schritt zu viel.

    Am elegantesten ist es immer aus Addons aus dem offiziellen Kodi-Repository zu installieren. Dabei müssen dann überhaupt keine Quellen im Dateimanager angegeben werden oder mit zip-Dateien hantiert werden.
    Sollte das gewünschte Addon dort nicht verfügbar sein, dann das Repository das das Addon enthält installieren (wie z.B. das Kodinerds-Repo) und aus diesem Repository dann das Addon installieren.

    So wie ich das verstanden habe hat Matter nicht direkt was mit der Übertragungstechnologie zu tun, oder?

    Es ist ein neuer Standard, der herstellerübergreifend für Kompatibilität sorgen soll.
    Technisch wird für die Übertragung "Thread" eingesetzt, was eine Weiterentwicklung des Zigbee-Standards ist.
    Hier wird das eigentlich ganz gut erklärt:
    https://www.connect.de/ratgeber/matte…nd-3202564.html

    Sowohl Zigbee, als auch Thread basieren auf dem IEEE-Standard 802.15.4.
    Somit sollte bestehende Zigbee-Hardware über ein Firmwareupdate Matter-kompatibel gemacht werden können.

    Das ist das komplette Gegenteil von zuverlässig und zukunftssicher. Wenn der dev von LibreElec RR irgendwann entscheidet, dass er keinen Bock mehr hat (was in der Vergangenheit bereits der Fall war), stehst du mit veraltetem Kodi + veralteten Emus da, die du selbst nicht updaten kannst.

    Ich weiß was du meinst. Hatte selbst LibreElec RR 9.x laufen und es gab irgendwann kein Update mehr.
    Inzwischen hat sich ein neuer Entwickler gefunden.
    Natürlich kann es erneut so kommen, aber das gilt für andere Projekte ebenso.

    Ist halt immer die Frage was man will.

    Bei dem Projekt liegt der Fokus eben auf Kodi mit vollem Funktionsumfang und Integration einer ganzer Reihe relevanter Emulatoren.
    Solange das aktiv maintained wird ist auch davon auszugehen, dass die Komponenten gut aufeinander abgestimmt sind.

    Bei den anderen Projekten die ich genannt hab liegt der Fokus auf Retrogaming und Kodi ist "nur" ein Zusatz und unterliegt ggfs. einigen Einschränkungen.

    Wenn du volle Kontrolle willst, installier dir ein lightweight OS wie Lubuntu und darauf Kodi + alle Emus, auf die du Bock hast. Dann hast du alles in der eigenen Hand, bist immer up-to-date und kannst es dir einrichten, wie du möchtest.

    Auch diese Variante hat vor und Nachteile.
    Man hat die volle Kontrolle. Aber auch einen im Vergleich deutlich höheren Pflegeaufwand um das alles Einzurichten, aktuell und am laufen zu halten. Insbesondere bezüglich Abhängigkeiten bei Updates.
    Das erfordert darüberhinaus auch mehr Know-How das man sich erstmal angeignet haben muss.

    Mal etwas weiter ausgeholt und generell gesprochen:


    Soweit mir bekannt gibt’s für RetroGaming und Kodi folgende Ansätze:

    • Kodi build-in RetroPlayer
      Da hapert es aber nach meinem letzten Kenntnisstand aber noch in einigen Punkten am Funktionsumfang. Insbesondere wenn man nicht unbedingt Spiele aus dem IAGL spielen möchte.
    • Eine grundsätzlich auf Gaming ausgelegtes OS von der aus man Kodi quasi als Add-On starten kann
      RetroPie/EmulationStation/Recalbox/Batocera/usw verfolgen wohl so einen Ansatz
    • Ein Kodi-System das externe Emulatoren usw. schon mit einkompiliert hat.
      Hier ist mir nur LibreElec RR bekannt.
    • Der Emulator als Kodi-Addon; ggfs. mit zusätzlichen Frontends für die Spiele
      Gamestarter wäre sowas gewesen das RetroArch als Addon lädt. Hier wäre mir aber nichts bekannt was mit aktuellen Kodi Versionen lauffähig wäre.
    • Eine Kodi-Installation bei der die Emulatoren parallel zu Kodi installiert werden und über ein Frontend in Kodi mit den zugehörigen Parametern zum Spielstart aufgerufen werden
      Rom Collection Browser, Advanced Emulator Launcher und Lutris, sowie Launchbox stünden hier im Angebot.

    Jetzt ist die Frage was man will.


    Jede Variante hat so ihre Vorteile und auch Einschränkungen. Insbesondere sind nicht alle Varianten für alle Plattformen geeignet.

    Bei mir ist es die letzte Variante mit dem Advanced Emulator Launcher geworden. Aus folgenden Gründen:

    • Ich kann die Emulatoren nutzen die ich möchte, was mir sehr viel Handlungsspielraum bzgl. Anpassungen, Performance, Grafikeinstellungen, Kompatibilität, Funktionsumfang usw lässt
    • Lässt sich mit dem zugehörigen Skin nahtlos in Kodi integrieren
    • Die optische Präsentation der Spiele finde ich ziemlich ansprechend (sofern mal alles komplett eingerichtet und mit Inhalt gefüllt ist)
    • Unabhängig von der Plattform (sei es jetzt Windows, Android oder Linux) habe ich die gleiche Optik und gleiche Benutzererfahrung, weil Kodi mit dem Frontend immer gleich aussieht.
    • Der Schwerpunkt lag für mich neben Retrogaming weiterhin auf Kodi.

    Macht aber wohl auch am meisten Arbeit.

    Naja ich würde diesbezüglich auch Matter im Auge behalten , wurde ja gerade Eingeführt. Matter FAQ

    Das hatte ich vorab auch schon gelesen.

    Soweit ich das sehe kann Matter wohl als indirekter Nachfolger von Zigbee betrachtet werden. Zumal die Zigbee-Alliance ja auch mit an der Entwicklung direkt beteiligt war.
    Von daher bin ich zuversichtlich mit aktuellen Zigbee-Geräten auf den richtigen, zukunftssicheren Standard zu setzen.

    Diese Devices-Datenbank fand ich sehr praktisch.
    Man hat herstellerübergreifend alle kompatiblen Geräte in der Übersicht und kann dann nach der gewünschten Funktion suchen.
    In meinem Fall habe ich nach "contact" gefiltert.
    Geht man dann auf die einzelnen Geräte, ist ersichtlich ob OTA untersützt wird oder nicht.

    Leider kann man nicht direkt nach OTA Fähigkeit filtern.

    ui hier ist es ja schon voll und du hast eigentlich genug kompetente beratung.

    Die Rückmeldungen hier sind wirklich spitze. [ay]
    Danke dafür.

    Daraus resultierend habe ich jetzt den empfohlenen Sonoff ZigBee 3.0 USB Dongle Plus sowie einen Xiaomi Mi Door and Window Sensor 2 (ebenfalls mit Zigbee 3.0) bestellt.
    Sobald das angekommen ist, werde ich alles mal zusammenbasteln und mich an die softwareseitige Einrichtung wagen.

    Gut, das sind jetzt natürlich ganz allgemein gültige Aussagen.
    Ich betreibe auch Kodi mit zig Add-Ons auf verschiendenen Endgeräten an verschiedenen Standorten, betreue mehrere NAS-Systeme unterschiedlicher Hersteller sowie Telefonanlagen, Serversysteme, Unraid-Server (inkl. an die 30 Docker), OPNsense-Firewalls (mitunter auch virtuell unter Unraid), Homepages, Smartphones von Freunden und Familien allesamt mit Custom-ROMs und einen eigenen Mail-Server...
    Und das alles läuft sehr zuverlässig und wartungsarm. Selbst nach Updates fange ich da nicht an zu schwitzen.
    Von daher hab ich vor dem Smarthome-Thema jetzt auch nicht unbedingt Angst :)

    Achja, und ich bastel da schon gerne überall dran rum...
    Aber das meinte ich vorhin damit dass ich nicht einfach nur möchte das etwas irgendwie zum laufen gebracht wird, sondern ich möchte mich mit dem System dann auch so weit auseinandersetzen, dass ich verstehen und nachvollziehen kann wie es funktioniert. Nur so kann ich es letzten Endes nicht nur in Betrieb nehmen, sondern eben auch langfristig vernünftig betreuen.

    @the ratman immerhin kann man selbst eingreifen, den Fehler finden und (ggfs. mit Hilfe einer Community) beheben.
    Das würde ich in jedem Fall vorziehen, anstatt dem Support eines bestimmten Herstellers und dessen Willkür auf Gedeih und Verderb ausgeliefert zu sein und zu hoffen dass Geräte nicht gar noch irgendwann durch den Hersteller unbrauchbar gemacht werden (siehe Sonos Recylingprogramm und andere Beispiele).

    Was man aber bedenken sollte ist leider, dass man beim Abweichen von den Hersteller Gateways meines Wissens nach keine Firmware-Updates mehr auf die Endgerät kriegt.

    Das ist ein guter Punkt!
    Was ich herausgefunden habe ist, dass es scheinbar grundsätzlich schon die Möglichkeit gibt Updates über Zigbee2MQTT auszurollen, aber eben nur für bestimmte Geräte:
    https://www.zigbee2mqtt.io/guide/usage/ot…ailable-updates

    Die bisherigen Erkenntnisse werfen folgende Fragen auf:

    • welcher Hersteller wäre für Türkontakte auch hinsichtlich der Updatefähigkeit über Zigbee2MQTT empfehlenswert?
    • welches Zigbee-Gateway wäre empfehlenswert?
    • Macht es in der Praxis einen Unterschied ob Zigbee 2.0 oder 3.0?
    • Wie funktioniert das Zigbee-Mesh bzw. welche Voraussetzungen sind dafür nötig?

    blieb mir nix anderes übrig, weil meine automatisation gewachsen ist

    Deswegen frage ich hier bewusst vor meinem Einstieg in die Smarthome-Welt, um einen unnötigen Wildwuchs bei Hard- und Software zu vermeiden ;)
    Will ja auch administriert und unterhalten werden alles...
    Meine Erfahrung hat mir gezeigt, dass es im Allgemeinen deutlich einfacher wird, wenn es eine einheitliche Basis gibt auf der man dann sauber aufbauen kann.

    protokolle sind mir scheiß egal, weil das eh fhem für mich zusammen führt.

    Das Thema Zuverlässigkeit sollte natürlich auch bei einer DIY-Lösung gegeben sein.
    Aber wenn ich jetzt z.B. die Sonoff-Türkontakte mit einem zugehörigen Gateway nehm, die ja über Zigbee funken, sollte es nach meinen Verständnis für die Zuverlässigkeit keinen Unterschied machen, ob ich die Hersteller-App nutze, oder eine andere App die ebenfalls Zigbee beherscht.
    Was ich aber nicht möchte, ist ein Sammelsurium verschiedener Standards, Protokolle und Schnittstellen für das ich dann verschiedene Bridges, Gateways oder sonstige Empfänger brauch. Daher suche ich bewusst nach einer offenen, allgemeinen Schnittstelle an die ich mit Geräten unterschiedlicher Hersteller bei Bedarf andocken kann.


    aja - wenn mit cloud "kein internet" gemeint ist, wirds auch gern eng.
    eine wettervorhersage oder z.b. auch anrufer rückwärts-suche macht die automatisation auch ein stückerl schöner und informativer.

    Damit meinte ich, dass die Sensoren/Aktoren etc. ohne eine Anbindung ans Internet und insbesondere einer Herstellercloud funktionieren können. Die Kommunikation soll rein lokal (ggfs. über ein erforderliches Gateway) mit der Smarthome-Zentrale (ioBroker/OpenHab/...) funktionieren.
    Hersteller sollen keinen Zugriff auf meine Geräte haben und auch keine Informationen darüber erhalten wann was wie geschaltet wurde. Nicht mal Telemetriedaten.
    ioBroker selbst darf natürlich Wetterinformationen und dergleichen online abrufen.

    Bedingt durch zigbee und MQTT hast du die eigentlich besten zwei Protokolle für DIY Dinge erwischt.

    Dann bin ich ja auf der richtigen Spur :)
    Ja, soll alles DIY bleiben. Ich möchte mich nicht von Herstellern oder deren Ökosystemen abhängig machen. Außerdem möchte ich selbst die Möglichkeit haben in Vorgänge einzugreifen bzw. nach meinen Vorstellen zu gestalten. Ohne Restriktionen durch Herstellervorgaben.
    Was mir außerdem wichtig ist: Es sollte sichergestellt sein, dass ein eventueller Zugriff der Geräte auf eine Herstellercloud nachhaltig unterbunden werden kann. Also z.B. durch das Flashen einer Tasmota-Firmware oder ähnliches.

    Berührungsängste oder Hemmungen etwas selbst zu machen habe ich eigentlich keine.
    Dafür schätze ich aber den Lerneffekt der entsteht wenn ich etwas eigenständig erreichen konnte. Außerdem reizt mich die Herausforderung dass dann nicht nur iiirgendwie lauffähig zu bekommen sondern so zu beherschen dass es reibungslos und wartungsarm läuft.

    Super, danke schon mal für den Input.
    Jetzt weiß ich schon mal dass ich nicht auf dem Holzweg bin.
    Und jede Erfahrung die hier eingebracht wird ist hilfreich für mich.
    Mir ist klar, dass ich bei der Thematik viel Zeit mitbringen muss und mich in verschiedene Bereiche einlesen werden muss.
    Aber so tappe ich schon mal nicht komplett im Dunkeln sondern habe eine grobe Richtung in die ich mich orientieren kann.


    Ich würde den Stick nehmen. Bei mir ist der Standort auch nicht ideal aber durch das Mesh-Netzwerk funktioniert es trotzdem gut.

    Wie funktioniert denn das Mesh bei den Zigbee-Geräten?
    Brauche ich da Repeater oder können das alle Teilnehmer im Netzwerk automatisch?
    Hätte ja in der "ersten Ausbaustufe" jetzt nur den USB-Stick am Server und den Sensor. Der USB-Stick wäre auch mit Verlängerung via USB-Kabel von viel Metall umgeben. Reine Luftlinie lägen knapp 20m dazwischen, sowie 2 Außenwände (massiv 30cm Stein) und 2 Innenwände (Gispkarton beidseitig doppelt beplant in Metallständerbauweise).


    Die Sonoff Bridge würde ich nicht nehmen, die war bei mir recht unzuverlässig

    Die Sonoff-Bridge war jetzt nur ein Beispiel. Könnte natürlich auch ein anderer Hersteller sein wenn das Gerät zuverlässiger arbeiten würde.


    Warum entscheiden? zigbee2mqtt unterstützt doch beides. Oder geht es jetzt speziell um den Fensterkontakt? Ich nutze hier den vom Lidl und bin zufrieden.

    Hatte gedacht es gäbe vielleicht Vorteile wenn man hier bei einem Hersteller bleibt.
    Grundsätzlich bin ich da flexibel.
    Wichtig wäre mir halt eine gute Reichweite, Zuverlässigkeit, lange Batterielaufzeit und eine gewisse Wetterfestigkeit wäre speziell für diesen Anwendungsfall hier noch relevant.

    Die Lidl-Teile kämen natürlich auch in Frage. Die und Sonoff funken wohl mit Zigbee 3.0 und die Aquaro "nur" mit 2.0. Ob das einen Unterschied macht bzw. welche Nachteile sich darauf ergeben könnten konnte ich aber bisher noch nicht in Erfahrung bringen.

    Bei Lidl hab ich eben auch die smarten Rauchmelder entdeckt. Das wäre dann eine der nächsten Baustellen :D

    Hallo,

    das Thema Smarthome interessiert mich schon eine ganze Weile und ich habe auch immer mal hier und da etwas dazu mitgelesen.
    Dadurch weiß ich schon mal grob was mich erwartet und dass das Thema komplex ist...

    Jetzt hat sich eine konkrete Anforderung ergeben, durch die ich das Thema aufgreifen und einsteigen möchte.

    Die Frage ist nur:
    Wie gehe ich das von Anfang an richtig an?


    1. Anforderung: Smarte Katzenklappe


    Ausgangssituation:
    Aufgrund baulicher Gegebenheiten wurde eine Katzenklappe mit RFID-Öffnung im Außenbereich angebracht.
    Ich müsste jetzt irgendwie signalisiert bekommen, wenn die Klappe passiert wird.
    Und das möglichst nur dann wenn es regnet oder nachts.

    Was ich grundsätzlich möchte:

    • keine "Insellösungen" einzelner Hersteller sondern ein zentrales System mit möglichst einheitlichem Standard
    • eine Lösung die gänzlich ohne Cloudanbindung auskommt
    • eine drahtlose Lösung
    • ein System das ich nach belieben erweitern kann

    Gegeben sind bereits ein Unraid-Server, ein separates Netzwerk für die Smarthome-Geräte, Ubiqiti-WLAN nach Wifi6-Standard.


    Die Überlegung war jetzt, an der Katzenklappe einen Türsensor anzubringen. Hier hatte ich mir bereit Aquara und Sonoff angesehen, da diese über Zigbee angebunden werden, was stromsparender (und günstiger sein dürfte, als z.B. das Wifi-Gegenstück von Shelly.
    Für die Anbindung der Zigbee-Komponenten hätte ich jetzt einen CC2531 USB-Stick an den Unraid-Server angeschlossen und in einen Zigbee2MQTT-Docker durchgereicht.
    Alternativ hatte ich mir das Zigbee-Gateway von Sonoff angesehen. Unter Verwendung von Zigbee2Tasmota auf dem Gerät wäre ich von der Reichweite her vermutlich flexibler als bei der Variante mit dem USB-Stick, da der Aufstellort des Unraid-Servers für eine Funkabdeckung der ganzen Wohnung eher ungünstig sein dürfte.

    Als zentrale Steuerungssoftware würde ich dann gerne ioBroker verwenden. In OpenHab hatte ich vor einiger Zeit schon mal kurz reingeschnuppert. Von der Programmierung her tendiere ich anhand dessen was ich bereits an Einblicke hatte aber eher zu ioBroker.
    Über entsprechende Adapter könnte ich dann Regeln für die Benachrichtigung bauen.

    Weitere Smarthome-Projekte würden folgen.


    Kann bzw. wird das so funktionieren?
    Welche Empfehlungen würdet ihr mir geben?
    Ist die Kombination aus Zigbee-Sensoren, einem entsprechendem Gateway und ioBroker sinnvoll?
    Eher Zigbee-Gateway oder CC2531-Stick?
    Eher Sonoff oder Aquara?
    OpenHab oder ioBroker?....
    Gibt es sonst noch was zu beachten?
    Irgendwelche Tipps von den Experten? :)

    Eigentlich bräuchte es, wie bei so vielem, nur etwas mehr Transparenz.

    Vor dem Kauf z.B. eine Info wie der Energieverbrauch bestenfalls ist (unter Angabe der damit verbundenen Einschränkungen) und wie viel höher er im schlechtesten Fall ist.

    Nach dem Kauf würde dann ein vernünftiger Einrichtungsassistent helfen.
    In der Regel ist es doch aktuell so, dass man zig Sachen abhaken und zustimmmen muss bevor man den TV in Betrieb nimmt. Kaum ein Anwender hat da überhaupt eine Ahnung wofür die ganzen "Features" sind, und welche Auswirkung sie haben. Sowohl auf den Energieverbrauch, als auch den Umgang mit den eigenen Daten.
    Hier müsste klar angegeben werden wofür der Dienst ist, welche Datenübermittlung damit verbunden ist, welche Einschränkungen sich ggfs. daraus ergeben wenn der Dienst nicht aktiviert wird und welche Auswirkungen auf den Energieverbrauch sich daraus ergeben.

    Vor allem aber sollte endlich mal der (eigentlich) gesetzlich verankerte Datenschutzgrundsatz des Opt-In-Verfahrens durchgesetzt werden und die Optionen zum Aktivieren eines datenschutzrelevanten Zusatzdienstes nicht deutlich prominenter platziert bzw. leichter zugänglich gemacht werden als die Optionen zu Abwahl so eines Dienstes.
    Generell wäre es wünschenswert wenn vieles modularer gestaltet würde.

    Wie mache ich denn das, dass der Raspbi von USB bootet?

    Das müsste wie hier beschrieben funktionieren.

    Wir denn ein externer Kartenleser, den ich über USB anschließe, als SD-Karte oder USB-Device erkannt

    Das kann ich dir leider nicht beantworten.
    Aber entweder er wird als SD-Karte erkannt und der Boot funktioniert wie gewöhnlich, oder er wird als USB-Gerät erkannt. Dann sollte die Variante mit dem USB-Boot funktionieren denke ich.

    Das alles klingt jetzt so als sei entweder die SD-Karte oder der SD-Kartenleser am Raspberry defekt.
    Aufgrund dessen scheitert das Repartitionieren und alle weiteren Probleme sind dann Folgefehler.

    Du könntest jetzt folgendes Versuchen:

    • andere SD-Karte
    • anderer Raspberry
    • anstatt des internen SD-Kartenlesers einen externen nutzen oder gleich "Boot from USB".

    Damit sollte sich dann zumindest schon mal die Fehlerquelle eingrenzen lassen und ggfs. auch beheben.


    Edit:
    Resize von extern über GParted oder ähnliches würde bei dem Fehlerbild wenig bringen, da bei einer defekten SD-Karte oder Kartenleser früher oder später weitere Folgeprobleme auftauchen würden.

    Zum Thema, legal, illegal...

    Und genau solche Fragestellungen in Bezug auf VPN allein sorgen doch erst dafür dass es so viele Missverständnisse rund um das Thema gibt.
    Die Frage sollte so garnicht erst gestellt werden.

    VPN ist nicht illegal! Zumindest nicht hierzulande. In China mag das vielleicht anders aussehen.
    Natürlich kann man über eine VPN-getunnelte Verbindung dann auch illegales anstellen. Aber illegales kann man auch ohne VPN anstellen.


    Vielleicht machts ein etwas abstrakter Vergleich deutlich:
    Auto fahren ist nicht illegal (mal vorausgesetzt man hat einen Führerschein und und.. ;) ).
    Jemanden mit dem Auto überfahren ist illegal.
    Das macht das Auto fahren aber an sich noch nicht illegal.
    Wenn ich jemanden platt machen will, brauch ich hingegen nicht unbedingt ein Auto
    :)