homebridge/homekit

[ducdarky]

Ok, ich verstehe. Dann hatte ich zumindest keinen Denkfehler. Das heisst dann, dann das schöne Beispiel bei Apple, der Garagentoröffner, der als zweiten Service "Licht" hat, hier auch nur über zwei Geräte funktioniert. Das schöne an den Geräte-Services ist, dass ich z.B. Siri fragen kann, ob der Saugroboter voll aufgeladen ist. Das geht im Moment nicht.

Als Idee würde mir da sowas einfallen:

Code Auswählen Erweitern


homebridgeMapping clear On=status,cmdOn=start,cmdOff=off,nocache=1 BatteryLevel=batPct,serviceType=BatteryService ChargingState=cleanMissionStatus-phase,values=/(charge)$/:CHARGING;/^.*/:NOT_CHARGING,serviceType=BatteryService

Dann könnte man einen Service angeben, wenn man nicht den aus dem genericDeviceType nutzen möchte für einen bestimmten Wert. Wenn man nichts angibt, wird der Default-Service genommen.

Die Möglichkeiten und Flexibilität, die homebridge fhem schon heute bietet, ist aber auch so Spitze. Großes Kompliment! 

[kalleknx]

Hallo zusammen,

die Zeit zw. Weihnachten und Neujahr bietet sich ja quasi an, sich an die Themen zu setzen, die schon seit längerem geschoben wurden Bei mir heisst das konkret: homebridge. Ich hatte schon vor längerer Zeit das Paket installiert, dann aber nicht mehr weiter verfolgt. Mittlerweile hat sich einiges getan und ich bin beeindruckt. Trotzdem habe ich noch ein paar Fragen:

1. wie bekomme ich die dropdown values von genericDeviceType erweitert? Bei mir fehlen einige Werte (z.B. speaker). Manuelles setzen geht, von daher nice to have.
2. kann man sehen, welche Konfiguration der einzelnen devices vom modul automatisch erzeugt wurde? Konkret: Devie vom Type MPD erscheint in der Homekit APP Home/EVE anders, als wenn ich ein dummy dort bekannt machen (inkl. genericDeviceType speaker).
3. Ist es möglich bei devices vom typ MPD und devicetype speaker bei aktionen wie play/stop anstelle MPD Play/Stop auf das Schalten von anderen dummies zu aktivieren?
4. Ich habe ein dummy device für devicetype thermostat. ISt bzw. Soll Temp will ich aus anderen Devices auslesen. Mein homebridgeMapping funktionert nicht:

Code Auswählen Erweitern


TargetTemperature=KNX_0001012:state,minValue=18,maxValue=25,minStep=0.2,nocache=0 CurrentTemperature=KNX_0001014,nocache=0


Auslesen der Werte aus dem gl. device funktioniert.

danke
kalle

[justme1968]

@ducdarky: ich habe mal eine version gebaut bei der man im homebridgeMapping die characteristic namen mit einem davor gestellten <service_name># ergänzen kann. also z.b. so:

Code Auswählen Erweitern

attr <name> homebridgeMapping BatteryLevel=clear StatusLowBattery=clear ChargingState=clear BatteryService#BatteryLevel=battery BatteryService#StatusLowBattery=battery,threshold=20,values=0:BATTERY_LEVEL_LOW;;1:BATTERY_LEVEL_NORMAL BatteryService#ChargingState=charging

die clear sind nur nötig um die automatisch angelegten defaults zu löschen falls die readings zufällig passen. bei denen readings brauchst du die vermutlich nicht.

ich kann aber in home keine änderungen sehen. die battery characteristics werden bei einem switch trotzdem nicht mit angezeigt.

in eve wird unverändert immer noch alles angezeigt.

das apple ein schönes beispiel mit zwei service typen in einem gerät hat heisst nicht das home etwas damit anfangen kann . ich denke die einschränkung liegt eher auf home seite. dort wird vieles was nicht 'standart' ist nicht angezeigt. es fängt ja schon bei den nachkomma stellen der temperatur an.

ich habe mit einer sehr alten homebridge version getestet. du kannst ja mal schauen ob es mit einer aktuellen version anders ist.

edit 2017-12-29: diese version ist inzwischen eingecheckt.

@kalleknx:
1. natürlich geht manuelles setzen. einfach in die command box oben auf der webseite oder per telnet:

Code Auswählen Erweitern

attr <name> genericDeviceType <xyz>

2. homebridge mit --debug starten. dann siechst du die defaults die erzeugt werden.

3. man kann die schalter in den jeweiligen apps nicht konfigurieren.

4. du hast bei der CurrentTemperature das reading nicht mit angegeben.

ansonsten: dreh es um. nimm das device bei dem die temperatur eingestellt wird um es einzubinden und hole dir dort per homebridge mapping die current temperature hinzu.

[TWART016]

Hallo,

seit heute habe ich folgendes Problem:
Nach einem Servernneustart werden bei mir in der Home App keine Geräte mehr angezeigt.
sudo service homebridge status ergibt das

Code Auswählen Erweitern

tim@FHEM:~$ sudo service homebridge status
[sudo] Passwort für tim:
● homebridge.service - LSB: Start daemon at boot time for homebridge
   Loaded: loaded (/etc/init.d/homebridge; bad; vendor preset: enabled)
   Active: active (exited) since Fr 2017-12-29 01:22:58 CET; 32s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1057 ExecStart=/etc/init.d/homebridge start (code=exited, status=0/SUCCESS)

Dez 29 01:22:56 FHEM systemd[1]: Starting LSB: Start daemon at boot time for homebridge...
Dez 29 01:22:56 FHEM su[1112]: Successful su for tim by root
Dez 29 01:22:56 FHEM su[1112]: + ??? root:tim
Dez 29 01:22:56 FHEM su[1112]: pam_unix(su:session): session opened for user tim by (uid=0)
Dez 29 01:22:56 FHEM homebridge[1057]: Homebridge starting
Dez 29 01:22:58 FHEM homebridge[1057]: Homebridge is running PID 1179
Dez 29 01:22:58 FHEM systemd[1]: Started LSB: Start daemon at boot time for homebridge.

stoppe ich den Dienst und starte ich mit "homebridge" werden die Geräte wieder normal angezeigt. Genauso wie bei service homebridge restart (oder stop+start)

Anschließend sieht die Statusabfrage gleich aus.

Code Auswählen Erweitern

tim@FHEM:~$ sudo service homebridge status
● homebridge.service - LSB: Start daemon at boot time for homebridge
   Loaded: loaded (/etc/init.d/homebridge; bad; vendor preset: enabled)
   Active: active (exited) since Fr 2017-12-29 01:23:54 CET; 4s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1647 ExecStop=/etc/init.d/homebridge stop (code=exited, status=0/SUCCESS)
  Process: 1686 ExecStart=/etc/init.d/homebridge start (code=exited, status=0/SUCCESS)
    Tasks: 0
   Memory: 0B
      CPU: 0

Dez 29 01:23:52 FHEM systemd[1]: Starting LSB: Start daemon at boot time for homebridge...
Dez 29 01:23:52 FHEM su[1690]: Successful su for tim by root
Dez 29 01:23:52 FHEM su[1690]: + ??? root:tim
Dez 29 01:23:52 FHEM su[1690]: pam_unix(su:session): session opened for user tim by (uid=0)
Dez 29 01:23:52 FHEM homebridge[1686]: Homebridge starting
Dez 29 01:23:54 FHEM homebridge[1686]: Homebridge is running PID 1694
Dez 29 01:23:54 FHEM systemd[1]: Started LSB: Start daemon at boot time for homebridge.

Gestartet wird der Dienst bei Systemstart mit dem Skript aus dem Wiki. Hat jetzt auch über 1 Jahr ohne Probleme funktioniert. Sieht für mich aus, dass es daran liegt.

[volschin]

Also erstmal möchte ich feststellen, dass Du ein systemd fähiges System hast. Schmeiß das alte init-Script weg und richte ein richtiges homebridge.service Script ein.

[Motivierte linke Hände]

Also erstmal möchte ich feststellen, dass Du ein systemd fähiges System hast. Schmeiß das alte init-Script weg und richte ein richtiges homebridge.service Script ein.

Das dürfte mit dem auftretenden Problem nichts zu tun haben. Ich hatte ähnliche Probleme, weil die Broadcasts hier im Netz nicht überallhin geroutet wurden. Da lief es auch nur kurze Zeit nach Starten der Homebridge und dann - ohne Fehlermeldung im Status oder sonstwo - nicht mehr. Von daher könnte beim Frager auch gut irgendeine andere Änderung in der Netzwerkinfrastruktur (Settings/Firmware bei Switches/Routern/Access Points, neue Geräte, etc.) zu diesem Problem geführt haben.

Abgesehen davon: Wenn Du ein systemd Skript hast, stelle es doch gerne ins Wiki (oder hierhin und ich kopiere es ins Wiki). Aktuell betreibe ich Homebridge (ohne diese Probleme, nachdem ich die Netzwerkinfrastruktur glatt gezogen haben) auch mit Init-Skript auf einem systemd-System.

Grüße, Christian

[volschin]

Die Infos werden durch Kopieren von einem Wiki ins andere sicher nicht besser. Hier der Link aufs Homebridge Wiki https://github.com/nfarina/homebridge/wiki/Running-HomeBridge-on-a-Raspberry-Pi
Dort unter systemd
Häufiges Problem ist, dass Homebridge gestartet wird, bevor das Netz vollständig online ist. Das Script verhindert das.

[Motivierte linke Hände]

Es geht ja nicht darum, die Infos durch Kopieren zu verbessern, sondern sie (überhaupt/einfacher) auffindbar zu machen. Ich habe daher Deinen Link mal mit einem entsprechenden Hinweis ins Wiki eingetragen.

[ducdarky]

@justme1968: Du bist der Größte!  Es läuft super mit Deiner Anpassung. Sowohl in der HomeApp als auch in Eve werden jetzt zwei Services angezeigt. Die HomeApp zeigt es unter Status an, Eve hat jetzt einen Service für "Strom" und einen für "Batterie" angezeigt. Meine Homebrigde-Version ist 0.4.33.
Allerings erhalte ich bei Starten der Homebridge die Meldung, dass ChargingState und StatusBatteryLow "not a number" sind, wenn ich sie auf :CHARGING/:NOT_CHARGING bzw. BATTERY_LEVEL_LOW/BATTERY_LEVEL_NORMAL mappe. Mach ich das einfach mit 0 und 1 funktioniert es. 
Kann ich damit die Default-Angaben für manufacturer, model und serial number auch überschreiben? Das habe ich noch nicht hinbekommen. Muss ich da information oder AccesoryInformation als Service angeben oder ist es nicht möglich?
Ich werde nachher noch mit anderes Devices testen, aber bisher läuft alles top!
Vielen Dank.

Grüße
Steffen

[justme1968]

die meldung ist mir gestern auch aufgefallen. ich weiss noch nicht warum die kommt. einfach ignorieren. es sollte trotzdem alles gehen.

interessant finde ich das es scheinbar von der homebridge version abhängt ob es funktioniert. bei meiner alten version macht es wie gesagt keinen unterschied. kannst du mal bitte zwei screenshots anhängen. ich bin neugierig wie das ausschaut.

die angaben zum gerät lassen sich aktuell nicht überschreiben. die werden automatisch aus den internals der fhem devices zusammen gebaut. ist es wirklich wichtig hier etwas zu überschreiben?

[volschin]

die angaben zum gerät lassen sich aktuell nicht überschreiben. die werden automatisch aus den internals der fhem devices zusammen gebaut. ist es wirklich wichtig hier etwas zu überschreiben?

Leider sind Firmware und Serial momentan sehr starr implementiert, spielen aber bei Apple eine größer werdende Rolle. Sie sollten adäquat gefüllt werden können, auch aus den INTERNALS.

[justme1968]

die frage war weniger wie wichtig die felder sind, sondern wie wichtig es ist das der anwender etwas überschreiben kann. ich fürchte das man hier ziemlich schnell etwas kaputt machen kann wenn serials oder id nicht mehr stimmen so das es besser ist alles automatisch zu erzeugen. und wenn etwas fehlt besser hier nachzubessern.

ich möchte z.b. eindeutige ids für geräte die keine serien nummer oder ähnliches haben automatisch erzeugen und auf der fhem seite persistent speichern. für alexa sind die ja auch wichtig.

[chseeliger]

Hallo Andre,

ich kämpfe gerade mit Homebridge und meinen Rolladenaktoren (HM-LC-BL1-FM), die ich offensichtlich verdreht angeschlossen habe. Da die Aktoren im Rolladenkasten verbaut sind und ich da nicht ohne weiteres drankomme, habe ich sie in FHEM mit levelInverse umgedreht, was in FHEM soweit auch passt. In Homekit werden sie mir aber nun falsch herum angezeigt (offen=geschlossen), wenn ich sie ohne homebridgeMapping und als genericDevice blind anlege. Wenn ich es richtig gelesen habe, wird "invert=1" in der Homebridge automatisch gesetzt, wenn levelInverse im device gesetzt ist, richtig? Das würde ich gerne verhindern. Kann ich im homebridgeMapping nur invert=0 setzen, ohne gleich alle mappings zu überschreiben? Also so was in dieser Art

Code Auswählen Erweitern

attr rollo homebridgeMapping CurrentPosition=,invert=0 TargetPosition=,invert=0

Viele Grüße
Christoph

[justme1968]

probier es und schau was beim start ausgegeben wird.

auf dauer wirst du aber vermutlich nicht glücklich mit den falsch angeschlossen autoren weil dann zwar die prozentangaben per siri funktionieren aber auf und zu nicht.

[chseeliger]

Danke für die schnelle Antwort! Kann ich das mit auf/zu nicht zusätzlich über Setzen von cmds umdrehen? Wenn es überhaupt nötig ist, denn ich habe den Eindruck, dass durch das automatisch gesetzte invert auch auf/zu vertauscht wurde.

Aber ich probiere es bei nächster Gelegenheit mal aus...