Skip to main content

Becker CentralControl smart home integration, free and open source

Becker CentralControl integration for Gladys Assistant

Becker shutters, awnings and weather sensors via the CentralControl, locally. Unofficial.

View on GitHubAll integrations

Control your Becker roller shutters, venetian blinds, screens, awnings and sun sails (Centronic, CentronicPLUS and B-Tronic radio) through your CentralControl CC31, CC41 or CC51, and read its sun, wind, rain and temperature sensors, from Gladys. Everything stays on your local network: the integration talks to the JSON-RPC API of the box (http://<box>/cgi-bin/cc51rpc.cgi), never to the Becker cloud nor its relay.

This integration has never been tested with a real box yet: it was built from Becker's own Home Assistant integration (becker_centralcontrol_has, MIT) and tested against a simulated box. Unofficial, not affiliated with Becker-Antriebe GmbH.

Configuration​

  1. Give your CentralControl a fixed address in your router (DHCP reservation).
  2. In the integration's Configuration tab, enter that address (like 192.168.1.70; add :port if the box answers on another port than 80). Names in .local do not resolve in the container: use the IP address.
  3. Optionally change the read interval (60 s by default, 30 s to 1 h) and the language of the feature names.
  4. Save, then Test the connection: it lists the covers the box answers with.
  5. Add your covers and sensors from the Discovery tab.

What you get​

  • Each cover (shutter, venetian, screen, awning, sun sail, blinds, fold-out shutter) becomes a shutter with an Open / close feature (open, close, stop). When the motor sends its position back (B-Tronic, CentronicPLUS: "feedback" in the box), a Position feature (0 % closed, 100 % open) is read at every interval and can be set. Centronic motors give no state back: only the commands, never a position.
  • An awning is reversed, as in Becker's integration: "close" retracts it, and its position is the one the box gives.
  • Each sensor (sun, wind, rain, twilight, temperature) becomes a read-only sensor. Sun and twilight are levels 0 to 15, wind a level 0 to 11 (the sensor's own scale, not km/h), rain 0 (dry) or 1 (rain), temperature in °C. A value outside these ranges is not published.
  • Doors, garage doors, roof and tilt windows, lights, switches, heating and scenes of the box are not offered in this version.

The stop​

The stop is never blocked: not by a read in progress (it cuts it), not by a pause asked by the box, not by another command waiting, not by the list of the box not yet read, not by a configuration that cannot be read (it goes to the last address known), not by /data being slow or unreadable. It leaves at once and waits up to 3.3 s for the answer (a slow answer is an answer); when the connection itself fails, it is written again every 250 ms within those 3.3 s. Any answer of the box counts (an acceptance, a refusal, an error page); a 429 or 5xx, a timeout or a cut connection does not.

The stop is kept (in memory, and in /data without waiting for it) until a read of the cover, started after the box answered, shows it no longer moves:

  • a stop the box has not answered is sent again after 5 s, 10 s, 20 s, 30 s, then every minute and at each successful read, without end and without age limit: only an answered send counts as a try;
  • a stop the box answered without accepting it (a refusal, an error page) is acked as failed, and the read back decides as for an accepted one;
  • the read back waits for the end of a pause the box asked (429, 5xx); when it gets no answer it is tried again after 5 s, 10 s, 20 s... up to every minute; when the box refuses to give that state (a group removed), the stop ends;
  • answered but the cover still moves the same way: sent again, 3 answered tries at most, then shown "still moving" on the badge;
  • the cover moves the other way: a move started elsewhere (app, remote) is left alone;
  • a motor without feedback, or a box that does not say whether it moves: one answered stop is all there is;
  • a newer command of that cover (open, close, position) accepted by the box replaces the stop; a newer command without answer does not (the stop goes);
  • after a restart, the stops kept in /data leave at once, before Gladys is reached.

A stop is not sent only while no address of the box is known at all (never configured, nothing in /data): it is kept and leaves as soon as an address is saved. Clicking stop also drops the commands of that cover not yet sent: nothing clicked before a stop leaves after it.

The close​

Close follows the same path (ahead of everything, cuts the reads, not held by a pause, by the list not yet read, by a new address not confirmed yet, 3.3 s budget), but it is never sent again after a restart. Its direction comes from the type the box lists now, else the type the device was created with, else a shutter (down). It is refused only when the box lists that id as something else than a cover (a door, a light).

Open and position​

They are refused, with the reason on the device's badge, when: the configuration is not valid; the box asked to slow down (429, 5xx; the pause is kept across a restart, 1 min to 6 h); the cover has not been listed by the box since the start (or since it stopped answering); the box lists that id with another type; the address of the box changed and was not confirmed yet; the motor gives no position (position only); the value is not a whole number from 0 to 100; 32 commands already wait; the command cannot leave within 2.5 s (its answer is awaited until 3.5 s); or a stop or close of that cover came after it.

A new address of the box: another box may hold covers with the same ids and types. After the address changes, only stop and close go until you press Test the connection and the box answers (kept across a restart).

Several covers move at once (up to 8; a scene of five covers sets all five). If a command gets no answer while others are in flight, the box may serve one request at a time: the covers are then commanded one after the other until the integration restarts; in that mode a command may leave until 3.8 s and is answered until 4.7 s, so that a scene of five covers at 0.9 s each still sets all five (the first scene, which finds out, may see the last two unanswered). On such a box a stop may also wait behind a command the box is serving. A command is said applied only when a read after it shows the asked position (5 s and 20 s after); otherwise the badge says "accepted, waiting for the read back", "not applied yet", "sent, without confirmation" (no answer) or "nothing sent".

Reads​

The positions and sensors are read at the interval you set, one request at a time; the lists of the box every 10 minutes. A cover missing from one list (the box may list part of its items) is kept until the next list, read at the next read; missing twice, it is shown "no longer listed". When every cover read fails, the integration is not shown connected and each cover says "Not read". A read that left before a command of a cover is never applied after it, and reads apply in the order they left. A cover or the sensor list that fails never stops the others. A restart (same box) never reads the states sooner than the interval; the lists (two requests) are read at once, so open and position work right after it.

Troubleshooting​

  • "not yet read back from the box": the box was not listed yet in this session (unreachable at start); press Test the connection: once it answers, the covers are known.
  • "another type of cover": the id of that device now holds another cover in the box (reconfigured). Delete the device and add it again from Discovery.
  • "/data not read yet": the file /data/becker-state.json could not be read (or took more than 2 s); it is left as it is, read again every 30 s, and the stops it keeps are sent as soon as it is read. Nothing is written to it meanwhile, so the stops are not kept across a restart until then.
  • The logs never hold an address you typed by mistake.

Configuration settings​

These are the settings Becker CentralControl asks for in its configuration screen in Gladys.

SettingTypeRequiredDescription
Your Becker covers in GladyssectionNoEach shutter, venetian blind, screen, awning or sun sail set up in your CentralControl CC31, CC41 or CC51 (Centronic, CentronicPLUS, B-Tronic) becomes a shutter in the Discovery tab (open, close, stop, and the position when the motor gives it back), and each sun, wind, rain or temperature sensor a read-only sensor. Everything stays on your local network (the JSON-RPC API of the box), no Becker cloud. The stop is never blocked. Never tested with a real box yet. Unofficial, not affiliated with Becker-Antriebe.
Address of the CentralControlstringYesThe local IP address of your CentralControl, like 192.168.1.70 (port 80 unless you add another one, like 192.168.1.70:8080). Give it a fixed address in your router (DHCP reservation).
Read interval (s)numberNoHow often the positions and the sensors are read from the box (30 to 3600 s).
Language of the feature namesselectNoUsed for the names of the features of the devices added from now on.

How to install Becker CentralControl in Gladys​

  1. In Gladys, open Integrations: Becker CentralControl appears in the catalog, next to the native integrations, with a community badge.
  2. Click Install. Gladys pulls the Docker image (ghcr.io/lm1lc3n7/gladys-becker:0.1.1), starts it in a sandbox isolated from the core, and generates the integration's interface (devices, discovery and configuration).
  3. Open the Configuration screen of the integration, fill in the settings, and save.
  4. You can also install it directly from its repository URL: https://github.com/LM1LC3N7/gladys-becker.

Becker CentralControl requires Gladys >=5.1.0. The catalog inside Gladys refreshes every hour, so a new version becomes available at most one hour after its release.

Not running Gladys yet? It is free and open source: follow the installation guide to get started.

About external integrations​

Becker CentralControl is an external integration: a community integration packaged as a Docker container and published on GitHub, that Gladys installs in one click and runs in a sandbox isolated from its core. It is published and maintained by LM1LC3N7, not by the Gladys core team.

Subscribe to the Gladys Assistant newsletter

A few emails per month about new releases and project news. Sent by Pierre-Gilles Leymarie, founder of the project. Unsubscribe anytime 🙂
Last updated on