homebridge/homekit

[hoppel118]

Hallo Sky,

dein homebridgeMapping sieht jetzt gut aus. Es tut, was es soll.

Nach wie vor kann ich immer noch den Shelly in Homekit schalten :

Ich hatte es schonmal geschrieben. Du kannst ganz normal weiter schalten, auch wenn das Gerät nicht erreichbar ist. Es gibt keine Möglichkeit, den EIN-AUS-Schalter in irgendeiner Hinsicht auszugrauen oder auszublenden. Durch die Characteristic "Reachable" erhälst du zumindest die Möglichkeit anzuzeigen, dass das Gerät gerade "nicht erreichbar" ist.

Oder verstehe ich dich falsch? Was willst du bezwecken?

In Fhem werden alle drei Zustände korrekt übermittelt , der "Error"-Status aktualisiert sich allerdings auch hier erst nach ca. 1 Minute .
Ich denke das dies der Zeitintervall im Device ist .

In Homekit wird der Status "Keine Antwort" , wie schon im vorherigen Post beschrieben ,erst nach dem Neustart der Homebridge angezeigt .

Irgendwo hängt es an der Übermittlung , weiß aber nicht warum und wo

Damit kann ich dir leider nicht helfen. Bei mir funktioniert das mit meinem Ventilator und dem userReadings ohne die Homebridge neustarten zu müssen. Aber ich werde das nochmal genauer prüfen. Ich melde mich nochmal dazu.

Vielleicht hat dazu ja noch jemand anderes eine Idee?

Gruß Hoppel

[Sky]

Hallo hoppel ,

Ich hatte es schonmal geschrieben. Du kannst ganz normal weiter schalten, auch wenn das Gerät nicht erreichbar ist. Es gibt keine Möglichkeit, den EIN-AUS-Schalter in irgendeiner Hinsicht auszugrauen oder auszublenden. Durch die Characteristic "Reachable" erhälst du zumindest die Möglichkeit anzuzeigen, dass das Gerät gerade "nicht erreichbar" ist.

Oder verstehe ich dich falsch? Was willst du bezwecken?

Vielleicht habe ich das nicht richtig formuliert .
Ich möchte einfach auf dem iPhone in Home ( Homekit ) erreichen ,daß ich z.B.
für den Shelly ( als Schalter definiert ) sehen kann , ob dieser noch ansprechbar ist . 
Dies ist für mich sinnlos , wenn ich diesen EIN-AUS-Schalter immer noch "schalten" kann, obwohl am Ende das Endgerät welches am Shelly hängt
nicht reagieren kann , da der Stromkreis unterbrochen ist .
Es soll kein ausgrauen oder ausblenden sein , reichen würde die Anzeige im Schalter " keine Antwort "

[volschin]

Möglicherweise ist heute Weihnachten. Oder Ostern? Oder beides zusammen?
Stellt Euch vor, Apple, Amazon, Google, die Zigbee Allianz und ein paar weitere tun sich zusammen und machen das Smarthome erwachsen und es gibt offene Standards zum Austausch zwischen den Komponenten.

Es ist wahr.

https://www.connectedhomeip.com

Oder soll zumindest wahr werden.

[Horst_T]

Hallo zusammen.

Vielleicht kann mir jemand weiterhelfen.
Hatte bisher Homematic Geräte direkt bei fhem und Homematic-IP Geräte unter Raspberrymatic laufen. Die Homematic-IP Geräte sind über HMCCU nach fhem gemappt. Alle Geräte funktionierten auch problemlos mit Homebridge. Jetzt sind die Homematic Geräte auch nach Raspberrymatic umgezogen und werden ebenfalls über HMCCU nach fhem gemappt.
Es funktionieren auch alle Geräte mit Homebridge bis auf Keymatic HM-SEC-KEY. Keymatic funktionierte vorher einwandfrei mit Homebridge, jetzt gemappt über HMCCU geht es nicht mehr. Das Problem scheint an Homebridge-fhem zu liegen, da hier der Schaltbefehl falsch zusammengestellt wird.

Die Konfiguration der Keymatic für Homebridge ist gleich geblieben.

Attributes:
   IODev      d_ccu
   ccureadingfilter (STATE|INHIBIT)
   eventMap   /datapoint 1.OPEN true:open/
   genericDeviceType lock
   group      HMCCUDEV,Tür / Fenster
   hmstatevals ERROR!1:clutch_failure,2:motor_aborted
   icon       hm_keymatic
   room       CCU,Flur,Homekit
   statedatapoint 1.STATE
   statevals  lock:false,unlock:true
   substitute STATE!(0|false):locked,(1|true):unlocked,2:open;INHIBIT!(0|false):no,(1|true):yes;STATE_UNCERTAIN!(1|true):manual;DIRECTION!0:none,1:up,2:down,3:undefined;ERROR!0:no,1:clutch_failure,2:motor_aborted
   webCmd     lock:unlock:open:inhibit on:inhibit off



Hier das Protokoll von Homebridge:

Türschloss sperren:

2019-12-18 6:48:35 PM] [FHEM] Tuerschloss: executing set cmd for LockTargetState with value 1
2019-12-18 6:48:35 PM] [FHEM]   executing: http://127.0.0.1:8083/fhem?cmd=set%20Tuerschloss%20lock%20locked&fwcsrf=csrf_755042824018342&XHR=1


Türschloss entsperren:

[2019-12-18 6:49:15 PM] [FHEM] Tuerschloss: executing set cmd for LockTargetState with value 0
[2019-12-18 6:49:15 PM] [FHEM]   executing: http://127.0.0.1:8083/fhem?cmd=set%20Tuerschloss%20lock%20unlocked&fwcsrf=csrf_755042824018342&XHR=1

Wäre schön, wenn mir jemand weiterhelfen könnte.

Gruß Horst

[hoppel118]

Möglicherweise ist heute Weihnachten. Oder Ostern? Oder beides zusammen?
Stellt Euch vor, Apple, Amazon, Google, die Zigbee Allianz und ein paar weitere tun sich zusammen und machen das Smarthome erwachsen und es gibt offene Standards zum Austausch zwischen den Komponenten.

Es ist wahr.

https://www.connectedhomeip.com

Oder soll zumindest wahr werden.

WOW!!! Das ist wirklich krass geil! Träume ich oder haben wir den 1. April?

Schön, dass du das hier postest, sonst hätte zumindest ich das so schnell nicht mitbekommen.

Kannst du dafür trotzdem einen neuen Thread aufmachen und den dann hier verlinken?

Das ist ein Bisschen sehr offtopic und könnte komplett ausarten.

Viele Grüße Hoppel

[hoppel118]

Damit kann ich dir leider nicht helfen. Bei mir funktioniert das mit meinem Ventilator und dem userReadings ohne die Homebridge neustarten zu müssen. Aber ich werde das nochmal genauer prüfen. Ich melde mich nochmal dazu.

So, ich habe das im Laufe des Tages mit 2 Geräten getestet.

1. Stehlampe (mit einer Hue Leuchten Gruppe) ohne eigenes homebridgeMapping
2. Ventilator mit eigenem homebridgeMapping

Fazit: Reachable funktioniert. In beiden Fällen wurde automatisch die Meldung ,,keine Antwort" angezeigt, nachdem ich die Stromkabel gezogen/entfernt hatte. Bis zur Meldung hat es allerdings ein wenig gedauert. Wie lange, weiß ich nicht. War unterwegs zwischendurch. Anschließend habe ich ohne Homebridge-Neustart die Stromkabel wieder gesteckt und die Meldung ist ebenfalls nicht sofort aber irgendwann wieder verschwunden.

Mit diesem Verhalten kann ich persönlich leben.

Hallo hoppel ,

Vielleicht habe ich das nicht richtig formuliert .
Ich möchte einfach auf dem iPhone in Home ( Homekit ) erreichen ,daß ich z.B.
für den Shelly ( als Schalter definiert ) sehen kann , ob dieser noch ansprechbar ist . 
Dies ist für mich sinnlos , wenn ich diesen EIN-AUS-Schalter immer noch "schalten" kann, obwohl am Ende das Endgerät welches am Shelly hängt
nicht reagieren kann , da der Stromkreis unterbrochen ist .
Es soll kein ausgrauen oder ausblenden sein , reichen würde die Anzeige im Schalter " keine Antwort "

Hm...

Ich weiß nicht, was ich dir dazu jetzt noch schreiben könnte. Die Characteristic ,,Reachable" kann dir ,,keine Antwort" anzeigen, wenn du sie richtig mappst. Mit dem Schalter kannst aber weiter schalten, unabhängig von ,,keine Antwort". Wenn das Gerät nicht erreichbar ist, funktioniert der Schalter natürlicherweise auch nicht, obwohl du ihn EIN und AUS schalten kannst.

So wurde das in Homekit implementiert. Daran kann hier wohl keiner etwas ändern.

Mit dieser Aussage möchte ich das Thema hier jetzt zumindest für mich auch beenden. Es sei denn hier bringt sich nochmal jemand anderes ein, der sich damit auskennt. Ich bin auch kein Profi bzw. kein Entwickler, sondern nur ein ambitionierter User.

In diesem Sinne viel Spaß weiterhin!

Viele Grüße Hoppel

[Cluni]

Möglicherweise ist heute Weihnachten. Oder Ostern? Oder beides zusammen?
Stellt Euch vor, Apple, Amazon, Google, die Zigbee Allianz und ein paar weitere tun sich zusammen und machen das Smarthome erwachsen und es gibt offene Standards zum Austausch zwischen den Komponenten.
...

Da finde ich das hier wichtiger für Homebridge selber: https://www.iphone-ticker.de/fuer-den-smart-home-gemeinschaftsstandard-homekit-wird-open-source-151294/#comment-1171638

Mit der Offenlegung vom HomeKit Accessory Development Kit ( siehe https://github.com/apple/HomeKitADK ) wird sich hier noch einiges tun in Bezug auf Homebridge. Ggf. könnte das auch komplett ohne den Umweg über Homebridge direkt in Fhem implementiert werden. Könnte mir vorstellen, dass dadurch weniger Overhead anfallen würde. Könnte nochmal einen extremen Geschwindigkeitsschub bringen...

[justme1968]

der overhead durch alexa-fhem als externen prozess ist minimal. ganz im gegenteil, das meiste in einem asynchronen externen prozess zu haben entlastet fhem. alle sich wiederholenden anfragen werden aus dem cache beantwortet ohne das fhem davon etwas mit bekommt. wenn man sich anschaut wo tatsächlich zeit verloren geht ist das alles was mit kommunikation nach aussen zu tun hat. und selbst die ist in der regel inzwischen schon so gut das nirgends mehr luft für einen 'extremen geschwindigkeitsschub gibt.

aber zurück zu homekit in perl: damals gab es die nötigen verschlüsselungsmethoden noch gar nicht in einer perl version. deshalb habe ich da nicht weiter gemacht. selbst wenn es die inzwischen gibt vermute ich das die node version aufgrund größerer verbreitung stabiler und schneller sind. das gilt auch für homebridge an sich. es ist nicht sinnvoll eine zweite implementierung in perl zu bauen die von einer minderheit genutzt wird statt die energie in die eine implementierung zu stecken die von allen genutzt wird.

viel wichtiger ist das mit der veröffentlichung die raterei bei den eher selten benutzen dingen oder bei Neuerungen weg fällt. vorausgesetzt die relevanten teile sind auch tatsächlich veröffentlicht und werden aktuell gehalten. homekit secure video scheint z.b. gerade nicht teil der veröffentlichung zu sein.

[Cluni]

Gut, ok - das sind natürlich Punkte, wo du wahrscheinlich Recht hast und es besser so bleibt, wie es ist. Der erste Gedanke war halt nur, dass man sich eine Schnittstelle - einen weiteren Teil in einer Kette - sparen könnte. Aber so macht das natürlich Sinn dies nicht zu tun...

viel wichtiger ist das mit der veröffentlichung die raterei bei den eher selten benutzen dingen oder bei Neuerungen weg fällt. vorausgesetzt die relevanten teile sind auch tatsächlich veröffentlicht und werden aktuell gehalten.

Ja, das denke ich auf jeden Fall....

homekit secure video scheint z.b. gerade nicht teil der veröffentlichung zu sein.

Ich denke, dass dies dabei auch so bleiben wird, da es sich dabei um sicherheitsrelevante Daten handelt.

[justme1968]

die sicherheit einer guten implementierung kommt niemals vom geheimhalten einzelner teile sondern nur von einem in sich sicheren konzept und dessen implementierung ohne lücken.

ganz im gegenteil. gute verschlüsselung und sicherheit lebt davon das man alle komponenten ansehen und unabhängig bewerten kann.

wenn hier etwas nicht veröffentlicht wird dann nicht wegen sicherheit sondern weil firmen dir das nutzen wollen dafür bezahlen sollen/müssen.

[Cluni]

Ok, guter Einwand...

Vielleicht kommt's ja noch..

[justme1968]

@sky: ich verstehe das problem nicht ganz.

geräte bei denen reachable auf 0 geht werden bei mir in home mit einem ausrufezeichen angezeigt und lassen sich nicht mehr schnalten. sobald das zugehörige reading in fhem sich änder wird der status in home fast sofort aktualisiert. fast weil der status nicht nach homekit gepushed werde kann sondern homekit ein mal irgend einen wert des gleichen service abfragen muss. das passiert aber direkt wenn man in die app wechselt oder in einem raum.

[hoppel118]

@sky: ich verstehe das problem nicht ganz.

geräte bei denen reachable auf 0 geht werden bei mir in home mit einem ausrufezeichen angezeigt und lassen sich nicht mehr schnalten.

Ich weiß, ich bin nicht Sky...

Was heißt das? Kannst du den EIN-AUS-Schalter von der Characteristic ,,ON" dann noch bedienen oder lässt er sich dann nicht mehr bedienen?

Ich sehe auch das rote Ausrufezeichen, wenn reachable auf 0 geht. Ich kann den Schalter aber immer noch ein- und ausschalten, auch wenn das Gerät gar nicht erreichbar ist. Natürlich ist der Schalter funktionslos, wenn das Gerät nicht mehr erreichbar ist, aber man kann den Schalter halt noch schalten...

Ich hatte Sky so verstanden, dass das sein Problem ist. Er will den Schalter am besten gar nicht mehr bedienen können.

Ich schätze, dass es sich bei dir genauso verhält wie bei mir, da meine Hue Leuchten sich genau so verhalten. Da habe ich kein eigenes homebridgeMapping hinterlegt. Es ist also deins.

Wie verhält sich das bei dir genau?

Gruß Hoppel

[justme1968]

in der home app kann ich nichts mehr bedienen. ich sehe das ausrufezeichen und ein ,gerät antwortet nicht'.

in eve sehe ich ein ausrufezeichen, kann  aber weiter bedienen.

[hoppel118]

Alles klar... Ich verwende in 99% der Fälle EVE wegen einiger custom characteristics.

Aber du hast Recht, habe das gerade mit meiner Stehlampe getestet. In der Home App kann man dann tatsächlich nicht mehr schalten.

Reachable war übrigens innerhalb von einer Minute auf 0. Nach den Tests dann ebenfalls wieder innerhalb von einer Minute auf 1 ohne die Homebridge neustarten zu müssen.

@Sky Evtl. kannst du bei EVE irgendwo einen Verbesserungsvorschlag (Feature Request) äußern. Keine Ahnung, ob die so freundlich sind, da was anzupassen. Es würde ja auch für deren Geräte einen Mehrwert bringen. Ist halt blöd, wenn man kein EVE Gerät hat und dann etwas von denen möchte...

Gruß Hoppel