AI
← All posts
Picoclaw Homeassistant Smarthome Telegram Automation

Connecting PicoClaw to My Smart Home

Dmitrii Balabanov
Dmitrii Balabanov
May 2, 2026 · 8 min read

I already had a fairly practical smart home setup: Home Assistant as the main hub, Zigbee devices, ESPHome projects, a few Wi-Fi devices, and a smart speaker for announcements. It worked well, but most control surfaces were still quite mechanical: dashboards, buttons, automations, and service calls.

At some point I wanted a different interface — not another dashboard, but a small AI assistant that already knows how my home is wired and can operate it from Telegram. This is where I started integrating PicoClaw with Home Assistant.

The goal was simple: keep Home Assistant as the reliable automation backend, and put PicoClaw on top as a natural-language control layer.

The existing setup

My smart home is built around Home Assistant. It is the source of truth for device states, automations, scripts, and integrations. Most devices are connected locally, because I prefer systems that keep working even when the internet is down.

The setup includes:

Home Assistant is great at automation, but it is not always the most convenient interface for quick commands. Sometimes I do not want to open a dashboard, find the right card, or remember the exact entity name. I just want to say what I need.

For example:

turn on the kitchen light

or:

announce that dinner is ready

The interesting part is not sending an HTTP request to Home Assistant. That part is easy. The real challenge is mapping a human phrase to the correct entity and doing it safely.

Where PicoClaw fits

PicoClaw does not replace Home Assistant. I use it as an intelligent layer above it.

The architecture looks like this:

Telegram
   ↓
PicoClaw agent
   ↓
Home Assistant helper / API
   ↓
Home Assistant services
   ↓
Lights, switches, speakers, automations

Telegram is the UI. PicoClaw receives the message, understands the intent, checks its instructions, and decides whether it needs to call a tool. Home Assistant still performs the actual operation: turning on a light, setting speaker volume, sending a TTS message, or reading an entity state.

This separation is important. Home Assistant remains predictable and stateful. PicoClaw adds context, language understanding, memory, and operational rules.

Accessing Home Assistant

For Home Assistant access, I use its HTTP API through a small helper script. The helper reads HA_URL and HA_TOKEN from environment variables, so secrets do not appear in prompts, files, shell history, or chat messages.

A read-only check looks like this:

skills/homeassistant/scripts/ha.py --insecure states light.kitchen

A service call looks like this:

skills/homeassistant/scripts/ha.py --insecure service light turn_on --data '{"entity_id":"light.kitchen"}'

The helper is intentionally boring. It wraps the API, keeps secrets out of the conversation, and gives PicoClaw a stable interface to use.

The most important part: local rules

The first version of this kind of integration can be dangerously naive. An LLM can understand “turn off the kitchen light”, but Home Assistant may contain several entities that sound relevant:

Those are not the same thing.

For example, a room may have smart bulbs behind a physical relay. If the assistant turns off the relay, the bulbs lose power and stop being smart. So the useful rule is:

Control the light group, not the power relay, unless the relay was explicitly requested.

That rule can live in a PicoClaw skill file together with the entity mapping:

light.kitchen — kitchen light group
light.kitchen_main — main kitchen lamp
light.kitchen_counter — counter light
switch.kitchen_relay — power relay, keep ON by default

Now when I ask PicoClaw to turn off the kitchen light, it knows to call light.turn_off on light.kitchen, not switch.turn_off on the wall relay.

This is the difference between “the assistant can call Home Assistant” and “the assistant understands the home”.

Skills as smart home memory

PicoClaw skills are just structured instructions and helper notes. For the smart home integration, this is a very convenient place to store household-specific knowledge:

For example, a Home Assistant skill can contain rules like:

Use light.living_room_main for the main living room lamp.
Use light.kitchen for the kitchen light group.
Never turn off power relays unless explicitly requested.
Use tts.speak for speaker announcements.

It can also contain small conventions. For example, when I say “set volume to 6”, the assistant can map that to volume_level: 0.6 in Home Assistant.

This turns the skill file into a practical, versioned memory of the house. It is not just documentation; PicoClaw actually uses it while deciding what to do.

Example: room lights without breaking smart bulbs

A normal command from Telegram can be very short:

turn off the kitchen light

PicoClaw checks the smart home instructions and maps this to the light group:

skills/homeassistant/scripts/ha.py --insecure service light turn_off --data '{"entity_id":"light.kitchen"}'

The important detail is what it does not do. It does not turn off the relay that powers the bulbs, because that would make them unavailable.

This pattern is useful in many rooms: control the logical device the user means, not necessarily the first entity that matches the name.

Example: household announcements

A smart speaker exposed through Home Assistant can be used for TTS announcements. That means PicoClaw can send messages to the speaker without needing a separate integration.

A message like this:

announce that the washing machine is done

can become a service call:

skills/homeassistant/scripts/ha.py --insecure service tts.speak --data '{"entity_id":"media_player.kitchen_speaker","message":"The washing machine is done."}'

This is more flexible than a fixed automation. I can send an arbitrary message from Telegram, and PicoClaw handles the Home Assistant call.

Example: maintaining automations

Another useful case is maintaining existing Home Assistant automations. Imagine several schedule reminders already announce events through a speaker, but the volume is too high in the evening.

Instead of manually opening every automation and checking YAML, PicoClaw can inspect the relevant automations, find the TTS calls, and update the volume setting to the desired value.

The final rule can be written as:

Evening schedule announcements should use volume_level: 0.4.
Daytime schedule announcements should use volume_level: 0.6.

This is a good example of why an AI assistant is useful here. It is not only about turning things on and off. It can help maintain the configuration around the smart home.

Example: safe climate commands

Climate control is another place where natural language is useful, but guardrails matter.

A command like:

make the bedroom warmer

should not blindly set the heater to the maximum temperature. A better rule is to make small bounded changes:

For climate devices, change target temperature by 1 degree unless the user gives an explicit value.
Keep changes within a comfortable range.
Ask for confirmation before switching modes.

Then PicoClaw can translate the request into a safe Home Assistant call, while avoiding surprising changes.

Safety model

I split operations into several categories.

Read-only actions are usually fine:

Low-risk actions are also acceptable when the intent is clear:

Riskier actions need more care:

For those, the assistant should either follow very explicit rules or ask for confirmation. The important point is that PicoClaw should not have “raw enthusiasm” access to the whole house. It needs guardrails.

Why not just use a voice assistant?

Voice assistants are useful, but they are usually limited to predefined integrations and simple commands. I wanted something more personal and more hackable.

PicoClaw gives me a few advantages:

For example, “kitchen light” in a real apartment may not be a single device. It can be a group, several bulbs, and a relay behind the wall switch. A generic assistant does not know that. PicoClaw can.

Lessons learned

A few things became clear after setting this up.

First, entity names matter. Home Assistant entity IDs are often historical. They may contain typos, old device names, or implementation details. The assistant should not guess too much from entity IDs alone.

Second, the smart home needs a written operational map. It is worth documenting which entities are safe to control and which are not.

Third, secrets must stay out of the LLM context. Environment variables and small helper scripts are much better than pasting tokens into configuration examples.

Fourth, natural language control is only good when the assistant has local knowledge. Without local rules, it is just a fancy API client.

Final result

The final setup feels simple from the outside:

I write a message in Telegram.
PicoClaw understands what I mean.
Home Assistant performs the action.

But the useful part is the layer in the middle. PicoClaw knows the difference between a lamp and the relay powering it. It knows how to send household announcements. It knows which Home Assistant service to call. It can read state before acting. And, when needed, it can explain or ask before doing something risky.

For me, this became a very natural way to control the smart home: Home Assistant remains the stable automation platform, and PicoClaw becomes the conversational control plane on top of it.

Happy automating!