Sonoff 4ch Rolladentemplate

Begonnen von michisa86888, 02 April 2020, 10:18:31

Vorheriges Thema - Nächstes Thema

michisa86888

Hallo zusammen,
ich habe meinen Sonoff 4ch erfolgreich mit Tasmota in FHEM Mqtt2 eingebunden (autocreate).
Mir gefällt das 2ch Shutter template ganz gut. Für den 4ch gibts leider kein template.
Nun meine Frage, ist es irgendwie möglich die Kanale 1/2 (Rolladen 1) und 3/4 (Rolladen 2) zu trennen?
Dann könnte ich quasi 2ma 2ch Templates benutzen?

Viele Grüße

Beta-User

Kurze Antwort: müßte gehen!

Vorschlag: Wende mal das 2-ch-Template an, und wir schauen dann, wie man das ggf. auf ein "split" für den 4-kanaligen erweitern kann.

Du mußt dich aber in jedem Fall bitte in diese interlock-Geschichten usw. einlesen, ich gehe jedenfalls davon aus, dass man ein paar andere bzw. zusätzliche "backlog"-Befehle braucht.
Das "End-Template" wäre dann von der Struktur her tendenziell so aufgebaut wie das "normale" 2-ch-split, also erst den ersten Kanal mit dem "single"-template konfigurieren (ohne Sprachsteuerung! => das vorhandene t. muß aufgebort werden...), dann auf den 2. Kanal (relais 3+4) kopieren (?) und/oder diese beiden Relais dann gesondert konfigurieren (einschl. backlog), am Ende dann jeweils die Sprachsteuerung ergänzen.

Reicht dir das als "Spielmaterial"?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

michisa86888

#2
Okay, hört sich kompliziert an ::)

ich denke "gesplittet" wurden die Kanäle schon. Habe 4 Devices von
ZitatMQTT2_DVES_49093A_CH1
bis
ZitatMQTT2_DVES_49093A_CH4
.
Dem CH1 habe ich jetzt das 2ch_shutter template zugewiesen. Dieses Device steuert nun Kanäle 1 und 2.
Wenn ich daselbe beim CH3 Device anwende werden wieder CH1 und CH2 gesteuert. Hier komme ich nicht weiter. Wo werden die CH1 im template defieniert?

Interlock habe ich aktiviert. Zwar aktuell noch als 1 Gruppe, werde noch 2 Interlock gruppen draus machen.

Beta-User

Hmm, gibt immer viele Wege.

Vorher splitten (mit den normalen templates) würde ich nicht, sondern wir brauchen ein neues (das dann intern das "normale" shutter-template für einen Rollladen = Relais 1+2 aufruft, und dann nur Relais 3+4 "extra" behandelt).

An sich ist es auch nicht kompliziert. Da du schon (indirekt) das "basic" angewendet hattest: Soweit ich mich entsinne, könnte es Optionen geben, das Ding auf der Tasmota-Seite (im Web-Interface des ESP) als mehrfach-Rollladenaktor zu konfigurieren (kann aber sein, dass das nur bei dem fork ging).
Wenn das geht: Spiel da mal ein wenig mit den slidern rum. Helfen würde mir vermutlich (erst mal) _ein_ Device, in dem dann alle Readings landen (oder der MQTT-Verkehr, das wäre eigentlich dann noch besser)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

michisa86888

Puh, also im Webinterface von Tasmota habe ich nur slider für die Kanäle 1 und 2. Denke das kommt vom Template aus FHEM.
Habe jetzt mal in FHEM alle Devices gelöscht und nun ein "nacktes" Device von autocreate bekommen.
Was würdest du den als nächsten Schritt sehen bzw. wie würdest du beginnen?

Beta-User

Korrekt, der eine Slider ist das Ergebnis einiger backlog-Befehle, die das attrTemplate an den ESP schickt.

Wie weiter?
Na ja, was wohl...: auf die "Erklär"-Seiten von Tasmota gehen und nachsehen, wie man das konfiguriert:
ZitatTo enable additional shutters, ShutterRelay<x> <value> must be executed for each additional shutter. Additional shutter declarations must be sequentially numbered, and without gaps (i.e., second shutter is 2, then shutter 3, and finally shutter 4).
(aus https://tasmota.github.io/docs/Blinds-and-Shutters/)

...ab da müßte ich mich sortieren: Erst mal nachsehen, welche (v.a. backlog) Befehle das "normale" attrTemplate sendet, dann einzeln austesten, was man _zusätzlich_ braucht (und das dann in die Konfiguration des 2. Kanals packen).

Was die "vertemplatung" auf der FHEM-Seite angeht, brauche ich eine Art Ablaufplan, am besten jeweils Punkte nennend, was zu welchem Kanal gehört. Und im Ergebnis dann je ein Device, das man vernünftig steuern kann, als eine Art "Soll-Ergebnis", was das attrTemplate am Ende an FHEM-Konfiguration liefern müßte...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files