Skip to main content
Skip table of contents

FAQ

  1. Why there is no communication between Shelly and other KNX devices?
    Check if the communication interface (e.g. KNXnet/IP to KNX TP gateway) operates properly, e.g. has power, its status LED and etc.
    Check that both sides of your communication interface is properly connected, i.e. Ethernet or Wi-Fi is up and running. Check that Shelly device has an IP address on the IP interface used.
    Check for proper connection at the KNX TP (twisted pair) side.
    Check KNX setting Multicast address and communication port.
    Check if all Shelly devices are using the same Multicast address and communication port as the ones configured at the communication interface used.

  2. What does unique Individual address mean?
    As described in the Knowledge base the Individual address has the following format X.Y.Z
    Unique means that within a single KNX installation there should not exist two or more devices with all three parameters identical one to another.
    Example: If device “K” has Individual address 1.1.3 then device "L" shouldn’t get an Individual address with all three parameters identical to device “K” (1.1.3), but something else like 1.1.4.
    Devices using the default Individual address (15.15.255) are not considered as a conflict only.
    NOTE: The Individual address has no significance during normal operation of the installation.

  3. Is it possible to detect individual address conflicts from within the UI of the Shelly device?
    No. Shelly devices currently do not support this feature. It is sole responsibility of the KNX integrator to prevent such conflict.

  4. Does it matter if the device is connected over Ethernet or Wi-Fi for the KNXnet/IP functionality to work?
    The network connectivity type does not matter from device’s point of view. Stable network connection is required for flawless operation and such shall be taken into account when building the network infrastructure.

  5. What data is sent over the KNX network? Is all the information described in the API docs available?
    KNX protocol is closed automation system and is intended for operation by certified KNX partners only. The information described in the API docs covers supported by Shelly KNX options only. For understanding the terminology used a basic KNX knowledge (Basic KNX certificate) is required.

  6. Is it possible to have the Shelly device both in the KNX network and in a Shelly account?
    Yes, it is absolutely possible. Moreover it is possible to also connect the device to local home automation controller like Home Assistant at the same time.

  7. Reboot and/or power failure behavior?
    All of the KNX settings made are kept internally and reboot/power failure does not require any additional interactions by the user for further proper operation of Shelly devices.

  8. How does KNX handle failures or malfunctions in the system?
    KNX is communication protocol which is designed with very high failure prevention in mind. Every KNX telegram sent contains a check byte, which is used by all of the recipients to generate their own acknowledgement of successful data transmission to notify the sender. When all of the recipients acknowledge successful data reception back to the sender, then a new telegram is sent again.
    In case of error detection the whole telegram is repeated. Default repetition of a KNX telegram is three times, a parameter which may be changed.

  9. Diagnostics and problems solving in Shelly + KNX integrations
    Proper diagnostic process can not be done without using KNX programming software (e.g. ETS).
    For comprehensive diagnostics one is obligated to use both - Shelly provided Diagnostics page from the embedded web interface (Advanced -> Diagnostics) and the Diagnostics function included in the KNX programming software (e.g. ETS → Diagnostics).

  10. Do Shelly devices support KNX Security?
    No. Shelly devices are not capable to decrypt neither the KNX IP Security or KNX Data Security, both part of the KNX Security extension of the KNX Standard. A non encrypted communication is supported only.

  11. Manually modifying the Communication Flags of KNX objects
    Some KNX manufacturers DO NOT set the Read Flag as Active (see Pic. 1) on their Switch actuators' Channel X Feedback object of the corresponding channel. When the Read Flag is not enabled the TOGGLE function of Shelly devices won’t work!

    image-20240711-140508.png

    When such case occur, the Read Flag should be manually enabled via the ETS (or other) configuration software. Select the KNX object which you need to modify and then Navigate to its Flags Properties - may be found onto the right side of the ETS configuration software under Properties → Flags (See Pic. 2 and Pic. 3).

image-20240711-141054.png

Should be modified to:

image-20240711-141310.png

Pic. 4 shows how the configuration should look like once all the Read Flags are set on all (or user needed) of the switch actuator channels.

image-20240712-061721.png

Note that the KNX manufacturers may give different names on their equipment for the Switch object and for the Feedback object. For example in the case above, for Channel [X] (1-4) the manufacturer is using R[X] Input for Switch object and R[X] Output for Feedback pobject.

You have to transfer all of the changes made back onto the affected KNX devices.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.