Roto / Rototronic (24V Motor) mit Shelly steuern

Begonnen von deathworm, 19 August 2021, 20:38:06

Vorheriges Thema - Nächstes Thema

deathworm

Hi!

Nachdem alle Rollos per Shellys und mein Velux per KLF200 gesteuert wird, möchte ich nun mein Roto Dachfenster auch noch bei FHEM einbinden. Auch hier würde ich gerne einen Shelly nutzen.

So, diese Rototronic is aber doof weil es keinen einfachen Stopp gibt.

Wenn ich in eine Richtung fahre, dann fährt er solange in diese Richtung bis ich die selbe Richtung erneut drücke.

Das heisst hoch bedeutet ich drücke auf hoch und zum stoppen muss ich einmal wieder auf Mittelstellung gehen und nochmal auf hoch. Wenn ich auf runter gehe, dann stoppt er leider nicht, sondern geht sofort wieder auf runter.

Wie ich das aber machen soll; da steig ich nicht durch. Weil wenn ich auf Stopp drücke, dann muss FHEM ja wissen in welche Richtung ich gefahren bin. Das selbe ja beim PCT Regler.

Eingerichtet ist der Shelly 2.5 komplett Standard per Template.


Kann mir da wer helfen oder ist das etwas zu umständliches?

Beta-User

Ohne Schaltplan ist das vermutlich sehr schwer zu beurteilen, was du eigentlich brauchst. Meine Glaskugel könnte so zu deuten sein, dass du potentialfreie Schaltimpulse suchst?
Könnte bzgl. der Firmware über Tasmota-Shutter-Optionen umsetzbar sein (https://tasmota.github.io/docs/Blinds-and-Shutters/, dort mal mit "PulseTime" beschäftigen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Hermann

Hallo

Das verhalten kann man ja im Shelly 2.5 angeben.

Button Type
Toggle - Press Button 1 for OPEN and press again for STOP.
Press Button 2 for CLOSE and press again for STOP.

Und in Fhem
toggleDir - toggelt die fahrtrichtung des Rollo-Aktors. Es wird umgeschaltet zwischen auf/stop/ab/stop


Wenn ich das richtig aus deiner Beschreibung verstehe ist dort einen Schalter montiert der in der gewählten Stellung stehen bleibt zB. Hoch und keinen Taster der in seiner Mittelstellung zurück kehrt.
Das müsste dann ein Taster sein.

mfg.
H.J.M.


Schöne Grüße aus dem Münsterland
PI3+ Fritzbox , Homematic , FS20 , 1Wire , Shelly , EspXXXX , Duofern

Prof. Dr. Peter Henning

#3
Achtung Gefahr !

Die Shelly-Aktoren liefern keinen potentialfreien Schaltimpuls, sondern (wenn man sie nicht explizit bei Niederspannung betreibt) 230 V

@Herrmann: Ganz sicher einmal geht es dem TE nicht darum, die Tastenfunktion nachzustellen (und nur auf diese bezieht sich die Einstellbarkeit auf der Shelly-Weboberfläche). Sondern die Steuerung (also die Ausgabeseite) des Aktors zu modifizieren. Mein Tipp: Etwas Zurückhaltung, wenn man das Problem nicht richtig verstanden hat.

LG

pah

Hermann

Schöne Grüße aus dem Münsterland
PI3+ Fritzbox , Homematic , FS20 , 1Wire , Shelly , EspXXXX , Duofern

Papa Romeo

Zitat von: Hermann am 24 August 2021, 19:54:09
mea culpa maxima

... aber man könnte ja zwei Relais oder Opto-Koppler nachschalten, die diese "potentialfreien" Impulse generieren könnten, wenn´s denn unbedingt ein Shelly sein soll.

LG
Papa Romeo
...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary

Beta-User

...solange wir nur raten können, WAS der TE eigentlich benötigt, ist die Diskussion müsig...

Auf https://www.roto-dachfenster.de/servicecenter/downloads/schaltplaene.html sind 3 Varianten zu finden, 24V, 230V und Bussystem (wieder mit 24V oder 230V). Es _kann_ also durchaus sein, dass ein Shelly das (fast) direkt kann, wenn der TE eine "normale" 230V-Variante verbaut hat und dann einfach seinen mechanischen Drehschalter (?) durch einen Jalousie-Taster tauschen kann. (Falls das so ist, sollte der TE seinen Elektriker verhauen, der ihm das so verbaut hat. Im Schaltplan steht deutlich: Taster!).
Das "Problem" beschränkt sich _dann_ darauf, dass (jedenfalls lt. der kurzen Doku-Durchsicht, die ich gemacht hatte) die Shelly-firmware (derzeit) keinen "gate"-Modus kann, also kurze Schaltimpulse für Start/Stop in je eine Richtung unter Errechnung/Meldung der aktuellen Position. Das kann aber wohl die Tasmota-firmware (deswegen "fast" => Umflashen (ausnahmsweise!))... (Meine Fibaro-Shutter-ZWave-Aktoren (222/223) können diesen Modus übrigens auch, wenn ich das richtig im Kopf habe). (Man kann das auch auf FHEM-Seite mit ROLLO usw. lösen, das ist aber deutlich komplizierter wie passende Hardware).

Alles andere kann man vermutlich mit den "eierlegenden" Platinen von Papa Romeo erreichen, zumindest, falls man die 24V (?) auch für die Versorgung des ESP's verwenden kann.

Aber bis wir Info haben, ist alles Spekulation, und bei der sehr rudimentären Info, die der TE geliefert hat.

Der TE sollte daher eine fachkundige Person seiner Wahl beauftragen, die grundlegenden Dinge zu klären...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

deathworm

Hi

sorry für die späte Antwort. Hab am Anfang immer gecheckt, da war noch nix da und nun plötzlich soviel ;)

Also - das ganze ist definitiv ausschließlich 24V Technik. Auch der Motor ist DC 24V. Die Roto Hotline hat mir versichert, dass die Elektronik keinerlei andere Funktion zulässt. Also geht es nur, dass man direkt an den Motor hingeht. Warum auch nicht ?

Ich habe nun auch eine passende Lösung für mich gefunden.

Ich nehme den Shelly 2.5 und versorge Ihn mit 24V Spannung. Dieser geht dann auf ein 2Fach Relais, dass auch 24V kann. Das Relais wird als Polwandler genutzt. Das heisst, beide NC Kontakte werden mit Plus, beide NO Kontakte mit Minus und der COM mit einem Kabel des Motors angeschlossen.

Bild mit meiner Testverkabelung im Anhang.

Eine Sperre gegen zwei Mal Relaisschalten ist ja automatisch auch schon integriert, da Jalousieschalter und Shelly Rollershuttermode. Nun wird der manuelle Schalter auch gegen einen Jung ausgetauscht und funktioniert wie alle anderen Schalter.


Todo ist noch:
- Messen der Laufzeit um eine Kalibrierung vorzugaukeln
- Der vorhandene Regensensor durchmessen.
--> Hier ist für mich wichtig zu wissen, gibt der Regensensor bei Kontakt nur einen kurzen Kontakt raus oder bleibt der dauerhaft auf runter bis wieder trocken ist. Schaltet er vielleicht auch mehrfach auf das Signal bei erneutem Regen in kurzer Zeit? Da sind noch ein paar Fragen offen. Das "blöde" ist nur, dass ich die Schutzfunktion gegen wiederöffnen im Regenfall mit dem Shelly ja überbrücke. Das wird also noch einwenig Arbeit geben mit ausmessen und überlegen.

Beta-User

Der Regensensor scheint einen separaten Eingang zu haben (https://www.roto-dachfenster.de/fileadmin/CH/Downloads/Schaltplaene_24V.pdf Abb. 9 + 10), das sollte also stressfrei gehen, wenn du das ganze dann "ganz normal" an die "Tasterschnittstelle" ("B", links) hängen würdest (Taster=>Shelly-Eingänge) und vermutlich kannst du mit Tasmota-firmware dann auch auf die externen Relays verzichten...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Prof. Dr. Peter Henning

Man kann problemlos auch ohne Tasmota auskommen. Beim Shelly muss lediglich das Setting auto-off gesetzt werden, dann gibt er einen kurzen Impuls am Ausgang ab (siehe https://shelly-api-docs.shelly.cloud/gen1/#shelly2-5-settings-relay-index).

Das bisschen Logik, mit dem FHEM sich merken kann, ob das Ding gerade hoch fährt oder stoppt, kann man mit 10 Zeilen Perl-Code hinbekommen.

LG

pah


Beta-User

An der Stelle (!) ist es m.E. eine Geschmacksfrage. Die Shelly-firmware ist in der Regel völlig ausreichend, soweit sind wir uns einig, und ich tendiere auch deutlich dazu, vom "generellen Umflashen" abzuraten.

Hier ist es aber so, dass man die 10 Zeilen Perl-Code (oder das ROLLO-Modul) braucht, um eine (hinsichtlich der timings) "wackelige" Lösung zu bauen, die man mit Tasmota "frei Haus" auf der Hardware laufend bekommt ;) . Und Tasmota ist nun auch nicht unbedingt "irgendeine firmware", oder?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Prof. Dr. Peter Henning

#11
Zitatirgendeine firmware
habe ich ja auch nicht geschrieben ...

Allerdings bleibt dann wohl nur die MQTT-Lösung, weil das Shelly-Modul nun wirklich nur das Shelly-API bedient.

Interessant ist übrigens, dass Allterco Robotics inzwischen von einer 2nd Generation Shelly-Devices spricht, die eine andere API-Struktur haben. Das erste der Geräte ist der neue Shelly 4 Pro.

Leider ist die Aktie immer noch nur in Bulgarien handelbar... https://de.investing.com/equities/allterco-ad

LG

pah

Beta-User

Zitat von: Prof. Dr. Peter Henning am 25 August 2021, 18:26:44
Allerdings bleibt dann wohl nur die MQTT-Lösung, weil das Shelly-Modul nun wirklich nur das Shelly-API bedient.
Ob "nur" paßt, sei mal dahingestellt, aber klar, für Tasmota kommt man um MQTT(2) kaum herum, und (nicht nur, aber v.a.) wegen der JSON-Payloads eben (in FHEM) MQTT2_.*.

(OT: ärgerlich, dass neuere Tasmota-Versionen soviel unnötigen Kram (besonders ärgerlich: der Konfigurationskram...) versenden, das ist fast so eine Plage wie die unnötigen default-updates der Shelly@MQTT)

"Jemand mit guten Verbindungen" kann aber gerne Allterco vorschlagen, "die paar Zeilen Code" für einen "gate"-Modus in die firmware zu integrieren (das sollte kein Hexenwerk sein, erhöht aber selbstredend die Zahl der erforderlichen Parameter) ;) .

Zitat
Interessant ist übrigens, dass Allterco Robotics inzwischen von einer 2nd Generation Shelly-Devices spricht, die eine andere API-Struktur haben. Das erste der Geräte ist der neue Shelly 4 Pro.
Da bin ich auch schon gespannt, was auf uns (schwerpunktmäßig: wir beide?) da ggf. zukommt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

deathworm

einen wunderschönen abend in die runde,

so - ich habe letzte nacht nun meinen abend auf der bühne und im bad mit bockleiter verbracht. obwohl die steuerung eig. fast fertig war, habe ich doch bis 3 uhr nachts herumgebastelt und auch diverse vorgänge getestet.


also zu dem thema tasmota... ja, das ding hätte ich bestimmt auch so konfigurieren oder programmieren können per fhem, dass ich es direkt an die steuerung hätte anschliessen können. aber ich wollte einfach etwas, dass hardware mäßig schon das ganze schaltet und auch bei einem möglichen fhem defekt, aussetzer etc. autark schält. zudem soll auch das fenster teilöffnungen beherrschen. also musste die vorhandene steuerung weg. ich habe mich einfach für shelly entschieden, da schon alle andere rollos per shelly angebunden sind und ich mit der gerätschaft echt glücklich bin. bei tasmota hatte ich schon den ein oder anderen suizidgedanken.


also grundsätzlich habe ich das ding wie oben auf dem bild angeschlossen.

nun kam aber ja noch der faktor regensensor dazu. der verhält sich so, dass auf rot +, schwarz + und auf dem "potential" kontakt orange/braun 24v+ kommt, sobald ein regenkontakt entsteht. hier habe ich nun als relais einen zusätzlich shelly 1 angeklemmt. dieser schliesst dann einen kontakt und zeigt mir zudem bei fhem den zustand an. an=regen, aus=kein regen.

nun hatte ich aber erst einmal das problem, wie klemme ich den nun an? klemme ich den direkt an den motor an, dann bleibt der natürlich sicher immer unten. toll. aber WAF-problem: drücke ich nun auf auf, dann ist der kontakt ja nicht gesperrt und zack, kurzschluss. zudem ist auf diesem weg auch dauerstrom auf den motor. ob das nun gut oder egal für den motor ist, keine ahnung. aber er brummelt die ganze zeit - also auch doof.

schliesse ich den shelly1 nun an den shelly 2.5 als schalterkontakt an, dann geht das fenster zu, der motor geht nach der max working time aus und toll. aaaaaaaaaber problem: drücke ich nun auf auf/hoch, dann geht das fenster auf, weil ja immer der neueste befehl beim shelly zählt. und angenommen der WAF kommt nun an, guckt natßürlich nicht hoch und macht einfach auf - dann is wieder alles doof. weil zu kann man das dann per kontakt nicht machen, denn dieser ist ja bereits dauerhaft vom regensensor close angezogen. also auch doof.

heute beim autofahren also überlegt, wie kann ich das ganze safe machen. hab dann schon überlegt ob ich das doch etwas per fhem programmierung machen kann. aber nee, weil der kontakt ja direkt am shelly anliegt. der shelly kann ja bei on close oder on open eine url betätigen. nun müsste es eine url auf dem anderen shelly geben, die halt bei aufruf sämtliche befehle sperrt. aber das gibts ja nicht und zusätzlich bin ich ja freund von hardwaretechnik bei solchen sicherheitsrelevanten sachen. dabei direkt eine idee gehabt. ein zusätzliches relais - dieses ist mit normally close am kontakt für das relais vom shelly 2.5 für den auf kontakt. bei regen wird der schaltkontakt somit getrennt. zu ist ja gedeckelt.


das funktioniert nun safe und einwandfrei. ich werde nun nur noch den shelly1 gegen einen zweiten 2.5 austauschen, der dann auch nur für den regenkontakt zuständig ist. dieser wird dann aber nicht im rollershutter modus sein, sondern relaismodus. ein relaiskontakt geht auf den rollershelly für runter und der andere kontakt hebt die verkabelung zum auf-relais auf. somit ist das ganze nun hardwaretechnisch so verkabelt, dass es idiotensicher zu geht und nicht mehr aufmachbar ist, sofern es regnet. es gibt aber glaube ich noch eine letzte möglichkeit sich idiotisch zu verhalten und zwar wenn das fenster gerade per regenkontakt zu geht, dann auf den auf-kontakt drückt. vielleicht doch das ganze so lassen, nur eben mit dem regenrelais den auf-kontakt vom relais und zusätzlich den auf-schalterkontakt auch noch genau gleich auftrennen. dann könnte man nur noch per fhem das ding vom schliessen unterbrechen, aber da kann ich ja eine einfache if abfrage reinmachen wie für den pct regler auch.


todo: - calibration vorspielen, damit eine teilöffnung möglich ist. die auf- und zuvorgänge habe ich bereits ausgemessen.
- schaltplan erstellen, damit jemand anders dies auch so nachbauen kann.
- nochmal testen, ob im regen-zu-vorgang ein unterbrechen just in diesem moment per schaltung möglich ist.
- fhem "programmierung" erstellen, dass PCT-regler nicht schiebbar ist, wenn "regensensor" an ist.

Beta-User

...klingt lustig, da scheint dir pah aber mal richtig Angst vor Tasmota eingeflößt zu haben...

Aber (vielleicht...?) mal unabhängig davon: Die Shelly haben doch alle (u.A.) zwei GPIO (TX/RX) nach außen geführt. Es sollte doch möglich sein, da (ggf. via Spannungsteiler oder Optokoppler) das 24V-Signal vom Regensensor abzugreifen, und dann genau das umzusetzen, was du eigentlich haben willst: eine autarke Lösung ohne viele zusätzliche Komponenten...

Tasmota würde afaik jedenfalls Möglichkeiten kennen, die Taster (und den GPIO-Eingang) von den Relays zu trennen und dann via "rules" alles auf dem einen ESP zu lösen.
Das gilt mAn. (für Tasmota) sogar, wenn man die ursprüngliche Steuerung beibehält, was ggf. für eventuelle "Nachahmer" interessant ist, denen die Erhaltung der Gewährleistung wichtig ist ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors