Status Rücklesen Dummy

[ather]

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...

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:

Code Auswählen Erweitern

lb_mosquitto:loxberry/mqttgateway/keepaliveepoch:.* keepaliveepoch

bridgeRegexp habe ich auch um die zeilen erweitert wie du geschrieben hast.
Das sieht dann so aus:

Code Auswählen Erweitern

(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.

[Beta-User]

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

Code Auswählen Erweitern

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.

bridgeRegexp habe ich auch um die zeilen erweitert wie du geschrieben hast.
Das sieht dann so aus:

Code Auswählen Erweitern

[...]
[\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.

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. 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:

Code Auswählen Erweitern

list TYPE=MQTT2_DEVICE

Support via Teamviewer kann und will ich nicht leisten, zumal eventuelle Nachahmer das dann nicht nachlesen/-denken können.

[ather]

Schau 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?

Code Auswählen Erweitern

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.

[Beta-User]

Nope.

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:

Code Auswählen Erweitern

loxberry/out/LichtBuero/state
loxberry/out/LichtBuero/pct


FHEM=>Loxone:

Code Auswählen Erweitern

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...

[Otto123]

- ü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:

Code Auswählen Erweitern

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

[ather]

Kannst 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.

[MadMax-FHEM]

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:

Code Auswählen Erweitern

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!

/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

[ather]

d.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

[Beta-User]

Bis jetzt habe ich einfach den Befehl

Code Auswählen Erweitern

/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?

/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...

[MadMax-FHEM]

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

[Beta-User]

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!).

[ather]

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?

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.

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   )...

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?

[Beta-User]

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).

[MadMax-FHEM]

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

[ather]

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