SP111 mit Tasmota und Shelly 1 PM paralell schalten

[debu]

Hi zusammen,

ich habe eine Gosund SP111 mit Tasmota und einen Shelly 1 PM. Jeder steuert jeweils eine Lampe im Wohnzimmer. Beide sind als MQTT2_DEVICE in FHEM angelegt und funktionieren astrein.
Jetzt würde ich gerne beide Lampen gleichzeitig schalten. Heisst wenn man an der SP111 das Knöpfchen betätigt soll auch der Shelly geschalten werden und umgekehrt. Das ganze wollte ich gerne über mqtt subscriptions lösen habe es aber nicht so richtig hinbekommen.

Wie würde man so eine Anforderung idealerweise Lösen?
Das einzige was ich hinbekommen habe ist den SP111 auf das relay/0 topic des Shelly zu "subscriben" mit folgendem Eintrag in der readingList des SP111:
shellies/shelly1pm-XXXXXX/relay/0:.* { fhem("set $NAME $EVENT"); }

Das ist aber vermutlich nicht die eleganteste Möglichkeit und führt auch dazu dass der state des SP111 ständig aktualisiert wird. Bin jeden Tip dankbar.
Vielen Dank und beste Gruesse,
DeBu

[Beta-User]

Vorab mal willkommen im Forum!

Das auf dem "MQTT-way" zu lösen ist sicher eine spannende Aufgabe, aber ganz ehrlich: Da sind sehr viele Fallstricke drin, v.a., weil du auch noch zwei unterschiedliche firmwares hast, die sich dann jeweils auch unterschiedlich verhalten...

(Tasmota-rules, Gruppen-Subscription, etc. pp.. Dazu die Frage, welche Aktualisierungsintervalle (setz das mal bei den Shelly auf 0...), und ggf. dann noch JSON auspacken... Das ist keine Freude!)

Falls du das im Ergebnis so haben willst, dass beide immer entweder an oder aus sind, egal, ob von FHEM aus geschalten wird oder an einer der Taster, tust du dich m.E. leichter, wenn du schlicht ein notify auf beide setzt und dann jeweils dafür sorgst, dass nur ein (FHEM-) trigger stattfindet, wenn ein on/off-Statuswechsel stattfindet. Dazu dann ein set auf beide mit $EVENT und FILTER (nur schalten, was nicht schon auf $EVENT steht).

[TomLee]

Hallo,

mit HTTP Requests mein ich nach kurzem einlesen wär das ganz einfach umzusetzen und klappt dann auch noch ohne FHEM 

Im Shelly unter I/O URL actions -> Output switched ON url die URL zum einschalten des Tasmota-Device eintragen (bspw. http://192.168.188.68/cm?cmnd=Power%20On) und unter Output switched OFF url die URL zu ausschalten des Tasmota-Device (bspw. http://192.168.188.68/cm?cmnd=Power%20Off). Hab ich getestet und klappt.

Im Tasmota-Device sollte das über Rules möglich sein den Shelly ein/aus zu schalten, aber noch nicht getestet, mach ich rein aus Interesse heute Abend mal.

Könnte so in der Art aussehen, was ich so auf die Schnelle gefunden habe, zu Rules muss ich mich aber nochmal einlesen:

Code Auswählen Erweitern

Rule1 on Power1#State=1 do websend http://192.168.188.46/relay/0?turn=on endon
on Power1#State=0 do websend http://192.168.188.46/relay/0?turn=off endon

Gruß

Thomas

[TomLee]

Ging schneller wie gedacht, mit dieser Rule wird beim betätigen des Button am Tasmota-Device der Shelly geschalten:

Code Auswählen Erweitern

Rule1 on Power1#State=1 do websend [192.168.188.46]/relay/0?turn=on endon on Power1#State=0 do websend [192.168.188.46]/relay/0?turn=off endon

[Beta-User]

Ähm, ist Power1 das Relay oder der Taster?
Für mich klingt es nach dem Relay... MAn. sollte man sowas nur auf den Taster reagieren lassen, sonst gibt das ggf. eine "Brummschleife", oder?

(Und mit rules könnte man selbstredend auch entsprechende MQTT-Kommandos versenden...)

[TomLee]

Ja, nur auf den Taster reagieren dacht ich mir im nachhinein auch, hab ich aber bis jetzt noch nicht genau verstanden wie der Switch dann genau zu konfigurieren ist, das man in der Rule auf dessen Status reagiert, weil ohne irgendwelche zusätzlichen Einstellungen klappts so mit SwitchMode1 4 nicht:

Code Auswählen Erweitern


Rule1 on Switch#State=1 do websend [http://192.168.188.46]/relay/0?turn=on endon
on Switch#State=0 do websend [http://192.168.188.46]/relay/0?turn=off endon

Wenn das klappt, kommt die Variante mit Mqtt-Kpmmando 

[debu]

Hi,

super. Vielen Dank.
Die Variante mit dem Notify ist mir auch schon durch den Kopf gegangen. Ich kannte nur den FILTER nicht. Ohne den gehts im Kreis;-)
Notify mit Filter wie folgt funktioniert (auch wenn weitere Lampen dazukommen):

Code Auswählen Erweitern

WZ_Lampe.* set WZ_Lampe.*:FILTER=state!=$EVENT $EVENT

Der Filter hilft im Übrigen auch bei meiner ersten Variante:

Code Auswählen Erweitern

shellies/shelly1pm-XXXXXXX/relay/0:.* { fhem("set $NAME:FILTER=state!=$EVENT $EVENT") }
Mit Filter finde ich den Ansatz gar nicht mehr so übel;-)

Der Ansatz über Tasmota rules ist auch interessant. Allerdings stört mich etwas die Verdrahtung über IP's
Eigentlich dachte ich ja dass MQTT mit seinen Topics und Subscriptions genau dafür gemacht sein müsste...aber so gehts auch.

Danke und beste Gruesse,
DeBu

[TomLee]

Ähm,

(Und mit rules könnte man selbstredend auch entsprechende MQTT-Kommandos versenden...)

ohne MQTT-Server (im Falle MQTT2_SERVER oder Mosquitto auf dem gleichen Rechner wie FHEM) auch keine MQTT-Kommunikation, wenn FHEM nicht mehr da, geht doch dann nur über HTTP Requests 

[TomLee]

Code Auswählen Erweitern

... hab ich aber bis jetzt noch nicht genau verstanden wie der Switch dann genau zu konfigurieren ist ...

der Switch benötigt gar keine besondere Konfiguration.
SwitchMode1 steht weiterhin auf 4, switchtopic auf default 0.

Das entscheidende ist die Angabe welcher Switch gemeint ist mit anzugeben.

War der Meinung beim ersten Switch kann man die 1 weg lassen, wie bei MQTT bei POWER die 1, ist aber nicht so.

So klappts:

RICHTIG:

Code Auswählen Erweitern

rule1 on Switch1#State do websend [192.168.188.46]/relay/0?turn=toggle endon


FALSCH:

Code Auswählen Erweitern

rule1 on Switch#State do websend [192.168.188.46]/relay/0?turn=toggle endon

[Beta-User]

Ähm,
ohne MQTT-Server (im Falle MQTT2_SERVER oder Mosquitto auf dem gleichen Rechner wie FHEM) auch keine MQTT-Kommunikation, wenn FHEM nicht mehr da, geht doch dann nur über HTTP Requests 

Korrekt.
ABER: Klappt das mit den HTTP-Requests noch, wenn man Passwörter für die ESP's setzt...?

[OT-Meinung (!)]
Diese Direktverknüpfungen haben Vor- und Nachteile. An sich schätze ich es sehr, wenn man sowas implementieren kann.
ABER: die Logik wird damit sehr verteilt und von FHEM (oder einer anderen Admin-Software) aus kann man es nicht sehen (anders als Peerings in CUL_HM oder associations in ZWave). Früher oder später wird man daher ggf. vergessen, was man da warum wie gemacht hat, und dann ist es schwer, sowas wiederzufinden und dann zu ändern. Via MQTT bekommt man dann wenigstens die Schaltanweisung mitlesend zu sehen.
Für meine MySensors-Nodes habe ich eine Zeitlang überlegt, ob es sinnvoll ist, dort Node-to-Node-Kommunikation zu machen und habe das dann verworfen - (neben dem Aufwand, das zu programmieren) vor allem aus diesem Grund.
[/OT]

[TomLee]

https://tasmota.github.io/docs/Commands/#with-web-requests

If you have set a password for web user interface access, this must be included (in plaintext) in the URL of the HTTP request, like so:

http://<ip>/cm?user=<username>&password=<password>&cmnd=Power%20On


In der Doku zu Shelly find ich kein Beispiel, hier eine aus der Beschreibung eines PDF zum Shelly2.5:

Wenn eine Autorisierung verlangt wird:Schalten Shelly2.5 Relais EIN:

http://user:pass@192.168.xxx.xxx/relay/0?turn=onuser: Benutzername anpassenpass: Passwort anpassen



Den Nachteil das man das nach einer gewissen Zeit wieder vergisst kann ich nachvollziehen.

Darum dokumentier ich seit längerem alles was ich so an Einstellungen vorgenommen habe (da muss ich ehrlich sein, das war nicht immer so bei mir)

[TomLee]

... von FHEM (oder einer anderen Admin-Software) aus kann man es nicht sehen ...

hatten wir doch schonmal, zumindest trifft das bei Tasmota nicht zu wenn man das RESULT-Topic abonniert hat :

Code Auswählen Erweitern

22:13:09 MQT: stat/DVES_55F827/RESULT = {"Rule1":"on","Once":"off","StopOnError":"off","Length":70,"Free":441,"Rules":"on Switch1#State do websend [192.168.188.46]/relay/0?turn=toggle endon"}

[Beta-User]

Das mit dem RESULT-Topic war mir nicht gegenwärtig, aber dass man die user/pw-Kombi mit in den HTTP-Request vercoden kann war - im Prinzip - klar.
(Derartige rule-Infos@MQTT sinnvoll auszuwerten, wäre dann wohl noch ein Aktionspunkt...)

Bei dieser ganzen WLAN-/WLAN-direkt- Geschichte gefällt mir _persönlich_ einfach zu viel nicht, hier z.B., dass Passwörter auf dem MQTT-Server landen und da dann ggf. "einfach" mitgelesen werden können, und wenn man wirklich "sicher schalten" will, ist die grundsätzliche Abhängigkeit von WLAN-Infrastruktur schon ein Thema...
Von daher _glaube_ ich, dass das mit FILTER die eigentlich _für diesen Anwendungsfall_ passendste Lösung ist. Die Welt geht ja nicht gleich unter, wenn FHEM down ist, und die Logik ist - ebenso wie das Einrichten - simpel und die Querbeziehungen ohne Klimmzüge in FHEMWEB zu erkennen .
Ggf. kann man die regex für das notify noch auf

Code Auswählen Erweitern

WZ_Lampe.*:o[nf]+schärfen, aber das ist wieder eine ganz andere Diskussion, und hat dann mit MQTT auch nichts zu tun .

[TomLee]

Das mit dem RESULT-Topic war mir nicht gegenwärtig, ...

Wsl. eher nicht mehr in Erinnerung:

Schön ist jedenfalls, dass man auch dafür eine Info als Reading bekommt, egal, ob es jetzt via pulseTime der via "anderer rule" ist.

(Derartige rule-Infos@MQTT sinnvoll auszuwerten, wäre dann wohl noch ein Aktionspunkt...)

Versteh ich nicht, ist das nicht sinnvoll:

Code Auswählen Erweitern

stat/DVES_55F827/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }

setstate MQTT2_Sonoff_OBI 2021-01-18 22:13:09 Rule1 on
setstate MQTT2_Sonoff_OBI 2021-01-18 22:13:09 Rules on Switch1#State do websend [192.168.188.46]/relay/0?turn=toggle endon

[Beta-User]

...alles gut ... ( bis auf WLAN ect....)