Status Rücklesen Dummy

[ather]

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.

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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.

[Beta-User]

(Überschitt sich in Teilen)

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:

Code Auswählen Erweitern

set lb_mosquitto publish fhemwohnzimmer/RolloB/RolloAuf 1; sleep 0.5; set lb_mosquitto publish fhemwohnzimmer/RolloB/RolloAuf 0

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

[Otto123]

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

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

set RolloB close
set RolloB open
set RolloB close
set RolloB close

Code Auswählen Erweitern

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 

Gruß Otto

[Beta-User]

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

[ather]

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.

Code Auswählen Erweitern

set lb_mosquitto publish fhemwohnzimmer/RolloB/RolloAuf 1; sleep 0.5; set lb_mosquitto publish fhemwohnzimmer/RolloB/RolloAuf 0

dieser Befehl lässt die Rollos nicht runterfahren und schickt kein Signal an MQTT.

Ich 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 Erweitern

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


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 

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.

[ather]

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?

Code Auswählen Erweitern

set lb_mosquitto publish fhem/RolloB/RolloAuf 1

Dieser Code geht, mit dem Sleep 0,5 leider nicht.

Code Auswählen Erweitern

set lb_mosquitto publish fhem/RolloB/RolloAuf 1; sleep 0.5; set lb_mosquitto publish fhem/RolloB/RolloAuf 0
So 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.

[Beta-User]

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.

[ather]

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.

[Beta-User]

Das hier sendet aber eben nicht zweimal denselben Wert, sondern kurz hintereinander erst 1, dann 0:

Code Auswählen Erweitern

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)

Code Auswählen Erweitern

set m2server publish fhemwohnzimmer/RolloB/RolloAuf 1; sleep 5; set m2server publish fhemwohnzimmer/RolloB/RolloAuf 0
macht, gibt das folgende Events:

Code Auswählen Erweitern

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
EDIT2: Merker, hier hat noch jemand komische Probleme mit gDT "blind": https://forum.fhem.de/index.php/topic,115972.0.html