Hauptmenü

Status Rücklesen Dummy

Begonnen von Unen, 12 März 2020, 21:01:13

Vorheriges Thema - Nächstes Thema

Unen

Hi ich habe einen Dummy Schalter angelegt und nutzen diesen erfolgreich um wget an Loxone zu senden, Virtueller Eingang in Loxone. Dort wird über Eine Logik ein Ausgang angesteuert. Ich würde nun gerne den Status dieses Ausgangs rücklesen in FHEM und den Status darstellen.
Loxone bietet die Möglichkeit mit dem Befehl http://miniserver/dev/sps/io/LichtWohnzimmer/state
Leider habe ich keine Ahnung wie ich das einbinden muss.
Hoffe mir kann jemand helfen.

MadMax-FHEM

Hast du schon mal im Forum gesucht?

Loxone und fhem war schon ein paar mal...

Ansonsten würde ich ganz ohne Dummy gleich HTTPMOD-Modul nehmen.
Dort kannst du Requests senden und "empfangen" und hast somit (eigentlich) den Status usw. in einem Device...

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)

ather

Hallo Zusammen,

ich bin Fhem newbie und bräuchte eure Unterstützung.

Ich habe bei mir Loxone als Hauptsystem laufen und Fhem auf einem Raspi als Erweiterung. Hier habe ich mit dem Modul gassitant Google Home integriert und kann Lampen auch per Sprache schalten (Dummy Modul) über MQtt.

Mein Problem ist die Statusmeldung von Loxone zu Raspi.

Wenn ich über Http dann den Status der Lampe an FHEM zurück melde z.B. wenn ich über Taste das Licht anmache, schaltet Fhem wiederum die Lampe aus.#

Wie kann ich denn einen Status an FHEM Melden bzw. verändern, ohne dass Fhem dann wieder schaltet. Oder Brauche ich hier ein anderes Modul?

Habe dazu im Forum leider nix gefunden.

Gruß
Ather

MadMax-FHEM

Zu "Loxone-Anbindung" sollte einiges im Forum vorhanden sein...

Das hier ist eine ähnliíche Problematik (vielleicht) aber statt HTTP-Requests eben set-Befehle und notify etc.: https://forum.fhem.de/index.php/topic,115191.msg1094530.html#msg1094530

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)

ather

Hallo,

danke für die Antwort.

Ich habe bereits ein notify, dass folgenden Inhalt hat:


SYS_MQTT:cmnd:.* {
    if ($EVENT =~ qr/.*?: (.*)/p) {
        my $cmnd = $1;
        Log3($NAME, 5, "executed mqtt command: " . $cmnd);
        fhem($cmnd);
    }
}


Wenn ich es richtig verstehe, dann wartet das notify auf events, und leitet alles an MQTT und somit an Loxone weiter.

Sollte ich hier ein 2. notify machen wie hier (https://forum.fhem.de/index.php/topic,115191.msg1094530.html#msg1094530) beschrieben, oder das bestehende einfach umschreiben?

Wenn eben der Status von Loxone kommt, soll nicht an MQTT weitergeleitet werden, sonst dauer Schleife.
Nur wenn der Befehl von google kommt. Soll eine Schaltung durchgeführt werden.

Denke auch, dass ich hier mit Filter im Notify arbeiten muss, weiss aber noch nicht genau wie ich es machen soll.

Gruß
Ather

MadMax-FHEM

#5
Also mit den gegebenen Informationen (bzw. wurde ja nicht wirklich etwas gegeben ;)  ) kann ich so nichts sagen...

1. Frage: das hier gepostete notify funktioniert bei dir schon!? Oder "einfach wo gefunden"? Wofür ist das gedacht?

Ja, ein notify "wartet" (eher: reagiert) auf Events.

Events sieht man bei fhem im EventMonitor: https://wiki.fhem.de/wiki/Event_monitor

D.h. das notify hier "wartet" auf Events vom Device "SYS_MQTT" (was immer das ist) mit einem "Inhalt" von "cmnd:usw." also "cmnd:" und weil "Punkt-Stern" -> usw. bzw. und irgendwas

Naja: wie kommen denn "Befehle von Google" rein?

Anmerkung: Evtl. wäre es besser gewesen einen eigenen Thread in einem passenden/passenderen Unterforum zu eröffnen (nächstes Mal auf jeden Fall), außer es ist ein "Modul-Thread", dann kann man sich da nat. "dranhängen", wenn es um die Nutzung eben diesen Moduls geht...

EDIT:
Zitatmy $cmnd = $1;
was soll das machen?

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)

Otto123

Zitat von: MadMax-FHEM am 24 Oktober 2020, 11:40:24
EDIT:  was soll das machen?

Gruß, Joachim
Hallo Joachim,

der Groupmatch wird übergeben :) $EVENT =~ qr/.*?: (.*)/p) .

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

MadMax-FHEM

Zitat von: Otto123 am 24 Oktober 2020, 11:54:05
Hallo Joachim,

der Groupmatch wird übergeben :) $EVENT =~ qr/.*?: (.*)/p) .

Gruß Otto

Hallo Otto,

DANKE! :)

Was es nicht alles gibt... ;)

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)

ather

#8
Zitat von: MadMax-FHEM am 24 Oktober 2020, 11:40:24

1. Frage: das hier gepostete notify funktioniert bei dir schon!? Oder "einfach wo gefunden"? Wofür ist das gedacht?

Ja, ein notify "wartet" (eher: reagiert) auf Events.

Events sieht man bei fhem im EventMonitor: https://wiki.fhem.de/wiki/Event_monitor

D.h. das notify hier "wartet" auf Events vom Device "SYS_MQTT" (was immer das ist) mit einem "Inhalt" von "cmnd:usw." also "cmnd:" und weil "Punkt-Stern" -> usw. bzw. und irgendwas

Gruß, Joachim

Hallo Joachim,

ja das Notify ist bereits am laufen und das habe ich nach dieser Anleitung erstellt, nachdem ich mein Sileno integriert habe.
https://ownsmarthome.de/2020/05/07/loxone-mit-raspberry-pi-mqtt-fhem-aufbohren/

ZitatNaja: wie kommen denn "Befehle von Google" rein?
Das habe ich nach dieser Anleitung gemacht. Also mit dem Modul gassistant.
https://wiki.fhem.de/wiki/Google_Assistant_FHEM_Connect

Die Kommunikation FHEM <> Loxone funktioniert ja einwandfrei. Nur wenn ich über Loxone schalte, soll der Status in Fhem und damit in Google angepasst werden ohne das fhem erneut eine Schaltung durchführt und somit in eine Dauerschleife kommt.

Dachte vielleicht kann ich auch über Loxone irgendwie ein set (setreading,setstate....) Befehl setzen, dass sich bei fhem dummy eben nur der Status ändert, aber keine Schaltung durchgeführt wird.

Gruß
Ather

MadMax-FHEM

#9
Naja wie so oft gibt es viele Wege... ;)

Einer wäre über dummy:

ein Reading kommt von gassistant -> notify -> Loxone

ein anderes Reading (selber dummy) kommt von Loxone -> status gassistant

Über das homebridgeMapping (das "versteht" gassistant ja auch!?) kannst du dann ja mappen, dass der Status eben das eine Reading ist -> gassistant/Google und das andere Reading eben per notify eine Aktion in Loxone auslöst (und auch das "Status-Reading" des dummy setzt [damit in Richtung gassistant alles passt] evtl. entkoppelt über ein kurzes sleep [bin nicht sicher, ob notify ein setreading auf das "feuerende Device" direkt zulässt])...

Also:


define dmGassistantLoxone dummy



setreading dmGassistantLoxone LoxoneToGoogle Wert

(spiegelt dann an Google, wäre dann der Status/Zustand im Mapping)


setreading dmGassistantLoxone GoogleToLoxone Wert

Das Reading GoogleToLoxone wird eben übder das homebridgeMapping seitens Google verändert...
Ein notify reagiert darauf, also auf dmGassistantLoxone:GoogleToLoxone.* und gibt das an Loxone weiter und setzt das Reading LoxoneToGoogle damit auch der zurückgespiegelte Zusatnd stimmt.


Ein notify "von Loxone" (auf was das reagieren kann musst du wissen) setzt dann eben auch nur das "StatusReading": LoxoneToGoogle damit Google richtig anzeigt...

Damit sollte es ja keine Schleife geben...
...sofern die Trigger der notify "sauber" sind...

Aber schön ist anders...

Ansonsten evtl. noch selbes Reading aber dann mit Filter, also wenn schon ein bestimmter Zustand (egal ob von Loxone oder Google) dann schalte nicht noch mal, sondern gib nur weiter...

Evtl. geht das auch ohne dummy und weiteres notify mittels readingsProxy...


Vielleicht ist sogar readingsProxy eher geeignet für die ganze Geschichte...


Und bestimmt gibt es noch eine (oder mehrere) Möglichkeit ;)

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)

ather

Ok gute Idee,

Bin mir nicht sicher ob ich es richtig verstanden habe.

ich habe jetzt ein Dummy angelegt:

define LICHTB dummy

Hier muss ich jetzt das Attribut  homebridgeMapping (OnOff) erstellen und zwei readings: (GoogletoLox und LoxtoGoogle), Oder?
Brauche ich dann hier kein setlist OnOff?

Jetzt müsste ich ja ein neues notyfy anlegen, dass eben erkennt wenn Google sendet und eine Schaltung durchführt.

Das habe ich soweit gemacht.

Wenn aber loxone den status sendet über einen Virt. Ausgang
setreading LichtB State on
Dann soll das ganze dann via homebridgemapping an google gehen?

Wie genau muss dann das notify aussehen?

Sorry wenn ich so doof Frage aber ich bin hier absoluter Neuling.

Danke für die Unterstützung.

Gruß
Ather

MadMax-FHEM

Ich würde nicht State als Readingname nehmen sondern wirklich die von mir vorgeschlagenen...

Schwierig wird nur das homebridgeMapping, da bin ich jetzt auch kein Spezialist und ich habe "nur" alexa-fhem ;)

Ich werde das mal versuchen nachzubauen, bis auf die Kommandos bzw. die genauen RegEx des notify bzgl. Loxone, da hab ich ja keine Ahnung ;)

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)

MadMax-FHEM

Hallo,

sorry, hat etwas gedauert...

Ich habe mal rumprobiert mit meiner Idee alles in einem dummy OHNE notify nur mit homebridgeMapping...
...leider ging es nicht wie gedacht :-\

Schließe aber nicht aus, dass es an meinem "Unvermögen" bzgl. homebridgeMapping liegt/lag... ;)

Ich habe auch mit readingsProxy "rumgespielt"... Leider auch erfolglos (und erneut: ich schließe nicht aus, dass mein "Unvermögen" daran "Schuld" ist ;)  )...

Aktuell fällt mir als Lösung nur sowas ein: https://forum.fhem.de/index.php/topic,115191.msg1094533.html#msg1094533

Also einen dummy für Google.
Dann eben 2 notify so wie in dem Link...

Eines hast du ja schon. Das dann erweitern, dass es auch den google dummy schaltet und aber VORHER das notify für Google->Loxone "ruhig stellt" und DANACH wieder aktiviert (so wie die beiden notify im Link)...

Und dann noch ein notify von Google->Loxone und das dann ebenso: ZUERST das notify LOXONE->Google "ruhig stellen" dann den Schaltbefehl an den dummy (damit Google den richtigen Status hat) und dann das notify wieder aktivieren, damit der nächste Schaltbefehl von Google wieder "durch geht"...

Du kannst auch weiter lesen und evtl. das mit Filter probieren.
Allerdings ist es manchmal gewünscht/nötig (oder es passiert), dass man DENSELBEN Befehl noch mal schicken will, das geht dann mit Filter nicht...
...der notify-Orgie ist das egal ;)

Für einen dummy für gassistant sollte es Beispiele geben.
Ich habe hier mal einen für alexa-fhem (sollte für gassistant auch funktionieren!?) als RawDef:


defmod dmGassistantLoxone dummy
attr dmGassistantLoxone alexaName Test
attr dmGassistantLoxone genericDeviceType switch
attr dmGassistantLoxone room Test
attr dmGassistantLoxone setList on off


attr dmGassistantLoxone alexaName Test musst du verm. anpassen: attr dmGassistantLoxone gassistantName DeinName ?

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

Na ja, jedenfalls beim ersten Durchlesen dieses Artikels https://ownsmarthome.de/2020/05/07/loxone-mit-raspberry-pi-mqtt-fhem-aufbohren/ hatte ich das ungute Gefühl, dass da lauter Einäugige irgendwas halbgares voneinander abschreiben... (Wie kann man im Mai 2020 noch ein MQTT_DEVICE bewerben...?!? Die Payload direkt in einem MQTT2_DEVICE an fhem() übergeben hätte denselben Effekt, und man kann sich das notify sparen...)

Ganz grundsätzlich aber: Selbstredend _kann_ man den kompletten set-Befehl an FHEM auch via MQTT übermitteln, aber damit umgeht man eben auch die "mach daraus keine Endlos-Schleife"-Mechanismen, die z.B. MQTT_GENERIC_BRIDGE mit mqttForward bietet.

Die ganze Sache müßte eigentlich einfacher aufgebaut werden können, indem man für
- originär in Loxone vorhandene Datenpunkte (oder "Geräte") statt eines dummy je ein MQTT2_DEVICE verwendet, das ganze auf einem separaten Topic-Tree und mit einer bridgeRegexp für das automatisierte Erstellen der Geräte;
- alle "nativen FHEM"-Geräte mit MQTT_GENERIC_BRIDGE nach Loxone bringt, und dazu halt den Aufwand treibt, die betreffenden subscriptions sauber zu setzen. Sonst bekämpft man halt nur die Nebenwirkungen...

Das ist aber wie gesagt nur mein erster Eindruck vom Ganzen.
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

MadMax-FHEM

#14
Zitat von: Beta-User am 27 Oktober 2020, 11:40:38
Das ist aber wie gesagt nur mein erster Eindruck vom Ganzen.

Da hast du sicher mehr Überblick...

Mit MQTT usw. habe ich mich (noch) nicht (so) beschäftigt...

Loxone habe ich auch nicht ;)

Habe nur mitbekommen, dass es immer wieder Anfragen bzgl. fhem<->Loxone gibt...
...daher auch erst mal der Hinweis bzgl. Suche.

Daher war ich nur bei der Symtombekämpfung beteiligt...
...und fand/finde die Lösung weder hier noch dort schön. ;)

Aber: es würde das Symtom bekämpft haben, (mein) Ziel "erfüllt" :)

Aber: besser richtig bzw. vernünftig machen!
Allerdings muss das ather entscheiden...

Gruß und danke, 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)