Yet another HomeKit adapter

[ronnyw]

Was mir außerdem spontan einfällt: Wenn Apples Home-App den Wert für die Farbtemperatur liefert: Was passiert dann, wenn man diese doch händich ändern möchte über einen Wandtaster oder Ähnlichem. Apple würde den eigenen Wert dann stetig überschreiben und man müsste das wieder mit einem iobroker Script abfangen.

Man stellt in der HomeApp ein, ob das Licht adaptiv betrieben wird oder mit einer fixen Einstellung. Sobald Du also mit ioBroker einen festen Wert zuweist, ist der auch fest. Oder -perspektivisch- würdest Du mit ioBroker auch die adaptive Einstellung wählen. Das müsste ja ein bestimmtes Setting im Hue-Objekt sein, soweit hab ich noch gar nicht geschaut (vielleicht kann das der Hue-Adapter auch schon?)...

[el_malto]

@loverz sagte in Yet another HomeKit adapter:

Ich verstehe, dass ihr gerne alles aus einer Hand haben wollt und auch gerne von Apple direkt, aber genau dafür ist doch iobroker da. Hier können wir endlich die Geräte verschiedenster Hersteller zusammenfassen. Egal ob diese aus Fernost, oder Fernwest kommen

Das ist mir schon klar, deswegen benutze ich ja auch ioBroker

Was mir außerdem spontan einfällt: Wenn Apples Home-App den Wert für die Farbtemperatur liefert: Was passiert dann, wenn man diese doch händich ändern möchte über einen Wandtaster oder Ähnlichem. Apple würde den eigenen Wert dann stetig überschreiben und man müsste das wieder mit einem iobroker Script abfangen.

Ja das ist klar. Wie gesagt, es gibt bestimmt mehr User die ihre Geräte nicht nur mit Homekit steuern. Dennoch wäre das ein cooles feature für Leute die es nur mit Homekit machen bzw für Leuchten in Räumen die sowieso nicht geändert werden (Flur usw. Ich weiß, es gibt auch Leute die da mit Farben usw. spielen.)

Aber deswegen finde ich die Diskussion (hoffe es ist jetzt nicht zu OT) -> https://forum.iobroker.net/topic/24936/diskussion-objektdefinition-licht/35 sehr interessant bzw. wäre das eine große Hilfe wenn man zu Lampen in ioBroker einen "Standard" zur Steuerung macht. So müsste man nicht für jede Lampe ein extra Skript haben wo man die Berechnungen usw. bastelt bis es passt.

[el_malto]

@ronnyw sagte in Yet another HomeKit adapter:

Man stellt in der HomeApp ein, ob das Licht adaptiv betrieben wird oder mit einer fixen Einstellung. Sobald Du also mit ioBroker einen festen Wert zuweist, ist der auch fest. Oder -perspektivisch- würdest Du mit ioBroker auch die adaptive Einstellung wählen. Das müsste ja ein bestimmtes Setting im Hue-Objekt sein, soweit hab ich noch gar nicht geschaut (vielleicht kann das der Hue-Adapter auch schon?)...

https://github.com/ebaauw/homebridge-hue/issues/766#issuecomment-731560178
Bei Punkt zwei und drei:

You can enable adaptive lighting (per light) only from the Home app, by selecting the adaptive lighting preset colour. Once enabled, it remains active, until the light's colour is changed or Homebridge restarts. Homebridge Hue logs a message when adaptive lighting is enabled: 

[Hue] Living 9: set homekit active transition count to 1

You can disable adaptive lighting (per light) from the Home app, by selecting another preset colour from the home app. Adaptive lighting is disabled automatically by Homebridge Hue, when light's colour is changed, from any HomeKit app, from any other API client, directly or through a scene. Note that adaptive lighting is not disabled when the light's colour temperature is changed. Homebridge Hue logs a message when adaptive lighting is disabled:

[Hue] Living 9: set homekit active transition count to 0

Das hört sich für mich so an als wenn das nur eine homebridge-hue funktion ist. Denke, dass das sonst von Homekit gesteuert wird. Wenn alles über homekit läuft, merkt homekit ja ob man händisch was verändert hat. Bei ioBroker kann man sowas dann nur über ein Skript wie @loverz das schon erwähnt abfangen.

[loverz]

@valbuz ne, hab es mit zigbee Datenbank verwechselt. Sorry.

[ronnyw]

@el_malto sagte in Yet another HomeKit adapter:

Das hört sich für mich so an als wenn das nur eine homebridge-hue funktion ist. Denke, dass das sonst von Homekit gesteuert wird. Wenn alles über homekit läuft, merkt homekit ja ob man händisch was verändert hat. Bei ioBroker kann man sowas dann nur über ein Skript wie @loverz das schon erwähnt abfangen.

Ich weiß nicht genau, wie Du das meinst. YAHKA müsste wie Homebridge-Hue die Funktionalität haben, die Fähigkeit für Adaptive Lighting an HomeKit zu melden. YAHKA ist die Brücke zwischen HomeKit, das initial und fortlaufend alle 24 Stunden die neuen Kurven für Helligkeit und Farbtemperatur sendet und dem Hue-Objekt in der ioBroker Datenbank. YAHKA müsste dann selbstständig alle Minute das Licht-Objekt anhand der aktuellen Kurve updaten (für die Eigenschaft Adaptive Lighting müsste es ggf auch noch einen neuen Datenpunkt geben?). Die ganze Adaptive Lighting Logik und Kommunikation mit HomeKit müsste von YAHKA erledigt werden. So macht es meine ich auch Homebridge.

[el_malto]

@ronnyw sagte in Yet another HomeKit adapter:

YAHKA müsste dann selbstständig alle Minute das Licht-Objekt anhand der aktuellen Kurve updaten

Genau das ist der Knackpunkt. Wenn alles über HomeKit läuft, ohne Homebridge und ioBroker oder einer anderen Smart Home Zentrale, regelt HomeKit alles und kann dann ja auch merken wenn man manuell über die HomeKit App geändert wird.
Wenn man aber Yahka oder sonst was dazwischen hat, wird es schwierig. Yahka müsste ja jetzt ständig die Datenpunkte der Lampen überprüfen und gucken das die Datenpunkte nicht anders als durch Yahka bzw. von der HomeKit App (z.B. durch ein Skript oder per Hand) geändert werden weil Yahka sonst nacher eine Minute den Wert wieder überschreibt.
Das ist ja genau das gleich wie mit den Skripten hier aus dem Forum die adaptive Lighting nachahmen. Wenn das Skript läuft und man dann händisch was an der Lampe verstellt, wird beim nächsten Zyklus dieser Wert wieder vom Skript überschrieben. Es muss also immer festgestellt werden ob und wie ein Datenpunkt geändert wird.
Die Problematik hat man in einer reinen HomeKit Umgebung nicht.

Oder habe ich irgendwo was vergessen oder übersehen?

[ronnyw]

@el_malto sagte in Yet another HomeKit adapter:

Oder habe ich irgendwo was vergessen oder übersehen?

Das Update geht natürlich in beide Richtungen. Wenn Du jetzt die Helligkeit vom Licht außerhalb von HomeKit änderst, hast Du in HomeKit ja trotzdem die korrekte Helligkeit.
Würde Adaptive Lighting implementiert werden, würde eine manuelle Änderung des Lichtes außerhalb von HomeKit dafür sorgen, dass damit Adaptive Lighting deaktiviert werden würde, und HomeKit das auch weiß. Das heißt - wissen sollte! Denn wenn ich das richtig gesehen hab, ist das gerade noch ein Bug, dass HomeKit das nicht immer korrekt reflektiert.

[el_malto]

@ronnyw wenn das so ist wäre das natürlich ein cooles feature.

[loverz]

@el_malto @ronnyw
In meinem oben verlinkten Script wird das doch auch berücksichtigt.

Ich errechne einen Sonnenstand zwischen 0-100%.

Die errechnete Prozentzahl ergibt dann die minutengenaue Farbtemp.

Wenn sich nun der Wert Farbtemp. ändert und von der oben errechneten Zahl abweicht wird die weitere Berechnung bis zum erneuten Einschalten der Lampe deaktiviert.

[TheAriba]

Hi zusammen,
wie ihr in meinem Thread lesen könnt habe ich die ein oder andere Frage zum YAHKA.
link

Hier mal zusammengefasst:
Habe Dimmaktoren welche ich gerne in Homekit integrieren möchte.
Um auf ein % Dimmen zu können muss ich erst den LVL Datenpunkt bei den Aktiren die % reinschreiben und anschließend dem CMD Datenpunkt eine 3=Set Level mitgeben.

Aktuell löse ich das über ein Blockly, gibt es denn die Möglichkeit das auch global/direkt in YAHKA zu konfigurieren? Ansonsten müsste ich mir 20 Blocklys anlegen.
Zusätzlich noch die Frage. Wenn ich Home schließe sind die Stati der Geräte quasi immer per default auf aus. Können diese irgendwie von Yahka gespeichert bzw. gemerkt werden?

Danke euch vorab und viele Grüße

[Asgothian]

@EnoceanEltako sagte in Yet another HomeKit adapter:

Aktuell löse ich das über ein Blockly, gibt es denn die Möglichkeit das auch global/direkt in YAHKA zu konfigurieren? Ansonsten müsste ich mir 20 Blocklys anlegen.

Hallo,

ich denke man kann das Skript auch irgendwie direkt im Yahka anlegen. Das ist aber meiner Meinung nach wenig zielführend. Einfacher ist es, wenn Du eine Anzahl von geeigneten Datenpunkten anlegst, so das du mit einem von einem "Selektor" getriebenen Trigger alle Lampen steuern kannst. Da musst du zwar für jede Lampe einen Datenpunkt anlegen, aber hast trotzdem nur ein recht einfaches Skript fuer die Verbindung.

[loverz]

@EnoceanEltako Hab deinen Thread kurz übersprungen.

Um zu dimmen benötigst du nur einen Datenpunkt in %. Entweder eine Selbst angelegtes Objekt, das du über ein (Blockly) Script fütterst und abholst, oder direkt dein Aktor, wenn der mit % arbeitet.

Außerdem wird ein Objekt für On/Off verwendet, aber manche Aktoren schalten auch bei 0% aus, dann würde man das nicht zwingend brauchen, kann dann aber glaube ich in der Home App nicht auf die Lampe touchen, sondern muss auf 0% runter regeln.

Hab dir die wichtigen Punkte mal gelb markiert:

"Level255" habe ich nur weil meine Hue Spots statt 0-100% mit 0-255 als Zahlenwert arbeiten. YAHKA rechnet dann entsprechend um.

[el_malto]

@loverz Bitte seinen Thread nochmal genau lesen. Das Problem ist, dass er den Wert mit einen extra Datunpunkt "bestätigen" odeer eher gesagt "setzen" muss.
Er sucht also eine Lösung die das evtl automatisiert. Mit dem Skript aus seinem Thread klappt das. Sein Problem ist nur, dass er jetzt 20 Skripte haben müsste.
Also wenn Yahka den wert im Datenpunkt LVL ändert, müsste Yahka danach im Datenpunkt CMD noch 3 schreiben.

[loverz]

@el_malto alles klar, dann habe ich es auf die schnelle falsch interpretiert und ziehe mich zurück

[el_malto]

@loverz brauchst du ja nicht. Eine passende Lösung wäre auch super

[loverz]

@el_malto
@EnoceanEltako

Also habe es mir jetzt doch aufmerksam durchgelesen.
Das erste Problem das du hast ist, dass in deinen LVL Objekt theoretisch ein Wert stehen könnte nehmen wir mal 50 % an und in dem anderen CMD Objekt eine Zahl ungleich drei.
Was passiert dann mit deiner Lampe? Ist die Auf 50 % an, oder ist die aus?

Diese Situation solltest du auch abfangen. Heißt wenn dieses Objekt sich geändert hat und 0 ist, dann soll das andere Objekt CMD auch wieder zurück gestellt (OFF) werden.

Letztlich hast du mit deinem Script schon mal einiges richtig gemacht.
Du solltest den Schreibe-Block aber noch durch einen Steuere-Block austauschen.
Außerdem würde ich statt „aktualisiere“ als Trigger „geändert“ auswählen. Hat auch einer schon geschrieben in deinem Post.

Jetzt würde ich als erstes mal versuchen diesen einen Lichtkanal zum laufen zu bringen und das Skript dann anschließend für die anderen Kanäle kopieren, das ist keine große Sache.
Der Vorteil wenn du alles in Blockly-Scripts machst ist, dass du auch von anderen Anwendungen anschließend einen Prozentwert an deine Lampen senden kannst. Wenn du das ganze über YahkaDirekt machst, dann würde das nicht gehen.

Man kann die Skripts auch in einem Ordner zusammenfassen, dann ist es auch schön übersichtlich.

[Asgothian]

@el_malto sagte in Yet another HomeKit adapter:

Er sucht also eine Lösung die das evtl automatisiert. Mit dem Skript aus seinem Thread klappt das. Sein Problem ist nur, dass er jetzt 20 Skripte haben müsste.

Das ist zu automatisieren.

Angenommen seine Dimmaktoren kommen aus dem Adapter "dimmaktortest.0", und heissen Lampe.1 bis Lampe.20, darin jeweils die DP's level und cmd.

1. Schritt:

Ein Skript mit (JS oder Blockly) mit einem Selektor als Trigger anlegen (Doku zum Selektor siehe hier)

Als Selektor channel[state.id=dimmaktortest.0*.level]

Im Trigger sich mit diesem Baustein einmal die ID holen

die ID zerlegen, und daraus die Ziel-ID fuer den CMD Datenpunkt heraus holen. Dann in diesen ein "3" herein schreiben.

Damit reicht es mit Yahka den level Datenpunkt zu verbinden. Jede Anpassung sorgt dafuer das der Wert auch gesetzt wird.

Zu testen wäre wie genau der Selektor aussehen muss. Das hängt von den Datenpunktnamen ab.

A.

Edit: ich hatte das Bild des korrekten Baustein vergessen

[loverz]

@Asgothian Das scheint mir die fortgeschrittene Variante zu sein.
Für den Anfang würde ich damit nicht anfangen

[Asgothian]

@loverz So fortgeschritten ist es nicht. Einmal den Selektor verstehen und glücklich sein. String Manipulationen sollten nicht das grosse Problem sein.

Alles andere sind Erweiterungen am Adapter oder viel Skript-click Arbeit, also eher nicht besser.

A.

Zur not kann ich auch auf Discord helfen das zu bauen, so ist es nicht. (nur nicht heute)

Nachtrag: Man kann das auch ohne Selektor bauen. Dann muss man halt alle 20 quell Datenpunkte von Hand in den Trigger eintragen. Entscheidend ist das man sich die ID des zu setzenden DP's aus der ID des DP welchen den Trigger ausgelöst hat zusammen baut. Dann reicht ein Skript für alle Lampen.

[loverz]

@Asgothian Naja, solange ich googeln muss was Discord, String Manipulationen und DP IDs sind finde ich es für mich zu kompliziert. Ich kann natürlich nicht für andere sprechen.