Homebridgemapping für Jalousien

Begonnen von Aekschn, 23 Mai 2025, 08:33:30

Vorheriges Thema - Nächstes Thema

Aekschn

Guten Morgen,
ich versuche meine Jalousien die per Modbusregister gesteuert werden und Werte zwischen 0 und 255 als zulässigen Zustand haben in Alexa zu integrieren. Leider gelingt mir das nur halb. Mein Problem ist, das die Alexa App nur Werte von 0 bis 100 darstellt und akzeptiert, gleich welches Homebridgemapping ich auch verwende. Ich hatte angenommen diese Grenzen variabel anpassen zu können aber das klappt nicht. Ich habe ein Reading pct das den aktuellen Zustand darstellt und das Reading position das die Sollposition aufnehmen soll. Hat jemand eine Idee dazu?

Hier mein Code:

[code]

attr Jalousie_Buero_West genericDeviceType blind
attr Jalousie_Buero_West homebridgeMapping clear\
CurrentPosition=pct,minValue=0,maxValue=255,minStep=1\
TargetPosition=position,minValue=0,maxValue=255,minStep=1


attr Jalousie_Buero_West stateFormat pct
attr Jalousie_Buero_West userReadings pct { 100/255 * ReadingsVal("$NAME","state",0);;;; },position {ReadingsVal("$NAME","state",0)}
attr Jalousie_Buero_West webCmd state

#   READINGS:
#     2025-05-16 10:35:38   IODev           PFC8215Keller
#     2025-05-23 08:41:40   RAW             00ff
#     2025-05-23 08:41:40   pct             100
#     2025-05-16 11:54:56   position        93
#     2025-05-23 08:41:40   positione       255
#     2025-05-23 08:41:40   state           255

[/code]

Lieben Dank vorab!
Florian

Beta-User

Imo macht das mit den userReadings wenig Sinn - die sind nicht als "set" verfügbar.

Wenn der set-Befehl auf 'state' geht, sollte das vermutlich (unten statt 'brightness') verwendet werden und ein "factor" für die Umrechnung.

Für light-genericDeviceType wäre die attrTemplate-Variante für factor (255 max-Wert für brightness) so:
attr DEVICE homebridgeMapping Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true
Mußt du halt anpassen und ggf. dann im log schauen, wo es hakt - 'state' ist halt u.U. speziell in der Handhabung.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Aekschn

Danke für die Antwort!
Mir ist die Syntax des Homebridgemappings unklar (und ich werde auch nicht schlauer aus den Infoseiten dazu)

 Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true

Chareacteristic=Fhemreading::was ist das 2. brightness,axValue=100,factor=0.39216,delay=true

VG

passibe

Siehe hier: https://github.com/justme-1968/homebridge-fhem?tab=readme-ov-file#enhanced-config
Dort steht:<command>:<device>:<reading> where parts can be omitted from left to right or
Das 2. brightness ist also "command" bzw. "cmd"; man könnte auch statt die Kurzform zu benutzen einfach den parameter "cmd" verwenden:Brightness=brightness,cmd=brightness,maxValue=100,factor=0.39216,delay=true
Am besten einfach nochmal die Doku GENAU lesen. Wichtig ist dabei auch, konzeptionell zu verstehen, dass manche Parameter im homebridgeMapping nur nur den Datenfluss in die Richtung FHEM -> Homebridge (z.B. values), manche andere Parameter nur in Richtung Homebridge -> FHEM (z.B. cmd) und wieder andere Parameter beides betreffen (z.B. factor). (Homebridge/Alexa sind hier natürlich austauschbar.)
Man muss sich beim Einrichten also fragen: Wohin sollen welche Daten fließen und welche(n) Parameter brauche ich dafür.

Was sehr helfen kann, ist das Log beim Neustart/reload von alexa-fhem (bzw. homebridge-fhem) zu lesen. Da wird einem nämlich ganz genau angezeigt, welches Reading aus FHEM benutzt und wie es in Homebridge/Alexa "übersetzt" wird. Und umgekehrt wird beim Schalten aus Alexa heraus genau protokolliert, wie alexa-fhem den Schaltbefehl an FHEM weitergesendet hat. Damit kann man ziemlich gut debuggen bzw. das homebridgeMapping immer weiter anpassen, bis es dann passt.

Aekschn

Danke! Der Tip mit dem Logfile ist Gold wert!

Jetzt klappt alles wie gewollt!