Apple Homekit: die Hoffnung stirbt zuletzt

[justme1968]

werden beim start für beide devices die gleichen daten ausgegeben?

ja. es müssen beide files gelöscht werden.

[rapster]

Nach was genau soll ich im Log schauen?

[FHEM] dg_wz_fensterantrieb_rechts has motor
[FHEM] dg_wz_fensterantrieb_rechts is dimable [0-100]
[FHEM] dg_wz_fensterantrieb_links has motor
[FHEM] dg_wz_fensterantrieb_links is dimable [0-100]

_links konnte ich grad erfolgreich neu pairen,
_rechts lässt sich jetzt nicht mehr pairen, zuletzt musste ich bei diesem Problem immer komplett das Homekit resetten


Was mir grad auch noch aufgefallen ist:
mi deviceType "switch" und "light" lassen sich die BlindAktor jeweils auf on & off schalten.
wenn ich siri aber sage "schalte fenster 80%" bekomme ich wieder als antwort dass sie keine Geräte gefunden hat.
Hat das hiermit zutun?

Code Auswählen Erweitern



[FHEM] query: dg_wz_fensterantrieb_links-pct
Characteristics.js:valueForUpdate(): invoking callback
Characteristics.js:valueForUpdate(): called, Siri has asked for the accessory's status
Characteristics.js:valueForUpdate(): called, Siri has asked for the accessory's status: returning 1

EDIT: Log ausgabe vom falschen Device gepostet ...

[volschin]

Hallo Andre,
ich habe mit gerade die Seite von Elgato zu EVE angesehen. Gibt es schon Unterstützung für den Air Quality Sensor? So wie ich das sehe, müsste das eigentlich zum CO20-Sensor in FHEM passen.
https://www.elgato.com/de/eve-room

Meine Threestate Sensoren für die Fensterdrehgriffe erkennt er irgendwie nur als Kontaktsensor und sagt bei bei offen "NO". Müsste er die nicht als Window erkennen?

Gruß
Veit

[rapster]

Also habe jetzt die Homekit Datenbank am iPhone resettet, und konnte das Device sofort wieder pairen.
Ganz seltsam, das Problem hatte ich nun schon öfter

Den genericDeviceType der BlinAktoren habe ich jetzt auf 'switch' gesetzt,
on/off funktioniert jetzt sowie
"Schalte Fenster Helligkeit 70%" fährt den Blindaktor nun auf 70%

[justme1968]

@rapster: immer einer geht und der andere nicht? egal mit welchem du anfängst? oder geht immer der gleiche nicht?

@volschin: der air quality service hat je eine characteristic für partikel größe und partikel anzahl. es gibt noch eine characteristik die co anzeigt. aber nur als ja/nein. co2 habe ich noch nicht gesehen. die machen das vermutlich über eine custom characteristic. so etwas kann ich auch einbauen. aber vermutlich nicht kompatibel.

es gibt (zur zeit) keinen sensor mit drei stati in homekit. window (und door) sind jeweils zum automatischen öffnen und schliessen gedacht. die position ist in % angegeben und funktioniert vermutlich nicht one sollwert und motor richtung. also nicht geeignet. von den standard typen bleibt nur contact sensor mit tiltet und open beides auf no abgebildet.

auch hier könnte ich eine custom characteristic verwenden. die ist aber dann nicht über siri abfragbar und vermutlich nur eingeschränkt in den rules verwendbar. ich schaue mal ob es sich lohnt. vielleicht als zusätzlicher wert im normalen contact sensor.

ps: auf den eve screenshots sind öfter plots zu sehen. ich habe keine ahnung wie das funktioniert. vermutlich auch etwas selbst gebautes. ich habe mal spasseshalber mit einer umgekehrten bridge angefangen. also eine mit der homkit fähige hardware an fhem angelernt werden kann. bei der perl version komme ich leider mit der verschlüsselung nicht weiter. siehe oben. wenn jemand eine idee hat...

die node.js version sollte hier kein problem machen. damit könnte man vermutlich  zumindest die custom characteristics mit sniffen wenn jemand die echte hardware von elgato hat.

gruss
  andre

[rapster]

nein das nicht funktionierende pairing hat generell nichts mit dem Device selber zutun,

Das tritt manchmal auch einfach so auf wenn ich mehrere Geräte hintereinander pairen will,

deswegen starte ich nach jedem Pairing den Homebridge server einmal neu, und die App neu und warte erstmal 2 Minuten bevor ich das nächste Gerät paire.

Ganz häufig tritt es allerdings auf wenn ich ein Gerät lösche und dann neu Pairen will, wie gesagt die einzige Lösung die ich bisher hiefür gefunden habe war Homekit zu resetten.

Evtl. ist das aber auch einfach ein Problem vom IOS9 PB2 ?

[volschin]

@volschin: der air quality service hat je eine characteristic für partikel größe und partikel anzahl. es gibt noch eine characteristik die co anzeigt. aber nur als ja/nein. co2 habe ich noch nicht gesehen. die machen das vermutlich über eine custom characteristic. so etwas kann ich auch einbauen. aber vermutlich nicht kompatibel.

Klingt nach viel Aufwand, ist momentan nicht prior.

es gibt (zur zeit) keinen sensor mit drei stati in homekit. window (und door) sind jeweils zum automatischen öffnen und schliessen gedacht.

Dann wäre das die Funktion, die meine Winmatic zum Laufen bringt.  Was muss ich da als devicetype eintragen?

Gruß
Veit

[dev0]

Der Effekt tritt auch mit IOS 8.4 auf. Wenn das einmal passiert, dann habe ich bisher auch keinen anderen Weg gefunden als Homekit zu resetten.

[Andy89]

nein das nicht funktionierende pairing hat generell nichts mit dem Device selber zutun,

Das tritt manchmal auch einfach so auf wenn ich mehrere Geräte hintereinander pairen will,

nutzt du/ihr mehrere iOS Geräte?

ich hatte das Problem auch, aber ich konnte es dann am Ende lösen, indem ich nicht auf dem iPhone(wo ich es standardmäßig mache) gepaired habe, sondern auf dem iPad. Dort wurden die Geräte angezeigt und konnten ganz normal gepaired werden (natürlich nachdem einmal die Daten im persist gelöscht waren). Die Geräte wurden zwar dann auch aufs iPhone syncronisiert, aber der Status war nicht erreichbar. Danach habe ich nochmal auf dem iPhone die Daten gelöscht und neu hinzugefügt und dann ging es auf beiden Geräten( iPhone und iPad). Seitdem läuft es auch problemlos.
Vielleicht hilft dir das

Beste Grüße
Andy

[rapster]

Danke für den Tipp Andy, werde ich nächstes mal probieren bevor ich mir den Stress antue alle Geräte neu zu pairen

[dev0]

Dito

[volschin]

Vll. kanns ja jemand gebrauchen, da ich irgendwo weiter vorne über Probleme mit dem Starten über cron gelesen habe (das Homebridge zu früh gestartet wird).

Ich starte bei mir den Homebridge Server mit forever über folgendes notify (fhem läuft bei mir als root, sonst muss evtl. noch mit sudo gearbeitet werden):

Code Auswählen Erweitern

define ntfy_homebridge notify global:.+ {
if ($EVENT eq "INITIALIZED") {
if(`forever list` =~ /No forever processes running/) {
return `/usr/bin/forever start --spinSleepTime 1000 --minUptime 1000 --no-colors --workingDir /opt/fhem/homebridge -l /opt/fhem/homebridge/log.log -a /opt/fhem/homebridge/app.js`;
}
}
elsif ($EVENT eq "SHUTDOWN") {
if(`forever list` !~ /No forever processes running/) {
return `/usr/bin/forever stopall --no-colors`;
}
}
}

Dadurch sollte immer gewährleistet sein das Fhem beim start der homebridge läuft, und die homebridge ebenfalls bei einem fhem-shutdown beendet wird.

Ebenfalls kann ich so relativ einfach über die Fhem Befehlzeile und einem { `forever restartall --no-colors` } den Homebridge-Server neustarten, oder mir über { `forever list --no-colors` } den Status ausgeben lassen.

Ich würde eher mit

Code Auswählen Erweitern

global:(INITIALIZED|SHUTDOWN)
arbeiten, sonst wird das notify bei jedem Call von global angetriggert. Wobei ich mir momentan nicht im klaren bin, wie häufig das in der Realität passiert.

[justme1968]

@volschin: ist noch nicht eingebaut fang mal damit mir ein list von device zu schicken. am besten jeweils offen und gekippt. und die ausgabe von set <device> ?

gruss
  andre

[rapster]

Ich würde eher mit

Code Auswählen Erweitern

global:(INITIALIZED|SHUTDOWN)
arbeiten, sonst wird das notify bei jedem Call von global angetriggert. Wobei ich mir momentan nicht im klaren bin, wie häufig das in der Realität passiert.

Ja kann man machen,  wirds noch etwas "sauberer", allerdings so viele events hat global ja nicht...
     

Following special events will be generated for the device "global"
    INITIALIZED after initialization is finished.
    REREADCFG after the configuration is reread.
    SAVE before the configuration is saved.
    SHUTDOWN before FHEM is shut down.
    DEFINED <devname> after a device is defined.
    DELETED <devname> after a device was deleted.
    RENAMED <old> <new> after a device was renamed.
    UNDEFINED <defspec> upon reception of a message for an undefined device.


Habs mal in dem Post vorne geändert...

[volschin]

Hier das list für device

Code Auswählen Erweitern

Internals:
   DEF        1E462E
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     68
   NAME       Fenster_L_WinMatic.Schlafen
   NR         354
   NTFY_ORDER 50-Fenster_L_WinMatic.Schlafen
   STATE      unreachable
   TYPE       CUL_HM
   channel_01 Fenster_L_Win.Schlafen
   channel_02 Fenster_L_Akku.Schlafen
   hmusb_MSGCNT 68
   hmusb_RAWMSG REA5B7927,0001,0AA82777,FF,FFCF,2EA0101E462EF11234060295202F
   hmusb_RSSI -49
   hmusb_TIME 2015-08-01 19:42:21
   lastMsg    No:2E - t:10 s:1E462E d:F11234 060295202F
   protEvt_AESerrReject 1 last_at:2015-08-01 09:40:39
   protLastRcv 2015-08-01 19:42:21
   protResnd  2 last_at:2015-08-01 13:41:05
   protSnd    112 last_at:2015-08-01 19:42:21
   protState  CMDs_done
   rssi_at_hmusb avg:-49.07 min:-53 lst:-49 cnt:90 max:-46
   rssi_hmusb min:-51 avg:-47.04 cnt:43 max:-44 lst:-47
   Readings:
     2015-08-01 09:39:54   Activity        alive
     2015-06-28 20:26:33   D-firmware      1.5
     2015-06-28 20:26:33   D-serialNr      JEQ0734999
     2015-07-22 05:31:48   PairedTo        0xF11234
     2015-06-28 20:27:22   R-intKeyVisib   invisib
     2015-06-28 20:27:22   R-keypressSignal on
     2015-06-28 20:27:22   R-pairCentral   0xF11234
     2015-06-28 20:27:22   R-signal        on
     2015-06-28 20:27:22   R-signalTone    low
     2015-07-22 05:31:48   RegL_00:        02:01 03:19 0A:F1 0B:12 0C:34 00:00
     2015-08-01 09:40:38   aesKeyNbr       00
     2015-07-22 05:31:46   powerOn         2015-07-22 05:31:46
     2015-08-01 19:42:25   state           unreachable
   Helper:
     HM_CMDNR   46
     cSnd       01F112341E462E010E,01F112341E462E020E
     mId        0028
     rxType     2
     Io:
       newChn     +1E462E,00,01,00
       nextSend   1438449133.32118
       rxt        0
       vccu       vccu
       p:
         1E462E
         00
         01
         00
       prefIO:
         hmusb
     Mrssi:
       mNo        2E
       Io:
         hmusb      -47
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rpt:
       IO         hmusb
       flg        A
       ts         1438450941.63539
       ack:
         HASH(0x2102378)
         2E8002F112341E462E00
     Rssi:
       At_hmusb:
         avg        -49.0777777777778
         cnt        90
         lst        -49
         max        -46
         min        -53
       Hmusb:
         avg        -47.046511627907
         cnt        43
         lst        -47
         max        -44
         min        -51
Attributes:
   IODev      hmusb
   IOgrp      vccu:hmusb
   actCycle   025:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.5
   model      HM-SEC-WIN
   msgRepeat  1
   room       hidden
   serialNr   JEQ0734999
   subType    winMatic
   webCmd     getConfig:clear msgEvents

Für channel1

Code Auswählen Erweitern

Internals:
   DEF        1E462E01
   NAME       Fenster_L_Win.Schlafen
   NR         356
   NTFY_ORDER 50-Fenster_L_Win.Schlafen
   STATE      locked
   TYPE       CUL_HM
   chanNo     01
   device     Fenster_L_WinMatic.Schlafen
   Readings:
     2015-07-30 18:06:03   CommandAccepted yes
     2015-06-28 20:27:22   R-pullForce     50 %
     2015-06-28 20:27:22   R-pushForce     50 %
     2015-06-28 20:27:22   R-setupDir      left
     2015-06-28 20:27:22   R-tiltMax       255
     2015-07-22 05:31:48   RegL_01:        16:01 1C:64 1D:64 1E:FF 00:00
     2015-08-01 19:42:19   direction       no
     2015-08-01 19:42:19   motorErr        ok
     2015-08-01 19:42:19   recentStateType info
     2015-08-01 19:42:19   state           locked
   Helper:
     Role:
       chn        1
       prs        1
Attributes:
   devStateIcon locked:fts_window_1w
   eventMap   /level lock 0 20:close/level 80 ignore 20:open/level 80 600 20:10min/
   genericDeviceType switch
   group      Fenster
   model      HM-SEC-WIN
   peerIDs    00000000,
   room       Heizung,Schlafen,Sicherheit
   webCmd     close:open:10min:stop

und channel2

Code Auswählen Erweitern

Internals:
   DEF        1E462E02
   NAME       Fenster_L_Akku.Schlafen
   NR         357
   NTFY_ORDER 50-Fenster_L_Akku.Schlafen
   STATE      74.5
   TYPE       CUL_HM
   chanNo     02
   device     Fenster_L_WinMatic.Schlafen
   Readings:
     2015-08-01 19:42:21   charge          dischange
     2015-08-01 19:42:21   recentStateType info
     2015-08-01 19:42:21   state           74.5
   Helper:
     Role:
       chn        1
Attributes:
   group      Akku
   model      HM-SEC-WIN
   room       Sicherheit

Channel 1 ist der interessante zum Schalten, Channel 2 ist nur für den Akkustand.
Das Device drüber ist eigentlich nur zu Verwaltungszwecken. Darüber lässt sich das Fenster nicht steuern.