hass-WEM-Portal

Brings a Weishaupt heating system into Home Assistant through the WEM Portal — readings, settings you can change, fault reporting and energy statistics.

There is no local API. Everything goes through Weishaupt's cloud, using the two interfaces the portal offers itself: the mobile app's API and the web frontend's expert view.

This is a fork of erikkastelec/hass-WEM-Portal.

Disclaimer: This is a personal hobby/test project, developed for my own setup and shared as-is. It is not an official integration, comes with no warranty, and no support or maintenance is guaranteed. Use at your own risk — especially the expert write feature, which changes settings on your real heating system. Always verify changes in the WEM Portal itself.

Developed with AI assistance (Claude), with all testing, decisions, and validation done by me against my own installation.

What you get

Entities are created from whatever your installation actually reports, so the exact list depends on your heat pump, its modules and the mode you choose.

Supported devices

Anything registered in the WEM Portal: the integration reads what the portal shows for an installation rather than a list of known models, so heat pumps and heating systems that appear there are covered as far as the portal exposes them.

Tested end to end with a Weishaupt Biblock heat pump (WBB 12). Reports from other models are welcome - especially if something is missing or looks wrong.

What it is for

Seeing the heat pump next to everything else - temperatures, operating states and faults on the same dashboards and in the same history as the rest of the house.
Being told about a fault - the Has Errors and Error Messages sensors below are made for a notification automation (in api and both mode).
Energy Dashboard - consumption and heat output as energy totals.
Acting on the house - setpoints as number entities, so an automation can raise the hot-water temperature while there is solar surplus, or a holiday period can be set from a presence or calendar automation.

Controls, weekly programmes and energy statistics come from the mobile API, so they exist in api and both mode; in web mode the portal's own entities are sensors only. The expert numbers (see below) exist in every mode.

Entity type	What it is
Sensor	Every reading the portal offers: temperatures, pressures, speeds, operating hours, states.
Number	A setpoint you can change — room setpoint, hot-water temperature, and anything else the portal marks as writable with a numeric range.
Select	A parameter with a fixed list of choices, e.g. the operating mode or a hot-water push duration.
Switch	A genuine on/off parameter.
Date	Holiday start and end. The portal stores them only as a pair, so setting one sends both; `set_holiday` sets a whole period at once.

Diagnostic entities

Three per device, and they stay available when a device is offline or unreachable — they are what explains why. Like every entity built from the portal's readings, they do go unavailable once two update cycles in a row have failed. They come from the mobile API's device status, so they exist in api and both mode; the web page has no such read, and in web mode there are none:

Connection Status — what the portal says about reaching the device.
Has Errors — yes / no, shown as Yes / No in Home Assistant's language. When a status read fails, this reports unknown rather than no: "no fault" because nothing is known is the one direction a fault sensor must never fail in.
Error Messages — every active fault. The full list is in the Errors attribute; the state itself is capped by Home Assistant at 255 characters and says how many it had to drop. Without a fault it is none, shown as No fault.

These three are named in Home Assistant's own language, not by the language option: they are the same on every installation, so Home Assistant's translations can name them. An automation compares against the states as listed (online, offline, busy, wrong_secret, unknown; yes, no; none), whatever the language.

Weekly programmes

Heating and hot-water programmes become a sensor whose state is the readable week, collapsing consecutive days that are alike:

MO 00:00-06:00 Komfort, 06:00-10:10 Normal, 10:10-13:30 Absenk,
13:30-24:00 Komfort; DI-SO 00:00-24:00 Komfort

The level names are the portal's own words, not a table in this repository, so they follow your portal's language. Attributes carry the full detail: Schedule (per day), CircuitTimesDay and PossibleValues (as the device reports them) and Raw_JSON.

These are read-only. Change a programme in the WEM Portal app; the integration re-reads it about once an hour.

Energy statistics

Each statistics group - consumption, heat output - is an energy sensor holding the current day's total (state class total, starting again at midnight), ready for the Energy Dashboard. They are fetched once an hour — that is the portal's own granularity, and asking more often only spends requests.

Installation

Prerequisites

Home Assistant 2026.9.0 or newer.
A WEM Portal account with your heating system registered in it - if the WEM app on your phone shows it, the integration can see it.
For expert write access only: the installation's Fachmann access in the portal.

HACS (custom repository)

In HACS, add https://github.com/Varitras/hass-WEM-Portal as a custom repository (category: Integration), or use the button above.
Install it and restart Home Assistant.
Continue with Setup.

Manual install

Copy everything from custom_components/wemportal/ in this repository into <config directory>/custom_components/wemportal/, then restart Home Assistant.

custom_components
└── wemportal
    ├── __init__.py
    ├── ...
    └── wemportalapi.py

Setup

Settings > Devices & Services > Add integration > search for Weishaupt WEM Portal.

Field	Meaning
`username`	The email address you log into the WEM Portal with.
`password`	Your portal password.
`language`	Language for entity names: `en` or `de`. Defaults to `en`.
`mode`	Where readings come from — see below. Defaults to `api`.

The credentials are checked before anything is saved: with the mobile API's login in api and both mode, with the web frontend's in web mode. The two are separate logins, and one working says nothing about the other. The same check runs again if you change the mode later. In both mode a web login that fails shows up afterwards, as the web access is not working repair.

Everything else is under CONFIGURE once the integration is added.

Changing the login later

Settings > Devices & Services, WEM Portal, the three dots on the entry, Reconfigure. It takes a new password, and also a different username - for when the e-mail address of your portal account changed - so you do not have to delete and re-add the integration. The new login is checked before anything is saved, and a login another WEM Portal entry already uses is refused.

A different username is treated as a different installation, even when it is only the e-mail address that changed: what the integration remembered about the old one is dropped, the expert parameter slots included, since their IDs belong to the old heating system. Enter them again in the options if you use them. If the new login really is a different installation, its devices appear as new ones; the old ones can then be deleted from their device pages.

This is not the same as the re-authentication Home Assistant asks for when a login stops working: that one only accepts a new password for the same account.

Choosing a mode

Mode	Source	Use it when
`api`	Mobile API only	Default, and the right answer for most people. Covers every device on the account and everything the app shows.
`web`	Expert web page only	You want readings the app does not show and do not need the API ones.
`both`	Both	You want the union. Costs both request budgets.

One device per account on the web path. The scraper reads a single expert page and the portal decides which device that page shows, so with more than one device on the account its sensors are filed under the first device the mobile API reported — which need not be the one the page showed. The integration says so in the log once, and api mode covers every device correctly. Resolving it means driving the portal's device selector, which needs a multi-device account to develop against; upstream issue #43 has been open for that reason since 2022.

Polling and the portal's rate limit

Weishaupt blocks an IP address that sends too many requests in a 12-hour window. The block is per IP, not per account, and waiting is the only cure — every retry during it makes it last longer.

The integration is built around that:

A 403 seen by the normal polling pauses all outbound requests for 15 minutes. One on an expert request pauses only that feature - it is not proof of an IP-wide block (see Expert write access (web)).
A login turned away once is not taken for that block: the next login usually goes through. For the API login that holds when the refusal is a bare page with no answer from the portal itself, and it costs that one cycle; a refused web login costs only the scrape, which tries again no sooner than five minutes later. A second refusal of the same login in a row pauses everything as above.
The setup and re-authentication dialogs refuse to send anything while that pause is active, and say so — deleting and re-adding the integration to "fix" a block is the one thing that reliably prolongs it.
Repeated failures back off progressively instead of retrying at full speed.
Parameter lists are discovered once and re-read daily, not every cycle.
Weekly programmes refresh hourly, statistics hourly. After a start both follow within a few minutes rather than holding up Home Assistant's start; until then a programme sensor shows only its programmed windows, without level names.

A single failed cycle does not take the entities with it. The portal answers a poll with an error now and then and the next one succeeds; at a 30-minute interval, going unavailable for that would cost half an hour of every graph. The second consecutive failure does show as unavailable. A device that stops answering while others still respond is handled separately: its parameter readings are shown as unknown after half an hour, or after two API intervals if those are longer, so nothing old is presented as current and a single missed cycle is still survivable at any interval. Its status sensors stay, since they say why.

What this means for your settings: the intervals below are floors, not recommendations. Halving an interval doubles the requests. If you run several Home Assistant instances, or the WEM app on your phone, from the same connection, they share the same budget.

Options reference

Settings > Devices & Services > WEM Portal > CONFIGURE, then Configure settings and expert slots.

Polling

Both intervals are entered in seconds, and held to one week at most.

Option	Default	Notes
`scan_interval`	30 min	Web scraping. Below 15 min is not recommended; under 60 s is clamped to 60 s.
`api_scan_interval`	5 min	Mobile API. Should not go below 3 min; under 60 s is clamped to 60 s.
`language`	`en`	`en` or `de`.
`mode`	`api`	Re-validated against the portal when changed.

Menu actions

Search the portal for new API parameters — marks the cached parameter lists for a re-read on the next update. Which parameters a module has is discovered once and cached for 24 hours, so activating an input or output in the portal is otherwise not visible until the next day. Makes no portal request of its own. Concerns the mobile API only; the web scraper re-reads the whole page every cycle anyway.
Discover expert parameters from the portal — see Expert write access.

Expert write access

All of these are described in their own section: Expert write access via web, ten name/ID slot pairs, Poll expert parameters periodically + interval, Notify on successful expert write, and two advanced navigation switches with the module index the first of them uses.

Services

`wemportal.set_holiday`

Sets a holiday period in one request. The portal refuses a write that carries only one of the two dates - it stores a holiday only as a pair.

Administrator only, like the expert service and for the same reason: it changes a real setting on a heating system, and a service call is not covered by the per-user entity permissions Home Assistant applies to the entities.

Entity ids below are placeholders - take yours from the device page.

action: wemportal.set_holiday
data:
  begin_entity: date.heating_circuit_1_holiday_start
  begin: "2026-12-24"
  end_entity: date.heating_circuit_1_holiday_end
  end: "2027-01-02"

Field	Required	Meaning
`begin_entity`	yes	The date entity holding the first day of the holiday.
`begin`	yes	First day of the holiday.
`end_entity`	yes	The date entity holding the last day.
`end`	yes	Last day of the holiday; must not be before `begin`.

Both entities must belong to the same module — the portal addresses parameters per module. A period ending before it starts is refused: the portal answers such a pair with a success status and stores nothing.

Setting a date entity on its own works too: it writes both dates in one request, keeping the other unchanged. Both ways read the result back. When the portal accepted the request but kept another day, the call fails with a message naming the day it kept, so an automation does not go on as if the holiday were set.

`wemportal.set_expert_parameter`

Writes one expert parameter. Requires the expert feature to be enabled and the parameter to sit in one of the slots — see below. It refuses while more than one WEM Portal entry has expert write access on: one action cannot say which account is meant.

action: wemportal.set_expert_parameter
data:
  # Replace with YOUR own entityvalue. This one is a placeholder.
  entityvalue: "3A7F91C2E0B48D5619F2A0C7B4E83D105C2A"
  value: 30

Field	Required	Meaning
`entityvalue`	yes	The parameter's hex ID from your own installation - see Step 1.
`value`	yes	The new value: a number, or the word the portal shows for an option that is not a number - beside the scale (for example `Aus`) or on a dropdown of words.

Administrator only. Runs synchronously and raises on failure, so an automation can tell whether the write succeeded. It takes a few seconds for the portal navigation.

Examples

Entity ids below are placeholders - take the real ones from your device pages.

Get told about a fault:

triggers:
  - trigger: state
    entity_id: sensor.your_heat_pump_has_errors
    to: "yes"
actions:
  - action: notify.notify
    data:
      title: Heat pump
      message: "{{ states('sensor.your_heat_pump_error_messages') }}"

Heat the water a little more while there is solar surplus, and let it go back afterwards:

triggers:
  - trigger: numeric_state
    entity_id: sensor.your_grid_export_power
    above: 2000
    for: "00:10:00"
    id: surplus
  - trigger: numeric_state
    entity_id: sensor.your_grid_export_power
    below: 500
    for: "00:10:00"
    id: no_surplus
actions:
  - action: number.set_value
    target:
      entity_id: number.your_hot_water_normal_temperature
    data:
      value: "{{ 55 if trigger.id == 'surplus' else 48 }}"

Put your usual setpoint where the example says 48: nothing sets it back unless an automation does.

Keep in mind that every write is a request against the portal's limit - an automation that fires every few minutes adds up. See Polling and the portal's rate limit.

Expert write access (web)

Some Fachmann/expert parameters — the heat pump's power limit ("Leistungsbegrenzung"), for instance — are only visible in the WEM Portal web frontend and are not exposed by the mobile API at all. This optional feature reads and writes them through the same web form the portal itself uses.

It is disabled by default. While disabled, no extra entities or services exist and the integration behaves exactly as without it.

How it works

Reaching a parameter is a minimal web navigation: the Fachmann submenu, then the parameter's edit form. The session is cached in memory and reused while its last use is less than two hours ago — the login is the request the portal is most likely to reject.
The new value is validated against the option list of your device's own edit form, so only values it actually accepts are sent.
After writing, the form is read back to verify the value was applied. Unconfirmed writes raise an error.
Only one expert operation runs per account at a time. A second write, or a write during the periodic read-back or a discovery, is refused rather than queued.
A 403 on an expert request pauses only this feature, briefly — sensor polling keeps running. A 403 here is not proof of an IP-wide block; it can equally mean the portal did not accept that one request. A 403 seen by the normal polling is the real rate-limit signal and pauses everything.

Step 1: find the parameter

Each writable parameter has a unique hex ID (entityvalue) that is specific to your installation — treat it like a serial number and do not post it publicly.

Option A: let the integration find them (recommended)

Settings > Devices & Services > WEM Portal > CONFIGURE
Choose Discover expert parameters from the portal.
Tick the modules to search (e.g. Wärmepumpe) and submit. One module at a time is gentler on the portal.
Back on the settings form, each slot's ID field is now a dropdown of what was found, labelled group / name (current value) — for example Pumpe / Leistung Heizen (100 %).

A discovery only runs when you ask for it, never in the background. The module list is kept once you save the settings form, so later discoveries do not fetch it again. If it cannot run, the form says which of four things happened: another expert operation is in progress, portal access is backing off after a 403, the search failed, or it ran and found nothing.

Every editable parameter of the module is offered, including the ones the portal shows alone under their own heading — Betriebsart, Heizkennlinie, So/Wi Umschaltung, Reset. Earlier versions skipped those, and they had to be entered by hand.

Option B: read the ID from the portal yourself

Use this if discovery does not find the parameter you want — the slot ID fields accept a typed-in value as well as a picked one.

Log into wemportal.com and navigate to the Fachmann page showing the parameter (e.g. Fachmann > Wärmepumpe).
Press F12, select the element picker and click the pencil/edit icon next to the parameter.
In the highlighted <input>, the onclick attribute contains WwpsParameterDetails.aspx followed by entityvalue=<long hex string> — for example entityvalue=3A7F91C2E0B48D5619F2A0C7B4E83D105C2A. That is an illustrative example, not a real ID; yours will be different.
Copy the hex string after entityvalue=.

Alternatively, open the parameter's edit dialog and copy entityvalue=... straight from the request URL in the developer tools Network tab.

Step 2: enable it

Settings > Devices & Services > WEM Portal > CONFIGURE, then Configure settings and expert slots.
Enable Expert write access via web.
Fill in one or more of the ten slots. Each has a name (free text, becomes the entity's name after the device name, in title case) and an entityvalue. Leave unused slots empty; a slot with an ID but no name gets a default one.
Save — the integration reloads.

Each filled slot becomes a writable number entity. A new one starts without a value unless periodic read-back is enabled — otherwise the value is only read as part of a write. After a successful write (or the first periodic read), the entity shows the verified value and its min/max tighten to the device's real range.

What the number means

The value, range and step are the ones the portal displays, not the ones it posts internally. Those differ on many parameters: a heating curve shown as 0.55 in a range of 0.05 to 1.50 is sent to the device as 55 in 5 to 150, and a delay shown in minutes is sent in seconds. The entity shows what you see on the portal page; the translation happens underneath.

A parameter whose options are all words - an operating mode, say - has no number to show. There the entity's number is the value the portal sends for the option, not anything it displays, and it need not be the option's place in the list - it can start at 0, so the first option may be 0, not 1. portal_value says which word is set. Set such a parameter by its word through the action, as below for Aus; a number written to it chooses by that internal value.

Two attributes come with each entity, both read from the same dialog:

Attribute	What it is
`portal_value`	The portal's own wording for the current selection
`factory_default`	The value the parameter left the factory with

After a Home Assistant restart the entity restores its last value, but not its range: bounds and step return to the permissive placeholders — the field is a typing box again — until the parameter has been read or written once. A stored range can be stale (a heating parameter's limits may depend on other settings), and Home Assistant checks the published range before this integration is asked, so a stale range could block exactly the write that would fetch the current one.

factory_default is useful for spotting settings that have been changed. Home Assistant cannot colour a number that differs from its default — a number entity has no such option — but a dashboard card can compare against this attribute and do it.

Parameters with an "off" position

Some parameters offer a special value beside their numbers: a heating curve can be set to Aus, a frost protection likewise. That is not a point on the scale — the portal encodes it as 0 on one parameter and as -32768 on the next — so it is left out of the entity's range.

Two consequences:

The number entity cannot offer it, and neither can Home Assistant's own range check. Set it through the action instead, naming the word the portal shows — case does not matter, unless two options differ only in case; then write it exactly as the portal does:
```
action: wemportal.set_expert_parameter
data:
  entityvalue: "3A7F91C2E0B48D5619F2A0C7B4E83D105C2A"
  value: "Aus"
```
When the portal has the special value selected, the entity reads unknown and portal_value says which one (Aus). That is not a failed read — a number entity simply cannot show a word.

Two limits worth knowing before you build on this:

Ten slots per account. Only a parameter sitting in one of them can be read by the auto-poll or written by the service — the service is not a general write primitive for any parameter of the installation.
One expert account at a time. The service is a single domain-wide registration with no account to target, so it refuses while more than one loaded account has expert write enabled. Polling and every other feature keep working for all of them; only the service is affected, and it says so rather than guessing which heating system to change.

Number entity vs. service

	Number entity	`set_expert_parameter`
Runs	Synchronously	Synchronously
Failure	Raises, so an automation sees it	Raises, so an automation sees it
Permission	Home Assistant's normal entity permissions	Administrator only

Both wait for the portal to confirm the write, which takes a few seconds — the call returns when the new value has been read back. Only the caller waits; polling, the other entities and the rest of Home Assistant are unaffected.

Either way, the value the portal confirmed is what the number entity for that parameter shows from then on. The service used to leave it on the pre-write value until the next read.

Successful writes do not notify by default (that gets noisy when setting several values). Enable Notify on successful expert write if you want a confirmation on success too. Failures are not notified: they are raised, so whoever asked for the write hears about it.

Note on permissions: the service is admin-only, but the same parameter is also a number entity, and Home Assistant has no way for an integration to restrict one. Anyone allowed to control that entity can write the parameter — treat the entity's permissions as part of the setting.

Periodic read-back (optional, off by default)

To have the entities reflect the portal's current values without a write, enable Poll expert parameters periodically and set an interval in minutes (default 60, minimum 15). All configured parameters are read in one shared session, with a small random jitter so the timing is less regular. A parameter that has been reported as failing to read is asked only once a day until it answers again; a write that works brings it back at once.

Warning: each read is a full Fachmann navigation. Polling too frequently can trigger a temporary 403 block, which pauses the expert feature until it clears. The 15-minute floor exists for this reason.

Advanced options (only if you know what you are doing)

Two navigation steps are skipped by default, because the submenu alone reaches the Fachmann level:

Enable module selection — runs the icon-menu module selection first. The Module menu index field then chooses the module (empty falls back to 6, the heat pump on the reference install).
Enable security-code step — runs the Fachmann security-code unlock. Only for a portal that requires the code per session.

Warning: leave both off unless reads or writes actually fail without them. They add requests — and thus 403 exposure — and exist only as a fallback for unusual setups.

Safety notes

Writes go to your real heating system, identical to changing the value in the portal itself.
Recommended first test: write the parameter's current value (e.g. 30 if the portal shows 30) and check the portal still shows it afterwards.
This path is heavier than the mobile API. Every read or write is a web navigation. It runs only on explicit writes and discoveries, or on the read-back timer if you enable it.

About the entityvalue ID (background)

Derived by observation, not from vendor documentation — it may not hold for every model.

Part of the ID is an address (which category, which parameter) and part is installation-specific. The same parameter on another installation has a different ID. Never copy an ID from someone else: on your system it would address a different parameter, and writing to it could change something unintended.
The ID also carries a snapshot of the value at the moment it was read. That part is not the address — the portal ignores it when opening the dialog, which is why a stored ID keeps working after the value changes.
Do not "clean up" a stored ID by zeroing the value portion. The integration uses the full ID exactly as the portal does, and verifies the result by re-reading the form after every write.

Known limitations

Cloud only. Everything goes through Weishaupt's WEM Portal; there is no local connection, and no data while the portal or your internet is down.
A request limit per IP address. The portal blocks an IP that sends too many requests in 12 hours; see Polling and the portal's rate limit.
Values are as fresh as the portal has them. A shorter scan interval does not make the heat pump report more often, it only spends requests.
Maintenance windows. During announced portal maintenance there are no new values; the integration recognises it and does not ask for your password.
Expert write access is web-only and needs the installation's Fachmann access in the portal.
Holiday dates are only kept as a pair - see set_holiday.
Weekly programmes are read-only.
Web-mode entities are keyed by the portal's labels. Changing the language of your portal account, or the portal rewording a row, creates new entities; the old ones keep their history.
Entity names follow the language option, not Home Assistant's. They are built at runtime from what the portal reports, in English or German; Home Assistant's own language setting does not translate them. With en, a word the built-in vocabulary does not know keeps the portal's German spelling. The exceptions are the integration's own names: the three diagnostic sensors and an expert slot without a name of its own follow Home Assistant's language.

Troubleshooting

Enable debug logging first: Settings > Devices & Services, find WEM Portal, click the three dots on the card, choose Enable debug logging.

Symptom	Likely cause
Setup says the portal is refusing this network	The IP is rate-limited. Waiting is the only fix; retrying prolongs it.
A sensor shows unknown for a cycle	The portal answered without that parameter. Deliberate: a stale reading is not shown as current.
Web-only sensors go unknown together	Three scrapes in a row failed. They come back on the next successful one.
A setpoint shows 0 while the heat pump is idle	The portal shows `--` there: no setpoint without demand. Read as 0, like a pump's `Aus`; a counter showing `--` stays unknown, since Home Assistant would take a 0 as a reset.
Asked to re-authenticate although the password is right	In `web` mode, repeatedly receiving the login form again can trigger re-authentication, even if the portal caused the problem; in `both` mode, web login failures alone do not trigger it. The mobile API treats HTTP 400 and HTTP 200 with an unsuccessful JSON `Status` as credential failures unless the response message announces maintenance; HTTP 403, server errors, and network failures do not count.
A new parameter does not appear	Parameter lists are cached for 24 hours. Use `Search the portal for new API parameters`.
Expert discovery says another operation is running	The auto-poll or a write holds the per-account lock. Try again in a moment.

Repairs

Some problems show up under Settings > System > Repairs and clear themselves once the cause is gone:

Repair	Meaning
WEM Portal is refusing requests (rate limit)	The IP is blocked; polling is paused and resumes by itself.
WEM Portal web access is not working	In `both` mode, the web half keeps failing while the API half still delivers.
Expert parameter … cannot be requested	A slot holds an ID that is not a readable parameter ID. Fix or clear it in the options.
Expert parameter … keeps failing to read	One parameter failed three reads in a row; usually a wrong ID, sometimes the portal refusing it.

The two expert repairs come from the periodic read-back only, which is off by default.

Diagnostics

Settings > Devices & Services, WEM Portal, the three dots on the entry, Download diagnostics. The file leaves out the username, password, session cookie, expert parameter IDs and the discovery cache, and replaces device IDs with device_1, device_2 and so on.

Reporting a problem

Please attach the diagnostics file and the debug log — with your entityvalue IDs, email address and device id removed from the log. The device id also sits inside entity ids such as sensor.<id>_..., which Home Assistant's own log lines name. The diagnostics file already leaves all of them out.

Removing the integration

Settings > Devices & Services, WEM Portal, the three dots on the entry, Delete. This removes the entry with its devices and entities, and also what the integration kept for it on disk: the cached module list, the stored web device id, and its repair issues. Nothing it stored is left behind in Home Assistant, and nothing is changed in the WEM Portal. An open expert-write notification stays until you dismiss it.
If it was installed through HACS, remove it there as well, then restart Home Assistant.

License

MIT — see LICENSE.

Name		Name	Last commit message	Last commit date
.github		.github
custom_components/wemportal		custom_components/wemportal
tests		tests
.deepsource.toml		.deepsource.toml
.gitignore		.gitignore
.gitleaks.toml		.gitleaks.toml
CHANGELOG.md		CHANGELOG.md
LICENSE		LICENSE
README.md		README.md
SECURITY.md		SECURITY.md
hacs.json		hacs.json
mypy.ini		mypy.ini
pytest.ini		pytest.ini
requirements_runtime.txt		requirements_runtime.txt
requirements_test.txt		requirements_test.txt
ruff.toml		ruff.toml

Latest commit

History

Folders and files

Repository files navigation