homebridge/homekit

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

Vorheriges Thema - Nächstes Thema

MatthiasL

Zitat von: no_Legend am 07 Januar 2018, 15:24:12
Was hast du für ne generic device typ genommen?
Gibt es eine Liste wo alle generic device typ aufgelistet sind?

Danke und Gruß Robert

Ja

https://github.com/KhaosT/HAP-NodeJS/blob/master/lib/gen/HomeKitTypes.js

no_Legend

Es scheinen hier aber nicht alle generic device typs drin zu sein.
Thermometer zum Beispiel ist nicht zu finden.

Gruß Robert
IntelNUC mit Ubuntu mit FHEM immer aktuell,2x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
HM-SEC-KEY,HM-LC-BL1-FM,HM-SEC-SD,HM-Sen-DB-PCB,HM-Sec-RHS,HM-Sec-SC-2,HM-WDS10-TH-O,Harmony,Netamo, 433MHz Steckdosen uvm.

EinEinfach

ZitatEs scheinen hier aber nicht alle generic device typs drin zu sein.
Thermometer zum Beispiel ist nicht zu finden.
Service "Temperature Sensor"
fhem auf Intel NUC6CAYH mit Proxmox im LXC (Debian 10), KNX mit knxd über MDT SCN-IP000.02, Buderus GB192-15i über KM100, Solaredge WR SE9K über Modbus-TCP

no_Legend

Zitat von: EinEinfach am 08 Januar 2018, 10:50:18
Service "Temperature Sensor"

Der Typ Thermometer ist nicht direkt zu finden.
Wenn dein Typ jetzt der Thermometer ist, dann muss es doch einer weitere Tabelle geben welche den FHEM generic device Typen einen homebridge Service zuordnet.

Und genau hier ist mein Problem.
Ich würde gerne wissen. Welche generic devices Typen in FHEM benutzt werden können.

Gruß Robert


Gesendet von iPhone mit Tapatalk Pro
IntelNUC mit Ubuntu mit FHEM immer aktuell,2x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
HM-SEC-KEY,HM-LC-BL1-FM,HM-SEC-SD,HM-Sen-DB-PCB,HM-Sec-RHS,HM-Sec-SC-2,HM-WDS10-TH-O,Harmony,Netamo, 433MHz Steckdosen uvm.

MatthiasL

Also FHEM unterstützt eigentlich fast alle Services genericDeviceTypes aus der Liste.
Ich hab auch mal alle als dummy getestet, habe die Listings aber leider nicht gespeichert.

Elektrolurch

Hallo,

habe seit drei Tagen nun auch die homebridge  am laufen und das meiste ging problemlos. Allerdings habe ich etwas Probleme mit den Fenster- und Türkontakten von FHT. Diese liefern im state Closed oder Open und wurden automatisch als contactsensor erkannt. Allerdings  wechselten diese die Anzeige auf dem IOS von geschlossen auf geöffnet, aber nicht mehr viceversa.
Nun habe ich mich mal in das mapping eingelesen und folgendes gesetzt:
genericDeviceType door
homebridgeMapping PositionState=state,values=Closed:1;Open:0
In der HomeKitTypes steht zu door folgendes:
door
    this.addCharacteristic(Characteristic.CurrentPosition);
  this.addCharacteristic(Characteristic.PositionState);
  this.addCharacteristic(Characteristic.TargetPosition);

  Characteristic.CurrentDoorState.OPEN = 0;
Characteristic.CurrentDoorState.CLOSED = 1;

Nach dem Setzen habe ich den homebridge service natürlich neu gestartet, aber die Fenster bleiben nach dem Öffnen und erneuten Schliessen trotzdem auf dem Zustand "geöffnet" stehen.

Was mache ich da falsch?

Elektrolurch
configDB und Windows befreite Zone!

EinEinfach

ZitatAllerdings habe ich etwas Probleme mit den Fenster- und Türkontakten von FHT.

Ich bin der Meinung, dass du den falschen genericDeviceType nutzt. Bei "Door" handelt es sich um selbst schließende bzw. öffnende Fenster oder Türen (mit target und current value).

Für die Fensterkontakte nutze ich den Service "ContactSensor". Meine Attribute sehen wie folgt aus:
genericDeviceType contact
ContactSensorState=state, values=closed:CONTACT_DETECTED; /.*/:CONTACT_NOT_DETECTED


In der HomeKit App kannst du dann deine Kontake als Fenster oder Türen einstellen, so dass Erscheinungsbild etwas passender wird.
fhem auf Intel NUC6CAYH mit Proxmox im LXC (Debian 10), KNX mit knxd über MDT SCN-IP000.02, Buderus GB192-15i über KM100, Solaredge WR SE9K über Modbus-TCP

Elektrolurch

Ok, danke das wars.
Zitat:
In der HomeKit App kannst du dann deine Kontake als Fenster oder Türen einstellen, so dass Erscheinungsbild etwas passender wird.

Ich dachte, dass da die Auswahl von Fenster oder Tür auch die charakteristik ändern würde. Aber es ist wohl nur das Erscheinungsbild. Wieder was gelernt.

Elektrolurch
configDB und Windows befreite Zone!

justme1968

#2738
du musst auf jedenfall contact und ContactSensorState verwenden. du kannst aber zusätzlich noch ein mapping für CurrentDoorState machen. das ist natürlicher weil es entgegengesetzt zu contact arbeitet/dargestellt wird. also zusätzlich nochCurrentDoorState=state,values=closed:CLOSED; /.*/:OPEN
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Elektrolurch

Ok. So ganz verstehe ich das nicht:

// The value property of ContactSensorState must be one of the following:
Characteristic.ContactSensorState.CONTACT_DETECTED = 0;
Characteristic.ContactSensorState.CONTACT_NOT_DETECTED = 1;

ABER OPEN und CLOSED gehören doch zum Typ "door"? Oder ist das egal, weil die eh immer auf 0 und 1 abgebildet werden?

Noch eine Frage zur HomeKitTypes:
Dat steht z.B. der Type "blind" für Rolladen überhaupt nicht drin....? Wie das und gibt es irgendwo  eine einfache Übersicht über die services und die Charakteristiken mit ihren Konstanten?
Ich habe da zwar auf gitup noch eine Tabelle gefunden, die ist aber so groß und unübersichtlich, so dass ich mit meinem Scrrenreader da nicht weiter komme.

Elektrolurch
configDB und Windows befreite Zone!

justme1968

das OPEN und CLOSED ist für den CurrentDoorState. den legst du im mapping zusätzlich zum ContactSensorState an.

der source code auf GitHub ist dir offizielle referenz was mit einer bestimmten homebridge version alles geht. eine extra zusammenfassung zu schreiben ist nicht wirklich sinnvoll weil man dauernd nachpflegen müsste.

homebridge-fhem unterstützt dynamisch alles was homebridge unterstützt. die paar vorgaben in genericDeviceType sind nur vereinfachungen für die häufigsten anwendungen. du kannst aber alle service type namen die homebridge kennt verwenden.

im wiki gibt es noch eine site mit ein paar angaben: https://wiki.fhem.de/wiki/Alexa_und_Mappings
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

M.K.

Hallo zusammen,

ich habe einen altmodischen Verstaerker ueber IR angebunden, und Ein/Aus geht auch einwandfrei, aber ich wuerde gerne lauter/leiser (in FHEM geht es natuerlich) auch als homebridge mapping verwenden. Allerdings sehe ich nicht welches der vordefinierten Befehle von Post 1 ich da verwenden koennte.

Ideen?

Oder ist das zu altmodisch und es gibt nur digitales 0-100 ...? Da sehe ich aber auch nicht wie ich das auf mein IR signal leger, was dann von der Tastendrueckdauer abhaengen wuerde...

M.K.

justme1968

homekit kennt nur absolute lautstarke 0-100. du kannst dir schalter für lauter und leiser anlegen und diese mit timeout wieder zurück setzen. du musst dann mehrfach drücken. drücken und halten geht nicht.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

dikay

Hallo zusammen,

ich denke, ich habe jetzt das Problem der langen "Aktualisieren" Zeiten und Hänger am iOS Device eingegrenzt bzw. behoben:
Das Problem tritt auf, wenn man FHEM regelmäßig durchstartet. Scheinbar bekommt das die homebridge dann nicht rechtzeitig mit...

Ich hatte einen regelmäßigen Restart von FHEM um 1 Uhr Nachts per at-Befehl eingeplant, da sonst das SMAInverter-Modul nach wenigen Tagen aussteigt. Ohne die Restarts funktioniert HomeKit nun problemlos... Jetzt habe ich die Qual der Wahl :o

Viele Grüße und ein schönes Wochenende
dikay

Elektrolurch

Schau Dir mal das serviced - Modul an. Da kannst Du wohl services in Abhängigkeit von reboot und restart von fhem sotppen und starten.

Das steckt in den Attributen.

https://forum.fhem.de/index.php/topic,79952.0/topicseen.html

Gruß

Elektrolurch
configDB und Windows befreite Zone!