Frequently asked questions

SUPLA is an open smart home platform that includes compatible devices, mobile apps, server software, cloud services, a web interface, and integration mechanisms.

With SUPLA, you can control lighting, shutters, gates, pedestrian gates, heating, and other devices, as well as monitor temperature, humidity, energy, water, or gas consumption. Available features depend on the devices used and their configuration.

SUPLA does not depend on a single central hub and is not a single product. It is a platform used by devices from different manufacturers and solutions created by the community.

No. You can buy ready-made SUPLA-compatible devices, install the app, and configure the system using the setup wizard.

Building your own devices, using the API, and running your own server are options for people who want to extend or customize the system. They are not required for everyday use of SUPLA.

Using the official SUPLA app and cloud is free of charge. Creating an account does not require a fee or a subscription.

You are still responsible for the cost of devices, installation, electricity, and Internet access. Your own server may also require hardware, a domain, a certificate, hosting services, and administration.

Terms of cooperation with device manufacturers are agreed separately and do not follow from the free use of the cloud by end users.

Most SUPLA devices do not require an additional central hub or gateway. Wi-Fi and Ethernet devices can connect directly to a SUPLA server.

Some devices do use an additional gateway, for example because of their radio technology or integration with another standard. Always check the product description and the instructions for the specific device to see whether a gateway is required.

Yes. One of SUPLA's core features is the ability to operate compatible devices from different manufacturers in one app.

This does not mean that every device from a given brand is SUPLA-compatible. Compatibility must be checked for the specific model.

See compatible devices.

No. The protocol, radio module, or microcontroller used does not by itself determine compatibility with SUPLA.

The device must have suitable software or work with a gateway or integration that supports SUPLA. Before buying, check the exact model in the device catalog and in the manufacturer's documentation.

Officially compatible devices can be found in the device catalog. Compare the exact model with the information provided by the manufacturer and seller.

You may also find devices modified to work with SUPLA and DIY projects online. They may work correctly with the platform, but they are not official SUPLA products and usually do not appear in the catalog. The seller or project author is responsible for describing their capabilities, configuration, software, and support.

Before buying such a device, ask the seller for at least the following information:

• which exact model and software project are used;
• which device features are available in SUPLA;
• whether the device requires an additional gateway;
• how initial setup, reset, and software updates work;
• whether the connection to the server is encrypted;
• who provides instructions, technical assistance, the warranty, and future updates.

The SUPLA logo or a claim that a listing “works with SUPLA” does not mean that the device is officially supported by SUPLA.

Yes. This is one of the important differences between SUPLA and closed smart home systems.

SUPLA devices are not permanently tied to the current official SUPLA infrastructure. They use an open protocol and can be configured to work with another SUPLA server.

There are no plans to shut down the official servers. However, if the official cloud service were ever discontinued, anyone could run their own server or use another provider offering compatible SUPLA infrastructure.

With closed systems, discontinuation of the manufacturer's cloud service may result in the loss of some or all device functionality. SUPLA's open-source software and the ability to change servers reduce this risk.

Moving an existing installation to another server is not always automatic. It may require reconfiguring devices, transferring data, and maintaining the infrastructure yourself. Some external services, such as push notifications or voice assistants, may require additional configuration or may not work identically on a private instance.

The simplest way to get started involves three steps:

1. download the SUPLA app for Android or iOS;
2. create a free account;
3. choose the option to add a device in the app and follow the setup wizard.

The exact setup process may depend on the manufacturer and device model. For devices connected to an electrical installation, make sure they are installed correctly according to the instructions first.

Almost all SUPLA devices that connect directly over Wi-Fi work only in the 2.4 GHz band and require a network compatible with IEEE 802.11 b/g/n. They usually do not support a network operating exclusively in the 5 GHz band.

Ethernet devices and devices communicating through an additional gateway are also available. Always check the exact requirements in the instructions for the specific model.

A router can provide 2.4 and 5 GHz bands under the same network name. Separating the names is not always necessary, but can help diagnose configuration problems.

Basic device operation does not have to depend on the Internet. Physical buttons, inputs, and logic executed locally by the device work independently of a connection to the server. Devices can also execute local weekly schedules, for example thermostats.

Scenes, schedules, reactions, notifications, and other automations configured in SUPLA Cloud are server-side features. To execute them, the device must be connected to the relevant SUPLA server. With the official cloud, this also means Internet access.

Controlling a device through the official cloud in the app also requires the phone and device to connect to the server. During an Internet outage, locally executed features should continue to work, but server-side features should not be expected to.

After replacing a router, the easiest option is to set the same Wi-Fi network name, password, and compatible security settings as on the previous router. In most cases, SUPLA devices will reconnect automatically and will not need to be configured again.

If the network name or password changed, the device must receive the new network details. If the device does not reconnect automatically, it must be placed in configuration mode again. Depending on the model, this may require holding a button, using a dedicated CONFIG button, or following a specific sequence of actions. Refer to the instructions for the specific device for the correct procedure.

The recommended order is:

1. check the device power and local-button operation;
2. check the required Wi-Fi band and security type;
3. start configuration mode according to the manufacturer's instructions;
4. enter the new network name and password;
5. check in the app that the device is online again.

Do not start with a factory reset if the device allows you to change only the network configuration. A reset may remove additional settings, calibration, or account assignment.

First determine whether the problem concerns power, the local network, Internet access, the server, or the device itself.

Check the following in order:

• whether the device has power;
• whether it can be controlled with its local button;
• how the status LED behaves and what its pattern means according to the device instructions;
• whether other devices on the same network have Internet access;
• whether the device is within Wi-Fi range;
• whether the router's network name, password, band, or security settings changed;
• whether the problem affects one device or the entire installation.

If the device provides a local configuration portal, first switch the device to configuration or pairing mode. Then connect a phone or computer to the Wi-Fi network broadcast by the device and open http://192.168.4.1 or https://192.168.4.1 in a browser, depending on the device. Check the Last state field there. The saved state or error message can indicate whether the problem concerns the Wi-Fi, Internet, or SUPLA server connection.

If the device remains offline, follow the manufacturer's instructions. A factory reset should be the last step, not the first diagnostic action.

It depends on the device. A battery-powered sensor or plug-in device may be intended for self-installation.

Devices connected to a 230 V installation, distribution board, gate drive, heating system, or other technical systems should be installed according to the instructions by a person qualified for the relevant work.

SUPLA is a platform, not one type of hardware. Always check the supply voltage, output load, required protection, wiring diagram, and warranty conditions for the specific product.

The simplest option is to register the SUPLA app on another phone using the same email address and password.

After registration, the app receives the access provided by the first access identifier and the locations assigned to it. This does not necessarily mean access to every location and device on the account.

After registering the phone, you will often need to sign in to SUPLA Cloud and assign the appropriate access identifier to the app. You can also create a separate access identifier and assign only selected locations to it.

This lets you control which devices are available on each phone. When sharing devices that open gates, pedestrian gates, or doors, pay particular attention to the scope of the granted access.

An installer should not add the customer's devices to their own account or give the customer access only to a Location from the installer's account. Devices should be added from the start to an account belonging to the owner of the installation.

SUPLA currently does not support migrating an entire installation between accounts. If devices were added to the installer's account, handing them over later may require adding each device again to the customer's account.

The SUPLA account should be created from the start by the owner of the house, apartment, or business using their own email address. SUPLA currently does not provide separate service access for installers.

During configuration, the installer may need the customer's login and password. Once the work is complete, the owner should set a new password known only to them and review the list of devices, Locations, Access Identifiers, client apps, tokens, and integrations.

The email address is the login for the SUPLA account and currently cannot be changed.

When selling a property, there are two options:

• transfer the entire existing account to the new owner — but only if the account is used exclusively for that property and control of the email address used to sign in can also be safely transferred;
• create a new account for the new owner and add all devices to it again.

If the account uses the seller's private email address or contains other Locations, devices, or data that the buyer should not be able to access, the entire account should not be transferred. In that case, creating a new account is the safer option.

Handing over only the account password is not sufficient if the seller still controls the email address.

Before the handover or reconfiguration, export any measurement history that should be retained and review linked integrations, Access Identifiers, client apps, and API tokens. After an account is handed over, the new owner should set a new password.

History is available for channels that record measurements, such as temperature, humidity, electricity, water, or gas.

After signing in to SUPLA Cloud, open the relevant channel and its history. Available data can be downloaded in formats including CSV, ODS, XLSX, and HTML. The available history depends on the channel type, account limits, and server configuration.

Before deleting an account, resetting a device, or migrating to another server, export data that may be needed for analysis or billing.

Yes. A SUPLA account has functional limits, data retention limits, API request limits, and other restrictions intended to protect the service from errors and abuse.

You can check the current limits and their usage after signing in to SUPLA Cloud → Account → Show my limits.

The panel includes limits for:

• input/output devices;
• access identifiers;
• client and OAuth applications;
• locations;
• channel groups;
• schedules;
• scenes;
• direct links;
• reactions;
• data sources;
• defined and sent notifications;
• API requests.

The same page also shows data retention rules. Some detailed measurement data is periodically deleted after a specified period. This may include voltage, current, and power history recorded by electricity meters. The panel shows the current retention periods that apply to your account.

Limits also apply to the size of individual configuration elements. For example:

• a channel group can contain up to 30 channels;
• a schedule can contain up to 20 actions;
• a scene can contain up to 20 operations.

The limits are primarily intended to protect the infrastructure from errors and abuse, rather than restrict normal use of SUPLA. If any limit is too low for your installation or integration, contact us by email. Specify which limit needs to be increased, provide the requested value, and briefly describe the intended use.

You can start deleting your account in the account settings in SUPLA Cloud. The operation requires your password and confirmation by email.

Account deletion is irreversible and removes data assigned to the account, including connected devices, configured channels, direct links, and measurement history. If you want to keep measurement history or other data, export it before confirming account deletion.

Connections between the SUPLA app and the SUPLA server, as well as connections from all official SUPLA devices to the server, are encrypted. However, the security of the complete system also depends on the device, its software, the Wi-Fi network, the account password, the phone, and the way access and integrations are configured.

Administrative access to the official SUPLA infrastructure is restricted to authorized personnel. The infrastructure is maintained, updated, and monitored, and the data is covered by backup mechanisms. Backups are primarily intended to restore the service after a serious failure. They should not be treated as a replacement for user data exports or as a guarantee that an individual deleted account item can be restored.

For a private SUPLA instance, its administrator is responsible for server security, administrative access control, updates, certificates, backups, and data recovery.

Unofficial DIY devices and modifications may work differently from official devices. Typical SUPLA devices based on Arduino Mega and other 8-bit AVR microcontrollers do not support an encrypted connection to the server. In older ESP8266-based DIY projects, encryption was also sometimes disabled by default because of limited RAM.

Users should:

• use a unique and strong password;
• secure the email account used for access recovery;
• keep the app and device software up to date;
• regularly review access identifiers and registered client applications;
• remove unused API tokens and integrations;
• properly secure any private server;
• not share access credentials with people who should not manage the installation.

A direct link should be treated as an access key to the assigned function. We do not recommend sending direct links that execute an action, such as opening a gate, by email. Email security systems may automatically open links while scanning messages and unintentionally trigger the assigned action. Share direct links only with trusted people and remove them when they are no longer needed.

Some SUPLA devices provide a local configuration portal over HTTPS, for example at https://192.168.4.1. Your browser may display a warning if the SUPLA Root CA certificate is not trusted by your operating system or browser.

To avoid these warnings, you can download and install the appropriate SUPLA Root CA certificate as a trusted certificate authority.

These CA certificates are also used to verify certificates used by SUPLA devices for encrypted communication, including device registration and login to a SUPLA server.

The certificates are available here:

• supla_org_root_ca.crt

  SHA-256: 31:5D:CD:05:73:E9:02:B8:16:0F:34:01:74:FB:9E:EE:49:1C:B3:97:40:CA:0E:DA:18:BF:29:D0:64:FB:4C:25

• supla_org_private_cloud_root_ca.crt

  SHA-256: FD:6A:E5:DD:6C:08:BB:4D:51:BE:A2:76:6D:28:7F:44:C1:28:14:A6:2C:2B:85:C1:5C:5D:1F:26:21:BF:24:5B

Only install CA certificates obtained from the official SUPLA domain.

Responsibility depends on the type of problem:

Problem	First contact
Device damage, warranty, instructions, or product firmware	device manufacturer or seller
Installation, wiring, or configuration performed as a service	installer
Account or operation of the official SUPLA cloud	SUPLA support
Private SUPLA instance	server administrator
Own DIY project	documentation, GitHub, and the community
Suspected security vulnerability	the relevant project's or manufacturer's private security channel

SUPLA integrates products from many companies, so we do not replace the device manufacturer's warranty service.

For a ready-made device, start with the manufacturer's or seller's instructions and support. Report installation issues to the installer, and account or official cloud issues to SUPLA support.

You can also ask direct questions about official devices on the SUPLA forum, which has dedicated sections for these topics. Questions about your own devices, integrations, and unusual configurations can be posted on the forum or in the relevant repository of the SUPLA GitHub organization.

Before reporting a problem, prepare the device model, firmware and app versions, network description, exact error message, and information about the steps already taken.

Yes. SUPLA provides source code and a set of containers for running your own instance. The recommended basis for deployment is the supla-docker project.

Your own server gives you more control over infrastructure and data, but requires administration. The server owner is responsible for updates, backups, TLS certificates, the domain, monitoring, availability, and security.

Do not assume that all services are fully compatible with the public cloud without additional configuration. Push notifications, voice assistants, and some integrations may require your own keys, certificates, or external services.

The current status of key SUPLA services and servers can be checked at status.supla.org. Information about ongoing and resolved incidents is also published there. You can also subscribe to notifications about changes in the infrastructure status.

Yes. SUPLA recommends MQTT as the primary way to integrate with Home Assistant.

SUPLA supports two MQTT scenarios: account-wide MQTT provided by the SUPLA server, and direct local MQTT available on supported devices.

Account-wide MQTT allows Home Assistant to receive device states and execute actions without configuring every device separately. It also supports MQTT Discovery, allowing Home Assistant to automatically discover and create entities for most supported device functions.

Some SUPLA devices can connect directly to an MQTT broker running on the local network.

Other integrations based on the SUPLA API may also exist, but they are not maintained or supported by the SUPLA project.

Yes. SUPLA works with Google Home and Amazon Alexa. Available commands depend on the device type, its functions, and the capabilities of the assistant.

After linking the accounts, check which devices and actions have been made available. For gates, pedestrian gates, and doors, pay attention to the command authorization method provided by the assistant platform.

Yes. The SUPLA app supports Android Auto and Apple CarPlay.

The car interface provides selected features adapted for safe operation while driving. Do not expect access to every channel, setting, and feature available in the full mobile app.

No. The car interfaces currently allow selected actions to be executed but do not show whether the gate is open or closed. You can check whether the gate is open or closed in the full SUPLA mobile app, but this requires a suitable opening sensor.

Yes. SUPLA Cloud provides a REST API and authorization mechanisms for creating integrations. MQTT is also available for automation systems, apps, and tools such as Home Assistant.

Grant tokens and integrations only the permissions they need. Remove unused tokens, and do not put access credentials in public source code.

Choose the tool that matches your goal:

Goal	Recommended path
Firmware for your own sensor, relay, or controller	supla-device
Application or system integration	REST API and OAuth
Event-driven integration or automation	MQTT
Your own complete SUPLA instance	supla-docker
Development of the web panel and cloud logic	supla-cloud

Ready-made examples can be used for learning and hobby projects. A commercial project additionally requires planning updates, diagnostics, secure data storage, the production process, legal compliance, and long-term device maintenance.

They should not. The main account should belong to the owner of each installation.

Using one installer account for multiple clients means that devices, configurations, history, and permissions belonging to different owners are managed within the same account. This makes it difficult to separate access, hand over an installation, delete data, and determine responsibility for the system. It also increases the risk that one client may gain access to devices or data belonging to another person.

SUPLA currently does not provide separate service access for installers. During configuration, an installer may therefore need the client's login and password. After the work is complete, the client should set a new password known only to them.

The client should receive at least:

• access to their own account and confirmation of the email address used as the login and for access recovery;
• a list of installed devices and their models;
• a basic description of locations, channels, scenes, schedules, and integrations;
• manufacturers' instructions and warranty information;
• information about who is responsible for installation, devices, firmware, and the cloud;
• instructions for entering configuration mode and what to do after changing the router;
• information about created access identifiers, API tokens, and integrations.

Since SUPLA currently has no separate service access, the client should set a new account password known only to them after accepting the installation. The installer should not keep the owner's new password.

No. An open-source license defines the rules for using source code. It does not automatically grant the right to use SUPLA's official infrastructure in commercial devices, the official app, product catalog, support, partner materials, or the SUPLA name and marks.

A manufacturer that wants to offer devices working with official services and the SUPLA brand should make the appropriate arrangements with us. The cooperation may cover software, testing, infrastructure, the app, branding, catalog publication, updates, and support.

The process should begin before the hardware design is finalized. Typical cooperation includes:

1. defining the product features and target users;
2. agreeing on the hardware architecture and communication method;
3. choosing the model for using the infrastructure and app;
4. preparing the firmware and update mechanism;
5. functional, integration, and security testing;
6. preparing the device for legal requirements and conformity assessment;
7. agreeing on brand use, catalog publication, support, and product maintenance.

Early contact reduces the risk that finished hardware will require costly changes before integration.

See information for manufacturers.

The manufacturer placing a device on the market is responsible for the product's legal compliance, documentation, warranty, and obligations related to security and the product life cycle.

Responsibility for preparing the firmware, updates, and maintaining the integration depends on the agreed cooperation model. It should be clearly established before sales begin.

Using a SUPLA library or source code alone is not confirmation that a product complies with technical or legal requirements.

Yes, provided that the device is fully compatible with the SUPLA infrastructure, has passed the agreed verification process, has a clearly identified manufacturer or other responsible entity, includes complete documentation, and has appropriate maintenance and support arrangements.

The manufacturer is also responsible for complying with the legal requirements applicable to the product and for the required CE marking.

Using open-source code or unofficial firmware alone does not automatically qualify a device for inclusion in the catalog.

Yes, within the permissions of the license for the specific repository. Source code for individual components is available in the SUPLA GitHub organization.

SUPLA does not prevent users from using their own DIY devices. Building and adding your own device to your own account does not require our permission. We encourage experimentation, learning, and creative development of home automation — hobby projects and the DIY community are an important part of the ecosystem.

Commercializing a solution is different. If a device or software is sold or offered to customers as a product or service, its creator becomes the manufacturer or provider and should review the “Device manufacturer questions” section, especially the answer about using the official cloud, app, and SUPLA brand.

Before using the code, also check the license of the relevant project and the obligations it imposes.

GUI Generic (GG) and ZigBee2Supla are projects created and developed by community members. They are not official SUPLA products. We are not responsible for their operation, compatibility, updates, or technical support.

Questions, problems, and suggestions relating to these projects should be directed to their authors and posted in the relevant sections of the SUPLA forum. Before using a project, review its documentation and check which devices and features it supports.

We encourage experimentation and creative use of SUPLA. Community projects, custom-built devices, and modifications are useful ways to learn electronics, programming, and automation.

It may not be. Security depends on the hardware design, framework, storage of passwords and keys, firmware updates, protection of configuration mode, and resistance to physical access.

A hobby project may be suitable for learning or non-critical applications, but without additional analysis it should not be treated as a ready-to-sell product or as part of an installation responsible for the safety of people or property.

Ordinary bugs can be reported in the relevant GitHub repository after checking that a similar report does not already exist.

Do not publish security vulnerabilities immediately as public issues. Use the private procedure described in the SECURITY.md file of the relevant repository or the device manufacturer's security channel.

A report should include a description of the problem, the component version, reproduction steps, possible impact, and — if safe — a proposed solution.