Beiträge von sargnagel

    Habe gleiches Problem. Auffällig ist auch, dass der Öffner bei Homekit/Homebridge dauerhaft auf geöffnet steht und sich das Wartesymbol dreht.


    Außerdem finde ich, dass die Nuki App selbst auch viel träger ist. Es dauert gefühlt viel länger, bis die Verbindung zum Opener steht.


    UPDATE: Nach zweimaligem Neustart der Bridge geht es wieder!

    ich hab die auch nun in HomeKit. Aber bei mir zeigen die immer an keine Gefahr.


    Wie ist das bei dir?

    Hatte ich anfangs auch, dass die Sensoren über das Tuya-Platform-Plugin keine Aktualisierung an HomeKit durchgereicht haben.

    Hast Du wie in der Plugin-Beschreibung angegeben einen Tuya-IoT-Account samt der Service-APIs angelegt? Bei mir fehlte einzig die API Device Status Notification, aber genau die war für die Benachrichtigen wichtig.

    Guten Abend!


    Ich habe verschiedenste Tuya-Sensoren günstig zum Testen gekauft.: Temperatur/Luftfeuchtigkeit, Tür-/Fenster-Sensoren und einen Rauchmelder.


    Die Anbindung habe ich anhand der Plugin-Anleitung vorgenommen: Smart Life App, Tuya IoT Platform, Cloud Services. Das Plugin Tuya Platform (@0x5e) habe ich genommen, da hier die breiteste Palette an Sensoren/Geräten unterstützt wird.


    Alle Tuya-Sensoren werden auch in Homebridge übernommen und schließlich auch in HomeKit angezeigt.


    Was mich allerdings irritiert: Die Werte (Temperatur, Zustand beim Türöffnen/-schließen, Test-Rauchalarm) werden in Homebridge und HomeKit nicht aktualisiert. In der Smart Life App schon...


    Hat jemand zufällig auch Tuya-Sensoren im Einsatz und vielleicht auch das Plugin Tuya Platform (@0x5e) installiert?


    Hier kann man ja keine Polling-Frequenz o.ä. hinterlegen oder übersehe ich etwas? In den Plugin-Issues habe ich auch nichts Hilfreiches gefunden.


    EDIT: Ich habe den Fehler gefunden. Habe eine Service-API übersehen. Und das war mit "Device Status Notification" auch prompt die wichtigste. Nun läuft es.

    Scheinbar gabs da auch eine Namensänderung, heißt jetzt owntone.


    https://github.com/owntone/owntone-server

    Oh, das ging bisher an mir vorbei.


    Hat jemand ein relativ nahtloses Update von Forked-DAAPD zu OwnTone vollzogen? Wenn ja wie?


    Ich habe auch gesehen, dass es ein Homebridge-Plugin für OwnTone gibt.


    Hat das jemand ausprobiert?

    Habe bisher nie etwas von Sclak gehört/gelesen. Habe insgesamt bestimmt 6 Mails geschickt.


    Ich habe mir nun auch einen Nuki Opener gekauft (bei „uptodate“ mit Newsletter-Gutschein für EUR 82,96)


    Ohne Bridge, da ich eigentlich nur hin und wieder Ring To Open nutzen möchte. Funktioniert gut, ist aber tatsächlich etwas träge.


    Einen Shelly Uni hatte ich mir auch bestellt, konnte aber keine Stromversorgung aus der Sprechanlage abgreifen und mit Akku oder Netzteil plus langer Zuleitung war mir das auch irgendwie zu doof. Der Shelly ging ungenutzt wieder zurück.

    Es scheint eine Möglichkeit zu geben per mqtt das ganze anzufangen. Aber keine Ahnung wie.

    In der App zeigt er mittlerweile auch keine Logs mehr an.

    Hatte ich mich auch kurz mit beschäftigt. War wohl auch hier im Forum mal Thema. Du meinst das hier, oder?


    GitHub / LFE89 / NELLO ONE - Remove cloud constraint


    Mir war das allerdings etwas zu abstrakt bzw. mit der Doku kam ich nicht wirklich klar. Erfolg hatte ich bei meinen Versuchen leider nicht.


    Ich glaube, ich versuche es mit NodeMCU und Relais.

    Weiß jemand, ob man einen Nello noch in der App auf eine entsprechende Firmware wechseln/updaten kann? oder ob es überhaupt einen speziellen Nello gibt oder hier nur die Verkablung anders ist?

    Ich glaube, wenn das mit Firmware-Updates OTA so leicht wäre, dann hätte man sicherlich auch schon irgendwo eine offene Flanke gefunden, mit der man die Verbindung zu den labilen Nello-/SCLAK-Servern kappen und eine lokale Lösung aufbauen könnte.


    Wenn die Server nun weiterhin einigermaßen durchlaufen, bin ich zufrieden. Die Lösung an sich funktioniert für unseren Haushalt sehr gut so.

    Hattest recht, Sebbo187. War tatsächlich noch aktiviert. Danke Dir.


    Funktioniert nun.


    Allerdings funktioniert Deine Automation über HomeKit ("Wenn es klingelt und jemand aus dem Haushalt anwesend ist, dann öffne die Tür.") bei mir nicht. Habe die Homekit-Anwesenheit auch generell noch nie in einer Automation eingesetzt. Vielleicht habe ich es auch unwissentlich falsch oder gar nicht konfiguriert.


    Nutze sonst nur den Anwesenheitssensor von Tado in HomeKit / Homebridge. Der funktioniert super, aber den kann ich für die Automation ja nicht nutzen, da es dann ja zwei Sensoren (Klingeln und Anwesenheit) als Auslöser wären...


    Überlege, ob ich vielleicht in Node-Red einen Workaround erstellen könnte. "Dreimal klingeln -> Öffnen" Glaube aber, das wird nicht klappen.

    1) Push-Benachrichtigen (wären mir aber auch nicht so wichtig)

    2) Beim betätigen der Klingel öffnet der Summer jeden. Auto-Unlock ist deaktiviert.


    Wie kann ich einstellen, das wenn jmd Klingelt ich eine HK-Benachrichtigung erhalte? Muss das über den Bewegungsmelder gehen? Wenn ja, weiß wer wie es konfiguriert werden muss?

    Hat da einer eine Idee?

    Moin Nudelsalat!

    Benachrichtigungen über HomeKit beim Öffnen funktionieren bei mir, aber nicht die Klingel sondern das Öffnen und Schließen der Tür wird gemeldet.

    Und auch bei mir wird die Tür immer kurz nach dem Klingeln geöffnet.

    Das funktioniert somit leider auch nicht mehr.

    Da bin ich auch früher gestolpert. Vielleicht hilft dir das hier weiter:

    https://flows.nodered.org/flow…733cf4ec694c5c1ceae6e20ec

    Ah! Prima. Vielen Dank!


    Das ist eigentlich auch recht naheliegend, ähnlich habe ich es am Schluss mit dem Setzen des "Triggerwortes" für MQTTThing schließlich auch gelöst. Man muss eben einzelne Nodes nutzen. Ich wollte innerhalb eines Nodes die Werte "umformen" und dann kamen zum Teil nur Zahlenkolonnen heraus.

    Etwas älter, der Thread hier, aber ich habe mich als Allergiegeplagter - mit wenig bis keiner Ahnung von Node-Red - mal an eine Umsetzung gemacht. Habe dazu einen Flow aus dem Netz umgebastelt, bei dem die Daten am Ende eigentlich per Mail o.ä. verschickt werden.


    Meine Lösung mit Node-Red und Homebridge-MQTTThing:


    Greife die DWD-Daten ab, filtere die Einzelwerte raus, leite den Wert für die Intensität (0 bis 3) direkt durch an jeweilige MQTT-Topics durch, frage parallel ab, ob der Wert größer als 0 ist und forme den Payload dann in ein "Trigger-Wort" um, das dann wiederum auch an jeweils gesondertes MQTT-Topic weitergeleitet wird.


    Ich hatte zuerst in MQTTThing dafür je Pollenart einen CO2-Sensor genommen, damit ich auch die Intensität des Pollenfluges ablesen kann, aber irgendwie irritierte der CO2-Alarm hier im Haushalt dann doch etwas. Somit ist es nun ein normaler Kontaktsensor, der ausgelöst wird. Der Wert für die Intensität fällt dann erstmal hintenüber.


    Im Ergebnis habe ich nun 6 Kontaktsensoren (Birke, Esche, Erle usw.), die jeweils auslösen.


    Schwierig war für mich mittendrin übrigens, dass die DWD-Pollenflugwerte nicht nur 1, 2 oder 3 sein können, sondern auch 0-1, 1-2 und 2-3. Da war ich mit meinem spärlichen Node-Red-Latein dann schnell am Ende.


    Falls jemand Interesse hat und sich an Node-Red herantraut oder darin vielleicht sogar mehr Erfahrung hat, gebe ich gerne mehr Infos. Mein Node-Red-Flow ist allerdings etwas umfangreicher, eben weil ich mit Node-Red noch wenig Erfahrung habe.


    Und vielleicht hat jemand bezüglich des Kontaktsensors auch noch andere Ideen. Hatte zwischenzeitlich auch einen Rauchsensor in MQTTThing zweckentfremdet. Aber auch das irritiert eher...

    Moin, gibt es Bestrebungen die Raumluftdaten und Pollendaten in HK zu integrieren, oder kann man die nicht über die API abgreifen? Das schalten und automatisieren geht ja. Auch die Temperatur. Wäre mehr denkbar SeydX?

    SeydX Erst einmal vielen Dank für dieses unglaublich vielseitige Plugin.


    Ich würde nur gerne noch einmal die Frage von Flausen hervorkramen. Die wurde meiner Meinung nach nicht weiter beachtet. Falls doch: SORRY.


    Wenn die Raumluft- und die Pollendaten ebenfalls abgreifbar wären, könnte man die auch noch vielseitig einsetzen. Die Lüftungserkennung eventuell auch noch als gesonderten Wert.


    Das wäre aber nun wirklich nur noch ein Sahnehäubchen... :)