Beiträge von SeRef

    Ich hatte in diesem Beitrag schon mal beschrieben, wie man einen 2.5 so einrichtet, dass man ihn über die Homematic mit einer Prozentangabe steuern kann. Da ich vor ein paar Tagen meinen ersten Plus 2PM erhalten und erfolgreich in der Homematic eingebunden habe, will ich hier mal meine Vorgehensweise vorstellen.

    Der hauptsächliche Unterschied liegt darin, dass beim 2.5 die aktuelle Position des Rollos von der CCU per http geholt werden muss und beim Plus 2PM die Position von ihm an die CCU übertragen wird.


    1. Wenn noch nicht geschehen, muss CUxD installiert werden. Ich habe für diese Anleitung Version 2.8 in Verbindung mit piVCCU 3.61.7 verwendet. Auf dem Shelly ist die Firmware 0.10.1.


    2. Erstellen eines neuen CUxD-Gerätes:

    CUxD-Gerät_1.png

    Gerätetyp: (28) System

    Funktion: Exec

    Control: Jalousie

    Seriennummer, Name und Geräte-Icon können frei gewählt werden. Die Angaben/Auswahl hat keinen Einfluss auf die Funktion.

    Wer die App Home24 verwenden möchte, muss bei Geräte-Icon einen Jalousieaktor auswählen (lässt sich auch nachträglich ändern). Ansonsten wird er in der App nicht angezeigt.


    3. Das eben erstellte CUxD-Gerät muss noch eingestellt werden:

    CUxD-Gerät_2.png

    Die nicht vollständig sichtbaren Einträge sind

    BLIND|CMD_SHORT:

    wget -q -O - -t 1 -T 10 'http://$C1$/rpc/Cover.Stop?id~3d0'

    BLIND|CMD_LONG:

    wget -q -O - -t 1 -T 10 'http://$C1$/rpc/Cover.GoToPosition?id~3d0~26pos~3d$VALUE$/10'

    Bei BLIND|CH_PARAM1 muss die IP-Adresse des Shelly eingetragen werden.


    4. Der erste Test.

    Wenn alles richtig eingestellt ist, sollte der Rollladen sich jetzt unter Status und Bedienung > Geräte bedienen lassen.

    HomeMatic WebUI_1.png


    Damit aber auch der Status der CCU bekannt ist, wenn von anderer Stelle (Shelly APP, Schalter/Taster, WebUI, …) gesteuert wurde, ist noch ein weiterer Schritt notwendig.

    5. Im Shelly ist ein Skript hinzuzufügen.

    Shelly Plus2PM_1.png


    Das Skript:

    IP der CCU und Name des Rollladenaktors muss angepasst werden!

    Ist im Namen des verwendeten Kanales vom CUxD ein Leerzeichen, muss dieses wie in meinem Beispiel durch <%20> ersetzt werden.


    Das sollte so weit alles sein, um den Rollladen steuern zu können und auch den aktuellen Stand in der CCU zu haben. Möglich wäre noch eine zusätzliche zyklische Abfrage der Position. Ob das aber überhaupt nötig ist, wird sich im Laufe der Zeit herausstellen. Mein Ziel ist es, auf das Polling gänzlich zu verzichten.


    Zum Schluss noch etwas Rechtliches:

    Die Anleitung inkl. der Skripte und Bilder unterliegt dem Urheberrecht. Wer gegen das Urheberrecht verstößt (z.B. Bilder oder Texte unerlaubt kopiert und auf anderen Webseiten publiziert), macht sich gem. §§ 106 ff UrhG strafbar, kann zudem kostenpflichtig abgemahnt werden und muss Schadensersatz leisten (§ 97 UrhG).

    © 2022 SeRef

    Alle Rechte vorbehalten

    Hallo Commander_1971,

    ich zitiere mal aus dem ersten Beitrag:

    Falls noch nicht vorhanden, bitte ein Gerät (28) System Exec anlegen! Darüber werden die Befehle abgesetzt. (Im CUxD-Exec werden keine Eintragungen gemacht!)

    Dieses CUxD-Exec-Gerät, das du da angelegt hast, hat insgesamt 16 Kanäle. Jeder Kanal hat eine eigene Adresse und im Skript ist die Adresse des Kanals anzugeben, den du beabsichtigst zu verwenden.

    Gruß

    SeRef

    Also, wenn ich das hier richtig lese, gibt es genau drei Möglichkeiten:

    1. Ich pfeiffe auf die internen Timer (dann brauche ich allerdings auch keinen NTP-Server)
    2. Ich erlaube dem Shelly Internetzugang (dann ist der eigene, lokale NTP-Server auch nicht so richtig notwendig)
    3. Ich nutze NTP-Server und verbiete Internet, muss dann aber 2x im Jahr bei allen Shellies den Haken für Sommer-/Winterzeit umstellen?!

    Es gibt noch eine 4. Möglichkeit:

    Der Shelly reagiert nicht auf die Einstellungen der Zeitzone und Daylite on/off/auto und zeigt immer die gleiche Zeit.

    Ich vermute, es liegt daran, dass er noch nie Verbindung zum Internet hatte.

    Hallo und willkommen im Forum!


    Ich habe das Skript etwas angepasst.

    Änderungen zum Skript aus #2 sind in den Zeilen 51, 59, 72, 73 und 78.


    Damit sollte verhindert werden, dass ein Wert eingetragen wird, der nicht aus der Antwort vom PM ausgelesen wurde.

    Bei Problemen melde dich bitte noch mal.

    Gruß

    SeRef

    Da ich keinerlei Erfahrungen mit LOGO habe, kann ich es dir nicht genau sagen. Aber laut ioBroker Forum soll es seit Adapterversion 1.1.1 funktionieren. Siehe hier. Aktuell ist 1.3.11.

    Aus den Beiträgen geht auch hervor, dass es mit openHAB auch eine Möglicjkeit geben soll.

    Hallo MAO25 und willkommen im Forum.

    Zu2:

    Es gibt für ioBroker einen Adapter, mit dem man eine S7 anbinden kann. Ich verwende es mit einer S7-300. Es soll damit auch möglich sein, einige LOGO-CPUs anzubinden. Damit würde dir der Weg offen stehen für Visualisierungen und weitere Anbindungen an andere Systeme.

    Gruß SeRef

    Bad news.

    Sry man, so you have to wait.

    I don't know why

    I had ordered a Pro 1PM on 07.02.22. At the time, the shop indicated availability from 12.01.22. The order confirmation gave me January 20, 2022 as the shipping date.

    On January 28, 2022, I was informed that the delivery had arrived and that the products were brand new and had to be tested before delivery. New shipping date was 07.02.22.

    Yesterday evening (February 9th, 2022) I got the message that the check found errors that prevent delivery. The reason for the error has been found and its elimination must now be incorporated into production. The Pro 1PM, Pro 2PM and Pro 2 appear to be affected by this.

    Since production takes time, availability is not expected until the end of March.

    Das es bei den Kanälen ausgegraut ist, kenne ich nur bei den nicht bedienbaren Geräten (z.B. Fensterkontakt). Diese erscheinen aber dennoch in den Räumen.

    Bei bedienbaren Kanälen lässt sich die Bedienbarkeit einstellen. Bei bedienbar (Haken gesetzt) erscheinen sie in den Räumen, bei nicht bedienbar (kein Haken) erscheinen sie auch nicht in der Liste.

    Bei CUxD-Geräten ist bei mir das Feld in den Kanälen nie ausgegraut und lässt sich ändern. Ich habe noch mal zum Test neue CUxD Geräte vom Typ 40 mit unterschiedlichen Controls erstellt, konnte aber bei allen den Haken in den Kanälen setzen. Auch bei denen, die als Tür-/Fensterkontakt oder Drehgriffkontakt definiert waren.

    Ob es nun daran liegt, dass du Rasperrymatic einsetzt und ich PivCCU, kann ich nicht sagen. Ich weiß, dass es Unterschiede gibt, habe aber im Moment keinen Zugriff auf eine Raspberrymatic um zu probieren, ob es in diesem Fall daran liegen könnte.

    Als Nächstes würde ich ein weiteres CUxD Gerät Typ 40 mit Control Schalter erstellen und es damit mal versuchen.

    Solange unter "Output on URL" er per http einen Befehl an sich selber sendet, wird dort http als letzte Quelle stehen, egal auf welchem Weg er ein- oder ausgeschaltet wurde.

    Das ist logisch. Verstehe ich denn "Output on URL" falsch? Ich habs so interpretiert, dass der Befehl dann abgesetzt wird, wenn switch=an. Und nicht bei jeder x-beliebigen Aktion. Falsch interpretiert?

    Sorry, falsche Info. Bei "Output on URL" natürlich nur beim Einschalten und nicht beim Ausschalten.

    Das er allerdings, obwohl schon Ein, auch beim Dimmen den Action auslöst, ist schon fragwürdig. Meiner Meinung nach sollte das nicht so sein und würde es als Bug bezeichnen. Hier wäre es besser, einen separaten Action zu haben, der dann auslöst, wenn der Dimmwert geändert wurde.

    Es hat den Anschein, dass alleine das Ändern des Dimmwertes den Action schon auslöst (ob das nun ein Feature oder Bug ist :/)

    Wann genau der Action auslöst, ließe sich recht leicht herausfinden. Du könntest z.B. per Befehl eine Variable über die API von ioBroker ansprechen und diese ins Log schreiben lassen.

    Bei mir steht immer http?

    Solange unter "Output on URL" er per http einen Befehl an sich selber sendet, wird dort http als letzte Quelle stehen, egal auf welchem Weg er ein- oder ausgeschaltet wurde.

    Hallo radierer,

    ich habe keinen Dimmer um es nachstellen zu können und bin mir über sein Verhalten nicht sicher, habe aber eine Vermutung.

    Du schaltest den Dimmer ein. Er sendet daraufhin an sich selbst über Output on (URLs) den Befehl, einzuschalten und auf 50% zu Dimmen. Meine Vermutung ist nun, dass er, da er den Befehl zum Einschalten bekommen hat, wieder den Befehl über Output on (URLs) absendet und so eine Schleife entsteht.

    Versuch mal das turn=on wegzulassen:

    http://localhost/light/0?brightness=50