CONTROLLER · remote service

Home Assistant troubleshooting and remote support

If you are stuck with your own Home Assistant setup, nobody needs to travel. Over a screen share or from the logs, we find out why the Zigbee network keeps dropping, why an automation does not fire, or what an update broke — and we fix it. Remote work does not depend on where you are.

Book a consultation

What we do: Troubleshooting, setup, system reviews, second opinions
Where: Remotely, from wherever you are
What you receive: The fix, and what caused it — so you can spot it yourself next time

What people call about

An automation that runs sometimes and not others. A Zigbee network that behaves for a few days after re-pairing. An integration that broke on an update. A system that works, but nobody remembers what controls what. These trace back to a handful of recurring causes, and the diagnostic route repeats too: log, trace, reproduce, fix, re-measure.

How remote work runs

We work over a screen share, on your machine, on your system — we do not ask for standing remote access. If logs or diagnostics need reviewing, you send those in advance. At the end it does not just work again: we tell you what the cause was and what would have shown it, so you can find it yourself next time.

Home Assistant setup and base configuration
Troubleshooting automations and making them deterministic
Surveying a Zigbee or Z-Wave network: channel, LQI, routes
Reviewing and documenting an existing system
Setting up a backup and update policy

Second opinions, design reviews and acceptance audits

It is not always about fixing something — sometimes you need an independent look before you decide. We review a design before installation starts, assess and document the state of a system that is already in, or give an opinion on a quote, a choice of system or a faulty installation. It works over a video call too. Any remote access to your system happens only with your permission.

Design review: an electrical, KNX or automation design checked before installation
Acceptance audit: the state of an installed system assessed, documented, with its risks
Second opinion: an independent assessment of a quote, a system choice or a faulty installation
Home Assistant consultation: architecture, integrations, automations, stability

What it costs

[TBD: remote consultation pricing, billing unit and minimum]

the logic underneath

What an automation looks like from the inside

An installation is not a system because it has many devices in it, but because the conditions and the reset branches have been thought through. This is a typical example of what that means in practice.

Automation logic example

TRIGGER

What starts it

PV surplus: > 1.5 kW
sustained for: 5 min

Not an instantaneous value: without the sustain window, a passing cloud would switch the heat pump on and off repeatedly.

CONDITION

What must hold

DHW cylinder: < 52 °C
time of day: 09:00–16:00
heat pump: no fault signal

All three conditions ANDed together. Without the fault check, the logic would also drive into a faulted state.

ACTION

What happens

DHW setpoint: 52 → 60 °C
heat pump: enabled
event: logged

Raising the setpoint uses the cylinder as a heat store: the surplus does not go back to the grid.

RESET BRANCH

If the surplus stays below 0.5 kW for 10 minutes, the setpoint returns to 52 °C. Without a reset branch the system would keep the raised setpoint into the evening and carry on heating from the grid — the most common fault in automations like this.

An example of an automation optimising for solar surplus, in three steps. Trigger: PV surplus exceeds 1.5 kW for five minutes. Condition: the domestic hot water cylinder is below 52 °C, the time is between 09:00 and 16:00, and the heat pump reports no fault — all three at once. Action: the cylinder setpoint rises from 52 to 60 °C, the heat pump is enabled, and the event is logged. Reset: if the surplus stays below 0.5 kW for ten minutes, the setpoint returns. The values are illustrative.

related systems

What we work with here

The full list, organised by layer on the home page, and protocol by protocol in the compatibility matrix.

Remote support — related systems and protocols
System	Bridge	What we do with it
Zigbee 3.0	coordinator	Channel selection to avoid Wi-Fi collision, planning router coverage, surveying and fixing an unstable network.
Z-Wave	controller stick	Building the network, rebuilding routes, sorting out coexistence between older and 800-series devices.
Matter / Thread	Thread border router	Placing border routers, sorting out coexistence between Thread and existing Zigbee on the same 2.4 GHz band.
MQTT	broker	Running the broker, designing the topic structure, setting up authentication and TLS.
Home Assistant	—	Setup, wiring in integrations, writing automations, backup and update policy, remote troubleshooting.
ESPHome	native API	Building custom sensors and controllers where no good off-the-shelf device exists; reflashing existing devices.
Shelly	local API / MQTT	Fitting behind existing switches without opening walls, energy metering, wiring into the controller over the local API.

what we fix

The situations people bring us for this

Symptom, cause, intervention. These are the most common situations people bring to us — most of them do not need a new system, only a survey and a clean-up of the existing one.

Unstable Zigbee network, devices dropping off

RADIO remote or on-site Symptom · cause · fix Close

Symptom: Devices go unavailable at random, commands are delayed or lost, and re-pairing helps for a few days before it starts again.
Typical cause: Usually channel collision with Wi-Fi, too few mains-powered routers in the mesh, poor coordinator placement, or 2.4 GHz noise from a USB 3.0 port.
What we do: We survey the whole network: channel occupancy, per-device LQI and routing. We change channel, place routers, move the coordinator away on an extension lead, then re-measure.

Home Assistant troubleshooting — your automation does not fire

CONTROLLER remote Symptom · cause · fix Close

Symptom: The automation runs sometimes and not others. An integration breaks after an update. The log is full, but none of it explains what went wrong.
Typical cause: A race between triggers, a missing condition, watching an attribute instead of a state, a broken custom entity, or a breaking change in the update.
What we do: We go through the logs and traces, reproduce the fault, and rewrite the automation so it behaves deterministically — and show you what you would have looked at yourself, had you known where to look.

Reviewing an existing system — security included

IP remote or on-site Symptom · cause · fix Close

Symptom: A system that grew over years across several generations and platforms. It works, but nobody knows any more what controls what, or what happens when something fails.
Typical cause: Undocumented integrations, overlapping automations, cloud-dependent devices in critical places, a controller with no backup — and typically devices still running factory passwords on a flat network.
What we do: The review runs on two layers. Operation: we map what is installed, remove conflicting logic, replace the cloud-dependent links and set up backups. Security: factory passwords, interfaces reachable from outside, outdated firmware, missing network segmentation, traffic leaving for the cloud. You get a written findings report on both, and a topology you can hand to anyone.

Insecure remote access — an open port on the router

IP remote or on-site Symptom · cause · fix Close

Symptom: You can reach the system from outside because you opened a port for it on the router. It works — and that is exactly the problem.
Typical cause: Port forwarding, weak or factory passwords, and a flat network where the IoT devices sit right next to your laptop. It is the most common fault we find, and the most dangerous one.
What we do: We close the open port and set up remote access over a VPN (WireGuard). The IoT devices move to their own network segment, where they cannot see the rest of your network.

A controller that slows down, and a backup that will not restore

CONTROLLER remote or on-site Symptom · cause · fix Close

Symptom: The controller gets slower and slower, then one morning it does not boot. That is when it turns out there is no backup, or one that cannot be restored.
Typical cause: A worn-out SD card, a database that has outgrown itself, and a backup that lives inside the house or has never been tested.
What we do: We move the controller to more durable storage, tidy up what gets recorded, and set up automatic backups that also leave the house. Then we actually test a restore.

what we do

The other layers of the stack

A system rarely stops at one layer. We handle these too, as part of the same installation.

KNX installation and ETS programming in Hungary

Topology design, bus cabling, ETS programming. We also take over existing installations, even when the ETS project is missing.

Details 02

Structured cabling, KNX bus wiring and electrical work

Structured cabling, mains electrical and the camera network, installed under our own electrical qualification.

Details 03

Retrofit automation without opening walls

For a finished, occupied home: modules behind the existing switches and wireless devices, no wall chasing.

Details

contact

Book a consultation

Describe what is installed today and where you got stuck. You do not need a finished plan — the point of the consultation is to work out what is realistic. The more specific you are (protocols, devices, controller), the more precise an answer we can give, even without a site visit.