Posts by 66er

    Hi koffie ,

    I am surprised and unsettled at the same time.

    Yesterday I received an email that my order is complete and the SL was sent now.

    I'm curious,:/

    A request to all users:

    We are seeing a steady increase in full quotes.

    Unfortunately, the button Zitieren.png always leads to a full quote. However, this can be edited manually.

    Most times, a full quote does not make sense in an immediate thread dialog!

    It would therefore be important to us that you shorten the quotes as far as possible to at least the important part.

    This keeps our database leaner and you yourself ensure that the performance of the forum is maintained in the long term.;)

    Thank you for your understanding :thumbup:

    To get the coupling up and running, we need the following programs and scripts:

    Pr EIN AUS.png

    Script for 1st THEN

    1. !Dimmer einschalten
    2. string url='';
    3. dom.GetObject("CUxD.CUX2801001:1.CMD_EXEC").State("wget -q -O - '"#url#"'");

    Script for 2nd THEN

    1. !Dimmer ausschalten
    2. string url='';
    3. dom.GetObject("CUxD.CUX2801001:1.CMD_EXEC").State("wget -q -O - '"#url#"'");

    Adjust the IP address of the dimmer and, if necessary, the CUxD Exec address!

    PR Aus von App.png

    script for THEN:

    1. !CUxD-Dimmer setzen
    2. string stdout;
    3. string stderr;
    4. dom.GetObject("CUxD.CUX2802006:2.SET_STATE").State(0);

    Adjust the CUxD channel of the dimmer!

    (The following 2 pictures result in 1 program)

    Dimmer aktualisieren T1.pngDimmer aktualisieren T2.png

    (Please ignore and omit the IF line with "CCU3-Reboot", unless you also monitor the boot status of your CCU)

    Script for 1st THEN:

    The script for the 2nd THEN line (in the ELSEIF branch):

    Please work through both scripts from top to bottom and adapt the IP address, CUxD device addresses and variable names to your system as indicated!

    That's it. :)

    #1 Introduction

    #2 The coupling

    View of the coupling as a dimmer:

    CUxD Dimmer.png

    to integrate the Shelly Dimmer in Homematic, you don't need any 3rd party firmware that you have to flash.

    techn. Requirements:

    • compatible with the Homematic systems CCU2, CCU3, Charly, as well as all offshoots such as RaspberryMatic and piVCCU.
    • installed addon CUxD in current version

    (At this point, I assume that you know how to use CUxD, e.g. how to create devices, otherwise this manual "explodes". Thank you for your understanding.)

    I have implemented the following functions on the Homematic page:

    • ON-OFF
    • Dimming using slider
    • Optional monitoring of the online status (accessibility in the WLAN)
    • Optional display of the power measurement

    Please note:

    Anyone who already knows my other Homematic couplings has to change a little. Due to the system differences described in # 1 between Homematic and Shelly, e.g. ON / OFF can be implemented in a completely new way. Therefore, please work through the instructions step by step from top to bottom, then it will work.:thumbup: Otherwise it can only go wrong. :D

    Contrary to the last couplings, the switching state ON or OFF can not be realized via actions!

    The implementation:

    (I do not describe the creation of the CUxD devices at this point, please use the CUxD documentation!)

    If not yet available, please create a device (28) System Exec! The commands are issued above this. (No entries are made in the CUxD-Exec!)

    Creation of a CUxD (28) Multi-DIM-Exec as dimming actuator 1-way:

    Bildschirmfoto vom 2020-01-05 19-28-31.png

    The device is set up as follows:


    Code for CMD_Exec:

    1. wget -q -O - '$1$'

    Adapt the IP!

    Now the controller is able to regulate the brightness of the dimmer .:)

    For the cyclical updating of the switching status and power display, we need 1 channel of an existing CUxD timer or a timer to be created.


    We also need 2 system variables


    These are linked to channel 2 of the CUxD dimmer so that they are displayed there.

    Of course, if you do not display the performance, you do not have to create the variable, but you must then delete the corresponding sections in the scripts.

    Online status display option:

    In order to monitor and display the online status, we need 1 channel of a CUxD ping device. (If you do not display, you do not need the variable in addition to the ping channel and can simply skip this section.)


    Adjust the IP address of the dimmer!

    (Times can be adjusted)

    Switch CMD EXEC TRUE:

    1. extra/timer.tcl Shelly-Dimmer_Onlinestatus_WZ 1

    Switch CMD EXEC FALSE:

    1. extra/timer.tcl Shelly-Dimmer_Onlinestatus_WZ 0

    adjust name of the variable (here: Shelly-Dimmer_Onlinestatus_WZ)

    ©2019 Stefan K. (alias 66er)

    #1 Introduction

    #2 The coupling

    Hello everybody,

    As a variant of the Shelly Dimmer - Homematic coupling from SparkyMaster , I present my solution below with the original firmware based on the connection as a CUxD dimmer.

    From my point of view, both solutions have advantages and disadvantages. That it is a matter of individual taste, which coupling you ultimately choose.

    Functionally, they can ultimately do the same.

    How does coupling via dimmer differ from the solution from Axel:

    • only 1 CUxD device (dimmer)
    • fewer system variables (2 instead of 4)

    For users who, like me, hardly use the Shelly app, my variant does not really cause a disadvantage. For users who also use the app a lot in parallel to Homematic, note the following:

    If the dimmer was switched off by the Homematic, the dimmer controller in the APP is turned down completely and must first be pulled up again if using the app.

    The reason for this is that the state OFF is handled differently by the Shelly and Homematic systems:

    When OFF, the Homematic dimmer is at 0% brightness at the same time, however, the Shelly controller remains in its set dimming position when switched off.

    Since of course I wanted to achieve a synchronous state in both systems, I had to make this compromise, otherwise OFF in the APP does not correspond to OFF in Homematic.

    There are other differences in both systems, which is why the coupling took longer time. The famous cat literally bit its tail very often due to these differences.

    :thumbup: But now, ther'senough written, let's go:

    Data transfer in Homematic:

    And now we come to the essentials.;)

    We create a 16-channel universal control in CUxD:


    A maximum of 16 Shelly Door / Windows can be mapped in Homematic with one 16-channel universal control . We need 1 channel for each Shelly Door / Window.

    The system variables desired in the view are linked to the channel (see picture in # 1) so that they become visible in the channel.

    We extend our program from # 2 in the THEN branch of the 1st IF condition by a 2nd line that executes the update script. It looks like this in the detail:

    Programm T2.png

    And last but not least, the script, which is to be worked through from top to bottom as usual. And as specified, IP of the Homematic, CUxD device address and CUxD Exec address must be adjusted:

    And now good luck with the reconstruction and above all have fun with it. :)


    The instructions including the scripts and pictures are subject to copyright. Anyone who infringes the copyright (for example, pictures or texts illegally copied and published on other websites), according to §§ 106 ff UrhG punishable, can also be warned for a fee and must pay damages (§ 97 UrhG).

    © 2019 Stefan K. (aka 66er)

    All rights reserved

    Query start and (optional) failure monitoring:

    Of cause the Shelly Door / Window is also battery operated, it is only online when it is sending data.

    In order for Homematic to know the time of transmission and to update the data accordingly, we first need a system variable that is updated by Shelly when it is sent.

    This system variable (here: Shelly-MK_Ausfall_WeFi) as well as the other variables must be created in advance:


    Now we need the actions in the Shelly Door / Window that serve as the trigger for the update process:


    The entry:


    Adapt the IP of the CCU and the name of the system variable to your own system. ;)

    Every time the Shelly is sent, the failure variable is updated, which we can now use as a trigger for updating the values in Homematic.

    However, since failure monitoring can also be optionally implemented with this variable, let's look at this first.

    We need a free channel of an existing device "CUxD-Timer" or create a new timer


    The time entry (preset) corresponds to 13 hours. The value may have to be adjusted later.

    (Since the official document for the Shelly Door / Window is not yet available, I assume a 12 hour interval for "routine reporting" of the Shelly.)

    And a program:

    Programm .png

    The timer is reset every time the Shelly has sent any data. The variable keeps the value "in order".

    (Later in this program, the values are updated via another THEN line.)

    You can do without the optional ELSEIF branch. I use it for an email notification if the Shelly fails.

    ©2019 Stefan K. (alias 66er)

    Hello everybody,

    to integrate the Shelly Door / Window in Homematic, you don't need any 3rd party firmware that you have to flash.

    Below is my solution with the original firmware:

    techn. requirements:

    • compatible with the Homematic systems CCU2, CCU3, Charly, as well as all offshoots such as RaspberryMatic and piVCCU.
    • installed addon CUxD in current version
      (At this point, I assume that I know how to use CUxD, e.g. how to create devices, otherwise this manual "explodes". Thank you for your understanding.)

    The advantages from my point of view:

    • very low price (19.90 €) compared to the Homematic original (from 29.95 €)
    • more properties can be used
    • all Shelly Door / Window properties are retained because I operate the Shelly with the original manufacturer firmware
    • all future Shelly Door / Window updates / updates will be available
    • full Shelly app usability parallel to Homematic automation
    • Operation as a local solution or via Shelly cloud, additionally Homematic

    So far I have implemented the following functions on the Homematicsystem:

    • Status display of the magnetic contact (open / closed)
    • Update of the integrated values with every transmission (battery status, brightness)
    • Optional monitoring of the cycl. reporting = failure monitoring and in case of failure e.g. email delivery

    The view of the connection:


    I would like to recommend you, especially beginners, to take a look at this thread before implementing:

    Please follow the instructions carefully from top to bottom when copying. ;)

    Otherwise, as always:

    If not yet available, please create a device (28) System Exec! The commands are issued above this. (No entries are made in the CUxD-Exec!)

    Have fun and good luck with it.:thumbup: