Hauptmenü

on von on unterscheiden?

Begonnen von meikelS, 15 September 2019, 15:39:13

Vorheriges Thema - Nächstes Thema

meikelS

Mir ist kein besserer Titel eingefallen.
Gibt es eine Möglichkeit zu erkennen, über welchen Weg ein Device eingeschaltet wurde?


Ich kann ja z.B. eine Lampe per Hue Bridge, per App, mit Alexa oder über FHEM schalten. In letzterem hat es auch noch mehrere Wege.
Aber das Resultat ist immer das gleiche. An ist an.
Hat jemand ne Idee, wie ich manuelles Schalten von "programmiertem" Schalten unterscheiden kann?


Ich denke da an ein userReading, dass gesetzt werden könnte.
Don't blame the newbies.

MadMax-FHEM

Du müsstest vermutlich (zumindest habe ich jetzt auch keine andere/bessere Idee) in jeden Zweig ein:

setreading DeviceName Einschaltweg EinschaltwegBezeichnung

einbauen...
(oder halt irgendwas anderes)

Dann steht im Device "DeviceName" im Reading "Einschaltweg" eben der "Weg des Einschaltens" drin...

Bei den genannten Wegen geht das sicher...
...in das jetzt vorhandene Kommando eben noch das zusätzliche "setreading ..." dazubauen.

Schwerer ist es dann über fhem direkt ("Knöpfchen" drücken etc.)...
...bzw. wo du keinen Einfluss hast.

Ansonsten ist (wie du ja bereits gemerkt hast) on halt einfach on ;)

Weil nur der Weg weiß Bescheid ;)
Das Device geht halt auf on ;)

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

Es gab mal eine ähnliche Diskussion zu (CUL_HM-) Homematic-Geräten. Da hat der Modulautor dann was eingebaut, damit man "manuelle" (lokale) Schaltungen von "FHEM"-Anweisungen unterscheiden kann.

Grundsätzlich hängt das m.E. sehr stark vom jeweiligen Modul ab. Es gibt einige Implementierungen, die erst mal ein "set xy" in das Reading/den state schreiben, bis der Aktor rückmeldet, dass er tatsächlich geschaltet hat, bei anderen funktioniert das nicht, teils prinzipbedingt.

Wenn du also was machen willst, mußt du dir klarwerden, wie die Signalverarbeitung in dem jeweiligen Modulen läuft (=> das meiste sollte schon der EventMonitor liefern). Dann kannst du das ggf. auch zentraler abfangen, ohne zusätzlich weitere Hilfsreadings zu setzen.

(Aber prinzipiell: Nicht so einfach, und für was genau gut...?)
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