Shelly2 IP Schaltaktor

[Papa Romeo]

Aber nur, wenn er dazu High Heels trägt ...

LG

pah

...sag blos du trägst so Dinger...wären mir zu unbequem......

[Papaloewe]

...noch eine etwas andere Idee zu den Rolladenmotoren:

Wie wäre es einen handelsüblichen Motor mit einem Impulsgeber zu erweitern?
Ich denke da an so etwas wie man früher in den mechanischen Rollermäusen verbaut hat.
Eine Scheibe mit Segmenten (ich komme gerade nicht auf den Fachbegriff) zum Aufstecken auf die Sechskantwelle und dazu noch eine Lichtschranke.

[Cluni]

Viele Wege führen nach Rom. Aber ob es den Aufwand wert ist?!

Vor allem musst du dann ja eine Regelung bauen die:
1. Die Impulse mitzählt (wie auch immer - z.B. über flankengesteuerte Zählerbausteine oder über Interrupteingänge an irgendeinem µControler).
2. Die aktuelle Position ständig mit der Sollposition vergleicht und darauf regelt

Was willst du denn eigentlich damit bezwecken? Wozu braucht man das SO genau???

[Papa Romeo]

...noch eine etwas andere Idee zu den Rolladenmotoren:

Wie wäre es einen handelsüblichen Motor mit einem Impulsgeber zu erweitern?
Ich denke da an so etwas wie man früher in den mechanischen Rollermäusen verbaut hat.
Eine Scheibe mit Segmenten (ich komme gerade nicht auf den Fachbegriff) zum Aufstecken auf die Sechskantwelle und dazu noch eine Lichtschranke.

...oder ein Hallsensor und kleine Magnete, ähnlich wie beim GW60-Projekt. Die Position des Rollladens ist immer bekannt, da sie Wemos gespeichert und z.B nach einem Stromausfall abgerufen und an FHEM übertragen wird.

[Prof. Dr. Peter Henning]

Das ist leider alles Käse.

Die Rollladen selbst laufen bei konstanter Winkelgeschwindikeit der Welle nämlich unterschiedlich schnell - die Dicke des "Wickelpaketes" ist nämlich nicht konstant. Nun könnte man zwar ein (mathematisches) Modell entwerfen - das wäre aber sehr ungenau, weil die Rollläden sich je nach Temperatur, Anfangsdrehmoment (=> straff oder weniger straff) ganz unterschiedlich aufwickeln können. ich tippe mal, dass man auf +/-5% genau sein könnte. Diese Genauigkeit kann ich aber auch mit einem Laufzeitmodell und primitivem Motor erreichen.

LG

pah

[Cluni]

Na dann müssen halt Lichtschranken im Abstand von allerhöchstens 1mm auf die Führungsleiste ... [emoji23][emoji849]

Ich kann mir immer noch kein Szenario vorstellen, wo man das so genau braucht?! Kann mich von den Leuten mal jemand aufklären wozu das Ganze gut sein soll?

Gesendet von iPhone mit Tapatalk

[marvin78]

1mm ist doch viel zu ungenau.... 

[Beta-User]

Laserabstandsmessung?
Aber bitte wo ist der Bezug zum eigentlichen Thema?
(Oder kann der Shelly bereits einen bestimmten Abstandsmesser ?)

[marvin78]

Der Bezug zum Thema war schon bei High Heels weg.

[Beta-User]

Der Bezug zum Thema war schon bei High Heels weg.

Einspruch. War ein paar Beiträge vorher.

Aber dennoch: Wie wäre es mit der Rückkehr zur Sache?

[noch ein wenig OT]
Nach meinen bisherigen Erfahrungen ist der MQTT2-Pfad für in etwa genau so einfach wie ein eigenes Modul.

Und das mit dem Flashen (in Richtung Tasmota) als Hürde ist zwar richtig, aber die Shelly's bringen doch schon die Schnittstelle mit (und ggf. Optionen an der Web-Oberfläche?). Hat man ein binary (und ggf. einen USB-Seriell-Wandler) sollte der geübtere FHEM-User das hinbekommen.[/OT]

[MarkusN]

Für die Leute mit Tasmota auf dem Shelly:
Welche Version nutzt ihr momentan? Die aktuelle stable Version (6.2.1) unterstützt die Shellys wohl noch nicht ohne weiteres.
Ich habe mir die aktuelle binary von http://thehackbox.org/tasmota/ heruntergeladen, hier funktionieren allerdings nur switchmode 1 und 2.

[Papa Romeo]

...ich hab das Development drauf...aber wir sollten vielleicht in den anderen Shelly2 Thread gehen. Die Tasmotianer sind hier nicht so gern gesehen.

[cs-online]

Das ist leider alles Käse.

Die Rollladen selbst laufen bei konstanter Winkelgeschwindikeit der Welle nämlich unterschiedlich schnell - die Dicke des "Wickelpaketes" ist nämlich nicht konstant. Nun könnte man zwar ein (mathematisches) Modell entwerfen - das wäre aber sehr ungenau, weil die Rollläden sich je nach Temperatur, Anfangsdrehmoment (=> straff oder weniger straff) ganz unterschiedlich aufwickeln können. ich tippe mal, dass man auf +/-5% genau sein könnte. Diese Genauigkeit kann ich aber auch mit einem Laufzeitmodell und primitivem Motor erreichen.

LG

pah

Ich habe bei mir bislang Homematic Rolladenschalter unterputz, die machen das auch über Laufzeit. Bei mir werden die Rollläden auf geschätzte max. 5mm wiederholgenau auf Position gefahren, meist exakt auf die selbe Position. Genauer braucht das kein Mensch... Allerdings wird natürlich bei z.B. 50% Anforderung nicht tatsächlich 50% Höhe gefahren, da (wie PAH schon ganz richtig schrieb) sich der Panzer ja zu einer Rolle aufwickelt und so trotz gleicher Winkelgeschwindigleit des Motors der Rollladen, wenn er weiter aufgewickelt ist, auch tatsächlich schneller rauf bzw. runter geht als bei dünnerer Rolle. Einzig ein Problem bleibt: Wenn der Panzer irgendwo auf dem Weg nach unten hängen bleibt, wird das natürlich nicht bemerkt und so ist es einmal in 15 Jahren passiert, dass sich die Rolle aufgeschoben hat und beim Hochfahren dann komplett in den Kasten gezogen wurde, was ein wenig Bastelaufwand gekostet hat, den Anfang da wieder raus zu bekommen....

Grüße

Christian

[Prof. Dr. Peter Henning]

Zum Thema Einstellhöhe: Man kann mit 3 Parametern einen einfachen Fit erzeugen, mit dem der Einstellwert 50% tatsächlich 50% entspricht. Man kann aber auch von vorneherein sagen "Stelle den Rollladen am Fenster auf 70 Prozent".

Zum Thema Shelly: ich habe einen Shelly 4 Pro jetzt unter MQTT laufen. Macht vom Handling her drei wesentliche Unterschiede

1. Mit MQTT können keine Settings beeinflusst werden - mit dem Modul 36_Shelly sehr wohl. Das gilt auch für den Shelly2, man kann ihn also NICHT per MQTT zwischen den Modi umschalten oder so etwas wie den OverPower-Wert setzen.
2. Mit MQTT kommen alle 30 Sekunden Leistungsdaten an - das ist, im Gegensatz zum Shelly-Modul nicht beeinflussbar
3. Die Syntax des setList-Attributes erlaubt offenbar nicht, dass Schaltkommandos parametrisiert werden. Man braucht also zum Schalten wirklich 8 Kommandos für 4 Kanäle

Code Auswählen Erweitern


setList    relay_0_on shellies/shelly4pro-061D51/relay/0/command on\
relay_0_off shellies/shelly4pro-061D51/relay/0/command off\
relay_1_on shellies/shelly4pro-061D51/relay/1/command on\
relay_1_off shellies/shelly4pro-061D51/relay/1/command off\
relay_2_on shellies/shelly4pro-061D51/relay/2/command on\
relay_2_off shellies/shelly4pro-061D51/relay/2/command off\
relay_3_on shellies/shelly4pro-061D51/relay/3/command on\
relay_3_off shellies/shelly4pro-061D51/relay/3/command off

Bei Punkt 3 bin ich mir nicht sicher, ob es nicht doch noch einen Workaround gibt. Trotzdem reichen mir bereits die beiden ersten Punkte um zu sagen: Das gibt sich nichts. Der Nachteil, dass eine Schaltänderung direkt am Shelly erst nach dem nächsten Poll sichtbar ist, scheint mir durch die bessere Ausstattung der REST-Schnittstelle aufgewogen.

Ein vierter Unterschied kommt beim Shelly2 hinzu: Die Logik, die in in 36_Shelly.pm für das Anfahren einer Rollladenposition implementiert habe, fehlt in der MQTT-Version. Für die Nutzung als Rollladenaktor ist also eindeutig 36_Shelly.pm die bessere Wahl. Für die Nutzung ist noch eine hybride Version denkbar: Alle Set-Befehle erfolgen über 36_Shelly.pm (und auch Konfigurationsänderungen). Aber statt in festen Abständen den Status zu pollen, wird eine minimales MQTT-Device definiert, sowie ein notify, das dann beim Eintreffen einer MQTT-Nachricht vom Shelly die Readings in dem anderen Device updatet.


LG

pah

[Papa Romeo]

@cs-online:  ...das kann immer passieren solange man keine Kontrolle hat, ob der Rollladen auch fährt , solange sich die Welle dreht. Ist mir auch schon passiert.