homebridge/homekit

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

Vorheriges Thema - Nächstes Thema

DeeSPe

Zitat von: onkel-tobi am 13 März 2021, 15:13:35
So und nun habe ich auch home noch mal runtergeworfen und siehe da, zumindest scheint es jetzt auch in der home app zu anzukommen (s. Photo). Außerdem wird via app auch geöffnet, aber via Siri sagt er nur eg_fl_door ist aufgeschlossen (stimmt ja im Prinzip  auch, denn der 2. Kanal müsste ja halt auf on?

Gruß,
Tobi


Da das Schloss natürlich nur "open" kann und kein "close", gibt es den Timeout von 250ms und den Fallback (default) auf "off".
On#On=lock,subtype=mach+auf,cmdOn=open,timeout=250,default=off

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

onkel-tobi

Zitat von: DeeSPe am 13 März 2021, 15:28:14
Da das Schloss natürlich nur "open" kann und kein "close", gibt es den Timeout von 250ms und den Fallback (default) auf "off".
On#On=lock,subtype=mach+auf,cmdOn=open,timeout=250,default=off
Gruß
Dan
Ok, vielleicht verstehe ich es falsch, aber zumindest öffnen müsste doch dann via siri gehen, wenn der richtige Kanal greift?

Gruß,
Tobi

DeeSPe

Zitat von: onkel-tobi am 13 März 2021, 18:10:47
Ok, vielleicht verstehe ich es falsch, aber zumindest öffnen müsste doch dann via siri gehen, wenn der richtige Kanal greift?

Gruß,
Tobi

Ja, genau! Und das tut es auch bei mir.

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

benze72

#4023
Zitat von: MarkusN am 13 März 2021, 15:07:08
Mein Tor funktioniert genau so. Aber dafür habe ich ja in FHEM die Zustände (offen, geschlossen) über zusätzliche Sensoren erfasst. Obendrein habe ich in meinem DOIF "Sperren" eingebaut, die mir das Öffnen des Tores nur ermöglichen wenn es geschlossen ist.

Mir geht es hier mehr um das Verhalten von Siri/Homekit. Ich weiß nicht ob ich vielleicht nur die falschen Erwartungen habe, aber besonders logisch erscheint es mir nicht. Nochmal zur Verdeutlichtung, und das ganze ist meiner Meinung nach losgelöst von FHEM zu betrachten:

Meine Erwartung:
Tor ist offen - ein Befehl über Siri/Home das Tor zu Öffnen sollte in diesem Fall nichts tun
Realität:
Tor ist offen - ein Befehl über Siri/Home das Tor zu Öffnen schließt es.

Hallo Markus,

ich kann das Verhalten von Siri bestätigen. Ist die Garage bereits offen und es kommt erneut der Befehlt Garage öffnen, wird der befehlt auch neu abgesendet. Bei getrennten Steuerungen für öffnen und schließen ist das auch kein Problem, in deinem Fall schon. Bedient man das ganze manuell über die Home App, geht das natürlich nicht, da der Schalter dann schon auf offen steht.

Den Fall Sprachbedienung musst Du in Fhem abfangen.

Ich habe das mal nachgebaut, der Einfachheit halber ohne dein Fehlerhandling. Das müsstest Du noch einbauen.

Device:

defmod testgarage MQTT2_DEVICE DVES_F5B7C0
attr testgarage IODev MQTT2_FHEM_Server
attr testgarage alias Testgarage
attr testgarage autocreate 0
attr testgarage cmdIcon opens:rc_GREEN closes:rc_RED
attr testgarage devStateIcon offen:fts_garage_door_10@red geschlossen:fts_garage_door_100@green oeffnet:fts_garage_door_up@yellow schliesst:fts_garage_door_down@yellow
attr testgarage genericDeviceType GarageDoorOpener
attr testgarage homebridgeMapping clear
CurrentDoorState=testgarage:current,values=offen:OPEN;;geschlossen:CLOSED;;oeffnet:OPENING;;schliesst:CLOSING;;4:STOPPED
TargetDoorState=testgarage:target,values=offen:OPEN;;geschlossen:CLOSED,cmds=OPEN:opens;;CLOSED:closes
attr testgarage readingList DVES_F5B7C0:stat/testgarage_F5B7C0/POWER1:.* sensor_garage_zu\
DVES_F5B7C0:stat/testgarage_F5B7C0/POWER2:.* sensor_garage_auf\
DVES_F5B7C0:stat/testgarage_F5B7C0/POWER3:.* garage_Relais\
DVES_F5B7C0:stat/testgarage_F5B7C0/POWER4:.* garage_Bedienung
attr testgarage room 1_Test,Homekit
attr testgarage setList opens:noArg    cmnd/testgarage_F5B7C0/POWER4 1\
closes:noArg     cmnd/testgarage_F5B7C0/POWER4 0
attr testgarage siriName Testgarage
attr testgarage stateFormat current
attr testgarage webCmd opens:closes
attr testgarage webCmdLabel Öffnen :Schließen\
:


DOIF:

defmod di_testgarage DOIF ##Garage öffnen
([testgarage:garage_Bedienung] eq "ON" and [?testgarage:sensor_garage_zu] eq "ON" and [?testgarage:sensor_garage_auf] eq "OFF") (set testgarage opens, setreading testgarage current oeffnet, setreading testgarage target offen)
##Garage geöffnet
DOELSEIF ([?testgarage:sensor_garage_zu] eq "OFF" and [testgarage:sensor_garage_auf] eq "ON") (setreading testgarage current offen)
##Garage schliessen
DOELSEIF ([testgarage:garage_Bedienung] eq "OFF" and [?testgarage:sensor_garage_zu] eq "OFF" and [?testgarage:sensor_garage_auf] eq "ON") (set testgarage closes, setreading testgarage current schliesst, setreading testgarage target geschlossen)
##Garage geschlossen
DOELSEIF ([testgarage:sensor_garage_zu] eq "ON" and [?testgarage:sensor_garage_auf] eq "OFF") (setreading testgarage current geschlossen)
attr di_testgarage room 1_Test


In dem Testfall wird "garage_Relais" - welches den Schließer am Garagentor betätigt, nicht direkt bedient, sondern nur über das DOIF.
Sowohl im Device und durch Siri wird ausschließlich "garage_Bedienung" betätigt und im DOIF dann abgefragt, ob die Garage offen, bzw. geschlossen ist. Ist sie offen und per Siri kommt erneut der Befehl offen, wird das Relais am Garagentor nicht betätigt.

Was ich auch festgestellt habe, für Home sollten TargetDoorState und CurrentDoorState nicht auf das selbe Reading zugreifen. CurrentDoorState kennt "geschlossen", "offen", "öffnen" und "schließen", während TargetDoorState nur "geschlossen" und "offen" kennt. Wenn TargetDoorState aber noch "öffnen" oder "schließen" angeboten bekommt, kreiselt in der Home App die "Sanduhr", weil Home den Status nicht kennt.

Gruß Karsten
Fhem und Homebridge in Docker auf Synology, überwiegend Shelly's, Sonoffs mit Tasmota, Z-Wave (Fibaro, Thermostate von EUROtronic und weitere noName-Geräte) im Einsatz.

tyrolean

Hallo, ist hier sicher nicht der 100% richtige Platz aber ich wollte keinen neuen Threat aufmachen:

Habe versucht Homebridge auf meinem Raspy ein Update zu gönnen, dies funktionierte aber nicht richtig.
Also habe ich das ganze einfach neu installiert, inklusive der config-ui-x (hatte ich vorher nicht drauf)

Nach einem Reboot die config.json im /var/lib/homebridge Verzeichnis (war vorher in /var/homebridge) wieder angepasst. (die Port Nr. hat sich nach der Installation geändert???, aber auch diese habe ich wieder auf die originale zurückgesetzt)

Allerdings kann jetzt das iPhone die Bridge nicht mehr erreichen. Wenn ich ein Backup Image starte funktioniert alles problemlos.
Ich möchte aber äußerst ungern die Bridge entfernen und neu einrichten da ich mittlerweile x Geräte und Szenen definiert habe und das somit alles weg wäre.

Habe ich da einen Denkfehler oder muss ich noch irgendetwas ändern?

Gruß und Danke für eure Hilfe

justme1968

nicht die neue config anpassen sondern wirklich die alte verwenden. vor allem der username muss gleich bleiben.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

tyrolean

Zitat von: justme1968 am 14 März 2021, 16:21:02
nicht die neue config anpassen sondern wirklich die alte verwenden. vor allem der username muss gleich bleiben.

Danke für die Antwort...
Irgendwie scheint es ein Problem zu sein wie der Service gestartet wird. Ich habe da glaube ich einmal einen Service über init.d laufen und parallel dazu irgendwann hb-service installiert. Habe das jetzt auf jeden Fall mal rausgeschmissen und es funktioniert mal.
Jetzt ist mir aber nicht klar ob auf die config von /var/hombridge oder /var/lib/homebridge zugegriffen wird. Gibt es da einen, eventuell Versions abhängigen, Standard?

onkel-tobi

Zitat von: DeeSPe am 13 März 2021, 18:17:26
Ja, genau! Und das tut es auch bei mir.

Gruß
Dan
Echt komisch. Irgendwas werde ich wohl falsch machen. Interessanterweise funktioniert: "Haustür an". Dann öffnet er mit der Info mach auf wurde eingeschaltet.
Noch eine Idee was ich falsch gemacht haben könnte?

Gruß,
Tobias

DeeSPe

Zitat von: onkel-tobi am 15 März 2021, 14:09:28
Echt komisch. Irgendwas werde ich wohl falsch machen. Interessanterweise funktioniert: "Haustür an". Dann öffnet er mit der Info mach auf wurde eingeschaltet.
Noch eine Idee was ich falsch gemacht haben könnte?

Gruß,
Tobias

Ändere doch mal Dein "mach auf" in etwas Komplizierteres, z.B. "Sesam öffne dich". Das habe ich so und keine Probleme.

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

benze72

Zitat von: DeeSPe am 15 März 2021, 14:18:12
Ändere doch mal Dein "mach auf" in etwas Komplizierteres, z.B. "Sesam öffne dich". Das habe ich so und keine Probleme.

Gruß
Dan

Das kann ich auch nur empfehlen. Ich habe mach+auf getestet, da hat mir Siri immer geantwortet, ich soll das Gerät korrekt benennen, da ich mehrere Lampen mit ähnlichem Namen habe. Sesam öffne dich ist mein persönlicher Favorit. 😉
Fhem und Homebridge in Docker auf Synology, überwiegend Shelly's, Sonoffs mit Tasmota, Z-Wave (Fibaro, Thermostate von EUROtronic und weitere noName-Geräte) im Einsatz.

JMC

Zitat von: benze72 am 13 März 2021, 09:38:43
Schade dass der Fehler mit den 0-Werten noch nicht weg ist. Ich überlege mal weiter.

Ich hab heute nochmal etwas ins Log geschaut auf der Suche nach dem Fehler. Was mir aufgefallen ist, er schreibt mehrfach ins history File scheinbar laut Log - einmal ohne currentTemp und einmal mit. Daher vermutlich die 0 Werte?

^[[37m[15.3.2021, 17:46:57] ^[[39m^[[36m[FHEM]^[[39m     caching: TargetTemperature: 21 (as number; from '21.0')
^[[37m[15.3.2021, 17:46:57] ^[[39m^[[36m[FHEM]^[[39m       adding history entry { time: 1615826817, setTemp: 21, valvePosition: 0 }
[...]
^[[37m[15.3.2021, 17:46:57] ^[[39m^[[36m[FHEM]^[[39m       adding history entry { time: 1615826817, setTemp: 21, currentTemp: 21.8, valvePosition: 0 }
Viele Grüße
JMC

benze72

Zitat von: JMC am 15 März 2021, 17:51:30
Ich hab heute nochmal etwas ins Log geschaut auf der Suche nach dem Fehler. Was mir aufgefallen ist, er schreibt mehrfach ins history File scheinbar laut Log - einmal ohne currentTemp und einmal mit. Daher vermutlich die 0 Werte?

^[[37m[15.3.2021, 17:46:57] ^[[39m^[[36m[FHEM]^[[39m     caching: TargetTemperature: 21 (as number; from '21.0')
^[[37m[15.3.2021, 17:46:57] ^[[39m^[[36m[FHEM]^[[39m       adding history entry { time: 1615826817, setTemp: 21, valvePosition: 0 }
[...]
^[[37m[15.3.2021, 17:46:57] ^[[39m^[[36m[FHEM]^[[39m       adding history entry { time: 1615826817, setTemp: 21, currentTemp: 21.8, valvePosition: 0 }


Laut Deinem Log-Auszug ist die valvePosition: 0 das Problem. Nimm die doch mal den Eintrag
CurrentHeatingCoolingState=ValvePosition,values=0:OFF;/^.*/:HEAT,nocache=true raus. So wie es aussieht, liefert dieses Mapping die "0"-Einträge.

Gruß Karsten
Fhem und Homebridge in Docker auf Synology, überwiegend Shelly's, Sonoffs mit Tasmota, Z-Wave (Fibaro, Thermostate von EUROtronic und weitere noName-Geräte) im Einsatz.

JMC

#4032
Zitat von: benze72 am 15 März 2021, 18:03:18
Laut Deinem Log-Auszug ist die valvePosition: 0 das Problem. Nimm die doch mal den Eintrag
CurrentHeatingCoolingState=ValvePosition,values=0:OFF;/^.*/:HEAT,nocache=true raus. So wie es aussieht, liefert dieses Mapping die "0"-Einträge.

Gruß Karsten

Nicht ganz - ich habe das nochmal weiter beobachtet (hatte heute morgen alle alten 0 Grad Einträge gelöscht). Das Problem scheint eher die humidity zu sein:

[15.3.2021, 18:05:01] [FHEM]       adding history entry { time: 1615827901, humidity: 60 }
Das erzeugt aber einen 0 Grad Eintrag in der Temperatur-Kurve

Da die Luftfeuchtigkeits-History ja leider auch nicht funktioniert (er zeigt nur die aktuelle an, aber keine History) scheint da der Hund begraben zu sein: Scheinbar landet die History für die Luftfeuchtigkeit bei der Temperatur...
Viele Grüße
JMC

benze72

Zitat von: JMC am 15 März 2021, 18:17:36
Nicht ganz - ich habe das nochmal weiter beobachtet (hatte heute morgen alle alten 0 Grad Einträge gelöscht). Das Problem scheint eher die humidity zu sein:

[15.3.2021, 18:05:01] [FHEM]       adding history entry { time: 1615827901, humidity: 60 }
Das erzeugt aber einen 0 Grad Eintrag in der Temperatur-Kurve

Da die Luftfeuchtigkeits-History ja leider auch nicht funktioniert (er zeigt nur die aktuelle an, aber keine History) scheint da der Hund begraben zu sein: Scheinbar landet die History für die Luftfeuchtigkeit bei der Temperatur...

Ich konnte den Fehler mit den "0"-Werten nun nachstellen, indem ich meinem Heizkörperthermostat mal ein Luftfeuchtigkeitsreading hinzugefügt habe und dieses ins Homebridge-Mapping eingebunden habe. Meine erste Idee, die Luftfeuchtigkeit in ein Home-Subdevice zu bringen, sieht nicht schön aus.

Wenn diese unbedingt benötigt wird, das Reading in ein eigenes Fhem Device auslagern (dummy) und dann als HumiditySensor in die Homebridge einbinden. Eine Historie gibt es trotzdem nicht. Darstellung in Home und EVE siehe Fotos.

StatusTampered=Luftfeuchtigkeit:StatusTampered,values=1:NOT_TAMPERED;;2:TAMPERED
StatusFault=Luftfeuchtigkeit:StatusFault,values=1:NO_FAULT;;2:GENERAL_FAULT
CurrentRelativeHumidity=Luftfeuchtigkeit:Luftfeuchtigkeit,format=FLOAT,unit=percent
history:size=1024


Gruß Karsten
Fhem und Homebridge in Docker auf Synology, überwiegend Shelly's, Sonoffs mit Tasmota, Z-Wave (Fibaro, Thermostate von EUROtronic und weitere noName-Geräte) im Einsatz.

onkel-tobi

Zitat von: DeeSPe am 15 März 2021, 14:18:12
Ändere doch mal Dein "mach auf" in etwas Komplizierteres, z.B. "Sesam öffne dich". Das habe ich so und keine Probleme.

Gruß
Dan
Ok, verstehen tue ich es nicht. Aber es geht :)

Vielen Dank!