homebridge/homekit

[Markus M.]

Gibt's schon was neues zum BatteryService?
Wäre es möglich den bei Bedarf je Device automatisch zu definieren, wenn die jeweiligen Characteristics definiert werden?

[justme1968]

aktuell geht das nur von hand im homebridgeMapping.

ich habe noch ein internes problem das durcheinander erzeugt wenn ich mehrere services automatisch anlege.

ist aber in arbeit.

[Markus M.]

aktuell geht das nur von hand im homebridgeMapping.

Gibt's dafür irgendwo ein Beispiel?

Das Characteristic StatusLowBattery geht eigentlich fast immer im Service.
BatteryLevel und ChargingState tauchen aber meist nur auf, wenn sie im extra BatteryService stecken.

[Typ1er]

Ich habe hier mal 3 Beispiele:

Aqara Motion:

Code Auswählen Erweitern

Internals:
   DEF        158d0002b5f12e sensor_motion.aq2 MiGateway_Flur
   FUUID      5c44a1c8-f33f-06ea-b5ba-b57b1c87c3ec12dd
   IODev      MiGateway_Flur
   LASTInputDev MiGateway_Flur
   MODEL      sensor_motion.aq2
   MSGCNT     2381
   MiGateway_Flur_MSGCNT 2381
   MiGateway_Flur_TIME 2019-02-17 21:10:30
   NAME       XMI_158d0002b5f12e
   NR         234
   SID        158d0002b5f12e
   STATE      motion
   TYPE       XiaomiSmartHome_Device
   VERSION    1.30
   READINGS:
     2019-02-17 14:32:10   batteryState    ok
     2019-02-17 14:32:10   batteryVoltage  3.035
     2019-02-17 14:32:10   heartbeat       158d0002b5f12e
     2019-02-17 21:10:30   lux             48
     2019-02-16 19:26:25   motionOffTimer  10
     2019-02-17 21:10:30   no_motion       0
     2019-02-17 21:10:30   state           motion
Attributes:
   alias      Motion 2
   devStateIcon motion:motion_detector@red off:motion_detector@green no_motion:motion_detector@green
   genericDeviceType MotionSensor
   homebridgeMapping MotionDetected=state,values=off:0;motion:1
StatusLowBattery=batteryState,values=ok:BATTERY_LEVEL_NORMAL;/^.*/:BATTERY_LEVEL_LOW
E863F10A-079E-48FF-8F27-9C2605A29F52=batteryVoltage,factor=1000,name=Voltage,format=FLOAT
0000006B-0000-1000-8000-0026BB765291:lux,name=BRIGHTNESS,format=FLOAT,unit=LUX,maxValue=10000,minValue=0,minStep=.0001
history:size=1024
   rnd_bat    3
   room       Homekit,XiaomiMiSmartHome

Aqara KontaktSensor:

Code Auswählen Erweitern

Internals:
   CHANGED   
   DEF        158d00022bd6e4 sensor_magnet.aq2 MiGateway_Flur
   FUUID      5c44a1c6-f33f-06ea-74b5-f247d0fc5fb758a4
   IODev      MiGateway_Flur
   LASTInputDev MiGateway_Flur
   MODEL      sensor_magnet.aq2
   MSGCNT     164
   MiGateway_Flur_MSGCNT 164
   MiGateway_Flur_TIME 2019-02-17 21:12:42
   NAME       DOOR_Schlafzimmer
   NR         164
   SID        158d00022bd6e4
   STATE      open
   TYPE       XiaomiSmartHome_Device
   VERSION    1.30
   READINGS:
     2019-02-17 21:05:46   batteryState    ok
     2019-02-17 21:05:46   batteryVoltage  3.055
     2019-02-17 21:05:46   heartbeat       158d00022bd6e4
     2019-02-17 21:05:46   no_close        0
     2019-02-17 21:12:42   state           open
     2019-02-17 21:12:42   status          open
Attributes:
   devStateIcon open:fts_door_right_open@red close:fts_door_right@green
   event-on-change-reading state
   genericDeviceType ContactSensor
   homebridgeMapping ContactSensorState=state,values=close:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED CurrentDoorState=state,values=close:CLOSED;;open:OPEN
StatusLowBattery=batteryState,values=ok:BATTERY_LEVEL_NORMAL;/^.*/:BATTERY_LEVEL_LOW
E863F10A-079E-48FF-8F27-9C2605A29F52=batteryVoltage,factor=1000,name=Voltage,format=FLOAT
history:size=1024
   icon       fts_door_right_open
   rnd_bat    3
   room       Homekit,Schlafzimmer,XiaomiMiSmartHome
   siriName   Zimmertür
   userReadings status {ReadingsVal($name,"state","")}

Aqara TemperaturSensor:

Code Auswählen Erweitern

Internals:
   DEF        158d0001ab75e1 weather.v1 MiGateway_Flur
   FUUID      5c44a1c6-f33f-06ea-3a89-69554d8d2ea1c60d
   IODev      MiGateway_Flur
   LASTInputDev MiGateway_Flur
   MODEL      weather.v1
   MSGCNT     507
   MiGateway_Flur_MSGCNT 507
   MiGateway_Flur_TIME 2019-02-17 21:11:55
   NAME       XMI_158d0001ab75e1
   NR         148
   SID        158d0001ab75e1
   STATE      Temperatur: <b>6.2 °C </b>
Luftfeuchte: <b>75 % </b><br>
Luftdruck: <b>1014 hPa</b>
Batterie: <b>ok ( 2.915 V )</b><br>
Taupunkt: <b>2.1 °C </b>
Absulute Feuchte: <b>5.5 g/m³ </b>
   TYPE       XiaomiSmartHome_Device
   VERSION    1.30
   READINGS:
     2019-02-17 21:11:55   absFeuchte      5.5
     2019-02-17 21:11:55   airpressure     1014.2
     2019-02-17 20:46:03   batteryState    ok
     2019-02-17 20:46:03   batteryVoltage  2.915
     2019-02-17 21:11:55   dewpoint        2.1
     2019-02-17 20:46:03   heartbeat       158d0001ab75e1
     2019-02-17 21:11:55   humidity        75.180
     2019-02-17 21:11:55   pressure        101.070
     2019-02-17 21:11:55   temperature     6.210
Attributes:
   alias      Eingang
   genericDeviceType TemperatureSensor
   homebridgeMapping CurrentTemperature=temperature
CurrentRelativeHumidity=humidity
E863F10F-079E-48FF-8F27-9C2605A29F52=airpressure,format=FLOAT
StatusLowBattery=batteryState,values=ok:BATTERY_LEVEL_NORMAL;/^.*/:BATTERY_LEVEL_LOW
E863F10A-079E-48FF-8F27-9C2605A29F52=batteryVoltage,factor=1000,name=Voltage,format=FLOAT
history:size=1024
   icon       temp_temperature
   rnd_bat    3
   rnd_hum    3
   rnd_pres   3
   rnd_tmp    3
   room       Draußen,Homekit,Wetter,XiaomiMiSmartHome
   siriName   Eingang
   stateFormat Temperatur: <b>[$name:temperature:r1] °C </b>
Luftfeuchte: <b>[$name:humidity:r0] % </b><br>
Luftdruck: <b>[$name:airpressure:r0] hPa</b>
Batterie: <b>[$name:batteryState] ( [$name:batteryVoltage:r3] V )</b><br>
Taupunkt: <b>[$name:dewpoint:r1] °C </b>
Absulute Feuchte: <b>[$name:absFeuchte:r1] g/m³ </b>
   userReadings airpressure {sprintf("%.1f",ReadingsVal($name,"pressure",0)*10.035)}

[Markus M.]

Ich habe hier mal 3 Beispiele

Die Eve Characteristics waren nicht was ich meinte.
Ich meinte die Characteristics für Batteriestand und Ladezustand, die direkt im Device in der Apple Home App zu sehen sind.
Aber bei den meisten Geräten eben nur, wenn sie in einem extra Service (BatteryService) stecken.

[justme1968]

das sind keine eve characteristics sondern die normalen standard homekit characteristics.

wenn du es so im homebridgeMapping angibst wird es auch in der home app angezeigt.

das problem ist: automatisch werden die batterie characteristics aktuell beim haupt service hinzugefügt. die home app zeigt sie aber dann nicht an. warnungen kommen übrigens trozdem.

eve zeigt sie auch an.

automatisch in einen extra BatteryService stecken geht erst demnächst.

wenn du sie sie wie oben vorgeschlagen von hand im homebridgeMapping angibst landen sie auch jetzt schon im BatterieService und auch die home app zeigt sie in den details an.

[Markus M.]

wenn du sie sie wie oben vorgeschlagen von hand im homebridgeMapping angibst landen sie auch jetzt schon im BatterieService und auch die home app zeigt sie in den details an.

Funktioniert bei mir nur bei StatusLowBattery (das nur bei Low angezeigt wird), nicht aber mit BatteryLevel.
Weil es eben nicht im extra Service zu landen scheint.

blind bekommt so keine Anzeige:

Code Auswählen Erweitern

CurrentPosition=position,minStep=10,default=100
TargetPosition=position,cmd=position,minStep=10,delay=1000
PositionState=state,values=drive-up:INCREASING;drive-down:DECREASING,default=STOPPED
BatteryLevel=batteryPercent,default=0,minValue=0,maxValue=100,minStep=1
StatusLowBattery=batteryState,values=ok:0,default=1

Lustigerweise werden Dinge wie FilterChangeIndication oder OzoneDensity in fast allen Services angezeigt.

[justme1968]

du muss den service ja auch mit
angeben damit es in einem extra service landet.

<service name>#<characteristic>:...

also BatteryService#BatteryLevel:batteryPercent,...

[Markus M.]

du muss den service ja auch mit
angeben damit es in einem extra service landet.
<service name>#<characteristic>:...

Ahh jetzt!
Danke, funktioniert wie gewünscht.
Automatik ist damit eigentlich auch nicht mehr nötig.

[Matze89]

Hallo an euch,

kurze und sehr knappe Frage:
Kann man auch den Befehl ,,Keine Antwort" in rot in einem Device (Lampe) definieren?

Anwendung: Ich habe einige Lampen, die häufig mit einem Schalter an der Wand zuvor abgeschaltet werden und als ,,unreachable" in Fhem durch den Hue-Hub als State-Meldung bekommt. Somit erkennt man in HomeKit nicht, ob die Lampe noch mit Strom versorgt wird. Besteht hierbei die Möglichkeit einer ,,emulierten" Kennzeichnung?

Gruß Matthias

[justme1968]

das muss ich erst wieder einbauen. apple hat hier an den unterstützen characteristics etwas geändert.

ich schaue es mir an.

[hoppel118]

Daran hätte ich auch Interesse. Bei uns gibt es auch zwei Lampen, die meine Frau manchmal ,,hart ausschaltet".

Besteht evtl. die Möglichkeit, dass du irgendwas einbaust, damit bei den HueGroups die letzte genutzte Lichtfarbe nach einem Neustart der Homebridge angezeigt wird. Bei mir sind die Farbkästchen in Eve danach immer rot, siehe Screenshot. In den Release Notes des letzten Updates der Philips Hue App stand, dass nun die letzte Farbe bei einem Stromausfall gespeichert wird. Keine Ahnung, ob dich das in dieser Hinsicht irgendwie weiter bringt... Das wäre genial.

Oder gibt es dafür bereits irgendeine andere Möglichkeit?

Viele Grüße Hoppel

[justme1968]

ich habe eben die version 0.5.1 veröffentlicht.

dort wird das reachble reading ausgewertet. achtung: der status wird nur an homekit übertragen wenn werte aus dem device abgefragt werden. es gibt keine möglichkeit den status aktiv zu pushen. die früher dafür vorgesehene Reachble characteristic hat apple scheinbar gestrichen.


zu den gruppen:
- ist der status in fhem denn richtig? hast du createGroupReadings passend gesetzt?
- das mit dem stromausfall: das ist eine eigenschaft der lampen bzw. der firmware version und kann über die hue app für jede lampe einzeln aktiviert werden.

nachschauen kannst du über das modul mit get <name> startup.

[Loredo]

Hi André,


eine Frage zur Versionierung: Mir ist aufgefallen, dass das aktuelle Update von 0.4.x auf 0.5.x nicht als "Latest" und "Wanted" Paket aufgeführt wird, sondern nur als "Wanted". Für ein Upgrade muss man daher wohl "npm install" anstatt "npm update" verwenden. Ich bin nicht sicher, ob ich das richtig verstehe, aber so wie es hier beschrieben ist, ist das wohl der Unterschied zwischen "strict" und "non-strict" versioned updates (bin aber auch nicht sicher, ob "npm install" tatsächlich das selbe tut, wie das dortige Beispiel mit "ncu").


Ich frage deshalb, weil ich im 42_npmjs.pm Modul derzeit die Verfügbarkeit von Updates ausschließlich davon abhängig mache, ob eine neue "Latest" Version verfügbar ist und "Wanted" lasse ich vollkommen außen vor. Das führt bei homebridge-fhem jetzt eben dazu, dass ein normales "npm update" eben gar nicht auf die 0.5.x aktualisiert, sondern bei der letzten 0.4.x Version verbleibt. Nun möchte ich wissen, ob das so auch korrekt und von dir gewollt ist oder ob das eigentlich nicht so sein soll.


Ich habe gerade im npmjs Modul auch schon einen Switcher eingebaut, um Updates über "install" statt "update" zu machen. Ich weiß aber nicht, ob das so richtig wäre und ich glaube die meisten verwirrt das auch eher. Auch bin ich unsicher, was ein generelles Update per "npm install" dann für nicht-FHEM-Pakete dann bedeuten würde.

[justme1968]

da hatte ich bis jetzt noch garnicht drauf geachtet.

es scheint so zu sein das node die minor version für globale pakete anders handhabt als für die abhängigkeiten zwischen paketen.


aber beim suchen scheint es tatsächlich so zu sein das npm die globalen paktete nur innerhalb des patch level automatisch updated und schon bei der minor version mit install aktualisiert werden muss.

siehe hier: https://docs.npmjs.com/cli/outdated.html

wanted is the maximum version of the package that satisfies the semver range specified in package.json. If there's no available semver range (i.e. you're running npm outdated --global, or the package isn't included in package.json), then wanted shows the currently-installed version.

ich würde sagen das npm outdated/update verhalten ist einfach blöd und irreführend.

für das modul: ich denke minor version updates sollten automatisch gemacht werden. mit install statt update. änderungen der major version sind laut npm doku für inkompatible änderungen und sollten vielleicht nicht mehr automatisch passieren.



ps: du findest sogar beispiele bei denen outdatet wanted mit einer größeren verision als latest angibt. keine ahnung wie man damit umgeht.