homebridgeMapping und mehrere Dienste?

[OiledAmoeba]

Moin,

bisher habe ich nur GAssistant verwendet. Jetzt stehe ich vor dem Problem, dass ein Apfelgerät in unseren Haushalt eingezogen ist. Meine Frau wünscht sich zudem noch eine Alexa.
Das Problem, das ich meine, ist: Die unterschiedlichen Dienste nutzen teils unterschiedliche Datenpunkte oder Gerätetypen für ein und das selbe Gerät. Ein Tür-/Fensterkontakt macht bei HomeKit nur als "contact" Sinn, diesen Typ kennt Google aber nicht. Der Google-Typ "window" führt aber bei Homekit wieder zu Problemen, wenn es nur eine Anzeige ist, weil "window" ein bedienbares Fenster ist. Ein genericDeviceType "contact" führt nach meiner Beobachtung aber dazu, dass Google einen Serverfehler (500) produziert und damit der gassistant gar nicht mehr geht.

Ein Shelly, der in Google und HomeKit auftauchen soll, enthält ohne homebridgeMapping auch die Temperatur, welche in den meisten Fällen überhapt nicht gebraucht wird und zu Problemen in der Temperaturabfrage führt: "OK, Google, wie warm ist es im Wohnzimmer? - Die Heizung ist aus und es sind 20,5 Grad, das Homeoffice ist eingeschaltet und es sind 54 Grad." -> Also im Mapping ein clear und die Datenfelder selbst übergeben. Die heißen bei Google und Apple aber unterschiedlich.
Zukünftig soll dann noch Amazon dazukommen...

Mein Gedanke, dass das wohl dazu führt, ein Masterdevice für z.B. Google zu definieren und für Apple und Amazon jeweils Dummys, die den Status des Master abbilden, gefällt mir überhaupt nicht.
Habe ich da was übersehen, oder ist mein Gedanke wirklich so richtig? Cool wäre es, neben dem Attribut homebridgeMapping ein alexaMapping und gassistantMapping definieren zu können, für Geräte, die in mehreren Welten leben sollen.

Ist es wirklich so umständlich, oder bin ich auf dem Holzweg?

[MadMax-FHEM]

Evtl. wäre folgendes eine Variante (statt dummy, die dumm[ie] sind ):

Ein Hauptdevice dass das tatsächliche Gerät "wiederspiegelt": da dann entscheiden für welche Lösung/Service du das Hauptdevice nimmst (z.B. für Google, weil das verm. alles schon passt/gepasst hat)

Für die weiteren Dienste:

bei alexa-fhem probieren, wie das mit gassistant "harmoniert", wenn nicht -> readingsProxy und den dann mit den Attributen bestücken

ebenso bei homekit (oder wie das Apfelzeugs dann heißt/eingebunden ist), also wenn nicht "kompatibel": readingsProxy

Evtl. auch warten, vielleicht hat Andre (justme1968) eine Idee (von ihm stammt die Alexa-Einbundung alexa-fhem und auch die Apfel-Einbindung [sofern ich richtig liege] und alexa-fhem war auch die Basis für gassistant [soweit mit bekannt])

Gruß, Joachim

[OiledAmoeba]

Moin,

ich habe jetzt einen etwas anderen Weg gewählt. Funktioniert, aber schmeckt mir nicht recht.
Für die Homebridge gibt es ein gassistant- und ein alexa-Plugin. So wandern die Daten jetzt von fhem zur Homebridge und von dort weiter zu Google/Amazon.
Lieber wäre es mir aber, wenn fhem mit allen drei Diensten (Homebridge, gassistant und alexa) selbst sprechen würde, aber so geht es erst mal auch.
Die Verzögerung, die dadurch entsteht, dass die Daten von Google erst zur Homebridge und von dort zu fhem wandern, ist leicht spürbar, aber noch in Ordnung.

[MadMax-FHEM]

Hast du dir readingsProxy mal angeschaut?

Viel Spaß noch, Joachim

[OiledAmoeba]

Hast du dir readingsProxy mal angeschaut?

Viel Spaß noch, Joachim

Moin & ein frohes neues Jahr!

Ich brauche nun doch einen anderen Weg. Da ich den Shellys auch den Stromverbrauch mitgebe (was "EVE" anzeigen kann), stürzt mir die Homebridge immer ab, wenn FHEM den Stromverbrauch sendet. Weil die Kopplungen Homebridge->gassistant und Hoembridge-> alexa mit Stromverbrauch bei Lampen scheinbar nicht umgehen können.

Wenn ich readingsProxy richtig verstehe, kann der aber nur einzelne Readings in ein jeweils neues Device mappen. Da bräuchte ich ja bei einem LED-Streifen ein bri-, ein hue-, ein sat- und ein state-Device. Oder? Scheinbar kann readingsProxy nicht mit Wildcards umgehen (so dass ich quasi eine 1:1-Kopie des Device bauen könnte). Da aber gassistant und alexa bei den Devices teilweise auch mehere Readings lesen/bedienen müssen, würde mir da kein praktikabler Weg einfallen. Oder ich verstehe das Modul vollkommen falsch...

Finde aber in Commandref und Wiki auch keine andere wirkliche Lösung. Außer, dass der Maintainer für das alexa-Modul tatsächlich ein eigenes Attribut "alexaMapping" eingeführt hat.

[MadMax-FHEM]

Hmm, hab readingsProxy mal überflogen, stimmt wohl...

Rein zur Anzeige kann/könnte man nat. tricksen mittels userReadings, also ein "vollgestopftes" userReadings am "Original-Device" erstellen, das dann per readingsProxy "vervielfältigen" und dann am jeweiligen readingsProxy per lokalem userReadings wieder "aufdröseln"...

Ist dann aber auch nicht weit weg von einem dummy+notify (ok: 1 readingsProxy statt jeweils dummy+notify bzw. reicht 1 notify pro "Original-Device")...

Allerdings ist die "Steuer-Richtung" schwierig, weil man aufpassen muss, dass man keine "Schleifen" baut...
Da müsste man dann genau schauen wo denn welche set-Kommandos abgesetzt werden sollen/müssen, also von wo aus gesteuert werden soll und wo "nur" angezeigt werden soll...


Das Attribut alexaMapping kannst du vergessen!
Das ist nur am Alexa-Device relevant und auch nur für den CUSTOM Skill...

Gruß, Joachim

[automatisierer]

Moin Moin und zwei Jahre später nochmal ein frohes Neues.
Ich stehe auch vor dem Problem, dass ich gassistant und auch homebridge benutzen möchte. Gibt es dazu mittlerweile einen neuen Lösungsweg?

Gruß
Ingo

[MadMax-FHEM]

Moin Moin und zwei Jahre später nochmal ein frohes Neues.
Ich stehe auch vor dem Problem, dass ich gassistant und auch homebridge benutzen möchte. Gibt es dazu mittlerweile einen neuen Lösungsweg?

Gruß
Ingo

Nicht, dass ich wüsste...

Gruß, Joachim