homebridge/homekit

Begonnen von justme1968, 01 Februar 2016, 16:16:37

Vorheriges Thema - Nächstes Thema

justme1968

der ansatz ist deshalb schon nicht gut da sich das gerät nicht automatisch und sofort mit homekit verbindet. da ist nix mit zeitnah.

und selbst wenn es das täte verbindet es sich davor auf jeden fall erst mal mit deinem wlan. hier anzusetzen ist doch viel besser. sobald das gerät sich z.b. per dhcp eine ip holt. das ginge z.b. so wie es das dash_dhcp für die amazon dash buttons macht.

homebridge plugins wissen übrigens nicht von irgendwelchen connections die auf oder abgebaut werden. homebridge ist auch frei werte zu cachen und garnicht erst beim plugin anzufragen. so ein plugin ist schlicht und einfach der falsche ansatz.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

f-zappa

Zitat von: justme1968 am 19 Juli 2017, 14:43:51
... verbindet es sich davor auf jeden fall erst mal mit deinem wlan. hier anzusetzen ist doch viel besser. sobald das gerät sich z.b. per dhcp eine ip holt. das ginge z.b. so wie es das dash_dhcp für die amazon dash buttons macht.
Beim WLAN-Verbindungsaufbau anzusetzen war auch meine ursprüngliche Idee, aber damit war ich nicht so recht weitergekommen. Auf die Idee, den DHCP-Request auszunutzen, war ich noch nicht gekommen.
Während ich das schreibe, habe ich mir den Source von dash_dhcp gerade einmal durchgelesen. Ich hab mich mit dem Modul nie befasst, weil ich Dashbuttons uninteressant fand, aber im Grunde ist das doch schon die gebrauchsfertige Lösung und ich muss gar nichts mehr selbst programmieren? Statt der MACs von Dashbuttons trage ich halt die von den Handys ein, und schubse mit einem DOIF ein bereits vorhandenes PRESENCE-Device manuell auf "present" um, sobald das passende Event kommt.

DeeSPe

Zitat von: f-zappa am 19 Juli 2017, 15:40:54
Beim WLAN-Verbindungsaufbau anzusetzen war auch meine ursprüngliche Idee, aber damit war ich nicht so recht weitergekommen. Auf die Idee, den DHCP-Request auszunutzen, war ich noch nicht gekommen.
Während ich das schreibe, habe ich mir den Source von dash_dhcp gerade einmal durchgelesen. Ich hab mich mit dem Modul nie befasst, weil ich Dashbuttons uninteressant fand, aber im Grunde ist das doch schon die gebrauchsfertige Lösung und ich muss gar nichts mehr selbst programmieren? Statt der MACs von Dashbuttons trage ich halt die von den Handys ein, und schubse mit einem DOIF ein bereits vorhandenes PRESENCE-Device manuell auf "present" um, sobald das passende Event kommt.

Und was tust Du dagegen dass Dein Handy sein WLAN schlafen legt?
Da es für dieses Problem keine Lösung gibt, halte ich PRESENCE anhand von Handy per WLAN ungünstig!
Wie lange willst Du auf das "absent" warten nachdem Du gegangen bist? Das dauert m.E. ein Weilchen...

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

justme1968

hier ging es ja vor allem um das schnelle erkennen wenn das handy in reichweite kommt. und das geht damit auf jeden fall. wie gut das abmelden bei einer dhcp basierten version geht weiss ich nicht. man könnte aber z.b. die lease time auf 10 minuten setzen.

ich mache die erkennung über den unifi controller und der meldet die wlan geräte absolut zuverlässig ab wenn die geräte 15 minuten nicht mehr in reichweite waren. klappt mit jedem handy. basiert aber halt auf dem wissen des controllers der auch infos zum sleep mode hat. an die kommt man rein auf netzwerk ebene nicht ran. nur wenn man den funk mit schneiden würde. vorher hatte ich wlan über airport base stations und da hat es per snmp ebenfalls wunderbar funktioniert.

die 15 minuten haben sich übrigens auch als sehr praktikabler zeitraum herausgestellt.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

f-zappa

Zitat von: justme1968 am 19 Juli 2017, 17:27:09
hier ging es ja vor allem um das schnelle erkennen wenn das handy in reichweite kommt. und das geht damit auf jeden fall.
Genau. Den tatsächliche Presence-Status einer Person steuert bei mir ein inzwischen recht längliches DOIF, was auf unterschiedlichste Trigger reagiert. Einer davon ist jetzt, wenn ein Handy einen DHCP-Lease verlangt (und das triggert tatsächlich nur "present", für "absent" gibt es bessere Kriterien als ein nicht rechtzeitig erneuerter DHCP-Lease).

Andi35

Hallo.
Noch mal ne dumme Frage. Ich blicke beim Homebridgemapping im Moment noch garnicht durch. Irgendwie fehlt da noch der zündende Funken.
Deshalb die Bitte an die Experten hier, wer kann mir eine Codezeile erstellen für folgende Situation.

Die Abfrage des Status eines Fensterkontaktes von MAX bringt immer nur die Aussage "Fenster ist geschlossen" auch wenn das Fenster auf ist.

Das DEVICE in FHEM nennt sich "MAX_073eff", DEF ist "ShutterContact 073eff", Alias ist "Fenster"
Die gelieferten Werte aus dem internals STATE sind "closed" und "opened"
Benötigte Werte (soweit ich das verstanden habe) für die richtige Aussage von Alexa sind "closed" und "open"

Das bedeutet also, ich muss eigentlich nur den Wert "opened" nach "open" umbiegen. Aber wie?

Danke schon mal.

CarstenF

Hallo, Eigentlich benötigst Du für Max Komponenten kein Homebridge Mapping. Hast Du das attr genericDeviceType  "shutterContact" gesetzt?


Gesendet von iPad mit Tapatalk
Raspberry Pi4
CUL 868, CUL 433, LaCrosse Gateway, Zigbeetomqtt2, HUE, Homematic
Max-Cube umgeflasht
MAX!, FhemtoFhem, Homebridge, FhemConnector, IR_Gateway und sonst auch noch allerlei Spielzeug....

Andi35

Danke für die Antwort. Ja, genericDevieType ist auf shutterContac gesetzt.


Internals:
   DEF        ShutterContact 073eff
   IODev      ml
   LASTInputDev ml
   MSGCNT     6
   NAME       MAX_073eff
   NR         57
   STATE      opened
   TYPE       MAX
   addr       073eff
   backend    ml
   ml_MSGCNT  6
   ml_TIME    2017-07-23 13:33:32
   rferror    0
   serial     KEQ0190418
   type       ShutterContact
   READINGS:
     2017-07-23 13:33:32   MAXLAN_error    0
     2017-07-23 13:33:32   MAXLAN_errorInCommand
     2017-07-23 13:33:32   MAXLAN_initialized 1
     2017-07-23 13:33:32   MAXLAN_isAnswer 0
     2017-07-23 13:33:32   MAXLAN_valid    1
     2017-07-23 13:33:32   battery         ok
     2017-07-23 13:30:31   firmware        1.4
     2017-07-23 13:30:31   groupid         1
     2017-07-23 13:33:32   onoff           1
     2017-07-23 13:33:32   state           opened
     2017-07-23 13:30:31   testresult      15
   internals:
     interfaces switch_active;battery
Attributes:
   IODev      ml
   alexaName  Fenster
   alexaRoom  Wohnzimmer
   alias      Fenster
   genericDeviceType shutterContact
   room       MAX,Wohnzimmer,alexa

CarstenF

Ach ich sehe gerade, Du machst das mit Alexa und nicht mit Siri/Eve . Ich vermute das es daran liegen könnte. Bin leider im Homebridgemapping auch nicht so richtig firm. Schonmal gegoogelt?


Gesendet von iPad mit Tapatalk
Raspberry Pi4
CUL 868, CUL 433, LaCrosse Gateway, Zigbeetomqtt2, HUE, Homematic
Max-Cube umgeflasht
MAX!, FhemtoFhem, Homebridge, FhemConnector, IR_Gateway und sonst auch noch allerlei Spielzeug....

CarstenF

Im wiki für homebridge gibt es ein mapping für EnOcean Fensterkontakte. Vielleicht kannst Du die auf die Values und States von Max umschreiben.


Gesendet von iPad mit Tapatalk
Raspberry Pi4
CUL 868, CUL 433, LaCrosse Gateway, Zigbeetomqtt2, HUE, Homematic
Max-Cube umgeflasht
MAX!, FhemtoFhem, Homebridge, FhemConnector, IR_Gateway und sonst auch noch allerlei Spielzeug....

Andi35

Sorry, bin wohl bei 1000 geöffneten Forumfenstern im falschen gelandet.

Nach dem Wiki habe ich es auch schon versucht.
Das Beispiel im wiki sieht ja so aus:

attr STM250 genericDeviceType ContactSensor
attr STM250 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;open:CONTACT_NOT_DETECTED

Ich habe es entsprechend geändert in:

attr MAX_073eff genericDeviceType ContactSensor
attr MAX_073eff homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;opened:CONTACT_NOT_DETECTED

Hat allerdings nicht funktioniert. Deshalb sagte ich ja, Ich blicke da noch nicht durch  :-\

CarstenF

Also das Mapping sieht so nicht gut aus glaube ich.Aber wie gesagt ich kann Dir da auch nicht so richtig gut helfen. Vielleicht liest noch jemand mit. Insbesondere in Sachen Alexa weiß ich nicht so genau, ob man da auch die gleichen Einstellungen haben muß, wie bei Homebridge und Siri. Sorry.


Gesendet von iPad mit Tapatalk
Raspberry Pi4
CUL 868, CUL 433, LaCrosse Gateway, Zigbeetomqtt2, HUE, Homematic
Max-Cube umgeflasht
MAX!, FhemtoFhem, Homebridge, FhemConnector, IR_Gateway und sonst auch noch allerlei Spielzeug....

Andi35

Kein Problem, trotzdem Danke für Deine Antwort. Ich werde die gleiche Frage mal im passenden Alexa Thread stellen.

Skjall

Moin zusammen,

ich habe ein Problem mit meinem NUKI Schloss in Homebridge:

Das schloss läuft gut in Homebridge, wenn ich die Home App von Apple verwende. Dort versucht die App beim Schalten die Zustände 0 (öffnen) und 1 (schließen) zu setzen. Ich Interpretiere diese mit unlatch und lock. Alles gut.

Jul 24 22:14:47 SRV-100-021 homebridge[16792]: [2017-07-24 22:14:47] [FHEM] 21301.DoorLock.1: executing set cmd for LockTargetState with value 1
Jul 24 22:14:47 SRV-100-021 homebridge[16792]: [2017-07-24 22:14:47] [FHEM]   executing: http://127.0.0.1:8083/fhem?cmd=set%2021301.DoorLock.1%20unlatch&XHR=1


Interessant wird es bei Siri: Die verwendet nicht 1 und 0 sondern true und false.
Jetzt dachte ich mir ich setze die Kommandos dafür auch noch, aber das klappt leider nicht.

attr 21301.DoorLock.1 homebridgeMapping LockCurrentState=lockState,values=lock:SECURED;unlock:UNSECURED;unlatch:UNSECURED LockTargetState=lockState,cmds=1:lock;0:unlatch;true=lock;false=unlatch

Jul 24 22:16:17 SRV-100-021 homebridge[16849]: [2017-07-24 22:16:17] [FHEM] 21301.DoorLock.1: executing set cmd for LockTargetState with value true
Jul 24 22:16:17 SRV-100-021 homebridge[16849]: [2017-07-24 22:16:17] [FHEM]   executing: http://127.0.0.1:8083/fhem?cmd=set%2021301.DoorLock.1%20undefined%20true&XHR=1


Kann man das durch ein Mapping abfangen oder ist das ein Modulproblem?

├─┬ homebridge@0.4.20
├─┬ homebridge-fhem@0.3.7
├─┬ homebridge-homematic@0.0.72
├─┬ homebridge-lightify@0.0.10
├─┬ homebridge-server@1.0.24
│ └─┬ homebridge@0.4.19


Vielen Dank im Voraus

Jan

justme1968

du musst : verwenden. keine =
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968