homebridge-knx 0.3.0 alpha (Apple HomeKit interface)

[schuma]

Hallo,
ich habe da heute noch mal etwas rumprobiert.....

Das "Listen" von Hombridge-KNX funktioniert einwandfrei.
Wenn ich das Dimmen auf der Config rausnehme, wird auch beim Dimmen von extern keine Lampe an oder aus gestellt.
Es scheint wirklich nur am Senden von Homkit zu liegen.
Damit ist das für KNX komplett nicht nutzbar!
Das gleiche Verhalten habe ich übrigends bei den Rolläden! Die fahren dann auch nicht in einem Stück sondern hoch und runter.

Schade eigentlich. Aber immerhin für ein/aus funktioniert es einwandfrei.
Evtl. klappt es ja mit dem nächsten IOS.

Ich frage mich allerdings immer noch, wie das andere Hersteller handhaben? Die müssen doch auch mit dem Gesendeten klarkommen. Das kann ja aber gar nicht sein....


Grüße, Marc

[schuma]

hmmm. Also alles blöd ;-)
Das macht aber nicht gerade einen durchdachten Eindruck von Apple....
Da muss es ja einen Sinn hinter geben. Oder anders gefragt, warum machen Die das so???
Ich kann mir nicht vorstellen das es Aktoren gibt die das wirre Zeug verstehen.

Mal eine Nacht drüber schlafen... Evtl kommt morgen ja eine tolle Idee vorbei.

gn8 und Danke für Deine Arbeit!

Marc

[snowdd]

Ach und leider ist das 100%-Problem von Apple Home noch inkonsistenter: Manchmal kommt auch erst 100%, direkt danach ein AN.

[snowdd]

Ok, mehr Erkenntnisse:
Die Home App schickt (zumindest nach einiger Zeit Inaktivität auf dem Gerät) beim Anschalten einer Lampe mit Dimmer einmal 100% Helligkeit mit.
Die EVE App (zumindest bei mir auf dem iPhone, Eve 2.5.2) handhabt Helligkeit und An/Aus komplett getrennt. Man kann die Helligkeit ändern ohne die Lampe an zu schalten.

Der Rest scheint "hausgemacht" zu sein:

Wenn der Aktor sein aktives Rückmeldeobjekt "Schalten" auch immer dann zurückmeldet, wenn die Helligkeit geändert wird, kommt bei HomeKit immer wieder ein "AN" an. Apple's Home schickt als Antwort darauf dann gerne mal ein "100%" (Kam ja gerade ein "AN" bei ihm an) hinterher, was zu Sprüngen beim Dimmen führt.

Andersherum, wenn der Aktor auf ein EIN oder AUS mit einer Helligkeit antwortet, kann das dazu führen dass HomeKit dann wieder mit AN antwortet (Nur Apple's Home, nicht EVE)

Ich habe mal in einer Testversion dafür gesorgt, dass nur dann an HomeKit zurückgemeldet wird, wenn der Wert sich geändert hat - dann kommt zumindest kein AN vom Bus mehr an, wenn HomeKit schon AN dachte, aber ansonsten hatte es leider nur geringen Effekt. Mit Eve funktioniert dann alles, mit Home nicht.

[snowdd]

Doch nicht.
Leider passiert nach einiger Zeit genau das wieder, was wir hier regelmäßig beobachten:

  EventedHTTPServer [::ffff:192.168.178.85] HTTP request: /characteristics +5s
  HAPServer [CC:22:3D:E3:CE:60] HAP Request: PUT /characteristics +1ms
  Accessory [DEVHomebridge] Processing characteristic set: [{"aid":3,"iid":20,"value":1},{"aid":3,"iid":21,"value":100}] +2ms
  Accessory [DEVHomebridge] Setting Characteristic "On" to value 1 +1ms
[2017-01-27 19:43:11] [homebridge-knx.KNX]  (reverse)
[2017-01-27 19:43:11] [homebridge-knx.KNX] DEBUG in knxwrite: 1/1/18, DPT: DPT1, val: 1
  EventedHTTPServer [::ffff:192.168.178.85] Muting event '3.20' notification for this connection since it originated here. +4ms
  Accessory [DEVHomebridge] Setting Characteristic "Brightness" to value 100 +1ms
[2017-01-27 19:43:11] [homebridge-knx.KNX]  (reverse)
[2017-01-27 19:43:11] [homebridge-knx.KNX] DEBUG in knxwrite: 1/1/16, DPT: DPT5, val: 255
  EventedHTTPServer [::ffff:192.168.178.85] Muting event '3.21' notification for this connection since it originated here. +6ms
  EventedHTTPServer [::ffff:192.168.178.85] HTTP Response is finished +1ms

Das Schreiben auf den Bus hatte ich auskommentiert. Im Log steht nur was übergeben wurde. HomeKit (Apples Home App) schickt erst ein "An" und dann "Helligkeit 100%" hinterher.

[snowdd]

Wenn ich nichts auf den Bus schreibe, sieht es eigentlich gut aus:

  EventedHTTPServer [::ffff:192.168.178.85] HTTP request: /characteristics +5s
  HAPServer [CC:22:3D:E3:CE:60] HAP Request: PUT /characteristics +1ms
  Accessory [DEVHomebridge] Processing characteristic set: [{"aid":3,"iid":20,"value":1}] +2ms
  Accessory [DEVHomebridge] Setting Characteristic "On" to value 1 +1ms
[2017-01-27 19:03:20] [homebridge-knx.KNX]  (reverse)
[2017-01-27 19:03:20] [homebridge-knx.KNX] DEBUG in knxwrite: 1/1/18, DPT: DPT1, val: 1
  EventedHTTPServer [::ffff:192.168.178.85] Muting event '3.20' notification for this connection since it originated here. +12ms
  EventedHTTPServer [::ffff:192.168.178.85] HTTP Response is finished +1ms

Sobald das "On" als schaltsignal auf den Bus geschrieben wird, findet wohl eine Art Rückkopplung statt.

[schuma]

OK, geht....

Das kommt dabei raus wenn ich von 100% auf 50% dimme:
knx2.jpg Ist das jetzt das was an KNXD geht?
Dann würde hier ja schon ein hoch runter Dimmen vorhanden sein.
Dann wird wohl Home aus dem hochdimmen einfach wieder ein "EIN" machen.
Irgendwie alles blöd....

[snowdd]

Dann starte homebridge doch mal mit sudo DEBUG=* homebridge - oder wie du das auch immer sonst startest.

Ich habe gerade mal in mein Log von der Produktiven Umgebung geschaut, und es sieht wirklich komisch aus. Ich baue mir gerade eine Testversion die nicht auf den Bus schreibt, und gucke mal was da ankommt.

[schuma]

Ehhhhh, noch mal geschaut...
also mit -g installiert!

[snowdd]

Zum Testen am einfachsten auf die Konsole. Hast Du Homebridge mit -g installiert (mit sudo) oder als user "pi" ?

[schuma]

Ok, ich nutze auch einen Pi mit Jessie.
Kannst Du mir sagen wie ich den Debugmodus einschalte.
und wo das Log geschrieben wird?
linux ist nur sehr begrenzt meins...

Marc

[snowdd]

schuma
ja kann man. Es kann alles protokolliert werden. Wie das geht hängt aber vom Betriebssystem und der Art des Starts ab.

Bei mir läuft es auf einem Raspberry Pi als systemd Service und schreibt in den systemd Protokolldaemon journald.
Da ich in der Service-Definitionsdatei homebridge mit `DEBUG=* homebridge` starte, wird alles protokolliert. Zumindest auf der Entwicklungsumgebung

[schuma]

Hallo Raoul,
ich habe Deine Fragen nicht so recht verstanden. Aber ich versuche mal den Vorgang noch einmal zu beschreiben.
In dem Bild sind die Schaltvorgänge der Hombridge markiert (Auszug Gruppenmonitor von EINEM Schaltvorgang):
knx.jpg
Alle diese Schaltvorgänge stammen aus einer einzigen Aktion. Ich sage: "Siri, Wohnzimmer Licht Esstisch 50%"
Danach werden alle Signale in den roten Kreisen auf den Bus geschickt. Das "EIN" zwischendurch bewirkt zusätzlich das die Lampe wieder auf den letzten Wert vor dem letzten Ausschalten gedimmt wird (Ist so im Aktor eingestellt.). Es wird also ständig hin und her gedimmt.

Was man jetzt als Notlösung gebrauchen könnte, wäre ein Funktion, die solange keine Werte mehr sendet bis der Zielwert (absolutes Dimmen - also hier 50%) +- 2% erreicht ist.

Also [Wert 50% senden], [weiteres senden unterbinden], [bei Rückmeldung Aktor 50% +-2% senden wieder aktivieren].

So dass, die gesendeten Signal zwischendurch nicht auf den Bus gegeben werden.

Am Ende sieht das für mich aber aus wie ein BUG in der Hombridge-KNX.
Kann man irgenwie sehen was von Hombridge an Hombridge-knx gegeben wird?
Und was von Homebridge-KNX an KNXD übergeben wird?

[snowdd]

@schuma: nicht ganz einfach, denn der Händler (autocorrect!) bekommt die Nachrichten ja einzeln von HomeKit. Was machst Du mit der Lampe, wenn Du Helligkeit:=100% bekommst? Und kurz danach ein an? Oder in anderer Reihenfolge? Wie lange müsste man nach einer Nachricht warten, ob sie vielleicht so ein HomeKit Querschuss ist, den man unterdrücken müsste?

Bei mir gehen mit Eve noch die meisten Dimmer, der am Esstisch allerdings gar nicht mehr, dort kann ich nur noch dimmen, an/aus geht nicht mehr... muss mir das Log mal ansehen, was da passiert.

Gruß
Raoul

[schuma]

snowdd kann man da als Lösung einen Handler bauen?
Würde das den internen Funktionen irgendwie zuvorkommen oder Sie ganz ersetzen?
Übrigens ist das Dimmverhalten bei Home, Eve und Siri vorhanden.
Also eher ein globales Problem;-)

Grüße, Marc