Zendure smart home integration, free and open source

Connect your Zendure solar batteries (SolarFlow) to Gladys Assistant through the Zendure cloud.
Connect your Zendure SolarFlow / Hyper solar batteries to Gladys Assistant. Gathers read-only telemetry (battery level, charge/discharge power, home output and solar production) from the Zendure cloud, and — optionally — directly from each device's local MQTT broker for LAN-speed, offline-resilient updates with automatic cloud fallback.
Each battery is read and driven through its local API (zenSDK) when it answers on your network — the way Home Assistant does it — with the Zendure cloud as an automatic fallback.
Prerequisites
- A Zendure account, with your batteries already set up and online in the Zendure app.
- Gladys Assistant 5.1 or later.
Supported models
SolarFlow 800, SolarFlow 800 Pro, SolarFlow 1600, SolarFlow 2400, SolarFlow 2400 AC, SolarFlow 2400 Pro, and Hyper 2000 (experimental — telemetry mapping to be confirmed by a community tester).
Untested hardware: SolarFlow 800 Plus, SolarFlow 800 Pro 2 and SolarFlow 4000 AC+ are supported from the ratings of the official Home Assistant integration (Zendure-HA), without a real device seen yet. If you own one, please report how it behaves (a Diagnostic of the batteries report is ideal) on the issues.
The model name the Zendure cloud reports is matched ignoring case and spaces
(SolarFlow 800 Pro, SolarFlow800Pro), like Zendure-HA does.
Features
Each battery is created with ten read-only features (plus the model-dependent ones below), in the Gladys energy categories (energy charts, history, dashboards):
| Feature | Gladys category | Unit |
|---|---|---|
| Battery level | Battery storage | % |
| Battery charge power | Battery storage | W |
| Battery discharge power | Battery storage | W |
| Home output power | Home output sensor | W |
| Solar input power | Energy production sensor | W |
| Battery charged energy | Battery storage | kWh |
| Battery discharged energy | Battery storage | kWh |
| Home output energy | Home output sensor | kWh |
| Solar energy | Energy production sensor | kWh |
| Battery energy remaining | Battery storage | kWh |
Zendure reports powers only: the four energy features (kWh) are computed by the integration, which adds up each power over time. They are cumulative indexes, saved in the integration's data volume so a restart does not reset them; a silence of more than 5 minutes (battery offline, broker down) is left out instead of being guessed. Gladys turns the solar energy index into its energy production charts. The energy remaining is the state of charge times the capacity of the packs the battery reports (AB1000, AB2000, AB3000, built-in packs); it stays empty until the battery sends its pack list.
Since version 1.3.0 the battery level is a battery storage level, not the battery of a device to replace: Gladys no longer counts your home battery in its low-battery alerts. A battery created with an older version keeps its previous categories until you apply the new definition: in the Discover tab, click Update on the battery (marked Already added). The features are updated in place, so their history, scenes and dashboards are kept. The same Update adds the energy features to a battery created before version 1.5.0.
Off-grid output, grid charging and temperatures
Depending on the model, a battery also gets these features:
| Feature | Gladys category | Unit | Models |
|---|---|---|---|
| Off-grid output power | Home output sensor | W | 800 Pro, 800 Pro 2, 1600 AC+, 2400 AC, 2400 AC+, 2400 Pro, 4000 AC+ |
| Off-grid output energy | Home output sensor | kWh | same |
| Grid charging power | Grid sensor | W | every model (AC charging) |
| Grid charging energy | Grid sensor | kWh | every model |
| Device temperature | Device temperature sensor | °C | every model, when reported |
| Hottest pack temperature | Device temperature sensor | °C | every model, when reported |
- Off-grid output: the power on the battery's off-grid (backup) socket
(
gridOffPower). A negative value means the socket feeds power in (a solar panel plugged there, as Zendure-HA notes): it shows 0 and is not counted. - Grid charging: the power the battery draws from the grid to charge
(
gridInputPower), on every model able to charge from AC. - The two energy features are computed like the others (power over time, saved in the integration's data volume, silences over 5 minutes left out).
- Temperatures: the device temperature (
hyperTmp) and the highest temperature of the packs (maxTemp), reported by Zendure in tenths of a kelvin and converted to °C. A battery that does not report them leaves them empty; an impossible value (below −40 °C or above 120 °C) is ignored.
Energy hierarchy — avoid double counting. The grid charging power is a grid sensor: if your home already has a main meter (Linky, a P1 or Shelly EM meter...) in Gladys, the battery's grid charging is already inside what that meter measures. In the energy settings of Gladys, place the battery under the main meter (as a child of it), not beside it, or the energy it draws would be counted twice.
A battery created with an earlier version gets these features with the same Update in the Discover tab: the existing features, their history, scenes and dashboards are kept.
Getting your Zendure cloud key
The integration authenticates against the Zendure cloud with an authorization key (a base64 token) that you generate once from the Zendure mobile app:
- Open the Zendure mobile app and sign in with your account.
- Go to the developer / Home Assistant integration section of the app and generate (or copy) your authorization key (also called the "HA key").
- Copy that key.
The key is a secret tied to your Zendure account: keep it private. Gladys stores it encrypted and never logs it.
Configuration
- Open the Configuration tab of the integration in Gladys.
- Paste your key into Zendure cloud authorization key.
- Set the Refresh interval (seconds) — how often the telemetry is refreshed when no real-time update is flowing. The default (30 s) is fine.
- (Optional) Enable local MQTT (zenSDK) — see below.
- (Optional) Choose the language of the Feature names (English by default): it applies to the batteries you create from now on.
- Click Save configuration. Your batteries appear in the Discover tab, ready to be added.
Local API (zenSDK, on by default)
The SolarFlow batteries (800, 800 Plus, 800 Pro, 800 Pro 2, 1600 AC+, 2400 AC, 2400 AC+, 2400 Pro, 4000 AC+ — every supported model but the Hyper 2000) serve a small HTTP API on your home network, called zenSDK. It is what the official Home Assistant integration uses for these models: neither MQTT nor the cloud. With Use the local API of the batteries on (the default), the integration reads every battery through it every 5 seconds, and sends the scene and widget commands through it too.
- Prerequisites: the battery and the Gladys host on the same network (the container must be able to reach the battery's IP address: no isolated guest Wi-Fi or VLAN in between), and a recent firmware: update the battery from the Zendure app if its local API does not answer. Model-specific steps, when there are any, are on the Zendure-HA wiki (e.g. its SolarFlow 800 page).
- Address: the integration takes the battery's IP address from the Zendure
cloud. When the cloud gives none, it tries the battery's mDNS name
zendure-<model>-<serial number>.local, which rarely resolves inside a Docker container: fill in Local API addresses withserial number=IP addresspairs, separated by commas (e.g.HOA1NAH4N123456=192.168.1.42). Giving your batteries a fixed IP address in your router helps. - Automatic fallback: a battery that misses three requests in a row goes to its local MQTT broker if you enabled it, at once; it only goes to the Zendure cloud after 90 seconds without an answer (a Wi-Fi blip does not take the cloud connection), and comes back as soon as its local API answers again. At startup, a battery gets the same 90 seconds to give its first answer. A battery that never answered simply stays on the cloud, without any warning badge.
- The cloud stays idle: when every battery answers locally, the integration does not connect to the Zendure cloud broker at all, so Home Assistant (or another app) using the same Zendure account keeps the account's single cloud connection.
Local MQTT (recommended if you use it)
When you enable local MQTT in the Zendure app (developer mode), each device publishes its telemetry to a local broker on your network. Turning on Enable local MQTT in Gladys makes the integration read from that broker:
- Faster: local values update every 1–3 s instead of ~30 s over the cloud.
- Resilient: telemetry keeps flowing during a Zendure cloud or internet outage.
- Automatic fallback: if a device goes silent on the local broker, the integration falls back to the cloud on its own, and returns to local as soon as local messages resume — no action needed.
Transport badges
Each device shows a badge telling you how it is currently reached:
- Local (green) — served by its local MQTT broker (nominal when local MQTT is enabled).
- Cloud (blue) — served by the Zendure cloud (nominal when local MQTT is off).
- Cloud + orange dot (degraded) — the device should be local but is temporarily on the cloud fallback (its local broker went silent). Hover the badge for the reason. This clears by itself when the device resumes locally.
- Unreachable (red) — the Zendure cloud reports the device offline, or it is silent on every source.
With the local API, Local means its local API or its local broker serves the device. The degraded reason tells which local source went silent.
Control from scenes
Gladys has no battery setpoint feature yet, so the batteries are controlled from scenes (and from the dashboard widget): in a scene, add an action of the Integrations category.
| Action | What it does |
|---|---|
| Set the output limit | Maximum power the battery delivers to the home (W) |
| Set the charge limit | Maximum power the battery draws from the grid, AC charge (W) |
| Set the AC mode | Charge from the grid, or discharge to the home |
| Set the charge levels | Charge target (70-100 %) and discharge floor (0-50 %) |
The integration protects the battery:
- a limit is clamped to the battery's rating (e.g. 800 W out on a SolarFlow 800 Pro);
- power limits are sent in "smart mode", kept in memory instead of being written to the battery's flash (frequent changes would wear it out);
- one setting cannot change more than once every 3 s (power limits) or 30 s (AC mode, charge levels): a scene that tries sooner fails with the delay to wait;
- a value the battery already runs with is not sent again (the action output Command sent is then false);
- the charge levels are refused until the battery has reported its current ones (its scale differs between firmwares).
The command goes through the broker that currently serves the battery (local or cloud); the new value shows up with the battery's next report.
The trigger Battery reachability changed starts a scene when a battery stops reporting on every source, or reports again (local API or local MQTT). Its variables give the battery name, the new state and the telemetry source.
Dashboard widgets
Four widgets are available in the dashboard editor (Gladys 5.1 or later):
- Zendure battery: one battery, chosen in the widget settings. Its charge level and its four powers follow the battery live; below them, its source (local, cloud, fallback, unreachable), the energy stored, the output and charge limits, the AC mode and the charge levels it reports. The Power limits and Mode & levels buttons open a form pre-filled with the current values: change what you need and confirm. The same protections as the scene actions apply.
- Battery group: several batteries summed up under a name of your choice: average charge level (weighted by the pack capacities when they are all known), total powers, energy stored, and one line per battery colored by its source. Leave the battery list empty for every battery of the account.
- Zendure site: the whole installation on one card. Choose the
Electrical layout: Single-phase sums the batteries selected (none: all
of them); Three-phase takes the batteries of the Phase L1 batteries,
L2 and L3 lists. The card shows the site totals (state of charge
weighted by the pack capacities, charging, discharging, solar, home output,
energy stored), then in three-phase one line per phase (
⌂home output,↑charge,↓discharge,☀solar, in W) and the Phase balance: the gap between the highest and the lowest home output, in orange beyond the Phase imbalance alert (500 W by default). Below: stored energy over the known capacity, time left at the current power, how many batteries each source serves (local, cloud, unreachable), and alert lines for the unreachable batteries, the cloud fallbacks, and a battery put in two phases, in none, or deleted. An unreachable battery keeps its level and stored energy, but its last powers are left out of the sums. - Energy today: the energy of the day since local midnight, same layout
choice and phase lists: charged, discharged, solar and home output (kWh),
one line per phase in three-phase with the gap between the phases, and a
chart of the home output per 30 minutes (one curve per phase). The day
starts at the midnight of the widget's Timezone (an IANA name,
Europe/Parisby default: Gladys does not give its timezone to an integration). The figures come from the energy counters of the integration (saved under/datawith a snapshot every 30 minutes, kept 26 hours): they count from the first report of the day, which the Counted since line shows (for example after a first install in the morning). With an electricity tariff in the configuration, it also shows the savings estimate (see Savings (estimate) below).
Three-phase example: 17 batteries on L1, L2 and L3. Add a Zendure
site widget, set Electrical layout to Three-phase, and tick in
Phase L1 batteries the six batteries wired to L1 (say two 2400 AC, a 2400
Pro, two 800 Pro and an 800 without battery), in L2 the six of L2 and in
L3 the five of L3. The card shows the site totals, a line such as
L1 (6) · 60 % — ⌂ 1890 · ↑ 500 · ↓ 1000 · ☀ 1400 W per phase, and
Phase balance — Δ 1490 W · L1 highest in orange when it exceeds the
threshold. Add an Energy today widget with the same three lists for the
kWh of the day. A single-phase installation keeps the default layout and
leaves the lists empty. The Battery group widget still works for any
other grouping.
Each widget only shows what the battery has: a SolarFlow 800 running without a battery pack keeps its solar, home output and output limit (no level, charge figures nor Mode & levels button), and an AC-coupled model (1600 AC+, 2400 AC, 2400 AC+) has no solar tile. While a battery charges or discharges, the widget shows the time left until its charge target or its discharge floor, as the battery reports it (or computed from its capacity when it gives none). A group leaves the batteries without a pack out of its average level and stored energy, and a group of such devices only shows their powers.
Savings (estimate)
With your electricity tariff, the integration estimates what your batteries save, every 30 minutes, per battery, and the Energy today widget sums it for its batteries (the site, or each phase). It is an estimate without a grid meter, marked as such in the widget: read the limits below.
Setting the tariff
In the Configuration tab, section Savings (estimate, no grid meter):
- Electricity tariff: None (the default: no estimate), Base (one price) or Peak / off-peak.
- Base price, or Peak price and Off-peak price: the price of one
kWh bought from the grid, taxes included (for example
0.1952). A missing price turns the estimate off. - Off-peak hours:
HH:MM-HH:MMranges separated by commas, for example22:00-06:00or01:30-07:30,12:30-14:30. A range may cross midnight;24:00is accepted as an end. Invalid hours turn the estimate off: the logs and the diagnostic say why (once), and the widget shows Tariff invalid. - I sell my solar surplus and Resale price: on, the solar energy stored in the batteries is valued at the resale price (what it would have earned on the grid); off, stored solar energy is free.
- Tariff timezone (IANA name,
Europe/Parisby default): the off-peak hours, and the days, months and years of the savings, follow it, clock changes included. It is a setting of the integration and not of the widget because the slots are valued in the background, as they close, when no widget is open; the widget's own Timezone still sets the midnight of its energy figures.
In the Energy today widget, Show the savings (estimate) is on by default: it only shows something once a tariff is set.
How it is computed
For each battery and each 30-minute slot, from its energy counters:
- Price of the slot: the base price, or the peak / off-peak price at the local time of the slot (a slot straddling the edge of a range is priced pro rata).
- Cost of the stored energy: a weighted average per battery. The energy charged from the grid (the Grid charging energy counter) costs the price of the slot; the rest of the charge, from the solar panels, costs the resale price when you sell your surplus, 0 otherwise. The stored energy is re-read from the state of charge when the packs are known.
- Home output: without a grid meter the integration cannot know what was exported, so the energy sent to the home is assumed consumed by the house. Its share coming from the battery saves price of the slot − cost of the stored energy (a battery charged at peak and discharged off-peak saves less than nothing); its share coming straight from the solar panels saves the price of the slot; the rest (grid passing through an AC battery) saves nothing.
- Savings = battery time-shift + direct solar (+ resale revenue, with the grid meter). The Grid charging (paid) line is information: that cost is already inside the cost of the stored energy.
The widget shows Saved today (estimate), the month and the year, today
per phase in three-phase, and today's breakdown (battery time-shift, direct
solar, grid charging paid, export). The totals of the current and previous
day, month and year are saved in /data/energy.json with the energy
counters (a file from an earlier version loads as is; the savings start at
the first 30-minute boundary after the update).
Limits
- No knowledge of the export: the home output sent back to the grid (house consumption below the battery output) is counted as saved at the price of the slot. The Exported, not valued line (or Resale when you sell) stays at 0 until the grid meter can be read.
- AC batteries (1600 AC+, 2400 AC, 2400 AC+, 4000 AC+): their AC charging is counted as grid charging at the price of the slot, even when it actually comes from the solar surplus of another inverter: only the site balance (the grid meter) could tell.
- Pack losses, conversion losses and missed reports make the figures approximate; the savings start when the tariff is set (nothing is computed backwards), and a tariff change applies to the slots that close afterwards.
- The currency is the one of your prices; the widget writes
€.
Coming soon
Two options will appear in the configuration once Gladys offers them to integrations (Gladys changes in progress: #3229 and #3230):
- Use the prices of Gladys energy monitoring, instead of typing them here.
- Grid meter (single-phase, or three-phase L1 / L2 / L3): to know what is really consumed or exported, value the resale and the losses, and tell the solar surplus from grid charging on the AC batteries.
One cloud consumer per Zendure account
Zendure allows only one cloud consumer per account at a time. If another app uses the same account's cloud connection (Home Assistant, a second Gladys instance…), the two fight over the connection and telemetry becomes intermittent. Prefer the local MQTT path for any second consumer — the local broker has no such limit. The integration warns once in its logs when it detects this take-over pattern.
With the local API on (the default), the integration only connects to the Zendure cloud broker while a battery needs it, and disconnects again 5 minutes after the last battery that needed it is back on a local source: if your batteries answer locally, Home Assistant and Gladys no longer fight over the cloud connection.
Updating the integration
Installed from the catalog (the usual case): Gladys checks the store regularly. When a new version is out, the integration shows an "Update available" badge (also counted next to Integrations in the menu), and its Supervision tab names the version offered, with a link to its release notes. Click Update: Gladys pulls the new image and applies the new manifest — new configuration fields appear on their own, there is nothing to re-paste. Your configuration and your devices are kept.
Gladys can take up to about an hour and a half to notice a new release (store index refresh). "Force update" checks right away: it reads the latest published version and pulls its image.
Installed in developer mode (manifest pasted by hand): "Force update" only re-pulls the image of the tag you installed, and the version shown and the configuration fields come from the pasted manifest — re-paste the updated manifest to pick up new fields.
Troubleshooting
- A battery is not discovered. Open the Logs tab: a line
Unsupported Zendure model skipped: productModel "..."gives the exact model string the Zendure cloud reports. Open an issue on gladys-zendure with it, so the model can be added. - One device shows no values (or is slower than the others) while the rest work. Check its transport badge. If it fell back to Cloud (degraded) while local MQTT is enabled, its firmware may have silently stopped publishing locally. In the Zendure app, toggle that device's MQTT control OFF, save, then ON again — it resumes publishing within a minute. The integration falls back to the cloud in the meantime and returns to local automatically.
Too Many Requestsin the logs. The integration paces its updates under the Gladys core rate limit and self-throttles when needed; occasional bursts are harmless. Persistent floods usually mean a second integration instance (e.g. a prod and a test container side by side) sharing the same core budget — run only one.- Everything is silent right after configuration. Make sure the cloud key is correct: an invalid or expired key shows a "Zendure cloud is unreachable or the cloud key is invalid" status on the Configuration screen.
- Full detail. Set
LOG_LEVEL=debugand read the integration logs in its Logs tab (ordocker logson the host). Every telemetry-source switch is logged on atelemetry:line. - A battery stays on the cloud although its local API should work. At
startup the logs list every battery that does not answer, with the address
tried and the reason, e.g.
local http: Garage (dCLTD95V) not answering at 192.168.1.42 (from the cloud): EHOSTUNREACH.ENOTFOUNDon a.localname means mDNS does not resolve in the container: set its address in Local API addresses.EHOSTUNREACH,ECONNREFUSEDorno answer within 2 smean the container cannot reach the battery (other network, VLAN, firewall) or its firmware has no local API yet. Every 5 minutes atelemetry(local http):line sums up which batteries answer.
Diagnostic
Two read-only buttons in the Configuration tab of the integration rebuild the whole picture on demand, so you do not have to dig through the logs. Neither writes to a battery nor changes its transport.
- Diagnostic of the batteries: a text report of the installation — the
integration version, the configuration (never the cloud key), the Zendure
cloud API, each broker (connected or not, reconnections over the last
5 minutes, cloud broker idle because every battery is local, take-over
warnings), the local API polling, then one block per battery: the source
serving it and why, the age of its last data on each source, its local API
address (from the options, the cloud or mDNS) and state, battery packs,
solar input, the settings it reports (limits, AC mode, charge levels),
remaining time and energy counters, then the firmware versions (device,
master, DSP, packs), the Wi-Fi signal (
rssi, with a hint below −75 dBm) and connection states, the raw status codes (heating, low temperature, SoC calibration and limit, bypass, HEMS, fault level) and per pack its level, hottest cell temperature, voltage, current and state of health. Pick a battery in the Battery list (the batteries created in Gladys) to report on it only; for a battery not created in Gladys, type its name or serial number in the field below. - Test the local API of a battery: reads
GET /properties/reportonce, right away, at the address the integration uses, and shows the answer time, where the address comes from and every property the battery returns — or the exact error with a hint (ENOTFOUNDon a.localname: fill Local API addresses;EHOSTUNREACH,ECONNREFUSEDor a timeout: network or firmware).
By default serial numbers are shortened (WOB1…0159) and local addresses
replaced by <local-ip>: paste the report as is into a
GitHub issue, between two
lines of three backticks. Show serial numbers and local addresses prints
them in full, for your own checks only: do not post that version publicly.
No report ever contains the cloud key or a password. Both reports are also
written, masked, to the integration logs.
Configuration settings
These are the settings Zendure asks for in its configuration screen in Gladys.
| Setting | Type | Required | Description |
|---|---|---|---|
| Getting started | section | No | Paste your Zendure cloud authorization key below (generated from the Zendure mobile app). Your SolarFlow / Hyper batteries then appear in the Discover tab. Each battery is then served by its local API when it answers on your network (like Home Assistant does), with automatic Zendure cloud fallback; local MQTT remains an option for older firmwares. The full step-by-step is in the Documentation link above. |
| Zendure cloud authorization key | secret | Yes | The authorization key generated from the Zendure mobile app (base64 token used to reach the Zendure cloud API). |
| Refresh interval (s) | number | No | How often device telemetry is polled, in seconds. |
| Use the local API of the batteries | boolean | No | Read and drive each battery through its zenSDK local HTTP API on your network (what Home Assistant uses), every few seconds. A battery that does not answer stays on the Zendure cloud, automatically. |
| Local API addresses (optional) | string | No | Only for a battery whose local API is not found (no address from the cloud, mDNS name not resolved): serial number=IP address pairs, separated by commas. |
| Enable local MQTT (zenSDK) | boolean | No | Also read telemetry from the device's local MQTT broker when available (older firmwares, Hyper 2000), before the Zendure cloud. |
| Feature names | select | No | Language of the feature names given to newly discovered batteries. A battery already created keeps its names: rename its features in Gladys if needed. |
| Savings (estimate, no grid meter) | section | No | Optional. With your electricity tariff, the integration estimates every 30 minutes what your batteries save: the energy sent to the home is assumed consumed by the house (without a grid meter nothing tells what is exported), valued at the price of the moment, minus the cost of the stored energy (grid charging at its price, solar charging at the resale price or free). The "Energy today" widget shows it for today, this month and this year. Details and limits in the Documentation link above. |
| Electricity tariff | select | No | None: no savings estimate. Base: one price. Peak / off-peak: two prices and the off-peak hours. |
| Base price (per kWh) | number | No | Base tariff: the price of one kWh bought from the grid, taxes included (€/kWh). |
| Peak price (per kWh) | number | No | Peak / off-peak tariff: the price of one kWh outside the off-peak hours, taxes included (€/kWh). |
| Off-peak price (per kWh) | number | No | Peak / off-peak tariff: the price of one kWh during the off-peak hours, taxes included (€/kWh). |
| Off-peak hours | string | No | HH:MM-HH:MM ranges separated by commas, in the tariff timezone; a range may cross midnight. Invalid hours: the estimate is off (see the logs). |
| I sell my solar surplus | boolean | No | On: the solar energy stored in the batteries is valued at the resale price (what it would have earned), and exported energy counts as revenue once a grid meter can be read. Off: stored solar energy is free. |
| Resale price (per kWh) | number | No | The price paid for one kWh of solar surplus sent to the grid (€/kWh). Used only when the option above is on. |
| Tariff timezone | string | No | IANA name, e.g. Europe/Paris (the default): the off-peak hours and the days, months and years of the savings follow it, clock changes included. |
| Coming soon | section | No | Two options will appear here once Gladys offers them to integrations (pending Gladys changes, linked below): "Use the prices of Gladys energy monitoring", instead of the prices above; and "Grid meter (single-phase, or three-phase L1 / L2 / L3)", to know what is really consumed or exported, value the resale and the losses, and tell PV surplus from grid charging on AC batteries. Until then the savings are an estimate. |
How to install Zendure in Gladys
- In Gladys, open Integrations: Zendure appears in the catalog, next to the native integrations, with a community badge.
- Click Install. Gladys pulls the Docker image (
ghcr.io/terdious/gladys-zendure:1.8.0), starts it in a sandbox isolated from the core, and generates the integration's interface (devices, discovery and configuration). - Open the Configuration screen of the integration, fill in the settings, and save.
- You can also install it directly from its repository URL: https://github.com/Terdious/gladys-zendure.
Zendure 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
Zendure 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 Terdious, not by the Gladys core team.
- Browse all integrations, native and community
- Build and publish your own external integration
- Source code on GitHub — source of this documentation