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.
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
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
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
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
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
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
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
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/ (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 (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
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
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
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
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
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.
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
Zitat von: MadMax-FHEM am 27 Oktober 2020, 12:28:06
Habe nur mitbekommen, dass es immer wieder Anfragen bzgl. fhem<->Loxone gibt...
Das war auch meine Wahrnehmung, daher auch der ziemlich dicke "Pflock" mit dem statement, dass das nach "blindem Gewurschtel" aussieht...
Zitat
Aber: besser richtig bzw. vernünftig machen!
Allerdings muss das ather entscheiden...
Genau. Mein statement war auch als Angebot gedacht, das irgendwie sinnvoller aufzugleisen...
Zu Loxone kann ich wenig sagen, aber eigentlich sollte sich das auch eher verhalten wie ein "normales" MQTT-Gerät (und nicht FHEM-Kommandos übermitteln), und für FHEM2FHEM auf dem MQTT(2)-Weg gibt es schon einige Beispiele...
Ich bin in der Ecke aber auch nicht der Experte.
Wir werden es erleben...
Zitat von: Beta-User am 27 Oktober 2020, 11:40:38
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.
wie meinst du das? Wenn ich den Statusbefehl Loxone>FHEM via MQTT übermittle, gibt es keine Dauerschleife mehr? Wieso dass? Mqtt leitet das ganze ja auch wieder an den LichtB Dummy weiter und ein event wird wieder ausgeführt? Oder sehe ich das falsch?
ZitatDie 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...
Ich würde es sehr gerne sauber und einfacherer aufbauen, aber leider habe ich dazu zu wenig Wissen in Sachen MQTT, BridgeRegexp und co. und benötige daher noch Unterstützung.
ZitatGenau. Mein statement war auch als Angebot gedacht, das irgendwie sinnvoller aufzugleisen...
Dein Angebot nehme ich gerne an.
ZitatZu Loxone kann ich wenig sagen, aber eigentlich sollte sich das auch eher verhalten wie ein "normales" MQTT-Gerät
Wie genau verhält sich denn so ein MQTT-Gerät? Bin da zwar auch kein Profi, aber bei Loxone kann ich denke ich schon mehr Auskunt geben.
Loxone ist hier das zentrale Smarthomesystem, das ich mit fhem erweitern möchte um Gewisse Sachen ,wie Sileno,Google Home usw., zu integrieren.
ich habe bereits den Sileno Roboter erfolgreich mit Hilfe des Gardena_device integriert und habe dabei das oben gepostete notify verwendet.
Gruß
Ather
Zitat von: ather am 27 Oktober 2020, 13:20:54
Dein Angebot nehme ich gerne an.
OK, dann beginnen wir mal bei den Grundlagen...
Das "Grundproblem" mit der potentiellen Dauerschleife ist allen "richtigen" MQTT-Implementierungen bekannt. Das "forward" von Schaltanweisungen an ein MQTT-Gerät wird daher in der Regel lokal unterbunden.
Gegen diese Grundregel verstößt du "doppelt", wenn du so eine Konstuktion baust:
Zitat von: ather am 27 Oktober 2020, 13:20:54
Mqtt leitet das ganze ja auch wieder an den LichtB Dummy weiter
Denn: dummy ist KEIN MQTT-Gerät und hat daher keine Ahnung, an wen es ggf. die eingehende Info NICHT weitergeben darf. Daher steht auch in der commandref zu MQTT_GENERIC_BRIDGE speziell zu dummy:
Zitat
This attribute defines what happens when one and the same reading is both subscribed and posted. Possible values: 'all' and 'none'.
If 'none' is selected, than messages received via MQTT will not be published from the same device.
The setting 'all' does the opposite, so that the forwarding is possible.
If this attribute is missing, the default setting for all device types except 'dummy' is 'all' (so that actuators can receive commands and send their changes in the same time) and for dummies 'none' is used. This was chosen because dummies are often used as a kind of GUI switch element. In this case, 'all' might cause an endless loop of messages.
MQTT_GENERIC_BRIDGE kann das aber nur dann unterbinden, wenn es "ahnen kann", dass die Anweisung über MQTT kam, was auf dem "notify-Weg" nicht ohne weiteres klappt...
ZitatIch würde es sehr gerne sauber und einfacherer aufbauen, aber leider habe ich dazu zu wenig Wissen in Sachen MQTT, BridgeRegexp und co. und benötige daher noch Unterstützung.
Auch, wenn jetzt manche Dinge schon (via diesem notify) "irgendwie" funktionieren, wäre meine Empfehlung, das ganze nochmal sauber aufzugleisen. Dabei sei angemerkt, dass man von "sauber" sehr unterschiedliche Vorstellungen haben kann. Andere MQTT-Experten nutzen "dummy", um "fremde" Devices in FHEM zu "repräsentieren" (u.A. hexenmeister, von dem MQTT_GENERIC_BRIDGE stammt!), ich würde pauschal empfehlen, im MQTT-Umfeld komplett auf dummy zu verzichten und diesen Teil mit MQTT2_DEVICE zu machen.
Dazu mußt du erst mal verinnerlicht haben, dass es zwei sehr unterschiedliche Implementierungen für MQTT-Dinge in FHEM gibt, nämlich die ältere Generation MQTT/MQTT_DEVICE/MQTT_BRIDGE und die neuere Generation mit MQTT2_SERVER oder MQTT2_CLIENT und MQTT2_DEVICE. MQTT_GENERIC_BRIDGE hat eine Sonderstellung und "kann" mit allen Interface-Modulen, siehe auch https://wiki.fhem.de/wiki/MQTT#Installation_in_FHEM.
Für's erste würde ich mal empfehlen, ein MQTT2_CLIENT-Interface für den Mosquitto einzurichten und den auf "autocreate simple" zu stellen. Dann bekommst du ein "Sammeldevice", in dem praktisch sämtlicher Inhalt irgendwie zu finden sein sollte, den der mosquitto "kennt".
Diese Inhalte müssen wir dann sortieren - einen Teil verwerfen, einen Teil als Anweisungen nutzen, einen Teil an MQTT_GENERIC_BRIDGE weitergeben, usw..... Als Startpunkt für diesen Teil wäre m.E. mal ein Blick auf https://wiki.fhem.de/wiki/MQTT2_CLIENT zu empfehlen. Je nach deiner vorhandenen Topic-Struktur könnte dann gleich ignoreRegexp und bridgeRegexp gesetzt werden.
Vermutlich wird das erst mal verwirrend sein, aber einen besseren Weg kann ich grade noch nicht anbieten. Ggf. würde es Sinn machen, du würdest dein "Sammeldevice" dann mal (ggf. auszugsweise) als RAW hier einstellen (https://wiki.fhem.de/wiki/Import_von_Code_Snippets).
Also ich habe jetzt MQTT2_Client (Mein Loxoberry mit dem MQTT Gateway) und ein MQTT2_Device (GoogleHome) angelegt.
Auf meinem Raspi läuft dieser MQTT Gateway.
https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway (https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway)
die Raw definition kann ich dann später reinstellen.
Ist es so korrekt, dass ich hier den Raspi mit MQTT Gateway als Client angelegt habe?
Zitat von: ather am 27 Oktober 2020, 14:45:16
Ist es so korrekt, dass ich hier den Raspi mit MQTT Gateway als Client angelegt habe?
Vermutlich. Wobei sich die Beschreibung auf der verlinkten Seite bei loxwiki irgendwie komisch liest. Wenn du MQTT nur dazu nutzt, um mit FHEM zu sprechen, wäre es ggf. einfacher, MQTT2_SERVER als Broker zu wählen und den Mosquitto zu deaktivieren.
Vorteil: FHEM kann sehr viel einfacher zwischen den internen und externen MQTT-Infos unterscheiden.
Zitat von: ather am 27 Oktober 2020, 14:45:16
und ein MQTT2_Device (GoogleHome) angelegt.
Das verstehe ich nicht. Spricht dieses "GoogleHome" nativ MQTT? Ich vermute: nein. Dann ist bitte der Weg für dieses Device über MQTT_GENERIC_BRIDGE.
MQTT2_DEVICE nimmst du nur für die Geräte, die "nur" außerhalb von FHEM existieren und erst via MQTT in FHEM leben sollen (also insbesondere alles, was direkt über den Loxone-Server läuft und irgendwie nach FHEM soll, falls es sowas gibt).
Ich denke auch, dass das bzgl. GoogleHome unnötig ist!
Wenn ich das jetzt richtig verstanden habe ist der Plan: für "Geräte" in Loxone "gespiegelte" Devices in fhem per MQTT zu haben, oder?
Wenn dem so ist, dann geht eine gassistant-Integration eher durch setzen der entsprechenden Attribute beim jeweils angelegten "Spiegel-Device" (MQTT) in fhem...
...also statt deinem bislang verwendeten "dummy-Dingens"... ;)
Klarer Vorteil: wenn von Google was kommt ist das direkt beim Device (und somit auch in Loxone!?) und andersrum...
EDIT: wenn ich Quatsch erzähle einfach sagen, dann bin ich (sofort) ruhig... ;)
Gruß, Joachim
Vielleicht nochmal zur Erläuterung, was ich mit
Zitat von: Beta-User am 27 Oktober 2020, 15:04:03
Wenn du MQTT nur dazu nutzt, um mit FHEM zu sprechen, [...]
meine: In dem https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway#MQTTGateway-Kommunikationsdiagramm (https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway#MQTTGateway-Kommunikationsdiagramm) sind rechts diverse "nativ MQTT sprechende Geräte" abgebildet.
Wenn dort "rechts" nur FHEM steht, ist es einfacher mit MQTT2_SERVER, steht da vieles andere, das bereits zu deiner vollen Zufriedenheit in Loxone eingebunden ist, ist vermutlich mosquitto die bessere Wahl.
Das gilt allerdings nur, sofern es einfach ist, deine anderen MQTT-Geräte in Loxone einzubinden. Ist das nicht der Fall (z.B., weil FHEM via attrTemplate ziemlich viele "spezielle Devices" ganz gut in den Griff bekommt ;) ), ist es evtl. einfacher, eine "doppelte MQTT-Anbindung" für das Device zu installieren und die erst mal via MQTT2_SERVER, MQTT2_DEVICE und attrTemplate nach FHEM zu bringen und dann den Teil, den du eigentlich in Loxone haben willst dann über MQTT_GENERIC_BRIDGE zu realisieren. (EDIT: das mit "doppelt" ist vermutlich in den meisten Fällen zu kompliziert; in der Regel wird es reichen, einfach an beiden Enden ein "Device" zu haben, das für das Gerät steht und die Daten direkt vom Broker zu verwenden).
"Leider" gibt es viele Wege, das macht es teilweise verwirrend. Es wäre ggf. einfacher, konkret was zu sagen, wenn wir in etwa ein Bild hätten, wie die gesamte Landschaft denn eigentlich grob aussieht...
Aus dieser Beschreibung
Zitat von: ather am 22 Oktober 2020, 14:37:37
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.
hätte ich jetzt folgendes entnommen: Du brauchst für jedes "Ding", das du mit Sprachsteuerung (bzw. -Abfrage) versehen willst, ein entsprechendes "Device" in FHEM, das dann passende Sprachsteuerungsattribute bekommt.
Wenn das die Mehrzahl deiner Geräte ist, könnte man FHEM als eine Art "hardware abstraction layer" ausgestalten und sollte dann auch möglichst alles in FHEM haben. Spräche auch für native MQTT-Geräte dafür, die mit Prio in FHEM zu verwalten => MQTT2_SERVER.
Die Ausnahme wären dann nur Geräte, die "in Loxone" nativ sind... (kann man das verstehen...?!?)
Hallo Zusammen,
Zitatwenn wir in etwa ein Bild hätten, wie die gesamte Landschaft denn eigentlich grob aussieht...
Was genau meinst du mit Landschaft? Wie kann ich Sie dir besser beschreiben?
ZitatWenn dort "rechts" nur FHEM steht, ist es einfacher mit MQTT2_SERVER, steht da vieles andere, das bereits zu deiner vollen Zufriedenheit in Loxone eingebunden ist, ist vermutlich mosquitto die bessere Wahl.
Ja tatsächlich steht dort rechts bei mir nur FHEM. Andere Systeme sind bis jetzt auch nicht geplant.
Über Fhem sollen andere Geräte, wie GardenaSmart, Google usw. in Loxone eingebunden werden.
Habe auch bemerkt,dass ich bereits eine MQTT_GENERIC_BRIDGE hatte die eben Daten übermittelt. Bis jetzt nur die von Gardena.
Raw
Zitatdefmod mqttGeneric MQTT_GENERIC_BRIDGE MQTT2
attr mqttGeneric IODev lb_mosquitto
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1
attr mqttGeneric globalPublish *:topic={"fhem/$device/$reading"}
attr mqttGeneric room MQTT2
setstate mqttGeneric 2020-10-28 14:57:40 device-count 0
setstate mqttGeneric 2020-10-28 14:57:40 incoming-count 0
setstate mqttGeneric 2020-10-28 15:17:10 outgoing-count 68877
setstate mqttGeneric 2020-10-28 15:17:10 transmission-state outgoing publish sent
setstate mqttGeneric 2020-10-28 14:57:40 updated-reading-count 0
setstate mqttGeneric 2020-10-28 14:57:40 updated-set-count 0
lb_mosquitto ist ebenfalls angelegt:
Zitatdefmod lb_mosquitto MQTT loxberry:1883
setstate lb_mosquitto opened
setstate lb_mosquitto 2020-10-28 15:17:43 connection active
setstate lb_mosquitto 2020-10-20 13:39:18 state opened
ZitatDas gilt allerdings nur, sofern es einfach ist, deine anderen MQTT-Geräte in Loxone einzubinden. Ist das nicht der Fall (z.B., weil FHEM via attrTemplate ziemlich viele "spezielle Devices" ganz gut in den Griff bekommt ;) ), ist es evtl. einfacher, eine "doppelte MQTT-Anbindung" für das Device zu installieren und die erst mal via MQTT2_SERVER, MQTT2_DEVICE und attrTemplate nach FHEM zu bringen und dann den Teil, den du eigentlich in Loxone haben willst dann über MQTT_GENERIC_BRIDGE zu realisieren. (EDIT: das mit "doppelt" ist vermutlich in den meisten Fällen zu kompliziert; in der Regel wird es reichen, einfach an beiden Enden ein "Device" zu haben, das für das Gerät steht und die Daten direkt vom Broker zu verwenden).
Bis jetzt habe ich keine Geräte mit MQTT. Aber ja wenn ich etwas dazu nehme würde ich es evtl über Loxberry Plugin oder über fhem in Loxone einbinden um den Miniserver von Loxone zu entlasten.
Zitathätte ich jetzt folgendes entnommen: Du brauchst für jedes "Ding", das du mit Sprachsteuerung (bzw. -Abfrage) versehen willst, ein entsprechendes "Device" in FHEM, das dann passende Sprachsteuerungsattribute bekommt.
Wenn das die Mehrzahl deiner Geräte ist, könnte man FHEM als eine Art "hardware abstraction layer" ausgestalten und sollte dann auch möglichst alles in FHEM haben. Spräche auch für native MQTT-Geräte dafür, die mit Prio in FHEM zu verwalten => MQTT2_SERVER.
Genau so habe ich es verstanden. pro Gerät muss ich ein Device bilden und es mit einem Namen versehen. Sobald ich es in den Raum GoogleHome einfüge, erstellt das Modul gasisstant automatisch ein Gerät in Google home und lässt sich per Sprache schalten. Funktioniert auch ganz gut.
Wie mache ich jetzt weiter? Bin im Moment etwas ratlos?
Soll ich jetzt das MQTT2_device GoogleHome wieder entfernen? und MQTT_Server erstellen für die Lampe z.B?
Gruß
Ather
Zitat von: ather am 28 Oktober 2020, 15:26:49
Hallo Zusammen,
Was genau meinst du mit Landschaft? Wie kann ich Sie dir besser beschreiben?
In etwa das, was auf dem Schaubild zu sehen ist. Das sollte erst mal reichen.
ZitatJa tatsächlich steht dort rechts bei mir nur FHEM. Andere Systeme sind bis jetzt auch nicht geplant.
Über Fhem sollen andere Geräte, wie GardenaSmart, Google usw. in Loxone eingebunden werden.
Du wirst um eine gewisse Einarbeitung in FHEM nicht rumkommen. M.E. gibt es einen prinzipiellen Unterschied zwischen GardenaSmart und Google (damit ist gassistant gemeint, nehme ich an): GardenaSmart dient der Einbindung von Hardware, gassistant ist eigentlich eine Art "input"-Device, das (btw.: wie die MQTT_GENERIC_BRIDGE) "quer" über alle anderen Devices eine zusätzliche Funktionalität einzieht.
Zitat
Soll ich jetzt das MQTT2_device GoogleHome wieder entfernen?
MAn. braucht gassistant keine Entsprechung in der MQTT-Welt; wie gesagt: das ist eine andere Ebene.
Zitat
und MQTT_Server erstellen für die Lampe z.B?
Auch MQTT2_SERVER ist eine Art Querschnittsdevice. Da du keine weiteren Geräte hast, die MQTT sprechen, würde ich erst mal vorschlagen, beim setup mit mosquitto zu bleiben; darum können wir uns ggf. am Ende nochmal kümmern, wenn alles andere klappt...
Zitat
Wie mache ich jetzt weiter?
Mein Vorschlag:
Wir gliedern das in 3-4 Teile:
Teil A - Vorbereitung
Teil B - Loxone-Hardware-Elemente nach FHEM bringen (für Sprachsteuerung)
Teil C - FHEM-Hardware-Elemente nach Loxone bringen (für GUI?)
Teil D - Nachbereitung (optional)
Erst mal zu
Teil A - VorbereitungZumindest ich, vermutlich aber auch du werden uns leichter tun, wenn wir das ganze mit MQTT2_.*-Modulen umsetzen. Daher werden wir als erstes lb_mosquitto rauswerfen und mit einem MQTT2_CLIENT als IO-Modul zum mosquitto hin arbeiten. Folgende Befehle sind dazu abzusetzen:
list -r TYPE=MQTT_DEVICEBitte den output (falls es welchen gibt) rauskopieren und wegspeichern.
Dann
delete lb_mosquitto
delete TYPE=MQTT_DEVICE
define defmod lb_mosquitto MQTT2_CLIENT loxberry:1883
attr lb_mosquitto room MQTT2
Was passiert dabei: Der TYPE des Interfaces wird geändert, und um Problemen vorzubeugen, werfen wir MQTT_DEVICE-Type Geräte auch gleich raus. Da MQTT_GENERIC_BRIDGE mit beidem "kann", sollte die eigentlich erst mal weiter funktionieren (in Senderichtung=aus FHEM heraus sowieso).
Dann schauen wir mal, was der mosquitto so an Daten parat hält:
attr lb_mosquitto autocreate simpleDas kann dazu führen, dass die MQTT_GENERIC_BRIDGE (MGB) erst mal nicht mehr (empfangsseitig) funktioniert.
Wir können das dann wieder reparieren, aber dazu müssen wir die Infos, die über die MGB gehen sollen von denen trennen, die als "natives MQTT2_DEVICE" leben sollen.
Anders gesagt: Du brauchst getrennte Topic-Pfade für die Kommunikation von und zur MGB und für die Hardware, die direkt an dem Loxberry hängt und dann "nur" über FHEM mit Sprachsteuerung versehen werden soll.
Damit wären wir bei
Teil B - Loxone-Hardware-Elemente nach FHEM bringen (für Sprachsteuerung)Da ist mir aber nicht so richtig klar, wie z.B. der "Rollladen" von links auf der Zeichnung "ver-MQTT't" wird.
Von daher wäre der betreffende Auszug aus dem durch "autocreate simple" erzeugten Gerät interessant. Du bekommst das in FHEM mit
list -r TYPE=MQTT2_DEVICE(Bitte kritisch durchsehen, ob da vertrauliche Infos drin sind und ggf. nur auszugsweise posten. Wenn wir das haben, können wir dann versuchen, diesen Teil fertigzustellen, bevor wir den nächsten Schritt machen. Wir können den aber auch vorziehen, wenn dir das lieber ist.
Ok habe ich so gemacht.
hier die Lsit bzw. Auzug:
define MQTT2_lb_mosquitto MQTT2_DEVICE lb_mosquitto
attr MQTT2_lb_mosquitto IODev lb_mosquitto
attr MQTT2_lb_mosquitto readingList lb_mosquitto:loxberry/mqttgateway/status:.* status\
lb_mosquitto:loxberry/mqttgateway/keepaliveepoch:.* keepaliveepoch\
lb_mosquitto:fhem/n_SYS_MQTT_cmnd/state:.* state\
lb_mosquitto:fhem/Gardena_Bridge/token:.* token\
lb_mosquitto:fhem/Gardena_Bridge/state:.* state\
lb_mosquitto:fhem/Gardena_Bridge/lastRequestState:.* lastRequestState\
lb_mosquitto:fhem/Gardena_Bridge/name:.* name\
lb_mosquitto:fhem/Gardena_Bridge/authorized_user_ids:.* authorized_user_ids\
lb_mosquitto:fhem/Gardena_Bridge/devices:.* devices\
lb_mosquitto:fhem/Gardena_Bridge/longitude:.* longitude\
lb_mosquitto:fhem/Gardena_Bridge/gateway_time_zone_offset:.* gateway_time_zone_offset\
lb_mosquitto:fhem/Gardena_Bridge/gateway_time_zone:.* gateway_time_zone\
lb_mosquitto:fhem/Gardena_Bridge/address:.* address\
lb_mosquitto:fhem/Gardena_Bridge/city:.* city\
.
.
.lb_mosquitto:fhem/SILENO/state:.* state\
lb_mosquitto:fhem/SILENO/mower_type-base_software_up_to_date:.* mower_type-base_software_up_to_date\
lb_mosquitto:fhem/SILENO/mower_type-mmi_version:.* mower_type-mmi_version\
lb_mosquitto:fhem/SILENO/mower_type-mainboard_version:.* mower_type-mainboard_version\
lb_mosquitto:fhem/SILENO/mower_type-device_type:.* mower_type-device_type\
lb_mosquitto:fhem/SILENO/mower_type-device_variant:.* mower_type-device_variant\
.
.
.
.lb_mosquitto:fhem/SYS_MQTT/cmnd:.* cmnd\
lb_mosquitto:fhem/Google/gassistantFHEM\xxx\xxxxxURL:.* gassistantFHEM.loginURL\
lb_mosquitto:fhem/Google/gassistant-fhem:.* gassistant-fhem\
lb_mosquitto:fhem/Google/gassistant-fhem-version:.* gassistant-fhem-version\
lb_mosquitto:fhem/Google/gassistant-fhem-lastServerError:.* gassistant-fhem-lastServerError\
lb_mosquitto:fhem/Google/gassistant-fhem-connection:.* gassistant-fhem-connection\
lb_mosquitto:fhem/Google/gassistant-fhem-lasterror:.* gassistant-fhem-lasterror\
.
..
.
lb_mosquitto:fhem/RolloWz/state:.* state\
lb_mosquitto:fhem/RolloB/command:.* command\
lb_mosquitto:fhem/RolloB/desired_pct:.* desired_pct\
lb_mosquitto:fhem/RolloB/last_drive:.* last_drive\
lb_mosquitto:fhem/RolloB/state:.* state\
lb_mosquitto:fhem/RolloB/drive-type:.* drive-type\
lb_mosquitto:fhem/RolloB/pct:.* pct\
lb_mosquitto:fhem/FileLog_SILENO/state:.* state\
lb_mosquitto:fhem/loxberrymqtt2/state:.* state.
.
.
setstate MQTT2_lb_mosquitto DISCONNECTED
.
.
setstate MQTT2_lb_mosquitto 2020-10-29 13:19:36 mower_type-base_software_up_to_date 1
setstate MQTT2_lb_mosquitto 2020-10-29 13:19:36 mower_type-device_type 13
setstate MQTT2_lb_mosquitto 2020-10-29 13:19:36 mower_type-device_variant 1
setstate MQTT2_lb_mosquitto 2020-10-29 13:19:36 mower_type-mainboard_version 10.35
.
.
.
.
Wahrscheinlich werden hier noch die ganzen readings von der ehemahligen installation angezeigt.
Jetzt habe ich ein MQTT2_client "lb_mosquitto" (opened) und ein MQTT2_Device "MQTT2_lb_mosquitto" (disconnected) der automatisch angelegt wurde.
Im "MQTT2_lb_mosquitto" sehe ich jetzt alle aktuellen readings unter readingList, obwohl da steht disconnected.
Ist das so Corrrect?
wie gehts jetzt weiter?
OK, dann versuchen wir das mal auszusortieren...
Wenn ich das richtig deute, schubst FHEM alle Readings usw. nach MQTT. Das sollte m.E. selektiver erfolgen (also eigentlich nicht via "globalPublish", sondern via mqttDefaults in der MGB und dann Einzelanweisungen an jedem Device) bzw. wenn, dann in jedem Fall auch auf einem dezidierten Unterpfad geschehen. Daher nur unter Vorbehalt:
attr mqttGeneric globalPublish *:topic={"fhem/MGB/out/readings/$device/$reading"}
Besser wäre sowas wie:
attr mqttGeneric globalDefaults base=fhem/MGB/
(bin aber auch bei den Details zu MGB nicht durch, es gibt hier irgendwo einen Thread mit "Beispielen" zu diesem Modul).
Damit die nicht wieder in FHEM ankommen, beschränken wir die subscription des CLIENT:
attr lb_mosquitto ignoreRegexp fhem/MGB/out
Danach solltest du eigentlich erst mal alles löschen, was mosquitto so an gespeicherten Messages hatte; vermutlich geht das am einfachsten, wenn du die DB löschst, wie hier vorgeschlagen: https://stackoverflow.com/questions/36729300/how-to-clear-all-retained-mqtt-messages-from-mosquitto#comment76794971_36729560. Sollte man aber nur machen, wenn sonst nichts wichtiges drauf war...
Kurz zur angedachten Topic-Struktur:
fhem/MGB/out => alle Readings, die von FHEM über die MGB an den Broker übermittelt werden
fhem/MGB/in => alle Anweisungen, die FHEM über die MGB erhalten und auswerten soll
loxberry/out => alle Anweisungen, die von MQTT2_DEVICE-Geräten in FHEM empfangen werden sollen
loxberry/in => alle Anweisungen, die FHEM (über MQTT2_DEVICE-Geräte) an Loxone senden soll;
Die letzten beiden Pfade gelten für die Dinge, die in Loxone "schon immer" exisitert haben und nicht mit FHEM zusammenhängen, die ersten beiden für alles, was in FHEM an _steuerbarer Hardware_ (oder an Messdatenerfassung) vorhanden ist und von Loxone aus erkannt und gesteuert werden soll. Wie du unschwer erkennen kannst, wird derzeit sehr viel mehr an mosquitto übertragen, als du eigentlich brauchst...
Falls du schon irgendwas von Loxone aus in Richtung MQTT angepaßt hattest, solltest du die Pfade dann auch entsprechend anpassen.
Danach kannst du die RAW-Definition von MQTT2_lb_mosquitto erst mal wegsichern und dann dieses Device in FHEM wieder löschen.
Nach einem Neustart des Mosquitto müßte dann wieder ein (deutlich kleineres) MQTT2_DEVICE mit diesem Namen erscheinen.
Den "notify-Pfad" würde ich erst mal hintanstellen, wie gesagt, ich meine, dass man den eigentlich besser nicht verwenden sollte, aber an der Stelle der Nachweis, dass das auch via MQTT2_DEVICE geht - dieses eine Device ersetzt dann die Kombination von MQTT_DEVICE und notify (allerdings ohne Log, aber das könnte man auch noch anflanschen...):
define MQTT2_Notify_replacement MQTT2_DEVICE n_replacement
fhem/SYS_MQTT/cmnd:.* { fhem($EVENT) }
Das ganze ist aber ein einziges Sicherheitsloch (der Broker muss zumindest von Loxone her ohne TLS oä. auskommen, weil das plugin das nicht kann!), daher sollte man das - genau wie das globale publish von FHEM aus - SEIN LASSEN...
Danach müssen wir uns wieder um das "MQTT2_lb_mosquitto" kümmern:
- zum einen speicherst du die neue (RAW-)Konfiguration erst mal wieder weg und wendest dann das attrTemplate "MQTT2_CLIENT_general_bridge" an.
- Die damit erzeugte bridgeRegexp erweiterst du um eine Zeile:
attr MQTT2_lb_mosquitto bridgeRegexp [...]
[\b]fhem/MGB/in.*:.* ""
Das sollte dazu führen, dass alle über "fhem/MGB/in" eingehenden Messages an die MQTT_GENERIC_BRIDGE auch bei eingeschaltetem autocreate weitergegeben werden.
Jetzt kümmern wir uns noch um den Eingangspfad von den Loxone-Devices und erweitern die bridgeRegexp um eine weitere Zeile - hier mal angenommen, der Name des Geräts in Loxone steht hinter dem "out" als ein Element des Topic-Pfades:
attr MQTT2_lb_mosquitto bridgeRegexp [...]
[\b]loxberry/out/([^/]+).*:.* "lb_$1"
Das sollte bewirken, dass alles, was über diesen Pfad an Infos kommt dann auch an demselben MQTT2_DEVICE in FHEM ankommt. Die Namensgebung ist dann erst mal MQTT2_lb_<nameInLoxone>.
Damit haben wir folgendes Gesamtbild für die einzelnen Topics von oben (von FHEM aus gesehen):
fhem/MGB/out => werden von der ignoreRegexp am IO verworfen
fhem/MGB/in => werden an die MGB weitergeleitet. Die Weiterverarbeitung in FHEM setzt jetzt voraus, dass am eigentlichen Zieldevice eine Auswertung definiert wird;
loxberry/out => füllt je Unter-Topic-Pfad ein MQTT2_DEVICE in FHEM.
loxberry/in => verwenden wir für die setList-Attribute an den betreffenden Devices. (Kommt noch).
Ist damit in etwa nachvollziehbar, wie das am Ende aussehen soll?
bei mqttGeneric habe ich bereits folgende Attribute:
globalDefaults
sub:qos=2 pub:qos=0 retain=1
globalPublish
*:topic={"fhem/$device/$reading"}
soll ich die jetzt löschen? und deine neu anlegen?
verstehe ich es richtig?
Kommt drauf an, für welchen Weg du dich entscheidest. Wenn du weg willst von dem "globalPublish", kannst du die global defaults einfach um die "base"-Angbae erweitern.
"retain" kann aber auch (v.a. allerdings von der eingehenden Seite her) komische Nebenwirkungen haben, wenn FHEM oder der Broker neu gestartet werden... (Ist mehr ein Punkt, den man im Hinterkopf behalten sollte).
ZitatDanach solltest du eigentlich erst mal alles löschen, was mosquitto so an gespeicherten Messages hatte; vermutlich geht das am einfachsten, wenn du die DB löschst, wie hier vorgeschlagen: https://stackoverflow.com/questions/36729300/how-to-clear-all-retained-mqtt-messages-from-mosquitto#comment76794971_36729560. Sollte man aber nur machen, wenn sonst nichts wichtiges drauf war...
Das habe ich noch net ganz gecheckt bzw. so verstanden:
- über putty als root anmelden am raspi
- Dann folgendes eingenben:
#!/bin/sh
echo "cleaning " $1 " :: usage: cleanmqtt <192.168.178.XX:1833>"
mosquitto_sub -h $1 -t "#" -v | while read line; do mosquitto_pub -h $1 -t "${line% *}" -r -n; done
ist das so korekt?
Zitat von: ather am 29 Oktober 2020, 15:15:36
Das habe ich noch net ganz gecheckt bzw. so verstanden:
- über putty als root anmelden am raspi
Win 10 sollte ssh auch nativ können... (k.A., ich habe einen Linux-Rechner für sowas)
Zitat
- Dann folgendes eingenben:
...ehrlich gesagt: k.A....
Ich habe das nur kurz über die SuFu meiner Wahl gefunden und hätte eher die "Datenbank löschen"-Variante darüber genommen.
Aber wenn du sowieso mit allem ganz am Anfang stehst, stellt sich mir die Frage, ob es nicht einfacher wäre, gleich den Schritt zum MQTT2_SERVER zu gehen...
Das hieße: mosquitto deinstallieren (falls es ein Debian-Derivat ist, sollte das mit "sudo apt-get remove mosquitto" funktionieren), MQTT2_SERVER in FHEM definieren ("define m2server MQTT2_SERVER 1883 global") und dann in dem Loxone-Ding eben die IP des FHEM-Servers als Broker angeben und den MQTT2_CLIENT wieder löschen+IODev der MGB auf den m2server legen...
ZitatAber wenn du sowieso mit allem ganz am Anfang stehst, stellt sich mir die Frage, ob es nicht einfacher wäre, gleich den Schritt zum MQTT2_SERVER zu gehen...
puhh das weiss ich leider auch nicht was besser wäre.
Ich habe jetzt die Schritte gemacht und ein neues kleineres "MQTT2_lb_mosquitto" erzeugt
hier steht in den readings nur noch:
lb_mosquitto:loxberry/mqttgateway/keepaliveepoch:.* keepaliveepochbridgeRegexp habe ich auch um die zeilen erweitert wie du geschrieben hast.
Das sieht dann so aus:
(tele|stat)[/]([^/]+)[/].*:.* "$2"
shellies[/]([^/]+)[/].*:.* "$1"
(zigbee2mqtt)/bridge/.*:.* "$1"
(ESPClient_[^/]+)/.*:.* "$1"
(ebusd)/global/.*:.* "$1"
valetudo[/]([^/]+)[/].*:.* "$1"
[^/]+[/](ems-esp[^/]+)/start:.* "$1"
wallpanel[/]([^/]+)[/].*:.* "wallpanel_$1"
(wled)[/]([^/]+)[/].*:.* "$1_$2"
(go-eCharger)[/]([^/]+)[/].*:.* "go_eCharger_$2"
(owntracks)[/]([^/:]+)[/]([^/:]+).*:.* "$1_$2$3"
Advantech[/]([^/]+)[/].*:.* "$1"
(sonos)/connected.* "$1"
(tvheadend)[/][^/:]+.* "$1"
(mygateway[\d]+)-(in|out)/.* "$1"
(milight)/LWT:.* "$1"
home/(O[^/]*M[^/]*G[^/]*)/LWT:.* "$1"
homeassistant/.*/config:.* ""
[\b]fhem/MGB/in.*:.* ""
[\b]loxberry/out/([^/]+).*:.* "lb_$1" oder muss das [\b] weg?
Was nun.
Zitat von: ather am 29 Oktober 2020, 15:41:25
puhh das weiss ich leider auch nicht was besser wäre.
Ich habe jetzt die Schritte gemacht und ein neues kleineres "MQTT2_lb_mosquitto" erzeugt
Na ja, wenn erst mal "mosquitto" wieder "sauber" ist, können wir auch damit weitermachen.
Nur um sicherzugehen, dass dem wirklich so ist: hast du alle drei Elemente mal neu gestartet? Also Loxone, den Rechner, auf dem Mosquitto läuft und FHEM?
Hinter
loxberry/mqttgateway/scheint der eigentliche Dienst auf dem Loxone-Ding zu sein. Würde das auch in die bridgeRegexp mit aufnehmen, damit das, was dazu an Infos (ggf. auch später noch) auch in einem eigenen Device landet.
Zitat von: ather am 29 Oktober 2020, 15:41:25
bridgeRegexp habe ich auch um die zeilen erweitert wie du geschrieben hast.
Das sieht dann so aus: [...]
[\b]fhem/MGB/in.*:.* ""
[\b]loxberry/out/([^/]+).*:.* "lb_$1"
Das [\b] kann m.e. da stehen bleiben. Das ist ein regex-Zeichen und soll nur absichern, dass die eingehende Message einigermaßen gut paßt. Falls es nachweislich Probleme macht, kann es auch raus.
Zitat
Was nun.
Würde vorschlagen, wir schauen uns jetzt mal zwei oder drei Devices an...
Was ist "RolloB", und was "SILENO"?
Falls es "native FHEM-Geräte" sind, würde ich vorschlagen, du versuchst mal, die für dich wichtigen Readings von RolloB zu "ver-MQTT-en" unter Zuhilfenahme dieses Threads: https://forum.fhem.de/index.php/topic,91642.0.html (https://forum.fhem.de/index.php/topic,91642.0.html). Ggf. kannst du dich auch mal an die Steuerungsseite von Loxone/MQTT aus machen (aber bitte über "gute" MQTT-Anweisungen, nicht über das Publishen von "set device abc").
Die SILENO-Readingnamen sehen komisch aus, das scheint ein expandJSON-Ergebnis zu sein. Falls das ein MQTT_DEVICE war, würde ich das noch zurückstellen, das bekommen wir via MQTT2_DEVICE sicher vorher noch vereinfacht.
Falls du RolloB hinbekommst, wäre damit klar, wie "Teil C" funktioniert.
Ansonsten sollten wir mal Teil B anschauen, aber wie geschrieben, ist mir noch nicht klar, wie "native Loxone-Geräte" ihren Status nach MQTT publishen und wie sie Befehle empfangen... Bitte experimentiere erst mal mit dem Publishen rum.
Schau mal nach, ob nicht doch bereits weitere MQTT2_DEVICEs erstellt worden sind:
list TYPE=MQTT2_DEVICESupport via Teamviewer kann und will ich nicht leisten, zumal eventuelle Nachahmer das dann nicht nachlesen/-denken können.
ZitatSchau mal nach, ob nicht doch bereits weitere MQTT2_DEVICEs erstellt worden sind:
Code: [Auswählen]
list TYPE=MQTT2_DEVICE
es sind nur 2 devices erstellt worden.Nämlich:
MQTT2_Notify_replacement
MQTT2_lb_mosquitto
Würde sagen wir nehmen das Device (Dummy) "LICHTB". Ist eigentlich nur Licht im Büro mit dem Reading "state: on|off".
wenn ich dieses reading jetzt weiterleiten will mache ich was?
attr MQTT2_lb_mosquitto mqttSubscribe state:topic=<topic>Diesen Attr in den LICHTB Dummy? Was müsste ich dann für <topic> einsetzen? (on:off)?
Sende ich jetzt an das Device "MQTT2_lb_mosquitto" oder an MGB? Ich habe das noch nicht genau verstanden wer an wen sendet.
Sorry.
Sileno ist der Rasenmäher und kommuniziert über JSON, das stimmt.
Nope.
Zitat von: Beta-User am 27 Oktober 2020, 13:45:51
Auch, wenn jetzt manche Dinge schon (via diesem notify) "irgendwie" funktionieren, wäre meine Empfehlung, das ganze nochmal sauber aufzugleisen. Dabei sei angemerkt, dass man von "sauber" sehr unterschiedliche Vorstellungen haben kann. Andere MQTT-Experten nutzen "dummy", um "fremde" Devices in FHEM zu "repräsentieren" (u.A. hexenmeister, von dem MQTT_GENERIC_BRIDGE stammt!), ich würde pauschal empfehlen, im MQTT-Umfeld komplett auf dummy zu verzichten und diesen Teil mit MQTT2_DEVICE zu machen.
Kurz: vergiß erst mal, dass es "dummy" als Device gibt.
Kannst du bitte beschreiben, wie "LICHTB" in der Wirklichkeit verdrahtet ist? Ich vermute, es ist eigentlich ein Loxone-Device?
Dann hätte ich gerne die Konfiguration, die du in Loxone hast, um den Status via MQTT zu publishen und wo das Ding auf Anweisungen von MQTT-Seite lauscht. Optimalerweise sollte das sowas in der Richtung sein (dimmbar mit 100%):
Loxone=>FHEM:
loxberry/out/LichtBuero/state
loxberry/out/LichtBuero/pct
FHEM=>Loxone:
loxberry/in/LichtBuero/state
loxberry/in/LichtBuero/pct
Falls es einfacher ist, das in JSON zu übermitteln: geht auch, es wäre aber in allen Fällen gut, es würde on/off verwendet statt 1/0...
Zitat von: ather am 29 Oktober 2020, 15:15:36
- über putty als root anmelden am raspi
Zwei Anmerkungen dazu:
als root anmelden tut man nicht. Man meldet sich als user an (gerne pi) und verwendet dann sudo.
putty ist aus meiner Sicht überholt. Zusätzliches Tool ... Windows 10 kann seit zwei Jahren ssh. Also einfach:
ssh pi@NameOderAdresseDesPiOderJedesAnderenSSHfähigemSystems und schon ist man drin.
Siehe auch meine Tipps hier: https://heinz-otto.blogspot.com/2018/06/windows-hat-jetzt-ssh.html
Gruß Otto
ZitatKannst du bitte beschreiben, wie "LICHTB" in der Wirklichkeit verdrahtet ist?
LichtB ist an einer LoxoneExtension (Relais) angeschlossen und kann von loxone geschaltet werden.
Von loxone aus kann ich den Status der Lampe entweder als UDP oder als HTTP als Virtuellen ausgang senden.
Bis jetzt habe ich einfach den Befehl
/fhem?cmd=setreading%20LichtB%20state%20on&XHR=1
an Fhem weitergegeben und es folgte eine schaltung des Dummys.
Bei den Virtuellen Eingängen funktioniert es etwas anders. Hier habe ich das reading (Event) an den Raspi > MQTT gateway weitergegeben und mittels einer "Text-to-Value conversions" den Wert on auf 1 und off auf 0 gesetzt. Loxone kann mit on/Off meines wissens nix anfangen.
Nun wird der konvertierte Wert (on>1) an Loxone als http weitergegeben und ich kann Ihn mit einem virtuellen Eingang in Loxone abgreifen und damit etwas schalten oder anzeigen.
Das ist eben der Vorteil von dem loxberry Plugin MQTT_Gateway.
Übrigens, mir ist vorhin eingefallen, das wenn ich es so mache wie am Anfang, ich die Dauerschleife verweiden kann, indem ich die Eingänge On und Off trenne und den Befehl On mittels eines Und-Bausteins nur dann durchschalte in Loxone, wenn das Licht aus ist. Off kann ich immer durchgeschaltet werden. Dies kann man in Loxone mittels eines virtuellen Tastschalters realisieren.
Aber ich bin schon gespannt ob wir es auch so direkt hinbekommen.
Das Licht ist hier nicht Dimmbar.
Zitat von: Otto123 am 29 Oktober 2020, 17:08:28
Zwei Anmerkungen dazu:
als root anmelden tut man nicht. Man meldet sich als user an (gerne pi) und verwendet dann sudo.
putty ist aus meiner Sicht überholt. Zusätzliches Tool ... Windows 10 kann seit zwei Jahren ssh. Also einfach:
ssh pi@NameOderAdresseDesPiOderJedesAnderenSSHfähigemSystems und schon ist man drin.
Siehe auch meine Tipps hier: https://heinz-otto.blogspot.com/2018/06/windows-hat-jetzt-ssh.html
Gruß Otto
Noch dazu wo root-Zugang eh (erst mal) gesperrt ist...
...und das aus eben gutem Grund! ;)
Zitat
/fhem?cmd=setreading%20LichtB%20state%20on&XHR=1
d.h. du hast (zumindest für diesen "speziellen"!?) Fhem-Web-Zugang csrf-Token deaktiviert?!
Da solltest du noch mal drüber nachdenken!
Ich würde ja wenn schon einen fixen Token nehmen...
Bzw. wenn dann alles auf MQTT läuft das "deaktivierte" Token wieder aktivieren (oder den "speziellen"?! Web-Zugang dann ganz löschen).
Gruß, Joachim
Zitatd.h. du hast (zumindest für diesen "speziellen"!?) Fhem-Web-Zugang csrf-Token deaktiviert?!
genau in dem Fall ging das nicht anders bzw. konnte ich es nicht anders.
Aber z.B beim Sileno habe ich per UDP einen Virtuellen Befehl an Loxberry:11884 (UDP eingang MQTT Gateway) gesendet, dieser hat dann den Befehl an Fhem weitergeleitet und fhem hat den Sileno gesteuert.
z.B der Befehl
/fhem/cmnd set SILENO startpoint disable 1 enable 2
Zitat von: ather am 29 Oktober 2020, 17:23:13
Bis jetzt habe ich einfach den Befehl
/fhem?cmd=setreading%20LichtB%20state%20on&XHR=1
Bitte Kommandos auch in Code-Tags.
Mein gedankliches Problem: Du kannst in FHEM nicht unterscheiden, was der Auslöser war - jedenfalls, wenn das Ding dann von dem Dummy aus auch wieder schaltbar sein soll. Damit läufst du Gefahr, genau die Schleife zu bauen, die du vermeiden wolltest.
Aber von mir aus kann das dann auch ein dummy bleiben, wenn das bisher (in beide Richtungen) funktioniert hat. ABER: das hat dann m.E. nichts mit MQTT zu tun, ich hätte sonst keine Idee, wie man zwischen einer Schaltanweisung über ein notify oder gassistant und einer innerhalb Loxone unterscheiden kann. Oder soll Loxone ein reines slave-Device werden? Wenn da gar keine Logik drauf ist, könnte es gehen (aber dann bräuchte man auch das setreading nicht?). Bin grade ein wenig verloren und hoffe, du kannst meine Gedanken erahnen?
Zitat von: ather am 29 Oktober 2020, 17:34:49
/fhem/cmnd set SILENO startpoint disable 1 enable 2
Nochmal: Das ist kein sauberes MQTT, was du da treibst. Laß das, sonst wird das ein unsauberer Verhau, bei dem niemand durchblickt, warum was passiert und dann auch wieder weitergeleitet wird...
Zitat von: ather am 29 Oktober 2020, 17:34:49
genau in dem Fall ging das nicht anders bzw. konnte ich es nicht anders.
https://wiki.fhem.de/wiki/CsrfToken-HowTo
EDIT: also einfach &fwcsrf=csrf_196525024154371 dazupacken und dann eben bei FhemWeb Attribut csrf csrf_196525024154371 setzen (es "darf" nat. auch ein anderes fixes Token ausgedacht werden ;) )...
Gruß, Joachim
Zitat von: MadMax-FHEM am 29 Oktober 2020, 17:37:29
https://wiki.fhem.de/wiki/CsrfToken-HowTo (https://wiki.fhem.de/wiki/CsrfToken-HowTo)
Gruß, Joachim
Yep.
Sowohl der "MQTT+notify"-(Un-)Weg wie die HTTP-Anweisung sollte dringend besser abgesichert werden (man sollte die Loxone-Jungs auch dazu verdonnern, alsbald eine sichere Authentifizierungsmöglichkeit via MQTT anzubieten!).
ZitatMein gedankliches Problem: Du kannst in FHEM nicht unterscheiden, was der Auslöser war - jedenfalls, wenn das Ding dann von dem Dummy aus auch wieder schaltbar sein soll. Damit läufst du Gefahr, genau die Schleife zu bauen, die du vermeiden wolltest.
Aber von mir aus kann das dann auch ein dummy bleiben, wenn das bisher (in beide Richtungen) funktioniert hat. ABER: das hat dann m.E. nichts mit MQTT zu tun, ich hätte sonst keine Idee, wie man zwischen einer Schaltanweisung über ein notify oder gassistant und einer innerhalb Loxone unterscheiden kann. Oder soll Loxone ein reines slave-Device werden? Wenn da gar keine Logik drauf ist, könnte es gehen (aber dann bräuchte man auch das setreading nicht?). Bin grade ein wenig verloren und hoffe, du kannst meine Gedanken erahnen?
Jep genauso entsteht die Schleife. Aber diese kann ich mit Loxone mittels Und-Baustein unterbinden. Klar das ist natürlich keine gute Lösung, aber das ist das einzige was bis jetzt funktioniert hat.
ZitatEDIT: also einfach &fwcsrf=csrf_196525024154371 dazupacken und dann eben bei FhemWeb Attribut csrf csrf_196525024154371 setzen (es "darf" nat. auch ein anderes fixes Token ausgedacht werden ;) )...
also wenn das geht kann man das natürlich auch machen. wählt man daa einfach einen beliebigen coden bzw muss er irgendwelche anforderungen erfüllen?
Zitat von: ather am 29 Oktober 2020, 17:56:26
Jep genauso entsteht die Schleife. Aber diese kann ich mit Loxone mittels Und-Baustein unterbinden. Klar das ist natürlich keine gute Lösung, aber das ist das einzige was bis jetzt funktioniert hat.
Das liegt aber m.E. schlicht daran, dass die ganze Konstruktion so nicht gut gewählt ist. Wenn irgend möglich, sollte man da klarere Strukturen schaffen, und (gute) MQTT-Implementierungen erlauben genau das: Unterscheiden zwischen dem, was Schaltanweisung ist und dem, was pure Statusrückmeldung ist...
Von daher würde ich dringend raten, alles an externer Kommunikation nach MQTT zu transferieren, was "in Loxone" stattfindet (und ggf. die Anforderung dann auch wieder an den Anbieter zurückzuspiegeln, falls es da Probleme gibt).
Zitat von: ather am 29 Oktober 2020, 17:56:26
also wenn das geht kann man das natürlich auch machen. wählt man daa einfach einen beliebigen coden bzw muss er irgendwelche anforderungen erfüllen?
Einfach entweder bei einem Fhem-Web welches noch den Token aktiv hat "klauen" oder das Attribut löschen, fhem neu starten und das dann angelegte Token nehmen und als fixes Token setzen ;)
Aber besser: Umstellung auf MQTT...
Dann kannst du Fhem-Web wieder aktivieren wie es sich gehört ;)
Gruß, Joachim
Hallo Zusammen,
ich hätte da eine klassische Anfängerfrage an euch bzw. benötige eure Hilfe:
Ich habe ein Modul dummy (RolloB) angelegt, welcher mir die Rollos über Gassistant steuert.
Jetzt müsste ich 2 readings erstellen, die jeweils eine 1 senden wenn ein bestimmtes Ereignis kommt.
z.B. Bei RolloB
die 2 readings sollen heissen:
1. Rollo auf
2. Rollo zu
Im dummy habe ich ein reading, das nennt sich state und hat folgende möglichen Werte: open/close
Wenn jetzt der state auf Open springt, dann soll das Reading "Rollo auf" eine 1 senden bzw. den wert 1 annehmen.
Und wenn state auf close springt, dann soll Rollo zu den Wert 1 senden und "rollo auf wieder auf 0 schalten.
Wie mache ich das am Dümmsten ;-)
Danke und Gruß
Ather
Hi,
meines Wissen können Readingnamen kein Leerzeichen enthalten. Da musst Du Dir was anderes ausdenken.
Ansonsten
setreading DeinDummy DeinReadingName DeinWertZitatUnd wenn state auf close springt, dann soll Rollo zu den Wert 1 senden und "rollo auf wieder auf 0 schalten.
Der Rest könnte über ein UserReading (https://fhem.de/commandref_DE.html#userReadings)gehen - in der Art:
attr RolloB userReadings RolloZu:state.* {ReadingsVal($name,'state','fehler') eq 'close' ?1:0}Das Andere kannst Du Dir selbst basteln. ;)
Gruß Otto
Zitat von: ather am 19 November 2020, 17:33:36
Ich habe ein Modul dummy (RolloB) angelegt, welcher mir die Rollos über Gassistant steuert.
(ich werde immer noch wuschig, wenn ich "dummy" lese und vermute immer noch, dass das Modul ROLLO eigentlich hier der bessere Weg wäre, vermutlich kann man da auch setreading Kommandos als "Relay" hinterlegen (und dann auch Prozentwerte ansteuern (!), aber was soll's...)
Würde auch auf userReadings tippen, davon aber zwei anlegen, die passend (und in meinem Beispiel dann auch wechselnd) getriggert werden und auch das anhalten ermöglichen sollten. Noch auf das "open/close" anzupassendes Beispiel:
defmod ot_dummy dummy
attr ot_dummy setList on:noArg off:noArg stop:noArg
attr ot_dummy userReadings auf:(on|off|stop) {return 0 if ReadingsVal($name,'state','on') ne 'on';; return 1}, zu:(on|off|stop) {return 0 if ReadingsVal($name,'state','off') ne 'off';; return 1}
attr ot_dummy webCmd on:off:stop
Zitat von: Beta-User am 19 November 2020, 17:53:29
(ich werde immer noch wuschig, wenn ich "dummy" lese und vermute immer noch, dass das Modul ROLLO eigentlich hier der bessere Weg wäre, vermutlich kann man da auch setreading Kommandos als "Relay" hinterlegen (und dann auch Prozentwerte ansteuern (!), aber was soll's...)
Hallo,
mit dem Modul Rollo habe ich es schon probiert, jedoch hat GoogleHome damit ein Problem und erkennt das Modul Rollo nicht als Rollo sondern als Dimmbare Lampe. Warum auch immer?.
Über den dummy (Type Blinds) steuere ich per Sprache und Gassistant meine Rollos.
Version von Beta-User hat funktioniert.
Wenn jetzt noch das selbstständige Rückstellung auf 0 klappt, wäre ich schon happy.
Wie kann man den Wert 1 auch selbständig zurück auf null stellen lassen, also nach ca. 1 sekunde? So dass es wie ein taster wirkt?
Vielleicht irgendein timer einbauen in Reading (z.b "at +00:00:05 set RolloAuf 0"), hs bei mir aber noch nicht funktioniert.
Also so habe ich es probiert:
RolloAuf:(open|close|stop) at +00:00:05 set RolloAuf 0 {return 0 if ReadingsVal($name,'state','open') ne 'open';; return 1}Danke euch beiden.
Gruß
Ather
Dein Code kann so nicht funktionieren. Das muss doch Fehlermeldungen geben?
Von einer Impulsschaltung stand aber nichts in deiner Anforderung :-\
Die Anforderung war (wenn close) dann 1 - ich halte in dem Fall die Umkehr der Abfrage (wenn nicht open) dann 1 für den falschen Ansatz. Das kann auch mal schief gehen.
Zitat von: Otto123 am 19 November 2020, 18:57:38
Dein Code kann so nicht funktionieren. Das muss doch Fehlermeldungen geben?
Von einer Impulsschaltung stand aber nichts in deiner Anforderung :-\
ja das stimmt er funktioniert nur so.
RolloAuf:(open|close|stop){return 0 if ReadingsVal($name,'state','open') ne 'open';; return 1 at +00:00:05 return 0},
RolloZU:(open|close|stop){return 0 if ReadingsVal($name,'state','close') ne 'close';; return 1 at +00:00:05 return 0}
Von einer Impulsschaltung stand aber nichts in deiner Anforderung Ja Genau eignetlich benötige ich nur ein Impulse auf den jeweiligen readings.
Wie mach ich das?
Gruß
Ather
Diese Konstrukt ist grober Unsinn!
return 1 at +00:00:05 return 0
Und über ein userReadings was sich nach einer Zeit selbst zurückstellt will ich eigentlich nicht nachdenken. :-[
Wie verarbeitest Du denn dieses Reading weiter? Mach dort den Impuls draus!
ZitatDiese Konstrukt ist grober Unsinn!
Sorry bin in Sachen Fhem und Perl blutiger Anfänger.
Habe diesen code von dir so probiert:
RolloZU:state.* {ReadingsVal($name,'state','fehler') eq 'close' ?1:0}
RolloAuf:state.* {ReadingsVal($name,'state','fehler') eq 'open' ?1:0}
Hat aber leider nicht funktioniert. Irgendwo ist da der Wurm.
ZitatWie verarbeitest Du denn dieses Reading weiter? Mach dort den Impuls draus!
Dieses Reading leite ich weiter per MQTT-Gateway an Loxone und steuere Damit meine Rollos und alles andere auch.
Mein Problem ist nur, wenn ich das Rollo z.B nur zur hälfte hochfahre,steht bei RolloAuf dann eine 1. Wenn ich aber dann wieder hochfahren will kann kein neuer impuls 1 kommen, da das reading ja bereits auf 1 steht. deswegen würde ich das gerne resetten.
Gruß
Ather
Ja ok - ich habe wieder nicht dran gedacht, dass es den state Event nicht gibt :)
Aber es ist egal ob Du Beta-users Code oder meinen nimmst, dass läuft aufs Gleiche hinaus - ist nur anders formuliert:
UserReadings werden mit Komma getrennt!
RolloZU:(open|close) {ReadingsVal($name,'state','fehler') eq 'close' ?1:0},RolloAuf:(open|close) {ReadingsVal($name,'state','fehler') eq 'open' ?1:0}ZitatDieses Reading leite ich weiter per MQTT-Gateway an Loxone
Wie?
Ich verstehe das Problem noch nicht: ein close erzeugt eine 1 ein nochmaliges close erzeugt wieder eine 1 - also vom event her ist das kein Problem? Wer verhindert den?
Was ich auch nicht verstehe: Wenn es open und close gibt - wozu braucht man dann zwei Dummy Readings die jeweils für sich open in 1 und close in 1 umwandeln? Kann man das nicht direkt übersetzen? Kannst Du das gesamte Konstrukt aufzeigen - damit man das verstehen kann?
Nimm ROLLO, kann nicht sein, dass das nicht mit Sprachsteuerung geht! Und dann direkte Publishers mit sleep dazwischen als up down command.
Zitat von: Beta-User am 19 November 2020, 19:48:14
Nimm ROLLO, kann nicht sein, dass das nicht mit Sprachsteuerung geht! Und dann direkte Publishers mit sleep dazwischen als up down command.
Habe jetzt mal ein Testrollo "ROLLO" angelegt. Leider erkennt Google Home das Ding nicht als Rollo an sondern als Dimmbare Lampe, bei der ich prozentual die Helligkeit einstellen kann.
Kein Plan warum das nicht geht. Wenn ich generictype blinds codiere, dann kann man nichts mehr steuern.
ZitatUnd dann direkte Publishers mit sleep dazwischen als up down command.
Was meinstu du damit? Wie mach ich das?
Gruß
Ather
Zunächst mal: ROLLO gibt es in 209 Installationen (von >5000 gemeldeten, also deutlich weniger wie hier user registriert sind) mit ca. 1200 Instanzen )= gesteuerten Rollläden; Quelle: https://fhem.de/stats/statistics.html). Ich kann mir nicht vorstellen, dass die 209 dort meldenden User alle keine Sprachsteuerung verwenden oder sich sonst niemand gemeldet hätte, wenn es ernsthafte Probleme an der Stelle gäbe. Vergiss also erst mal das mit der "Lampe", vermutlich ist es nur solange ein Problem, wie ROLLO nicht sauber eingerichtet ist. Soweit nachvollziehbar?
Das mit den publishes ist wie folgt:
Alle Client-Module zu MQTT (MQTT2_DEVICE, MQTT_GENERIC_BRIDGE, MQTT_DEVICE und ein paar Derivate mehr) haben zum Ziel, letztlich irgendwas an den MQTT-Server zu schicken, um darüber dann andere Client-Systeme entsprechend zu informieren. Schlussendlich bilden die alle einen String, der dann versendet wird. Alle MQTT-Interfaces in FHEM (00_MQTT.pm, 00_MQTT2_SERVER.pm und eben auch das von dir verwendete 00_MQTT2_CLIENT.pm) kennen daher die Option, den String auch direkt an das IO zu übergeben.
Wie, steht in der commandref (https://fhem.de/commandref_modular.html#MQTT2_CLIENT):
ZitatMQTT2_CLIENT is a cleanroom implementation of an MQTT client (which connects to an external server, like mosquitto) using no perl libraries. It serves as an IODev to MQTT2_DEVICES.
[...]
Set
- publish -r topic value
publish a message, -r denotes setting the retain flag.
Ergo solltest du als erstes lernen (und uns mitteilen), wie du direkt über das IO MQTT2_CLIENT deine Relays schalten kannst.
Das kann man dann in der Kommandozeile auch mit einem sleep verbinden:
set <IODev> publish loxberry/in/Rolladen1/Auf 1; sleep 0.5;set <IODev> publish loxberry/in/Rolladen1/Auf 0
Wenn das klappt, solltest du das komplette Kommando einschl. des sleep als Attribut an das ROLLO bringen können:
attr <Rollo-Device> rl_commandUp <string = dein Kommando...>Das hat aber mit dem global publish via MQTT_GENERIC_BRIDGE nichts zu tun (meine Empfehlung wäre immer noch, das anders zu lösen; wer auch immer diese Anleitung gemacht hat, hat vermutlich keine allzu vertieften FHEM-Kenntnisse und das ganze nicht bis zum Ende durchdacht, just my2ct.).
Zitat von: Otto123 am 19 November 2020, 19:32:05
Wie?
Ich verstehe das Problem noch nicht: ein close erzeugt eine 1 ein nochmaliges close erzeugt wieder eine 1 - also vom event her ist das kein Problem? Wer verhindert den?
Was ich auch nicht verstehe: Wenn es open und close gibt - wozu braucht man dann zwei Dummy Readings die jeweils für sich open in 1 und close in 1 umwandeln? Kann man das nicht direkt übersetzen? Kannst Du das gesamte Konstrukt aufzeigen - damit man das verstehen kann?
Also es ist ja so, dass FHEM nur dann an MQTT-Gateway sendet, wenn sich das Reading ändert bzw. ein event ändert. Wenn aber da schon eine 1 ist, und nochmals eine 1 erzeugt wird leitet Fhem/notify hier nix mehr weiter an den MQTT Gateway. Somit lässt sich das Rollo dann nur noch in die andere Richtung fahren, wenn der Wert dann wieder auf 0 springt. (event -on-change).
Oder gibt es vielleicht doch eine Möglichkeit die 1 immer auch wiederholt zu senden?(event-on-update) oder so.
Auch mit open/close habe ich das ganze schon mal realisiert, jedoch hatte ich da das selbe problem. Wenn letzter befehl close und ich mache manuell auf(per taster), lässt sich das Rollo dann per Sprache nicht mehr runterfahren, da 2xclose.
Der letzte Versuch war das ganze mit dem pct Wert zu machen. Auch da habe ich eine Möglichkeit die Soll-Position der Rollos anzugeben.(Siehe screenshot) ,aber auch da das selbe Problem. 2 x Close/open hintereinander funktioniert nicht.
Darum habe ich gedacht wenn ich 2 Impulse schicken könnte für open und close , dann könnte es funktionieren.
Gruß
Ather
Klingt so, als wäre da irgendwo "event-on-change-reading" gesetzt (vermutlich genauso "undurchdacht pauschal" wie das "publish alles" via MQTT_GENERIC_BRIDGE). Aber ehrlich gesagt fehlen mir hier dann list-Infos, mit denen man wenigstens wüßte, was in etwa FHEM macht.
Zitat von: Beta-User am 20 November 2020, 13:32:25
Klingt so, als wäre da irgendwo "event-on-change-reading" gesetzt (vermutlich genauso "undurchdacht pauschal" wie das "publish alles" via MQTT_GENERIC_BRIDGE). Aber ehrlich gesagt fehlen mir hier dann list-Infos, mit denen man wenigstens wüßte, was in etwa FHEM macht.
Naja es wird eigentlich durch ein notify bestimmt was gesendet wird und was nicht.
So hab ich das. (Wie gesagt erstmal ohne Filter)
SYS_MQTT:cmnd:.* {
if ($EVENT =~ qr/.*?: (.*)/p) {
my $cmnd = $1;
Log3($NAME, 5, "executed mqtt command: " . $cmnd);
fhem($cmnd);
}
}Hier die list des RolloB. Meintest du das?
Internals:
CFGFN
FUUID xxxxxx
NAME RolloB
NR 881
STATE pct-30
TYPE ROLLO
stoptime 1605874761
READINGS:
2020-11-20 13:19:14 command pct-30
2020-11-20 13:32:36 desired_pct 42.0
2020-11-20 13:19:14 drive-type modul
2020-11-20 13:19:14 last_drive drive-up
2020-11-20 13:19:21 pct 30
2020-11-20 13:19:21 state pct-30
Attributes:
alias Büro Rollo
cmdIcon open:fts_shutter_up closed:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
devStateIcon open:fts_shutter_10:closed closed:fts_shutter_100:open half:fts_shutter_50:closed drive-up:fts_shutter_up@red:stop drive-down:fts_shutter_down@red:stop pct-100:fts_shutter_100:open pct-90:fts_shutter_80:closed pct-80:fts_shutter_80:closed pct-70:fts_shutter_70:closed pct-60:fts_shutter_60:closed pct-50:fts_shutter_50:closed pct-40:fts_shutter_40:open pct-30:fts_shutter_30:open pct-20:fts_shutter_20:open pct-10:fts_shutter_10:open pct-0:fts_shutter_10:closed
group Unten
homebridgeMapping {
"OpenClose": {
"reading": "state",
"values": ["/^closed/:CLOSED", "/.*/:OPEN"],
"cmdOpen": "open",
"cmdClose": "closed"
},
"TargetPosition": {
"reading": "position",
"cmd": "position",
"invert": true
},
"CurrentPosition": {
"reading": "position",
"invert": true
}
}
rl_autoStop 0
rl_excessBottom 2
rl_excessTop 4
rl_secondsDown 35
rl_secondsUp 35
rl_switchTime 1
rl_type normal
room GoogleAssistant
webCmd open:closed:half:stop:pctKlar du hast recht wenn das alles mal ght, werde ich später genau filtern was weitergegeben wird und was nicht. Aktuell wird per event-on change alles weitergegeben.
Habe aber auch noch nicht so viele readings.
Homebridgemapping habe ich reingemacht, da der befehl Schließen "closed" sein muss und nicht "close". So reagiert jetzt der Rollo Baustein wenigstens auf meine Sprachbefehle.
Nochmal: Diese notify-Lösung ist MIST! Und sie betrifft nur die von loxone an FHEM gesendeten Infos. Zuletzt ging es aber doch um die Ansteuerung einzelner Relays von FHEM aus. Das hat mit dem notify nichts zu tun, oder habe ich was verpaßt?
Was das ROLLO-Device angeht OK, das ist schon mal was. Aber da kann ich jetzt nicht erkennen, dass irgendwas per MQTT rausgeht.
(Wollte erst schreiben: "Für's erste würde ich erst mal empfehlen, außer genericDeviceType alles zu löschen, was mit Sprachsteuerung zu tun hat - oder ist die Logik jetzt doch auf der loxone-Seite?" Aber wenn es funktioniert: lass' es).
Jetzt kümmerst du dich bitte als erstes mal um den MQTT-publish für das "Antriggern" der Relays. Anders gefragt: Was erwartet deine Gegenstelle an Kommando/Signal, um einen der Ausgänge an- bzw. auszuschalten?
Und um dieses Missverständnis müssen wir uns auch nochmal kümmern:
Zitat von: ather am 20 November 2020, 13:36:46Aktuell wird per event-on change alles weitergegeben.
"event-on change" tut nichts, außer Events zu unterdrücken! siehe z.B. https://wiki.fhem.de/wiki/Event-on-change-reading
Ist zumindest an dem ROLLO aber gar nicht gesetzt...
Zitat von: Beta-User am 20 November 2020, 13:50:39
oder ist die Logik jetzt doch auf der loxone-Seite?" Aber wenn es funktioniert: lass' es).
Also die Logik/Visualisierung/Steuerung der Relay's ist auf der Loxone Seite. FHEM soll mir nur als Bridge zu Google Home und Einbindung paar anderer Geräte helfen.
Zu Loxone will ich eigentlich nur die Kommandos Hoch und Runter schicken. Daher hat mir ja ein dummy eigentlich schon gereicht.
Die Verbindung Fhem<>Google Home funktioniert mit dem Modul gassistant ja schon super. #
Es scheitert im Moment eben nur an der Logok zwischen Fhem<>Loxone zu scheitern.
Wie gesagt, eigentlich scheint die Aufgabe einfach:
Wenn per Sprache der Befehl kommt aufmachen soll eben nur ain signal an Loxone erfolgen das den Impuls 1 bei RolloAuf gibt und umgekehrt. Alles andere macht Loxone.
Nochmal: Diese notify-Lösung ist MIST! Und sie betrifft nur die von loxone an FHEM gesendeten Infos. Zuletzt ging es aber doch um die Ansteuerung einzelner Relays von FHEM aus. Das hat mit dem notify nichts zu tun, oder habe ich was verpaßt?Stimmt hast Recht, das notify wartet nur auf Befehle von loxone und verarbeitet diese.
Habe noch eine MQTT Bridge angelegt, welche alle readings weitergibt.
define lb_mosquitto MQTT loxberry:1883 loxberry <deinMQTTPasswort>
define mqttGeneric MQTT_GENERIC_BRIDGE
attr mqttGeneric IODev lb_mosquitto
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1
attr mqttGeneric globalPublish *:topic={"fhemwohnzimmer/$device/$reading"}hier kann ich dann später auch filtern.
(Überschitt sich in Teilen)
Zitat von: Beta-User am 20 November 2020, 13:50:39
Jetzt kümmerst du dich bitte als erstes mal um den MQTT-publish für das "Antriggern" der Relays. Anders gefragt: Was erwartet deine Gegenstelle an Kommando/Signal, um einen der Ausgänge an- bzw. auszuschalten?
Da die Frage vermutlich mangels Kenntnis der Zusammenhänge schwierig zu beantworten ist, würde ich mal tippen, dass es (leider!) damit noch geht:
set lb_mosquitto publish fhemwohnzimmer/RolloB/RolloAuf 1; sleep 0.5; set lb_mosquitto publish fhemwohnzimmer/RolloB/RolloAuf 0Dem liegen (falls das jemand nachvollziehen will) folgende Überlegungen zugrunde:
- Es gibt ein MQTT2_CLIENT-Device als IO. Das müßte "lb_mosquitto" heißen (zwischenzeitlich bestätigt, was den Namen angeht, auch wenn der TYPE, warum auch immer >:( jetzt doch wieder MQTT ist. Nochmal: Du wirst dich leichter tun, wenn du auf die MQTT2_.*-Familie setzt).
- MQTT_GENERIC_BRIDGE steht immer noch - wie es in dieser dusseligen Anleitung steht - auf global publish nach "fhem/$device/$reading" (bereits korrigiert zu fhemwohnzimmer...). Da es mit dem userReadings an dem (nicht namentlich genannten) dummy ging, und das Rollo jetzt so heißt, gehe ich mal davon aus, dass das $device" ist. "$reading" entspricht dann dem, was wir bei dem userReadings-Test als "erfolgreich" (ohne die "Rückstellung auf 0" rückgemeldet bekommen haben.
Ergo: Wärst du so freundlich, das mal einfach in die Kommandozeile zu werfen und dann rückzumelden, ob du damit den Rollladen auf bekommst?
Deinem letzten Post liegen ein paar Annahmen zugrunde, die "schwierig" sind.
- Willst du das Rollo per Sprachsteuerung wirklich nur "Auf" oder "Zu" machen? Wäre mir zu wenig, ich würde haben wollen, dass ich dem Teil sagen kann: "Mach halb auf". Geht aber nur, wenn FHEM das verarbeiten kann (oder irgendwie anders (ohne Schleifenbildung!) die Info bekommt, auf welchem Prozentwert das Ding steht).
- Das notify ist und bleibt - unabhängig vom Verständnis von dessen Funktionsweise - MIST! So kannst du in FHEM nicht unterscheiden, warum etwas geschieht und mußt mühsam auf der Loxone-Seite nacharbeiten (so das überhaupt möglich ist). Außerdem ist es hochgradig unsicher, weil schlicht beliebige Befehle durchgestellt werden!!!
- Das Filtern sollte (so das überhaupt geht) nicht an der MQTT_GENERIC_BRIDGE erfolgen, sondern du solltest direkt am jeweiligen Device entscheiden, was gepublisht werden soll. Also kein blacklist-, sondern ein whitelist-Verfahren. Außerdem ist die verwendete Topic-Struktur hochgradig "verwechselungsverdächtig", was Sende- und Empfangsrichtung angeht.
(Aber ich wiederhole mich, und das macht wenig Freude >:( ).
Ich weiß nicht mehr genau bei welchem Problem jetzt wer ist - um auf die Behauptung mit den Events zurück zukommen:
Eine Fingerübung...
Der Dummy RolloB
defmod RolloB dummy
attr RolloB userReadings RolloZU:(open|close) {ReadingsVal($name,'state','fehler') eq 'close' ?1:0},RolloAuf:(open|close) {ReadingsVal($name,'state','fehler') eq 'open' ?1:0}
Jetzt den Event Monitor in einem extra Fenster auf und RolloB.* als Filter
Dann im ersten Fenster in die FHEM Kommandozeile nacheinander:
set RolloB close
set RolloB open
set RolloB close
set RolloB close
2020-11-20 14:40:03 dummy RolloB open
2020-11-20 14:40:03 dummy RolloB RolloZU: 0
2020-11-20 14:40:03 dummy RolloB RolloAuf: 1
2020-11-20 14:40:17 dummy RolloB close
2020-11-20 14:40:17 dummy RolloB RolloZU: 1
2020-11-20 14:40:17 dummy RolloB RolloAuf: 0
2020-11-20 14:40:26 dummy RolloB open
2020-11-20 14:40:26 dummy RolloB RolloZU: 0
2020-11-20 14:40:26 dummy RolloB RolloAuf: 1
2020-11-20 14:40:33 dummy RolloB open
2020-11-20 14:40:33 dummy RolloB RolloZU: 0
2020-11-20 14:40:33 dummy RolloB RolloAuf: 1
Was sieht man? prima Events auf die man reagieren kann :)
Die könnte man mit event-on-change-reading unterdrücken - muss man aber nicht ;D
Gruß Otto
Zitat von: Otto123 am 20 November 2020, 14:45:05
Ich weiß nicht mehr genau bei welchem Problem jetzt wer ist
Ich versuchs mal:
- Der TE (Unen) scheint entweder sein Problem gelöst zu haben oder liest verwundert hier mit...
- Unser "Freibeuter" @ather ist bei allen Problemen gleichzeitig, die diese ganze Konstruktion so mit sich bringt, insbesondere:
-- FHEM-Grundlagen;
-- MQTT-Grundlagen,
und glaubt anscheinend, FHEM wäre eine gute Fernbedienung, über die man "einfach" "ein paar Knöpfe" generieren könnte, ohne sich die Informationsverarbeitungswege genauer zu vergegenwärtigen.
Ich bin mittlerweile ratlos und gehe der Frage nach, ob ich hier noch helfen soll, scheinbar finde ich nicht die richtigen Worte, um @ather zu erklären, wie er ggf. das ganze sinnvoll aufsetzen kann, ohne sich ständig selbst ein anderes Bein zu stellen...
(Habe ich wen oder was wesentliches übersehen?)
Zitat von: Beta-User am 20 November 2020, 14:55:40
Ich versuchs mal:
- Der TE (Unen) scheint entweder sein Problem gelöst zu haben oder liest verwundert hier mit...
- Unser "Freibeuter" @ather ist bei allen Problemen gleichzeitig, die diese ganze Konstruktion so mit sich bringt, insbesondere:
-- FHEM-Grundlagen;
-- MQTT-Grundlagen,
und glaubt anscheinend, FHEM wäre eine gute Fernbedienung, über die man "einfach" "ein paar Knöpfe" generieren könnte, ohne sich die Informationsverarbeitungswege genauer zu vergegenwärtigen.
Ich bin mittlerweile ratlos und gehe der Frage nach, ob ich hier noch helfen soll, scheinbar finde ich nicht die richtigen Worte, um @ather zu erklären, wie er ggf. das ganze sinnvoll aufsetzen kann, ohne sich ständig selbst ein anderes Bein zu stellen...
(Habe ich wen oder was wesentliches übersehen?)
Ne das Problem habe ich noch nicht gelöst. Ich sagte ja, dass ich in Sachen Fhem blutiger Anfänger bin.
Nein ich glaube nicht das Fhem eine Fernbedienung ist über die man Knöpfe generiert, für mich ist es aber eine Art Bridge zu anderen Systemen.
set lb_mosquitto publish fhemwohnzimmer/RolloB/RolloAuf 1; sleep 0.5; set lb_mosquitto publish fhemwohnzimmer/RolloB/RolloAuf 0dieser Befehl lässt die Rollos nicht runterfahren und schickt kein Signal an MQTT.
ZitatIch weiß nicht mehr genau bei welchem Problem jetzt wer ist - um auf die Behauptung mit den Events zurück zukommen:
Ich habe es bis jetzt hinbekommen Dank FHEM Über GoogleHome einige Geräte wie Licht und Rollo per Sprache zu steuern. Und das geht auf verschiedene Art und weisen.
Status von Licht und Rollo gebe ich auch wieder erfolgreich zurück an FHEM.
Code: [Auswählen]
2020-11-20 14:40:03 dummy RolloB open
2020-11-20 14:40:03 dummy RolloB RolloZU: 0
2020-11-20 14:40:03 dummy RolloB RolloAuf: 1
2020-11-20 14:40:17 dummy RolloB close
2020-11-20 14:40:17 dummy RolloB RolloZU: 1
2020-11-20 14:40:17 dummy RolloB RolloAuf: 0
2020-11-20 14:40:26 dummy RolloB open
2020-11-20 14:40:26 dummy RolloB RolloZU: 0
2020-11-20 14:40:26 dummy RolloB RolloAuf: 1
2020-11-20 14:40:33 dummy RolloB open
2020-11-20 14:40:33 dummy RolloB RolloZU: 0
2020-11-20 14:40:33 dummy RolloB RolloAuf: 1
ZitatWas sieht man? prima Events auf die man reagieren kann :)
Die könnte man mit event-on-change-reading unterdrücken - muss man aber nicht ;D
Ok du hast Recht. Das Event wird immer wieder gesendet. Das Problem liegt bei Loxone. Wenn da der Trigger bereits auf 1 steht und ich ne 1 1 schicke tut sich nichts. Muss wahrscheinlich in Loxone den Triggerwert wieder resetten. Mal schauen ich probiers mal.
Danke euch.
ZitatErgo: Wärst du so freundlich, das mal einfach in die Kommandozeile zu werfen und dann rückzumelden, ob du damit den Rollladen auf bekommst?
set lb_mosquitto publish fhem/RolloB/RolloAuf 1Dieser Code geht, mit dem Sleep 0,5 leider nicht.
set lb_mosquitto publish fhem/RolloB/RolloAuf 1; sleep 0.5; set lb_mosquitto publish fhem/RolloB/RolloAuf 0So tut sich leider nichts
Aber wie Otto123 schon geschrieben hat wird die 1 ja immer wieder getriggert. Liegt also eher an Loxone das wiederholte Signale nicht ausgeführt werden. Ich probiere es über loxone zu lösen.
Das Problem scheint zu sein, dass die Info ggf. zu schnell aktualisiert wird, aber man kann ja mit den Zeiten spielen; das mit den 0.5 war ja nur als "sehr kurzer Impuls" gedacht, (mit M2-server) getestet ist es jedenfalls... (Beachte den Punkt, Komma geht hier nicht)
MMn. solltest du dir jetzt erst mal noch Kenntnisse aneignen, wie man den MQTT-Verkehr mithört. manpage zu mosquitto_sub wäre mein Tipp.
Zitat von: Beta-User am 20 November 2020, 16:49:20
MMn. solltest du dir jetzt erst mal noch Kenntnisse aneignen, wie man den MQTT-Verkehr mithört. manpage zu mosquitto_sub wäre mein Tipp.
Wie man den Verkehr mithört habe ich bereits raus. Daher konnte ich ja testen ob die 1 zwei mal gesendet wird. Es ist nur wenn der Analoge Ausgang oder die Rollostellung bei Loxone bereits auf einem Wert Steht und der gleiche Wert erneut gesendet wird, tut sich nichts.
Das hier sendet aber eben nicht zweimal denselben Wert, sondern kurz hintereinander erst 1, dann 0:
set lb_mosquitto publish fhem/RolloB/RolloAuf 1; sleep 0.5; set lb_mosquitto publish fhem/RolloB/RolloAuf 0
Wenn man das mit sleep 5 (hier über einen MQTT2_SERVER)
set m2server publish fhemwohnzimmer/RolloB/RolloAuf 1; sleep 5; set m2server publish fhemwohnzimmer/RolloB/RolloAuf 0
macht, gibt das folgende Events:
2020-11-20 16:38:59 MQTT2_SERVER m2server lastPublish: fhemwohnzimmer/RolloB/RolloAuf:1
2020-11-20 16:39:04 MQTT2_SERVER m2server lastPublish: fhemwohnzimmer/RolloB/RolloAuf:0
Also genau den "Impuls", den du "angefordert" hattest.
Es wäre jetzt wichtig zu wissen, ob du wirklich einen Puls brauchst, oder ob das auf "1" stehen bleiben kann (bzw. soll) - jedenfalls solange das Rollo fahren soll. Und damit wären wir dann genau bei den Konfigurationsmöglichkeiten von ROLLO...
EDIT: Hier noch ein link zu einem komplett eingerichteten ROLLO-Device, vielleicht wird es dann etwas klarer, wo ggf. die "publish"-Befehle hin müßten: https://forum.fhem.de/index.php/topic,95832.msg1076648.html#msg1076648 (https://forum.fhem.de/index.php/topic,95832.msg1076648.html#msg1076648)
EDIT2: Merker, hier hat noch jemand komische Probleme mit gDT "blind": https://forum.fhem.de/index.php/topic,115972.0.html (https://forum.fhem.de/index.php/topic,115972.0.html)