Beiträge von Deralte

    jap, seit heute morgen konnte ich das auch beobachten. Was ich aber ebenfalls bemerkt habe, ist, dass ich scheinbar nicht mehr die App an sich erwähnen muss, dass Siri schnallt, welche sie nutzen soll - zumindest ist die verbuggte Antwort die gleiche. Man könnte daraus schließen, dass Siri tatsächlich gelernt hat, welche App dafür am meisten genutzt wird.


    Heißt:

    Vorher: Setze Atomreaktoren auf meine Einkaufsliste in Bring

    Antwort: Du musst in Bring fortfahren

    Jetzt: Setze Atomreaktoren auf meine Einkaufsliste

    Antwort: Du musst in Bring fortfahren


    Die bauen was das angeht echt nur noch Scheiße bei Apple.

    Lohnt sich das flashen der Shelly Homekit Firmware oder ist das Homebridge Plugin eigentlich ausreichend?

    zusätzlich kannst du mit HK Firmware durch erneutes Tippen auf die Kachel das Rollo stoppen - das geht mit dem Plugin selbst nicht. Ich hatte jedoch mit der HK Firmware deutliche Verbindungsprobleme. Mit dem Plugin ging es dann etwas besser. Jetzt sind die per HomeAssistant in HomeKit und es läuft tadellos.

    Zitat

    Stand heute: es war ein Fehler, mich von Alexa zu trennen und auf die Minis zu setzen.

    Das würde ich ganz genauso unterschreiben!


    Ich sehe mittlerweile, bis auf den Privacy Aspekt keine Vorteile mehr für mich, die Dinger einzusetzen. Thread ist mir (noch) nicht wirklich wichtig, da es bisher Apple exklusiv ist. Multiroom Audio ist cool, bekommt man auch anders hin. Ich warte noch ein Update ab. Wenn sich dann nichts gebessert, gehen die Dinger in den Verkauf.

    Das Rädchen dreht sich, die Jalousie ist schon lange oben oder unten, aber der Status des Schalters ändert sich nicht mehr.

    Das habe ich tatsächlich bei einem Rollo (ist ein Shelly 2.5) ebenfalls. Genau dieser Shelly dümpelt bei einer WLAN Signalstärke von nur 16-20% rum - er reagiert zwar prompt, jedoch habe ich nur das Anzeige Problem, was mich jedoch nicht weiter stört. Ich würde es also auf die WLAN Verbindung - zumindest bei mir - schieben. Kannst du ja mal überprüfen (je nachdem was deine Jalousien steuert).

    Mit de aktuell technischen Möglichkeiten sind die Usecases wirklich recht begrenzt bzw. überschaubar. Aber ich sehe gerade mit Kindern im Haushalt ein sehr großes Potenzial dieser Funktion, bzw. was Restriktion bei den Sprachbefehlen in Bezug auf HomeKit angeht... Ob Apple so weit geht, bezweifele ich zwar, aber das ist ne andere Sache.

    Hi,


    Ich habe einst die shelly 2.5 mit der HK Firmware genutzt. Jetzt bin ich auf das Shelly Homebridge Plugin umgestiegen. Vorher war das Verhalten, dass 1x Tappen auf das Rollos in der Home App das Rollo (je nachdem öffnend oder schließend) in Bewegung gesetzt hat und das 2. tappen das Rollo gestoppt hat. Jetzt bewirkt das 2. tappen, dass das Rollo in die andere Richtung zurück fährt. Kann ich das irgendwie konfigurieren? Ich nutze die Shelly App nicht, sondern gehe nur über Weboberfläche der einzelnen Shellys.

    Eben, und ein zusätzlicher Parameter ist die Lautstärke. So ein Move a la Scheibe-einschlagen-und-rein erfüllt diesen also ganz gewiss nicht. Ich würde mir bei „älteren“ Fenstern, die leicht auszuhebeln sind, deutlich mehr Gedanken machen.

    Vielleicht auch mit einem Kurbefehl selbst. Der Befehl "ich gehe ins Bett" löst dann den Kurbefehl mit demselben Namen aus, welcher die Gute-Nacht-Szene beinhaltet, (dort wird dann besagtes Licht auf X% gestellt und der HomePod mini angesteuert) und startet dann den (wenn auch extrem buckeligen) Time innerhalb des Kurzbefehls.


    Es müsste im Kurzbefehl lauten:

    Wiederholen: 7200

    Warten: 30 sekunden

    DANN:

    - Licht ausschalten

    - HomePod mini -> Wiedergabe anhalten


    Ob die App jedoch diese übellange Wiederholen/Warten Konstellation auf die Kette bekommt oder zeitnah abbricht, gilt es auszuprobieren.


    Versuche mal als Auslöser einen "beliebigen" WERT zu nehmen

    Roger das kannst du eigentlich als Grundsatz nehmen. Wenn du auf Basis, von Lux-, Temperatur-, Lautstärke- oder ähnlichen Werten eine Automation erstellst, muss der Auslöser immer eine "beliebige Änderung" sein. Die Bedingung ist dann dein gewünschter Wert (z.B. 7 Lux, 22 Grad, 70dB).

    Du kannst versuchen ausschließlich Deckenlicht Weiß als Trigger zu nutzen. Wenn du die einzeln eh nie betreibst, sollte es ausreichen. Mit einer Gruppenauswahl hatten die Schalter bei mir auch immer Probleme

    So ich habe diesbezüglich Rücksprache Dresden Elektronik Support gehalten


    Es gibt sowohl "alte" Aqara Sensoren mit der Modell-ID "lumi.sensor_magnet.aq2" und eine neue Variante "lumi.magnet.acn001". In der API Ausgabe der Phoscon App ist die Modell-ID zu finden.

    Die neuere Variante wird wohl erst mit deCONZ 2.13.2 unterstützt.


    Also bin ich jetzt auf wieder auf die deCONZ Beta 2.13.2 gegangen und die Sensoren selbst reagieren nun prompt auf die Statusänderung in der Phoscon App. Homebridge-HUE spuckt mir trotzdem den Fehler aus, dass er den Sensor nicht kennt und somit wird auch nichts an HomeKit durchgeschleift. Ich würde also daraus schlussfolgern, dass die Problematik eher beim HUE Plugin anzusiedeln ist, als bei deCONZ.


    Edit: Ich werde jetzt erstmal WIEDER zurück auf 2.12.6 gehen, da damit die Sensoren in HomeKit wenigstens funktioniert haben und ich meinen Kram umsetzen kann. Dass sie in der Phoscon App nicht auftauchen, ist mir dann erstmal egal. Ich weiß natürlich nicht, wie es in der deCONZ Weboberfläche ausgesehen hätte, da ich diese nicht benutze.

    das hier kann nicht stimmen, du brauchst den gesamten Dateipfad:

    || natürlich. Jetzt hats auch funktioniert.


    Kurios ist jetzt, dass die vorgehenden LUMI Sensoren gar nicht mehr sichtbar sind in der Phoscon App. Dennoch habe ich einen von denen wieder zurückgesetzt und neu angelernt. Im Anlerndialog stand dann "Sensor bereit". Dieser ist jedoch nicht in der Phoscon Übersicht aufgetaucht. Auf der anderen Seite ist er an erfolgreich HomeKit übermittelt worden und funktioniert auch.

    das Ergebnis bleibt leider gleich.


    pi@homebridge:~ $ wget -O deconz-latest.deb https://deconz.dresden-elektronik.de/raspbian/stable/

    --2021-12-02 13:51:20-- https://deconz.dresden-elektronik.de/raspbian/stable/

    Resolving deconz.dresden-elektronik.de (deconz.dresden-elektronik.de)... 144.76.96.194

    Connecting to deconz.dresden-elektronik.de (deconz.dresden-elektronik.de)|144.76.96.194|:443... connected.

    HTTP request sent, awaiting response... 200 OK

    Length: unspecified [text/html]

    Saving to: ‘deconz-latest.deb’


    deconz-latest.deb [ <=> ] 1.66K --.-KB/s in 0s


    2021-12-02 13:51:20 (8.90 MB/s) - ‘deconz-latest.deb’ saved [1702]


    pi@homebridge:~ $ sudo dpkg -i deconz-2.12.06-qt5.deb

    dpkg: error: cannot access archive 'deconz-2.12.06-qt5.deb': No such file or directory

    pi@homebridge:~ $


    Ggf. muss ich mal den Support antickern. Mal sehen was die sagen.

    Den Deconz-Service habe ich vorher per sudo systemctl stop deconz gestoppt.


    Unten ist das Ergebnis des Befehls wget -O deconz-latest.deb https://deconz.dresden-elektro…/stable/deconz-latest.deb


    pi@homebridge:~ $ wget -O deconz-latest.deb https://deconz.dresden-elektronik.de/raspbian/stable/

    --2021-12-02 13:02:46-- https://deconz.dresden-elektronik.de/raspbian/stable/

    Resolving deconz.dresden-elektronik.de (deconz.dresden-elektronik.de)... 144.76.96.194

    Connecting to deconz.dresden-elektronik.de (deconz.dresden-elektronik.de)|144.76.96.194|:443... connected.

    HTTP request sent, awaiting response... 200 OK

    Length: unspecified [text/html]

    Saving to: ‘deconz-latest.deb’


    deconz-latest.deb [ <=> ] 1.66K --.-KB/s in 0s


    2021-12-02 13:02:46 (10.0 MB/s) - ‘deconz-latest.deb’ saved [1702]

    Hab meinen Beitrag oben nochmal editiert!


    siehe Nr. 4: https://github.com/dresden-ele…ki/Update-deCONZ-manually bzw. zwei Seiten hier zurückblättern auf folgenden Beitrag: RE: RaspBee II Zigbee Gateway deCONZ

    danke dir Patrick.


    ich bekomme bei Befehl sudo dpkg -i deconz-latest.deb folgende Fehlermeldung

    pi@homebridge:~ $ sudo dpkg -i deconz-latest.deb

    dpkg-deb: error: 'deconz-latest.deb' is not a Debian format archive

    dpkg: error processing archive deconz-latest.deb (--install):

    dpkg-deb --control subprocess returned error exit status 2

    Errors were encountered while processing:

    deconz-latest.deb

    pi@homebridge:~ $

    Spannend, dass der Sensor als Sensor von Lumi erkannt wird und nicht als Aquara.

    Ja genau das wundert mit auch. Komisch ist auch, dass die Produktbezeichnung "Kontaktsensor" ist, jedoch das Bild einen Bewegungsmelder anzeigt.


    Ich habe den jetzt aus der Phoscon App gelöscht, dann zurückgesetzt (Reset Button 10sek halten) und neu eingebunden - selbes Ergebnis


    zusätzlich steht noch im Log:

    [02/12/2021, 11:37:43] [Hue] Phoscon-GW: warning: not using recommended deCONZ gateway version 2.12.6


    Meine aktuelle Version ist 2.13.02 / 10.11.2021