Homebridge Raum-Attribut für Devices

Begonnen von Nogga, 26 August 2022, 23:21:30

Vorheriges Thema - Nächstes Thema

Nogga

Ich nutze Homebridge sehr gerne. Aber manchmal haut es mir meine Räume durcheinander und ich muss alles neu sortieren.
Gibt es eine Möglichkeit einem Device einen (Homekit) Raum mitzugeben? Ähnlich wie siriName?

DeeSPe

Soweit ich weiß gibt es dafür kein Attribut wie siriName.
Bei mir kam das früher auch öfter vor dass die Geräte wieder im Default-Raum gelandet sind, vor allem die Hue Geräte. Seit dem ich nur sehr selten an Homebridge "herum mache" ist das Problem aber nicht wieder aufgetreten.

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

Hi zusammen,

also ich habe das auch ab und an. Gerade wieder passiert machdem auf ios 16 und die neueste Homebridge Version aktualisiert wurde.
Ein entsprechendes Attribut wäre natürlich klasse.

Gruß,
Tobi

Miami

Ich hatte ein ähnliches Problem mit meinen Homematic IP Komponenten. Da braucht das FHEM-Modul HMCCU nach dem FHEM Start einige Zeit bis die Verbindung zur Homematic Zentrale aufgebaut ist. Daher habe ich nun den Start der Homebridge verzögert, bis HMCCU meldet, dass die Verbindung steht. Seither habe ich mit den Räumen keine Probleme mehr.

Als erstes muss man den automatischen Start der Homebridge ausschalten. Bei mir ging das mit der Eingabe in einer Konsole:
sudo systemctl disable homebridge.service

Bei mir heißt die HMCCU-Instanz einfach CCU.  Im Reading rpcstate zeigt CCU den Zustand der Verbindung an.
Das werte ich aus und starte (oder stoppe) entsprechend den die Homebridge mit serviced:


# HomeBridge Service
define HomeBridge serviced homebridge
attr HomeBridge cmdIcon restart:rc_REPEAT stop:rc_STOP status:rc_INFO start:rc_PLAY
attr HomeBridge devStateIcon Initialized|status:audio_pause error|failed:audio_rec@red running:audio_play:stop stopped:audio_stop:start stopping:audio_stop .*starting:audio_repeat
attr HomeBridge genericDeviceType ignore
attr HomeBridge webCmd start:restart:stop:status

#HomeBridge an- und aus-schalten
define Start_HomeBridge DOIF ([CCU:"rpcstate: running"]) \
    (set HomeBridge restart, {Log 2, "MHCCU is now running, HomeBridge start in 10s"})\
DOELSEIF ([CCU:"rpcstate: inactive"])\
    (set HomeBridge stop, {Log 2, "HMCCU stoped -> stop HomeBridge"} )\
DOELSEIF ([CCU:"rpcstate: error"])\
    (set HomeBridge stop, {Log 2, "HMCCU with error -> stop HomeBridge"} )
attr Start_HomeBridge wait 10:0:0


Bei einem Neustart von FHEM kann es bei mir ca. 2 min dauern, bis ich FHEM wieder richtig bedienen kann, was aber meiner Meinung nach am Verbindungsaufbau zur Homematic Zentrale liegt.
Auch habe ich mir angewöhnt, vor der Bearbeitung der fhem.cfg über das Web-Interface die Homebridge zu stoppen, da bei Speichern der fhem.cfg ja ein Neustart/Reload ausgeführt wird.

Seitdem ist mir nie wieder bei ein bereits vorhandenes Gerät in Apples Home App in den Standardraum "gerutscht".

Ralli

Danke für den Beitrag.

Bei mir taucht das benannte Problem bei einem normalen Neustart von fhem alleine nicht auf. Dieses nervige Problem habe ich ausschließlich, wenn die CCU neugestartet wurde und dann danach ERSTMALIG fhem an die CCU connected, da aus dies innerhalb der CCU offensichtlich etwas auslöst, was den HmIP-Bereich dann erneut re-initialisiert. Das kann ich leider auch nicht wirklich mit einer solchen Automatisierung abfangen.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

stefan-dd

Den Fehler zu umgehen, habe ich jetzt es mal so realisiert. Mit DOIF gibt es das Problem nicht. Die Seriennummer wird mit dem Reading "FUUID" erzeugt.
defmod HB_Dusche DOIF ([Bad_Dusche] eq "on") (set Bad_Dusche on) DOELSE (set Bad_Dusche off)
attr HB_Dusche alias Dusche
attr HB_Dusche genericDeviceType light
attr HB_Dusche homebridgeMapping On=state,valueOn=cmd_1,valueOff=cmd_2,cmdOn=cmd_1,cmdOff=cmd_2
attr HB_Dusche room Homekit


Warum macht man die mit HM Geräten anders und nimmt erst die "FUUID" und nach der Verbindung mit der CCU ein Wechsel auf die "ccuaddr"?
Ist doch vollkommen Sinnfrei?

Ralli

#6
Zitat von: stefan-dd am 02 Januar 2023, 19:45:15
Warum macht man die mit HM Geräten anders und nimmt erst die "FUUID" und nach der Verbindung mit der CCU ein Wechsel auf die "ccuaddr"?
Ist doch vollkommen Sinnfrei?

Gute Frage - das wäre vielleicht echt ein Ansatz.

Edit:
Wenn ich das richtig sehe, ist folgende Zeile im Homebridge-Plugin "der Übeltäter":

https://github.com/justme-1968/homebridge-fhem/blob/master/index.js#L2054

Wenn - aus welchen Gründen auch immer - die Adresse des HM-Devices für die Seriennummer herhalten soll, wäre es ggf. sinnvoller, nicht ccuaddr zu nutzen sondern DEF, denn das ist immer da, auch wenn die CCU-abhängigen Internals aufgrund einer noch nicht verbundenen CCU vor dem Homebridge-Connect noch nicht vorhanden sind.

Meines Erachtens würde helfen, die Zeile 2054


    this.serial = s.Internals.ccuaddr;


zu ersetzen durch


    this.serial = s.Internals.DEF;


oder


    this.serial = s.Internals.IODev + "." + s.Internals.DEF;


Beim letzteren bin ich mir aber nicht sicher, ob das Internal IODev tatsächlich immer vorhanden ist.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

stefan-dd

So wäre es einheitlich:
this.serial = s.Internals.FUUID;

Ralli

#8
Aber nur, wenn für alle Devices, und dem ist nicht so. Die Serial wird typenabhängig unterschiedlich erstellt.

Ein Vorteil, wenn die HM-Adresse sich irgendwo im Homebridge-Device wiederfindet ist die, dass man in Apples Home einfacher zuordnen kann, wenn man verschiedene Devices mit gleichem Namen hat ("Deckenleuchte"). Laut Best Practices sollen ja keine Raumnamen im Devicenamen mit vergeben werden.

Edit:
Ich habe in meiner Installation die besagte Zeile durch


    this.serial = s.Internals.DEF;


ersetzt. Funktioniert einwandfrei und gibt keine bösen Überraschungen mehr, wenn FHEM/HMCCU und die CCU gerade nicht synchron sind.
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

onkel-tobi

Hi,

funktioniert das bei dDir nit dem code zuverlässig?
Ich habe heute meinen RPi runtergefahren und auch homebridge und offensichtlich in falscher Reihenfolge und nun sind alle meine Geräte wieder im Standard Raum und auch Automationen nicht mehr vollständig vorhanden :(

Werde das denke ich mit der Zeile dann auch mal probieren.
Oder gibt es noch andere Möglichkeiten?

Gruß,
Tobi

Ralli

Zitat von: onkel-tobi am 12 April 2024, 23:18:06funktioniert das bei dDir nit dem code zuverlässig?
[/code]

Ja.

Werde das denke ich mit der Zeile dann auch mal probieren.
Oder gibt es noch andere Möglichkeiten?
[/quote]

Vielleicht. Aber wozu was anderes suchen, wenn es so einwandfrei funktioniert?
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa