Device State setzen ohne notify, aber für Homekit/ Alexa/ etc

Begonnen von Flanders, 11 Juni 2022, 08:45:35

Vorheriges Thema - Nächstes Thema

Flanders

Hallo,

ich möchte einen dummy-Schalter in Homekit, Alexa, GoogleAssistent benutzen um
a) beim Betätigen etwas zu schalten
b) den aktuellen Zustand darzustellen

Bedeutet z.B. wenn ich den Schalter auf ON stelle, soll die Markise ausfahren/ OFF-fährt sie ein.
Wird sie von "Hand" ausgefahren, soll der Schalter auf ON gesetzt werden. Hier würde aber ein SET ein Notify für Fall A auslösen, ein SETSTATE zwar den Zustand verändern, das würde Homekit,etc. jedoch nicht mitbekommen.

Gibt es hierfür eine Lösung?

Ich habe mehrere dieser Schalter
  Flurlicht für eine Reihe von separat geschalteter Lampen
  Garage für das Garagentor....

Greets

Flanders

MadMax-FHEM

Warum nimmst du nicht das Original-Device?

Dann stimmen Status und es wird entsprechend geschalten, egal worüber?

Ansonsten wird es nicht gehen (oder irre kompliziert), weil eben (zumindest alexa-fhem und somit wohl auch gassistant, weil gleiche Code-Basis [sowit ich weiß] [und auch homekit]) ohne Event der Status nicht an Alexa, Google usw. weitergegeben wird (wie auch, wenn es "niemand" mitbekommt ;) )...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Flanders

Na ja,

dass ist schnell erklärt.
Da es kein "Original-Device" gibt.
Es ist vielmehr eine Gruppe (also 5 Schalter z.B.).
Oder in einem anderen Fall wird der Status nicht korrekt unterstütz von homekit oder ähnlichem (Markise, da habe ich dann auf einen dummy verwiesen der on=ausgefahren, off=eingefahren läuft).

Und ich hatte gehofft, dass es -wie in vielen Programmiersprachen- ein "Refresh" Befehl gibt, der das homekit oder Alexa oder ähnlich dazu veranlasst die Daten des Devices (oder auch alle) neu zu laden.
Ich habe auch mit einem Reading experimentiert, das den aktuellen Status anzeigt und im homebridgeMapping darauf verwiesen (On=Zustand,valueOn=on,valueOff=off,cmdOn=on,cmdOff=off; dabei ist Zustand der aktuelle Zustand).
Das funktioniert in homekit, allerdings macht alexa kein Refresh. Das macht nur bei Änderung des states ein Refresh....

Also, es ist nicht so einfach

Greets

Flanders

MadMax-FHEM

Das mit Markise verstehe ich zwar nicht, denn wenn es für einen dummy geht warum sollte es dann nicht für die "Original-Markise" gehen?

Ansonsten kann man halt ein set Alexa reload machen, das sollte dann den aktuellen Status "holen" usw.
Ist aber (bestimmt) unschön, bei jedem Vorgang Alexa "neu zu laden"...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Flanders

OK, danke.

Marikse ist das Problem, dass es in den verschiedenen Alexa, Homekit, etc. unterschiedlich gehandelt wird.
Alexa kennt nicht ausfahren oder on oder so, da muss man 100% und 0% sagen. usw.
Der Garagenmotor wird über einen Taster gesteuert und den Zustand sehe ich über einen Öffnungssensor, also 2 Geräte die zusammen erst Sinn ergeben....

Greets

Flanders

MadMax-FHEM

Es gibt doch die Alexa-Routinen, da kannst doch DU vorgeben was du sagen willst... 8)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Zitat von: Flanders am 11 Juni 2022, 12:19:38
Der Garagenmotor wird über einen Taster gesteuert und den Zustand sehe ich über einen Öffnungssensor, also 2 Geräte die zusammen erst Sinn ergeben....
Prinzipiell glaube ich auch nicht daran, dass eigenes "dummy-Geschubse" irgendeinen Sinn ergibt, und speziell zum Thema Garagentor siehe https://forum.fhem.de/index.php/topic,127542.0.html (und vielleicht https://forum.fhem.de/index.php/topic,127835.0.html).

Eine Markise sollte mAn. auch mit genericDeviceType blind handhabbar sein. (Kenne aber nur RHASSPY).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Flanders

Anders geht s aber nicht. Der Garagenantrieb ist autark.
Über einen Taster/Brücke, kann ich ihn über fhem auslösen. Der Zustand kann nur mit einem fenstersensor überwacht werden. Also das hilft nicht.
Und Rollos/Markiesen sind in einigen Systemen eher schlecht unterstützt.

Aber diese Diskussion führt zu nichts.
Danke, ich probiere es mit den mit vorliegenden Infos.

Beta-User

Zitat von: Flanders am 11 Juni 2022, 14:48:01
Anders geht s aber nicht.
[...]
Aber diese Diskussion führt zu nichts.
Aha...
Wie wäre es mit "erst lesen, dann motzen..."?!?

Deine Problemstellung ist 1:1 das Thema des verlinkten Threads :P
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files