Beiträge von sschuste

    Heisst also, ich brauche NICHT ein Gateway von Gardena, Homebridge mit dem Plugin Gardena Mower reicht, solange natürlich mein Wlan genug Reichweite für in den Garten hat?!

    Da ich über keinen Garten verfüge und nicht einmal einen langflorigen Teppich besitze, der den Kauf eines Mähroboters rechtfertigen würde, kann ich dazu wenig sagen außer: die Reichweite deines WLANs nur dann wichtig, wenn auch der Mähroboter WLAN kann.


    In vielen Fällen steuern Homebridge-Plugins die Bridges/Gateways und die Bridges/Gateways steuern dann die daran angeschlossenen Geräte. Wie sich das bei Mährobotern verhält, weiß ich nicht. Für mich ist das Vorhandensein einer Bridge immer ein Indiz dafür, dass das Endgerät (hier der Mähroboter) eben kein WLAN kann - wozu sollte sonst die Bridge existieren?


    Aber natürlich weiß ich es nicht genau. Vielleicht braucht man die Bridge nur dann, wenn man eine Cloud-Anbindung einrichten will, die es erlaubt, den Mähroboter von unterwegs zu starten, und man gleichzeitig kein HomeKit hat. Hach, ist es nicht herrlich, einfach mal blöd herumzuspekulieren, wenn man keine Ahnung hat, Hauptsache, mal irgendwas geschrieben? ;)

    Aber ich muss definitiv dann die Leute noch einladen oder ? Das die evtl nur einen QR Code oder sowas scannen müssen und drin sind geht evtl nicht oder ?

    Ich sag's dir lieber gleich jetzt: die Mehrheit der Bevölkerung will einen Lichtschalter. Da drücken die drauf und die Funzel geht an. Alles andere führt zu gewaltigem Supportaufwand deinerseits, selbst dann, wenn es Lichtschalter plus Sprachsteuerung sind.


    Ich würde AUF JEDEN FALL jedes Einladen weglassen oder jeden QR-Code oder alles, was die mit irgendeinem Handy machen müssen. Denn wenn du Pech hast, kommen auch noch ein paar Gestalten mit Android um die Ecke, es sei denn, du hast die Ferienwohnung nur für iPhone-Anwender, die auch noch iCloud verwenden, annonciert.


    Und deine Mieter rufen nicht tagsüber an. Nee, die rufen nachts an, wenn die das Licht nicht einschalten können. In der Bewertung deiner Ferienwohnung kannst du dann nachlesen, dass das Licht nur dann angeht, wenn der Vermieter es einschaltet.


    Zusätzlich wird Sprachsteuerung einen Haufen von Leuten glauben lassen, dass du sie heimlich überwachst. Im Zweifel entfernen die den HomePod vom Strom - soviel dann zur Steuerzentrale.


    Ich glaube nicht, dass du damit irgendwem einen Gefallen tust - am wenigsten dir selber.

    In der Home App (original auf dem iPhone)

    Konnte ich irgendwie die Räume anordnen. Ich finde diese Einstellung einfach nicht mehr. Wie ging das noch gleich ?

    Oben links das Haus anklicken, dann:

    Raumeinstellungen -> oben links: Räume -> oben links: Bearbeiten, dann Räume in die Reihenfolge verschieben.

    Ist abschätzbar wie lange die Thermostate noch funktionieren würden

    Kann man präzise sagen: zu einem beliebigen Zeitpunkt in vierzigdreißigzwanzigzehn Jahren wirst du die Thermostate nicht mehr steuern können. Um es noch genauer abschätzen zu können, muss man sich folgende Fragen stellen:


    Wie funktioniert die Steuerung?

    Welches Protokoll wird zur Steuerung eingesetzt? Irgend ein Standard so wie https oder MQTT oder irgendetwas anderes, was gerne Standard sein will so wie HomeKit? Vielleicht etwas völlig eigenes, das wahrscheinlich nie ein Standard sein wird?


    Ich meine, welche Standards haben sich denn gehalten seit 1980? Ah, da ist beispielsweise 7-bit ASCII-Text. Der wird benötigt, um Textdateien so zu speichern, dass andere Programme ihn wieder lesen können. Er umfasst das englische Alphabet und Zahlen und Sonderzeichen, aber nicht etwa so absonderliche Dinge wie Umlaute. Und schon gar nicht irgendwelche Formate wie fett, kursiv und unterstrichen. Aber er ist heute noch lesbar.


    Was ist mit den Bildern, die 1988 auf einem Atari ST mit Degas, Stad oder Neochrome gemalt wurden? Oh, schade. Perdu. Was mit Texten, die damals mit Calamus geschrieben wurden wurden? Tonne. Was ist mit einem Text, der 1993 in QuarkXpress verfasst wurde? Weg damit. Was mit einer Webseite aus dem Jahre 1995? Oh! Die funktioniert! Was mit einer Animation, die 1999 in Flash erstellt wurde? Ähm.


    Die Programme Stad, Calamus und QuarkXpress waren wegweisend. Ich bin sicher, dass du davon noch nie gehört hast. Sie sind vergessen und ihre Dokumente auch. Sie basieren auf Protokollen, die herstellerspezifisch waren, und als die Produkte eingestellt wurden und die Hersteller verschwanden, war auch Schluss mit diesen Protokollen. Aber das ist auch egal: ich habe hier auf meinem Rechner alte Word-Dateien aus dem Jahre 1994, die kann heute nicht mal Word öffnen.

    oder gibt es Alternativen?

    Alternativen gibt es für diejenigen, die sich tief in die Materie eingraben und die gleichzeitig in die Zukunft schauen können. Genauer betrachtet gilt das für niemanden auf diesem Planeten.


    Ich wünschte, das alle smarten Geräte eine JSON-Schnittstelle bereitstellen, die ich über https ansteuern kann oder dass sie per MQTT steuerbar wären. So könnte ich im Zweifel noch selbst was basteln. Dann könnte ich in der Zukunft vielleicht auch ein kaputtes Heizungsventil durch irgendein anderes Produkt ersetzen. Aber bevor das passiert, ruft mich eher Catherine Zeta-Jones an und wünscht sich nackte Tatsachen.


    Zum heutigen Zeitpunkt würde ich sagen: kauf, was du willst und erfreu dich daran, solange es funktioniert. Geh davon aus, dass deine Investition nicht haltbar ist. Glaube nicht daran, dass irgendein Hersteller seine eigenen Standards in die Zukunft mitschleppt. Deine Hue-Bridge v2 geht 2026 kaputt und du kannst nur die neue Hue-Bridge v3.7 bekommen, aber die unterstützt leider deine alten Lightstrips nicht mehr. Ja das ist aber schade. Noch schader ist es, dass Philips vielleicht gar nicht mehr existiert. 2007 war Nokia too big to fail, aber alle im Jahre 2000 geborenen haben heute keine Ahnung, was Nokia je gewesen sein mag.


    Was auch immer du anschaffen willst: es ist falsch. Es sei denn, es hat offene Schnittstellen und du kennst dich damit aus. Falls dir das zu blöd ist (und das ist es), dann komm in zehn Jahren wieder. Oder steig jetzt ein und komm auch in zehn Jahren wieder. So sieht's in meinen Augen aus.

    Sehe ich es richtig, dass dieser Befehl „dmesg -T„ erst Sinn macht einzugeben, nachdem sich der RasPi wieder aufgehangen hat und bevor ich nen reboot mache?

    Ja, ansonsten werden die Information, die du bekommen könntest, beim Systemboot überschrieben.


    Das Log, das dmesg liefert, ist noch hässlicher als die, die man im Allgemeinen schon kennt. Dagegen liest sich ein Homebridge-Log wie das erste Kapitel von Pippi Langstrumpf. Aber es enthält eine Menge Informationen über die verwendete Hardware und du darfst gerne rätseln, was das alles zu bedeuten hat.


    Die Homebridge ab Version 1.3 erlaubt es im Gegensatz zu früheren Versionen, den Homebridge-Service an eine bestimmte Schnittstelle zu binden. Das kannst du in homebridge-config-ui-x unter Homebridge-Einstellungen einstellen oder auch direkt in config.json:


    "bridge": {
    "name": "Homebridge",
    "username": "AF:95:64:EA:1D:F8",
    "port": 51826,
    "manufacturer": "homebridge.io",
    "model": "homebridge",
    "pin": "095-77-114",
    "advertiser": "ciao",
            "bind": [
    "eth0"
    ]

    },

    Das bedeutet wahrscheinlich, dass der gleichzeitige Betrieb beider Netzwerkerkkarten (wlan0 und eth0) kein Problem mehr darstellen sollte. Ältere Homebridge-Versionen schickten mal über die eine, mal über die andere Schnittstelle Daten raus, was HomeKit irgendwie wuschig gemacht hat (jedenfalls war das meine Erfahrung). Ich will damit nur sagen, dass der gleichzeitige Betrieb des WLANs dir die Möglichkeit geben würde, dich nach dem Versagen von eth0 einzuloggen und nachzuschauen, ohne dass du einen Monitor und eine Tastatur anschließen musst.


    der Befehl ifconfig ist ebenfalls ganz nützlich - er zeigt an, welche Netzwerkkarten überhaupt aktiv sind. Ich verwende nur wlan0 und daher sieht der Output bei mir so aus:


    eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500

    ether dc:a6:32:17:c2:f6 txqueuelen 1000 (Ethernet)

    RX packets 0 bytes 0 (0.0 B)

    RX errors 0 dropped 0 overruns 0 frame 0

    TX packets 0 bytes 0 (0.0 B)

    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


    lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536

    inet 127.0.0.1 netmask 255.0.0.0

    inet6 ::1 prefixlen 128 scopeid 0x10<host>

    loop txqueuelen 1000 (Local Loopback)

    RX packets 368503774 bytes 110480440109 (102.8 GiB)

    RX errors 0 dropped 0 overruns 0 frame 0

    TX packets 368503774 bytes 110480440109 (102.8 GiB)

    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


    wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

    inet 192.168.1.22 netmask 255.255.255.0 broadcast 192.168.1.255

    inet6 fd36:84f2:e2f1:2:89d2:37e5:fdfb:de0 prefixlen 64 scopeid 0x0<global>

    inet6 fe80::edf9:d542:9ad0:bda6 prefixlen 64 scopeid 0x20<link>

    ether dc:a6:32:17:c2:f7 txqueuelen 1000 (Ethernet)

    RX packets 326121146 bytes 498456708 (475.3 MiB)

    RX errors 0 dropped 0 overruns 0 frame 0

    TX packets 311907728 bytes 918591856 (876.0 MiB)

    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


    An eth0 ist kein Kabel angeschlossen, daher wird die Netzwerkkarte zwar angezeigt, aber sie hat kein IP-Adresse.

    Alle Log-Einträge folgen dem gleichen Muster:


    Apr 22 17:55:46 raspberrypi rngd[372]: stats: Entropy starvations: 0


    Fett markiert habe ich mal den wesentlichen Eintrag. Das ist irgendein Name mit einer Nummer dahinter. Es gibt noch andere im Log:

    avahi-daemon[344]

    dhcpcd[626]

    dbus-daemon[293]

    homebridge[350]

    fake-hwclock[103]

    systemd[1]


    Der Name sagt aus, welcher Service etwas loggt. Die Zahl dahinter ist die Prozess-ID. Jeder laufende Prozess bekommt eine solche ID und behält sie auch während seiner Laufzeit. Stoppt man den Prozess und startet ihn neu, bekommt er eine neue ID zugewiesen. Soll dir egal sein.


    Du hast also Meldungen von verschiedenen Services, wobei die Meldungen von rngd wurscht sind - das hat was mit dem Zufallsgenerator deines Systems zu tun. Wahrscheinlich ist auch die Meldung des dbus-daemon, der der Interkommunikation der Prozesse auf dem System dient, egal. Aber was weiß ich davon. Der Prozess fake-hwclock hat was mit der Uhrzeit deines Systems zu tun. Der systemd startet einen weiteren Service (udev).


    Der Prozess homebrigde warnt, dass er die Netzwerkverbindung zum Harmony Hub geschlossen hat. Dein dhcpcd schreibt was davon, dass er über eth0: keine Informationen erhalten konnte. Gehört der zu pihole? Aber auch egal.


    Es geht offenbar eine Verbindung über eth0: verloren. An eth0: hängt ein Netzwerkkabel und das führt wahrscheinlich zu einer Ethernet-Schnittstelle an einem Switch (oder an einem eingebauten Switch in einem Router). Es gibt damit drei plus zwei Elemente:

    1. eth0: an deinem Raspi
    2. Ethernet-Schnittstelle an deinem Switch
    3. Kabel, die beide verbindet

    plus

    1. Netzwerksoftware auf dem Raspi
    2. Netzwerksoftware auf dem Switch


    Wenn eines von den dreien Hardwaredingern nicht richtig funktioniert, fällt die Verbindung aus. Kabel kaputt - keine Verbindung. Nur eine Ethernetschnittstelle kaputt - keine Verbindung.


    Aber auch die Software kann Probleme machen: Paketfilter falsch konfiguriert, Switchsoftware falsch konfiguriert. Oder die Software ist schlichtweg veraltet. Mal alle Komponenten einem Update unterzogen?


    Das kannst du alles nur feststellen, wenn du dich auf deinem Raspi einloggst, sobald er kein Netz mehr hat - mit einer Tastatur und einem Monitor. Wahrscheinlich bleibt der Monitor schwarz, wenn du ihn erst dann anschließt, daher sollte er die ganze Zeit dranhängen, so hässlich das auch ist.


    Das Log oben sagt jedenfalls nicht viel aus. Dafür ist der Befehl dmesg -T besser geeignet, aber nur vor einem Reboot.

    Kann ich ein iPad als HB benutzten?

    Wahrscheinlich ja. Dazu musst du dein iPad einem Jailbreak unterziehen, damit du an den Unix-Unterbau herankommst. Es sollte dann für jeden, der extrem gute Kenntnisse von iPadOS hat (und weiterhin extrem gute Kenntnisse von Unix-Software) möglich sein, Homebridge auf dem iPad zu installieren. Programmierkenntnisse sind jetzt unabdingbar.


    Mit extrem guten Kenntnisse meine ich, dass du iPadOS-Hardcore-Programmierer und bei Apple arbeitest. Du liest gerne technische Spezifikationen und arbeitest dich in Dokumentation ein. Du bist darüber hinaus in der Lage, die Software der Homebridge an iPadOS anzupassen. Du bist willens, dich damit längere Zeit auseinanderzusetzen, damit du 70€ sparen kannst.

    Und wenn nein, warum nicht?

    Weil es Homebridge nicht im Appstore gibt - tatsächlich ist es letztendlich so simpel. Homebridge ist eine Software, die auf anderer Software basiert (die auf deinem iPad nicht existiert) und diese andere Software basiert auf noch anderer Software (die auf deinem iPad nicht existiert). Natürlich könnte sich jemand hinsetzen und das programmieren, aber ich würde nicht darauf warten. So ein iPad ist was Feines, aber als Server-Hardware ist es nicht gedacht.

    Ich fand die Idee ganz cool mir ein iPad an die wand zu basteln mit dem ich dann das ganze Haus steuern kann. Dieses iPad würde ja quasi alle Voraussetzungen einer HB erfüllen (also immer an, immer vor Ort, immer am Netz).

    Diese Voraussetzungen erfüllt auch dein Router, und du könntest auch deinen Herd, deine Waschmaschine und deinen Eierkocher eingeschaltet lassen, aber auf die Idee, die Homebridge dort zu installieren, kommst du aus irgendwelchen Gründen nicht. Warum nicht? Sie sind für die Homebridge ähnlich gut geeignet wie ein iPad.

    Verstanden habe ich auch:

    Das beste Gerät für eine HB ist ein Raspberry Pi

    Das hast du richtig verstanden. Und es so zu machen wie die meisten, hat immer den Vorteil, dass man vernünftige Antworten auf seine Fragen bekommt, weil einfach der "Vernünftige-Antworten-Pool" groß genug ist.

    Welchen Ventilator kann man für HomeKit am besten benutzen? Gibt es einen mit HomeKit oder muss man sich etwas zusammen basteln?

    Ich verwende einen Standventilator, den Xiaomi Fan 2S, den ich über Homebridge nach HomeKit gebracht habe. Das ist der leiseste Ventilator, den ich je besessen habe. Außerdem hat er noch einen Akku und kann auch mal über Nacht ins Schlafzimmer.

    https://www.idealo.de/preisver…destal-fan-2s-xiaomi.html


    Funktioniert gut.

    Wie soll ich vorgehen? Wie hier beschrieben?

    Keine Ahnung. Im Source Code sollte nicht /uptime.txt drin stehen, sondern /tmp/uptime.txt. Das kannst du checken, indem du den Source Code mit sudo nano /usr/local/lib/node_modules/homebridge-raspberrypi-info/index.js aufrufst und dann darin nach uptime.txt suchst und es gegebenenfalls verbesserst. Aber eigentlich sollte der Source Code das schon so enthalten.


    Da ich das Plugin nicht nutze, habe ich den Pfad zum Source Code mal so geraten. Ich hoffe, er stimmt.

    Was mir aber auffällt ist, das ich mich Terminus auf dem iPad nicht mehr verbinden kann.

    Weil du dir beide Arme gebrochen hast? Oder gibt es irgendeine andere Fehlermeldung, vorzugsweise auf dem Display deines iDings?


    Ich nehme an, du hast das neue Image auf deinen Raspi installiert. Termius erkennt ein neues Gerät und hält das sicherheitshalber mal für einen fetten Betrug. Das ist nicht der Raspi, den Termius kennt, also hält die App lieber mal die Füße still. Das macht nicht nur Termius so. Das machen alle ssh-Clients so. It's not a bug - it's a feature.


    Versuch mal das: lösche das Gerät aus der Known Hosts-Liste in Termius und verbinde dich nochmal.

    Ich wüsste nicht, wie ich ihn dazu bringen kann, das zu korrigieren und woher der Fehler überhaupt kommt. Eine Idee?

    Leider nicht. Damit kenne ich mich überhaupt nicht aus. Ich weiß nicht, ob es hilfreich ist, aber die Klammer kann ja an den verschiedensten Stellen verloren gehen. Für mein MQTT verwende ich MQTT.fx, damit kann man ganz bequem den MQTT-Server beobachten.


    Oh. Ich sehe gerade, dass das inzwischen Geld kostet. Aber immerhin kann man es drei Monate testen.


    Da ist es: http://www.jensd.de/apps/mqttfx/1.7.1/

    {

    "Time": "2021-04-11T18:23:39",

    "Switch1": "ON",

    "AM2301": {

    "Temperature": 12.3,

    "Humidity": 56.6,

    "DewPoint": 3.9

    },

    "SML": {

    "Total_in": 234.5124,

    "Power_curr": 52.6,

    "Meter_number": "0a01445a4700039954f6",

    "Curr_p1": 0.000,

    "TempUnit": "C"

    }

    }


    Am Ende des JSON-Strings, den du da auswerten willst, fehlt eine schließende Klammer, die ich jetzt mal in rot dazu gesetzt habe. Der JSON-String ist also nicht vollständig und das führt zu SyntaxError: Unexpected end of JSON input.