Ziqi (Katrina) Ding

Connect Jira and Confluence to Claude Code with Atlassian MCP and CLI

Fri, 20 Mar 2026 00:00:00 GMT

import { Aside, MdxImage } from 'astro-pure/user' import img_pasted_image_20260320131130 from './pasted-image-20260320131130.png'

The Problem

Context-switching between Jira, Confluence, and the terminal is a drag. Every time we need to check a ticket, create a task, or look up a Confluence page, we're leaving the editor, clicking through Atlassian's UI, and losing focus.

Even with project scope docs living in Confluence, breaking those down into Jira tickets manually still takes time. And when working with Claude Code, we end up copy-pasting ticket descriptions and page content just to give it context.

The Solution

Install both Atlassian MCP and Atlassian CLI (ACLI), then let Claude Code pick the right tool for the job.

Atlassian MCP — deeper integration with both Jira and Confluence. Can set Jira properties (priority, labels, sprint), run JQL/CQL searches, create and update Confluence pages, and manage comments.
Atlassian CLI (ACLI) — lighter weight. Faster for simple reads and writes, uses fewer tokens, and works across any AI agent without needing per-tool MCP setup. Covers both Jira and Confluence.

With both available, Claude Code chooses MCP when it needs full property access or rich Confluence editing, and ACLI when a quick lightweight call is enough.

How to Do It

1. Atlassian MCP

In the terminal, run this to add Atlassian MCP at the user level:

claude mcp add --transport http "atlassian" "https://mcp.atlassian.com/v1/mcp" -s user

Follow the browser prompt to authenticate.

Back in Claude Code, run /mcp to verify the connection:

  Manage MCP servers
  11 servers

    User MCPs (/Users/ziqiding/.claude.json)
  > atlassian · connected
    context7 · connected
    sequential-thinking · connected

That's it. Claude Code can now interact with both Jira and Confluence through MCP tools like createJiraIssue, searchJiraIssuesUsingJql, transitionJiraIssue, getConfluencePage, createConfluencePage, and searchConfluenceUsingCql.

2. Atlassian CLI (ACLI)

Install

macOS via Homebrew:

brew tap atlassian/homebrew-acli
brew install acli

For other platforms, see the full install documentation.

Authenticate

Two options — pick whichever suits your setup.

Option A: Web login (easiest)

acli jira auth login --web

Follow the steps in the browser. You'll see this on success:

Authentication successful
  Welcome, Ziqi Ding

Option B: API key (for headless environments or CI)

Go to Atlassian Account Security settings and create an API token.

Then authenticate with:

# Replace <token>, site URL, and email with your own values
echo <token> | acli jira auth login --site "mysite.atlassian.net" --email "user@atlassian.com" --token

Key Commands

Here are the two commands you'll use most. For the full list, check the ACLI getting started guide.

Create a work item:

acli jira workitem create --summary "Add auth middleware" --project "HSP" --type "Task"

Transition a work item:

acli jira workitem transition --key "HSP-42" --status "In Progress"

Allow ACLI in Claude Code

Claude Code needs permission to run acli commands. Usually when Claude needs to invoke that tool, it will ask for permission and add it to settings automatically.

If not, we can manually add it to your allowed tools — either in Claude Code settings or in project's CLAUDE.md:

In .claude/settings.json:

{
  "permissions": {
    "allow": [
      ...
      "Bash(acli jira:*)",
      "mcp__atlassian__searchJiraIssuesUsingJql",
      "mcp__atlassian__editJiraIssue",
      ...
    ]
  }
}

This lets the AI invoke ACLI directly without prompting for approval each time.

How Claude Code Chooses

With both tools available, Claude Code picks the best one per task:

| Scenario | Tool | Why | |----------|------|-----| | Set priority, labels, or sprint | MCP | Full property access | | Complex JQL/CQL search | MCP | Richer query support | | Create issue with all metadata | MCP | More fields available | | Create or update Confluence pages | MCP | Rich content editing, inline comments | | Quick status check | ACLI | Fewer tokens, faster | | Simple transition | ACLI | Lightweight call | | Read a Confluence page | ACLI | Fast, low-token retrieval | | Bulk operations | ACLI | Scriptable, piped commands |

You can also guide this in your CLAUDE.md:

Prefer ACLI for reads and simple transitions. Use Atlassian MCP for creating issues or setting Jira properties.

Or let Claude add it to your global memory:

❯ can you remember this: Prefer ACLI for reads and simple transitions. Use Atlassian MCP for creating issues or setting Jira
properties.

⏺ I'll save that as a feedback memory right away.

⏺ Recalled 1 memory, wrote 2 memories (ctrl+o to expand)

⏺ Saved. I'll use ACLI for reads and simple transitions, and Atlassian MCP for creating issues or setting Jira properties going forward.

Practical Examples

"What are my current sprint tasks?"

Claude Code uses MCP's searchJiraIssuesUsingJql with a JQL query like sprint in openSprints() AND assignee = currentUser(), then formats the results as a list.

"Create a task for adding dark mode support in project HSP"

Claude Code calls acli jira workitem create --summary "Add dark mode support" --project "HSP" --type "Task" — quick, low-token call for a straightforward create.

"Move HSP-42 to Done and add a comment that the PR is merged"

Claude Code uses ACLI for the transition (workitem transition --key "HSP-42" --status "Done") and MCP's addCommentToJiraIssue for the comment — best of both tools in one prompt.

"Summarize the architecture page from our Confluence space"

Claude Code uses MCP's searchConfluenceUsingCql to find the page, then getConfluencePage to read its content and return a summary — no need to open a browser.

Summary

With Atlassian MCP and ACLI both connected, Claude Code can manage Jira tasks and Confluence pages without us ever leaving the terminal.

Xcode Developer Tool Version Mismatch

Wed, 18 Mar 2026 00:00:00 GMT

Context

Environment:
- Having multiple Xcode installed (16.4 and 26.2)
What I was doing:
- Installing Supabase CLI via Homebrew

The Error

cii-intelligence git:feature/supabase-deployment*  
❯ brew install supabase/tap/supabase                         

==> Auto-updating Homebrew...
Adjust how often this is run with $HOMEBREW_AUTO_UPDATE_SECS or disable with
$HOMEBREW_NO_AUTO_UPDATE=1. Hide these hints with $HOMEBREW_NO_ENV_HINTS=1 (see man brew).
==> Fetching downloads for: supabase
✔︎ Formula supabase (2.75.0)                                                                                                                     Verified     28.1MB/ 28.1MB
==> Installing supabase from supabase/tap
Error: Your Xcode (16.4 => /Applications/Xcode_16.4.app/Contents/Developer) at /Applications/Xcode.app is too outdated.
Please update to Xcode 26.3 (or delete it).
Xcode can be updated from the App Store.

Root Cause

It is refusing to proceed because the active Xcode/Developer tools it sees are too old for current Homebrew requirements. Homebrew does enforce minimum Xcode / Command Line Tools versions, and when they are outdated it stops installs.

Even if a newer Xcode is installed, xcode-select is set to the old Xcode developer directory -- the Command Line Tools are stale.

The Fix

Try this in order.

# Show which Xcode/Developer tools path is currently selected on this Mac
xcode-select -p

# Check whether /Applications/Xcode.app exists and whether it is a real app folder or a link to another Xcode
ls -ld /Applications/Xcode.app

# List all Xcode apps in /Applications so you can see which versions are installed
ls /Applications | grep Xcode

Then, if you do have a newer Xcode installed, switch to it explicitly:

sudo xcode-select -s /Applications/Xcode.app/Contents/Developer

If your real app is not /Applications/Xcode.app, point at the actual one, for example:

sudo xcode-select -s /Applications/Xcode_26.3.app/Contents/Developer

Also check the CLI tools:

# Show the installed version/details of Apple's Command Line Tools package
pkgutil --pkg-info=com.apple.pkg.CLTools_Executables

If Command Line Tools are outdated, Homebrew’s usual fix is to reinstall them: remove the old CLT directory and run the installer again. That is the standard remedy Homebrew points people to when tools are too old.

# Delete the current Command Line Tools so they can be cleanly reinstalled
sudo rm -rf /Library/Developer/CommandLineTools

# Open Apple's installer prompt to download and install the latest Command Line Tools
xcode-select --install

After that:

# Accept the Xcode license agreement from terminal so build tools can run without blocking
sudo xcodebuild -license accept

# Refresh Homebrew metadata and formula definitions to the latest version
brew update

# Run Homebrew diagnostics to detect common setup problems on your machine
brew doctor

Summary

If Homebrew blocks an install with a "too outdated" Xcode error, point xcode-select at your newest Xcode, reinstall Command Line Tools if needed, then re-run brew update && brew doctor.

References

https://github.com/orgs/Homebrew/discussions/5690

Android Studio google pom failed to respond

Wed, 12 Nov 2025 00:00:00 GMT

import { MdxImage } from 'astro-pure/user' import img_pasted_image_20251112084452 from './pasted-image-20251112084452.png'

Context

Environment:
- Physically in China
- Have VPN turned on
What I was doing:
- Building Android app for RN

The Error

❯ ./gradlew assembleDebug 

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'Feed4Ward'.
> Could not resolve all dependencies for configuration ':classpath'.
   > Could not resolve com.android.tools.build:gradle:8.7.2.
     Required by:
         root project :
      > Could not resolve com.android.tools.build:gradle:8.7.2.
         > Could not get resource 'https://dl.google.com/dl/android/maven2/com/android/tools/build/gradle/8.7.2/gradle-8.7.2.pom'.
            > Could not GET 'https://dl.google.com/dl/android/maven2/com/android/tools/build/gradle/8.7.2/gradle-8.7.2.pom'.
               > dl.google.com:443 failed to respond
> There is 1 more failure with an identical cause.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

Root Cause

Since I have VPN, the proxy that VPN have config is different with the one that Android studio is using.

VPN's config:

The Proxy port is at 8118,
The Outbound Mode is "Rule-based Proxy"

The network config that Android Studio uses (in ~/.gradle/gradle.properties):

## For more details on how to configure your build environment visit
# http://www.gradle.org/docs/current/userguide/build_environment.html
#
# Specifies the JVM arguments used for the daemon process.
# The setting is particularly useful for tweaking memory settings.
# Default value: -Xmx1024m -XX:MaxPermSize=256m
# org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
#
# When configured, Gradle will run in incubating parallel mode.
# This option should only be used with decoupled projects. For more details, visit
# https://developer.android.com/r/tools/gradle-multi-project-decoupled-projects
# org.gradle.parallel=true
#Tue Nov 11 17:42:54 CST 2025
systemProp.http.proxyHost=127.0.0.1
systemProp.http.proxyPort=1080
systemProp.https.proxyHost=127.0.0.1
systemProp.https.proxyPort=1080

The Fix

1. Use Socks Proxy instead of Http/Https proxy for Android Studio

In ~/.gradle/gradle.properties, replace the existing proxy setting with:

systemProp.java.net.useSystemProxies=false

# Use SOCKS instead (Clash exposes SOCKS on 127.0.0.1:8119 from your screenshot)
systemProp.socksProxyHost=127.0.0.1
systemProp.socksProxyPort=8119
systemProp.socksProxyVersion=5

# Recommended for avoiding IPv6 routing issues
org.gradle.jvmargs=-Djava.net.preferIPv4Stack=true

2. Ensure Android Studio is No Proxy

Settings → System Settings → HTTP Proxy → No proxy

When that popup appears, select: No (Do NOT keep global gradle proxy settings)

3. Repo config sanity check

Make sure you have these in your top-level build.gradle or settings.gradle:

repositories {
    google()
    mavenCentral()
}

4. Change VPN Config

Change Outbound Mode to Global Proxy

5. Restart Gradle

./gradlew --stop
./gradlew --no-daemon --refresh-dependencies

6. Build Project

# from android/
./gradlew assembleDebug

Summary

The dl.google.com:443 failed to respond error happens when Gradle's proxy settings don't match your VPN's actual proxy port. Switching to SOCKS proxy and setting the VPN to Global Proxy mode fixes the mismatch.

Move your MacOS notification position

Mon, 15 Sep 2025 00:00:00 GMT

import { MdxImage } from 'astro-pure/user' import img_pasted_image_20250915120938 from './pasted-image-20250915120938.png' import img_cleanshot_2025_09_15_at_1211072x from './cleanshot-2025-09-15-at-1211072x.png'

What It Does

PingPlace is a lightweight macOS menu bar app that lets you move your notification banners to any corner of the screen. By default, macOS locks notifications to the top-right — PingPlace removes that restriction.

Why I Chose It

macOS notifications always appear at the top-right corner. If you have a notch-style MacBook or use the menu bar heavily, notifications can overlap with what you're doing. There's no built-in setting to change this, and PingPlace is the only tool I found that does it cleanly — free, open-source, and no background daemon.

Installation

brew tap notwadegrimridge/brew
brew install pingplace --no-quarantine

Basic Usage

For the first time launching the app, it asks us to grant accessibility permissions for it to work.

Then we can set notification position from the menu bar menu:

When to Use It

Notch-era MacBooks where top-right notifications collide with the camera notch area
Multi-monitor setups where you want notifications on a specific screen corner
Screen recordings or presentations where top-right popups are distracting

Summary

PingPlace is a simple, free tool that solves a long-standing macOS annoyance — letting you move notifications wherever you want.

Prevent AI to read your .env file

Sun, 14 Sep 2025 00:00:00 GMT

import { MdxImage } from 'astro-pure/user' import img_pasted_image_20250914190638 from './pasted-image-20250914190638.png'

Keeping Your `.env` Files Safe from GitHub Copilot

If you’ve ever worked with GitHub Copilot inside VS Code, you might have wondered: is Copilot peeking into my .env file?
That file is where API keys, tokens, and other sensitive credentials usually live. And while .gitignore stops them from leaking into your repo, it doesn’t guarantee that Copilot (or other extensions) won’t see them.

Let’s walk through what actually happens, what tools exist to mitigate the risk, and the simplest way to keep your secrets private.

What’s Really Happening

VS Code indexes everything: By default, VS Code scans your entire workspace to provide IntelliSense, search, and extension features.
Copilot builds on that index: Even though .env is ignored by Git, it’s still indexed locally.
If you open .env, it’s fair game: Once you open the file, its contents can appear in Copilot’s context and even leak back into code suggestions.
Other extensions may also access it: Just because Copilot usually avoids .gitignore files doesn’t mean other VS Code extensions will.

So while .env isn’t automatically leaked, the risk is real.

The “Heavy” Option: Dotenvx

There’s a library called dotenvx, built by the creator of dotenv, that encrypts your .env file.

It generates an encrypted .env.encrypted and a private key .env.keys.
You run commands with a prefix like:

"scripts": {
  "dev": "dotenvx run -- next dev --turbopack",
  "build": "dotenvx run -- next build",
  "start": "dotenvx run -- next start"
}

During runtime, dotenvx decrypts and injects your variables.

The catch:

In React Native, you need to manually decrypt before building.
In Next.js + Vercel, you must ship the encrypted file and configure a decryption key. Encrypted values can’t be used directly in Vercel’s settings.
The tool is still young, with frequent breaking updates.

Great idea, but probably too much friction for most workflows today.

The “Lightweight” Option: VS Code Exclusion

A more practical solution is simply to keep .env files out of VS Code entirely. That way, Copilot and other extensions never index them.

How to exclude `.env` files

Open VS Code settings (CMD + , on macOS).
Search for “exclude”.
Under Files: Exclude, add:
```
**/.env*
```

Your .env files will instantly disappear from the Explorer and stop being indexed.

How to view `.env` safely

Open them with a lightweight editor outside VS Code. For example, on macOS:

open .env   # Opens in TextEdit

Or use Sublime Text, Notepad++, or any other simple editor.

Why This Matters

Imagine asking Copilot to generate a function that uses your API key, while the .env file is open. Copilot might “helpfully” autocomplete with your real key. Not only is that a security risk, it’s a nightmare if snippets get copy-pasted, logged, or shared.

By excluding .env files, you cut off that risk completely with almost no workflow change.

Takeaways

Copilot doesn’t automatically read .env, but it can if the file is open.
Dotenvx encrypts env files, but it’s heavy for day-to-day use.
Excluding .env in VS Code is the fastest, lowest-effort way to protect secrets.

A single exclusion rule in VS Code keeps your credentials private, keeps Copilot useful, and saves you from accidental leaks.

Adding a Zigbee device to Zigbee2MQTT and Home Assistant

Tue, 02 Sep 2025 00:00:00 GMT

import { Aside, MdxImage } from 'astro-pure/user' import img_pasted_image_20250902192139 from './pasted-image-20250902192139.png' import img_pasted_image_20250902192053 from './pasted-image-20250902192053.png' import img_pasted_image_20250902200302 from './pasted-image-20250902200302.png' import img_pasted_image_20250902200121 from './pasted-image-20250902200121.png'

Environment

OS: Debian GNU/Linux 12 (bookworm)
Kernel: Linux 6.12.33+deb12-amd64
Architecture: x86-64
HA: Home Assistant Container
- Core: 2025.7.4
- Frontend: 20250702.3

Prerequisite

Setup Home Assistant
Setup Zigbee network
A Zigbee 3.0 Device. Check Z2M database for supported devices.

How to Do It

1. Adding the device into Zigbee network

Insert battery or plug the device to power source.
Set the device to pairing mode (usually has flashing indicator) according to its manual.
On Zigbee2MQTT frontend portal, Press "Permit join". <MdxImage src={img_pasted_image_20250902192139.src} alt={"Permit join"} />
Then, we can see that the device has been added automatically. <MdxImage src={img_pasted_image_20250902192053.src} alt={"The sensor has been added"} />
Turn off device scanning by clicking "Disable join", which is the same button as "Permit join" above.

Note: Sometimes the device may looks different from the image on Z2M.

2. Config and connect to HA

Click on the device "Friendly name", first edit the friendly name to something that is truly friendly.

If you've integrated MQTT on HA, the device should be added into HA automatically. If not, follow Step 4 in Set up Zigbee dongle with HA.

Summary

This walkthrough shows how to pair a Zigbee device with Zigbee2MQTT (“Permit join”), give it a clean friendly name, and have it appear in Home Assistant automatically via the MQTT integration.

Differences between Model and Zigbee Model

Tue, 02 Sep 2025 00:00:00 GMT

import { MdxImage } from 'astro-pure/user' import img_pasted_image_20250902195139 from './pasted-image-20250902195139.png'

Question

What is the difference between Model and Zigbee Model?

Answer

These two fields represent different layers of device identity and serve distinct purposes in Zigbee2MQTT:

Zigbee Model

Definition: The identifier reported by the device during the Zigbee interview process.
Example: TS0201
Source: Comes directly from the device’s Zigbee firmware.
Purpose: Used by Zigbee2MQTT to match the device to its internal support database.
Notes: Multiple devices from different brands may share the same Zigbee Model if they use the same firmware or chipset.

Model

Definition: The manufacturer’s product model name.
Example: IH-K009
Source: Typically derived from Tuya or other vendor metadata.
Purpose: Helps users identify the physical product they purchased.
Notes: More specific to the device’s external design, packaging, or retail listing.

Analogy

Think of it like this:

Zigbee Model = the engine type (e.g., “V6 Turbo”)
Model = the car’s make and model (e.g., “Toyota Camry 2021”)

Troubleshooting Tips

Zigbee2MQTT's frontend pulls images from it's device support database, which organizes entries by Model, NOT Zigbee Model.
Use the Model field to label your devices meaningfully in dashboards or logs.
For Tuya devices, expect some overlap or ambiguity between these fields due to shared firmware across product lines.

Clean and Reinstall RN dependencies

Mon, 01 Sep 2025 00:00:00 GMT

The Problem

When we change the library version, it's easy to have some issues that are because the caches contains old version code, causing a pods/embedding issue.

The Solution

Do the clean install

How to Do It

From repo root:

watchman watch-del-all || true

rm -rf $TMPDIR/metro-* $TMPDIR/haste-map-*

rm -rf node_modules

yarn install

cd ios

# or remove all derived data: ~/Library/Developer/Xcode/DerivedData/*
rm -rf Pods Podfile.lock  ~/Library/Developer/Xcode/DerivedData/<project_name>-*

pod cache clean --all

pod install

On your test device or emulator, delete the app (or Device -> Erase All Content and Settings...)

Quit and reopen Xcode, clean build folder (Product -> Clean Build Folder...).

Start metro and build the app again

watchman watch-del-all && yarn cache clean && yarn start --reset-cache --verbose

Summary

A full clean reinstall — clearing Watchman, Metro cache, node_modules, Pods, and DerivedData — resolves most stale-cache build issues after changing library versions in React Native.

Set up Zigbee dongle with HA

Sun, 31 Aug 2025 00:00:00 GMT

import { Aside, MdxImage } from 'astro-pure/user' import img_pasted_image_20250831135604 from './pasted-image-20250831135604.png' import img_img_2013 from './img_2013.png' import img_pasted_image_20250831150847 from './pasted-image-20250831150847.png' import img_pasted_image_20250831151841 from './pasted-image-20250831151841.png' import img_pasted_image_20250902171003 from './pasted-image-20250902171003.png' import img_pasted_image_20250902201531 from './pasted-image-20250902201531.png' import img_pasted_image_20250902202512 from './pasted-image-20250902202512.png' import img_pasted_image_20250902202309 from './pasted-image-20250902202309.png' import img_pasted_image_20250902202415 from './pasted-image-20250902202415.png'

Environment

OS: Debian GNU/Linux 12 (bookworm)
Kernel: Linux 6.12.33+deb12-amd64
Architecture: x86-64
HA: Home Assistant Container
- Core: 2025.7.4
- Frontend: 20250702.3

Goal

This guide will walk through the steps setup Sonoff ZBDongle-E connected with Home Assistant, as preparation for connecting variety of Zigbee devices.

Here we will be using Zigbee2MQTT (Z2M) as Zigbee bridges due to it's better compatibilities to various devices. For simpler setup, you could also consider Zigbee Home Automation (ZHA) . See Background for more details.

Introduction

We want to connect Zigbee devices and sensors from various manufacturers and manage them all through Home Assistant. However, many of these devices require binding to the vendor's own platform (e.g., Tapo, Aqara), with data uploaded to their respective clouds. To unify everything locally for both convenience and privacy, we can communicate with Zigbee-compatible devices directly via the Zigbee protocol.

For this, we need a Zigbee 3.0 USB dongle. After some research, I found the Sonoff Zigbee 3.0 USB Dongle-P to be one of the most popular options. I ended up purchasing its upgraded version, the Sonoff Zigbee 3.0 USB Dongle-E, also known as Dongle Plus V2. Although some reviews noted that the Dongle-E was less stable and compatible than the Dongle-P, continuous firmware updates over the past couple of years have brought it to a much more stable state.

Background

Set up with Z2M

flowchart LR
  %% --- Zigbee side ---
  subgraph Zigbee_Network["Zigbee Network"]
    ZDev1["Zigbee sensor 1"]
    ZDev2["Zigbee sensor 2"]
  end

  Coord["Sonoff ZBDongle-E"]

  ZDev1 -- "Zigbee frames" --> Coord
  ZDev2 -- "Zigbee frames" --> Coord

  %% --- Host side (Docker) ---
  subgraph Host["Debian mini PC (Docker)"]
    Z2M["Zigbee2MQTT<br/>(adapter: ember, serial: /dev/ttyUSB-ZBDongleE,<br/>baud: 115200, software flow control)"]
    Broker["Mosquitto<br/>MQTT Broker"]
    HA["Home Assistant<br/>(MQTT integration)"]
  end

  Coord <-->|"EZSP over serial (USB)"| Z2M
  Z2M -->|PUBLISH device states on topics| Broker
  HA -->|SUBSCRIBE discovery/states| Broker
  HA -->|PUBLISH commands| Broker
  Broker -->|FORWARD messages| Z2M
  Z2M -->|convert to Zigbee commands| Coord
  Coord --> ZDev1
  Coord --> ZDev2

Set up with ZHA

flowchart LR
  %% --- Zigbee side ---
  subgraph Zigbee_Network[Zigbee Network]
    ZDev1["Zigbee sensor 1"]
    ZDev2["Zigbee sensor 2"]
  end

  Coord["Sonoff ZBDongle-E"]

  ZDev1 --> |Zigbee frames| Coord
  ZDev2 --> |Zigbee frames| Coord

  %% --- Host side (Docker) ---
  subgraph HAHost["Debian mini PC (Docker)"]
    subgraph HA["Home Assistant container"]
      ZHA["ZHA integration<br/>(native Zigbee gateway)"]
      Zigpy["zigpy core<br/>(Zigbee stack in Python)"]
      Bellows["Radio library: bellows<br/>(EZSP for EFR32)"]
      HACore["HA Core<br/>entities, automations, UI"]
    end
  end

  ZHA -->|uses| Zigpy
  Zigpy -->|loads radio| Bellows
  Bellows <-->|"EZSP over serial (USB)"| Coord
  ZHA -->|creates entities/events| HACore
  HACore -->|service calls| ZHA

Step-by-step Guide

1. Flash official firmware on the ZBDongle-E

According to the official guide, they have released an online quick flasher for ZBDongle. This makes thing much easier.

Official Tutorial: SONOFF Dongle Quick Flasher: Effortless Firmware Updates in 1 Minute

First we need to connect our dongle via USB, and go to the online flasher, click "Connect".

Wait a few seconds, the tool should successfully detect the dongle. Then we can flash the latest firmware by clicking "Flash".

After it completes, it will display "Firmware flashing complete, the device will restart automatically", and it's safe to unplug the dongle now.

Next, plug the dongle to your HA host, and confirm the dongle is visible from the serial port by executing this command on the host.

$ ls -l /dev/serial/by-id/
total 0
lrwxrwxrwx 1 root root 13 Aug 31 15:25 usb-Itead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_V2_2e3ace430dc3ef119d08e2b08048b910-if00-port0 -> ../../ttyUSB0

2. Preparation

2.1 Uninstall `ModemManager`

Firstly, if your HA is running on Linux, it is recommended to uninstall or disable ModemManager, as it would "sniff" any new serial port, causing "Serial port is locked/Resource busy/ping timeout" errors. Check out HA doc here

If you don't plan to use WWAN connection, uninstalling or disabling it would be the safest way (See discussion here).

$ sudo apt-get purge modemmanager     # Uninstall
$ sudo systemctl disable ModemManager # Disable

To confirm it's being uninstalled:

$ systemctl status ModemManager
Unit ModemManager.service could not be found.

(If you want to remain ModemManager for future use, you can just disable it for now, but it may restart and causes potential issues in future. In this case, you may need to somehow explicitly let ModemManager to ignore the ZBDongle device)

2.2 Plug adapter to the host correctly

There are two recommended setup for the USB adapter:

Use a USB extension cable to keep the adapter at least 50cm away from the computer can largely reduce the interference from computer's radio signals.
Plug the adapter to a USB 2 instead of USB 3 port.

As stated in the official doc:

When plugged directly into the computer, the antenna suffers from interference of radio signals and electrical components of the computer. ... Additionally, it may help to plug the adapter to a USB 2 instead of USB 3 port.

Check out official doc for more details.

3. Install, Config & Start Z2M bridge and MQTT Broker (Mosquitto)

3.1 Create required directories and files

The following directories are required by the services, so we should create them before hand.

Mosquitto
- config/, data/, log/
Zigbee2MQTT
- data/

Run this to create required directories in /opt

mkdir -p /opt/{mosquitto/config,mosquitto/data,mosquitto/log,zigbee2mqtt/data}

This creates

zigbee2mqtt/
└── data
mosquitto/
├── config
├── data
└── log

3.2 Mosquitto

Update docker compose file:

## ...rest

mosquitto:
  container_name: mqtt5
  image: eclipse-mosquitto:latest
  network_mode: host
  restart: unless-stopped
  volumes:
    - /opt/mosquitto/config:/mosquitto/config
    - /opt/mosquitto/data:/mosquitto/data
    - /opt/mosquitto/log:/mosquitto/log
      
## ...rest

Create configuration file:

/opt/mosquitto/config/mosquitto.config

## Network listener port
listener 1883

## Disable anonymous connections, enable password authentication
allow_anonymous false
password_file /mosquitto/config/passwords

## Enable persistence, save subscription and message state
persistence true
persistence_location /mosquitto/data/

## Log level (optional)
log_type all
log_dest stdout

Use Docker to run Mosquitto's mosquitto_passwd tool to create the MQTT user password file and add a user z2m with a password (remember to replace <STRONG_PASSWORD> with your password):

docker run --rm -it -v /opt/mosquitto/config:/mosquitto/config eclipse-mosquitto \
mosquitto_passwd -b -c /mosquitto/config/passwords z2m <STRONG_PASSWORD>

Explanation:

Docker part
- --rm: Automatically remove the container after it finishes, avoiding leftover temporary containers.
- -it: Run the container in interactive mode; -i keeps stdin open, -t allocates a pseudo-terminal.
- -v /opt/mosquitto/config:/mosquitto/config: Mount the host's /opt/mosquitto/config directory into the container at /mosquitto/config for reading and writing config files.
- eclipse-mosquitto: Use the Eclipse Mosquitto latest image.
Mosquitto part
- -b: Batch mode -- provide the password directly on the command line (no interactive prompt).
- -c: Create a new password file -- overwrites it if it already exists.
- /mosquitto/config/passwords: Path to the password file (inside the container).
- z2m: The username.
- <STRONG_PASSWORD>: The password you want to set (replace with a strong password).

To add more users in the future without overwriting the existing file, drop the -c flag and use only -b to append users.

So this warning is just informational and does not affect your current operation.

To test mosquitto, in the same folder with docker-compose.yaml, run the container that we just defined:

docker compose up -d

Or, you can create containers first but not to start them:

docker compose up --no-start

Then, start mosquitto only:

docker compose start mosquitto zigbee2mqtt

Use docker ps to verify mosquitto has been started and running.

Next, we can open two new terminals, one for publisher and one for subscriber, let the publisher send a test message to the subscriber.

## terminal 1 (subscribe)
docker run --rm -it --network host eclipse-mosquitto:2 \
  mosquitto_sub -h 127.0.0.1 -p 1883 -u z2m -P '<STRONG_PASSWORD>' -t 'test' -v

## terminal 2 (publish)
docker run --rm -it --network host eclipse-mosquitto:2 \
  mosquitto_pub -h 127.0.0.1 -p 1883 -u z2m -P '<STRONG_PASSWORD>' -t 'test' -m 'hello'

Explanation:

--network host: Use the host's network so the container can reach Mosquitto on 127.0.0.1:1883.
mosquitto_sub: Subscribe to a topic and print incoming messages.
- -h 127.0.0.1 -p 1883: Connect to the local Mosquitto broker.
- -u z2m -P '<STRONG_PASSWORD>': Authenticate with the credentials we created earlier.
- -t 'test': Subscribe to the topic named test.
- -v: Verbose mode -- print the topic name alongside the message payload.
mosquitto_pub: Publish a message to a topic.
- -m 'hello': The message payload to send.

The subscriber will print this out in terminal:

test hello

3.3 Zigbee2mqtt

Docker compose service official docs: Docker | Zigbee2MQTT

docker-compose.yaml

## ...rest

zigbee2mqtt:
  container_name: z2m
  image: ghcr.io/koenkk/zigbee2mqtt:latest
  network_mode: host  # posts mapping will be ignored
  restart: unless-stopped
  devices:
    - /dev/serial/by-id/usb-Itead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_V2_2e3ace430dc3ef119d08e2b08048b910-if00-port0:/dev/ttyUSB-ZBDongleE
  volumes:
    - /opt/zigbee2mqtt/data:/app/data   # as per official docs
    - /run/udev:/run/udev:ro  # required for auto-detecting the adapter
  environment:
      - TZ=Australia/Melbourne

## ...rest

Configuration files: official docs: Configuration | Zigbee2MQTT

/opt/zigbee2mqtt/data/configuration.yaml

version: 4
mqtt:
    base_topic: zigbee2mqtt
    server: mqtt://127.0.0.1:1883
    user: z2m # The username we set in Mosquitto
    password: <YOUR_PASSWORD> # The pw we set in Mosquitto
serial:
    # Adapter
    port: /dev/ttyUSB-ZBDongleE
    adapter: ember
advanced:
    # Network
    channel: 25
    network_key: GENERATE
    pan_id: GENERATE
    ext_pan_id: GENERATE
    # MQTT
    output: 'json'
frontend:
    enabled: true

Explanation:

Explicit settings:
- mqtt
  - server: mqtt://127.0.0.1:1883 -- Point to the port of mosquitto
  - user: z2m -- The username we set in the previous step
  - password: <YOUR_PASSWORD> -- The password we set in the previous step
- serial
  - adapter -- According to EmberZNet adapters (Silicon Labs) | Zigbee2MQTT, the adapter we use (ZBDongleE) is ember based.
- advanced
  - channel -- Zigbee channel. Set to 25 to avoid problems. Default 11.
Implicit settings:
- serial
  - rtscts: false -- According to doc, ember based adapter can only use software flow control, which means rtscts (Hardware Flow Control) has to be false. The setting is default to false.
- frontend
  - port: 8080 -- default
  - host: 0.0.0.0 -- default

Then, in the same folder with docker-compose.yaml, run the container

docker compose up -d

Check docker's logs:

docker compose logs zigbee2mqtt

Check if this is at the end of the logs:

...
z2m  | [2025-09-02 16:51:59] info:      z2m: Connected to MQTT server
z2m  | [2025-09-02 16:51:59] info:      z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload '{"state":"online"}'
z2m  | [2025-09-02 16:51:59] info:      z2m: Started frontend on port 8080
z2m  | [2025-09-02 16:51:59] info:      z2m: Zigbee2MQTT started!

Congrats! Both Mosquitto and Zigbee2mqtt are running properly now!

3.4 Check out the Z2M Frontend

After both Mosquitto and Zigbee2mqtt are running, and we have frontend.enabled: true in z2m configuration, we can open the frontend to setup devices or further configure the zigbee network. In your browser, go to http://<host_ip>:8080, You should see

You should be able to scan devices by clicking the "Permit to join" button (Next to the language setting icon)

4. Integrate MQTT into HA

On HA, go to Settings → Devices & Services → Add integration → Search "MQTT"

Select the first one

In the next form we need to config the MQTT broker, which is the Mosquitto we setup earlier.

Broker address -- localhost or 127.0.0.1 since we're running Mosquitto on the same host
Port -- Mosquitto's default port 1883
Username -- The username we set for Mosquitto
Password -- The password we set for Mosquitto

We don't need "Advanced options" here, so just hit "Submit".

Tada! We can see the Bridge (Z2M) and one existing device (Tuya Temperature & humidity sensor) are detected.

Any new devices added to Z2M will also be added into HA in the future.

Summary

This guide walked through flashing the Sonoff ZBDongle-E firmware, setting up Mosquitto as an MQTT broker, configuring Zigbee2MQTT, and integrating everything with Home Assistant -- giving you a fully local Zigbee network ready to connect devices.

RN app does not hot reload

Tue, 26 Aug 2025 00:00:00 GMT

import { MdxImage } from 'astro-pure/user' import img_pasted_image_20250826223635 from './pasted-image-20250826223635.png' import img_pasted_image_20250826223101 from './pasted-image-20250826223101.png'

Context

Environment:
- React Native 0.76.8
- Xcode 16.4
What I was doing:
- Built and run RN app on Xcode, but running Metro on terminal

The Error

RN app does not hot load, pressing r in Metro session will display no apps connected error, no matter running on emulator or physical device.

...
debug Key pressed: r
info Reloading connected app(s)...
warn No apps connected. Sending "reload" to all React Native apps failed. Make sure your app is running in the simulator or on a phone connected via USB.

Updates in code not reflected in the running app until rebuild and rerun the app.

Root Cause

The app is not in debug mode. For example, the "Build Configuration" in XCode was set to Release

The Fix

Go into Xcode, open your project
Press [⌘]+[⇧]+[,], or go from menu Product -> Scheme -> Edit Scheme <MdxImage src={img_pasted_image_20250826223635.src} alt={"Xcode's Scheme Editor Entry"} />
Make sure in the new window that Run is selected
Ensure the Build Configuration is set to Debug (could be set to Release and that's why it's not working) <MdxImage src={img_pasted_image_20250826223101.src} alt={"Xcode Scheme Editor"} />
Click Close
Press [⌘]+[⇧]+[k] to do a full clean of the build folder
Try running it on device again.

References

React Native does not hot-reload on ios device : r/reactnative

Update NPM package to Github release

Mon, 25 Aug 2025 00:00:00 GMT

import { Aside, MdxImage } from 'astro-pure/user' import img_pasted_image_20250826112734 from './pasted-image-20250826112734.png'

The Problem

Sometimes we find that the package version on NPM is not up-to-date as the Github one.

For example, this React Native package: react-native-pdf-thumbnail - npm on NPM has the latest version 1.3.1, which was updated in 2023.

This package introduced build error on Android SDK 35, specifically a Kotlin issue

Type mismatch: inferred type is Bitmap.Config? but Bitmap.Config was expected

occurs in this line

val bitmapWhiteBG = Bitmap.createBitmap(bitmap.width, bitmap.height, bitmap.config)

where bitmap.config returns nullable in SDK 35, and the fix should be providing a default bitmap.config ?: Bitmap.Config.ARGB_8888.

Interestingly, in the Github repo, the files was updated only 2 months ago, containing the fix, tho the update was not released due to lack of maintenance.

The Solution

So instead of specifying a version number in package.json, we can point the resources to a git commit from a public repo.

How to Do It

For example, after confirming that the latest commit in react-native-pdf-thumbnail contains the fix, we can update package.json as follows:

-"react-native-pdf-thumbnail": "^1.3.1",
+"react-native-pdf-thumbnail": "songsterq/react-native-pdf-thumbnail#<tag-or-commit>"

Example

Here are a few way we can specify the release or commit we want. For example:

// Point to a Github tag/release
"react-native-pdf-thumbnail": "git:songsterq/react-native-pdf-thumbnail#v1.3.2"

// Point to a commit
"react-native-pdf-thumbnail": "songsterq/react-native-pdf-thumbnail#f5774dc2",

// Point to a commit using full git url
"react-native-pdf-thumbnail": "git+https://github.com/applickable/react-native-boundary.git#f5774dc2",

// Use the latest commit in a branch
"react-native-pdf-thumbnail": "songsterq/react-native-pdf-thumbnail#master"

Note: Usually the latest commit might contain some unstable features that could introduce new bugs or instabilities. Targeting the specific fix commit is more precise and safer for production apps.

Summary

When an NPM package is outdated but the fix already exists on GitHub, point your dependency to a specific commit or tag instead of waiting for a new release.

Use USB Speaker as Audio Output

Fri, 22 Aug 2025 00:00:00 GMT

import { Aside } from 'astro-pure/user'

The Problem

Home Assistant can generate audio (TTS, alerts), but getting it to actually come out of a USB speaker on a Linux box can be weirdly painful—mostly because audio services love fighting over devices and permissions.

In this post, I’ll show how I routed HA audio through a USB speaker using MPD, how to verify the ALSA device, and how to fix the classic “device busy” / “PipeWire connection refused” traps so sound finally plays where it should.

The Solution

How to Do It

1. Ensure your speaker is visible by the system

katrina@homeserver:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
...    # Other devices
card 2: Device [USB Audio Device], device 0: USB Audio [USB Audio]     # <== This one
  Subdevices: 0/1
  Subdevice #0: subdevice #0

In my case, the USB speaker is the card 2. We can also verify it by cat /proc/asound/cards.

katrina@homeserver:~$ cat /proc/asound/cards
...    # Other devices
 2 [Device         ]: USB-Audio - USB Audio Device    # <== This one
                      GeneralPlus USB Audio Device at usb-0000:00:14.0-1, full speed

2. Ensure MPD is installed and Verify it's working

Check MPD system daemon status by systemctl status mpd

katrina@homeserver:~$ systemctl status mpd
● mpd.service - Music Player Daemon
     Loaded: loaded (/lib/systemd/system/mpd.service; enabled; preset: enabled)
     Active: active (running) since Fri 2025-08-22 17:27:41 AEST; 14min ago
	 ...

We can verify that is running as it's saying Active: active (running). If not, enable and start MPD by

sudo systemctl enable mpd
sudo systemctl start mpd

Then we can check its status using mpc

katrina@homeserver:~$ mpc status
volume:100%   repeat: off   random: off   single: off   consume: off
ERROR: Failed to decode http://192.168.0.208:8123/api/tts_proxy/ffxnuIRPgDEXKSy1qKMovg.mp3; CURL failed: The requested URL returned error: 404

Uh oh, it's currently off, and the speaker-test fails as well.

katrina@homeserver:~$ speaker-test -D hw:2,0 -c 2 

speaker-test 1.2.8

Playback device is hw:2,0
Stream parameters are 48000Hz, S16_LE, 2 channels
Using 16 octaves of pink noise
Playback open error: -16,Device or resource busy

Since the output indicates Device or resource busy, it maybe occupied by other process.

2.1 Debug - Check Who is Using PulseAudio

Execute command:

## Check who is using audio devices
sudo fuser -v /dev/snd/*

## Check audio processes
ps aux | grep -E 'pulse|pipewire'

## If above indicates that PulseAudio is occupied, try temporarily stop it
systemctl --user stop pulseaudio.socket
systemctl --user stop pulseaudio.service

3. Configure and Test MPD

Open MPD config file with nano sudo nano /etc/mpd.conf Edit:

## Ensure MPD listen to localhost
bind_to_address                 "0.0.0.0"

## Ensure MPD listen  port 6600
port                            "6600"

Then, restart MPD

sudo systemctl restart mpd 

## Check status 
systemctl status mpd 

## Ensure the port is listened 
ss -tuln | grep 6600

Play a sample mp3 to test the MPD

## Clear old playlist
mpc clear 

## Play a sample mp3
mpc add https://www.soundhelix.com/examples/mp3/SoundHelix-Song-1.mp3 
mpc play 

## Check status
mpc status 

## Check volumn
mpc volume

## List all audio output devices
pactl list short sinks

In my case, I see this output:

katrina@homeserver:~$ mpc status
https://www.soundhelix.com/examples/mp3/SoundHelix-Song-1.mp3
[paused]  #1/1   0:00/6:13 (0%)
volume: n/a   repeat: off   random: off   single: off   consume: off
ERROR: Failed to enable output "PipeWire Output" (pulse); pa_context_connect() has failed: Connection refused

katrina@homeserver:~$ pactl list short sinks
43      alsa_output.usb-GeneralPlus_USB_Audio_Device-00.analog-stereo   PipeWire        s16le 2ch 48000Hz       RUNNING
...

The first mpc status gives Connection refused error, while pactl list short sinks indicates that our USB speaker is running as device 43.

3.1 Debug - Speaker is running, but PipeWire Output says "Connection refused"

Observation: We could list our speaker through pactl list short sinks, which was running with user-level permission; but MPD service could not connect to PipeWire (showed "Connection refused" error).

This might be because MPD service is running as a mpd user, so it can't connect to the user-level (katrina) PipeWire session.

We can verify this conflicts:

katrina@homeserver:~$ ps aux | grep -E "mpd|pipewire"
katrina  3832551  3.4  0.1 109980 29416 ?        Ssl  17:10   6:07 /usr/bin/pipewire        # <== PipeWire running with "katrina"
katrina  3832553  2.3  0.5 216200 85196 ?        SLsl 17:10   4:14 /usr/bin/pipewire-pulse  # An adapter layer
mpd      3923115  0.1  0.4 727684 72492 ?        SLsl 18:00   0:11 /usr/bin/mpd --systemd   # <== MPD running with "mpd" user
katrina  4060487  0.0  0.0   6336  2064 pts/5    S+   20:09   0:00 grep -E mpd|pipewire     # The grep itself

The problem is clear now. MPD running as an "mpd" user, so it doesn't have permission to access PipeWire's socket.

Solution: Let's check MPD config file

Stop MPD service

sudo systemctl stop mpd 
sudo systemctl disable mpd

Open MPD config file, and find this line

# This setting specifies the user that MPD will run as. MPD should never run as
# root and you may use this setting to make MPD change its user ID after
# initialization. This setting is disabled by default and MPD is run as the
# current user.
#
user                           "mpd"

Ah, we can see that user is set to "mpd". We just need to comment this line to let MPD run as the current user
```
# Comment this line
# user                           "mpd" 
```
Start MPD service
```
mpd
```

Verify permission -- All running with current user

katrina@homeserver:~$ ps aux | grep -E "mpd|pipewire"
katrina  3832551  3.4  0.1 109980 30184 ?        Ssl  17:10   7:40 /usr/bin/pipewire
katrina  3832553  2.4  0.5 216200 90956 ?        SLsl 17:10   5:18 /usr/bin/pipewire-pulse
katrina  4122244  1.9  0.3 932160 53944 ?        Ssl  20:51   0:00 mpd
katrina  4122673  0.0  0.0   6336  2144 pts/5    S+   20:51   0:00 grep -E mpd|pipewire

If not, try killing mpd process completely then start again

katrina@homeserver:~$ ps aux | grep mpd | grep -v grep                  # Find the process
katrina  4122244  0.3  0.3 932160 53944 ?        Ssl  20:51   0:00 mpd
katrina@homeserver:~$ kill -9 4122244                                   # The process ID
katrina@homeserver:~$ ps aux | grep mpd | grep -v grep                  # Verify the process is gone
katrina@homeserver:~$ mpd                                               # Start MPD

Then, repeat the steps to play sample mp3 to test the MPD. The USB speaker should now be able to play some sound.

Summary

Home Assistant audio now plays through a USB speaker by routing output via MPD and fixing PipeWire/permission conflicts.

Convert SVG to PNG on macOS

Tue, 19 Aug 2025 00:00:00 GMT

import { MdxImage } from 'astro-pure/user' import img_cleanshot_2025_08_19_at_165558 from './cleanshot-2025-08-19-at-165558.gif'

The Problem

macOS's built-in Quick Actions for image conversion fail with SVG files. Instead of converting the SVG, it creates an empty PNG file - not exactly helpful.

The Solution

The best tool for this job is librsvg, an open-source library for rendering SVG files. It comes with rsvg-convert, a command-line tool that handles SVG to PNG conversion beautifully.

What makes it great:

Fast and reliable - Written in Rust for performance and memory safety
Handles complex SVGs - Full support for gradients, filters, text, and transformations
Simple to use - Just one command for basic conversion
Flexible output - Control dimensions, DPI, and background colors

Installation

If you have Homebrew installed (and you should!), installation is a breeze:

brew install librsvg

That's it. The tool is now ready to use.

Basic Usage

Navigate to Your SVG Files

First, you'll need to get to your SVG files in Terminal. Check out this quick tip for the fastest way to do this.

Converting Your SVG

The simplest conversion command:

rsvg-convert icon.svg -o icon.png

This uses the SVG's original dimensions. If your SVG doesn't specify dimensions, it defaults to 96 DPI.

Getting Better Quality

The default conversion might look pixelated or small. Here's how to fix that: Key options:

-w/--width - Set width in pixels
-h/--height - Set height in pixels
-d/--dpi-x and -p/--dpi-y - Resolution (default 96)
--keep-aspect-ratio - Prevent distortion
-b/--background-color - Add a background color

Practical examples:

## Large, high-quality output
rsvg-convert -h 1024 --keep-aspect-ratio icon.svg -o icon-large.png

## Retina display (2x resolution)
rsvg-convert -d 192 -p 192 icon.svg -o icon@2x.png

## Fixed square with white background
rsvg-convert -w 512 -h 512 --keep-aspect-ratio -b white icon.svg -o icon-square.png

Batch Processing

Need to convert multiple SVGs? Here's a simple loop:

for file in *.svg; do
    rsvg-convert -h 1024 --keep-aspect-ratio "$file" -o "${file%.svg}.png"
done

Pro Tips

For app icons: Use specific dimensions like -w 1024 -h 1024 for iOS app icons
For web use: Try -d 144 for crisp images on most screens
Transparent SVGs: Add -b white or any color if you need a background
Check all options: Run rsvg-convert --help for the complete list

Summary

rsvg-convert is a powerful yet simple tool that solves the SVG to PNG conversion problem on macOS. It's fast, reliable, and gives you full control over the output quality. No more empty PNG files from Quick Actions!

Quickly Find Path to a Folder or File in Terminal

Tue, 19 Aug 2025 00:00:00 GMT

import { MdxImage } from 'astro-pure/user' import img_cleanshot_2025_08_19_at_210951 from './cleanshot-2025-08-19-at-210951.gif' import img_cleanshot_2025_08_19_at_211307 from './cleanshot-2025-08-19-at-211307.gif'

The Problem

We often encounter this scenario: you've found a file using Finder (which is more visual and convenient for browsing), but you need to perform Terminal operations on it. When Terminal opens, it defaults to your home directory, forcing you to navigate step-by-step to reach your target folder - a tedious and time-consuming process.

The Solution: Drag and Drop

The quickest and simplest method is to drag files or folders directly from Finder into Terminal. Terminal automatically converts the dropped item into its corresponding file path.

For Files

Simply drag any file from Finder into Terminal, and the complete path appears instantly:

For Folders

The same technique works perfectly with folders. For example, to navigate to your current Finder location in Terminal:

Press Command + ↑ in Finder to go up to the parent directory
Drag the desired folder into Terminal
Terminal automatically generates the correct path

Pro Tips

Works with multiple items: You can drag multiple files/folders to get all their paths at once
Combine with commands: Type your command first (like cd, ls, or open), then drag the file/folder to complete it
Spaces in paths: Terminal automatically handles spaces in file names by escaping them properly
Works in any Terminal app: This technique works in Terminal, iTerm2, and other terminal emulators

Common Use Cases

cd [drag folder] - Navigate to a directory
open [drag file] - Open a file with its default application
code [drag folder] - Open a folder in VS Code
rm [drag file] - Delete a specific file (use with caution!)

Summary

This simple drag-and-drop technique can save you countless keystrokes and time when working between Finder and Terminal. No more typing long paths or navigating directory by directory!

GitHub Copilot Custom Chat Modes - Create Your Own AI Assistant

Mon, 18 Aug 2025 00:00:00 GMT

import { MdxImage } from 'astro-pure/user' import img_pasted_image_20250818115318 from './pasted-image-20250818115318.png' import img_pasted_image_20250818115408 from './pasted-image-20250818115408.png' import img_pasted_image_20250818115426 from './pasted-image-20250818115426.png' import img_pasted_image_20250818115815 from './pasted-image-20250818115815.png' import img_pasted_image_20250818120156 from './pasted-image-20250818120156.png' import img_pasted_image_20250818120745 from './pasted-image-20250818120745.png' import img_pasted_image_20250818122033 from './pasted-image-20250818122033.png'

Why Custom Chat Modes?

GitHub Copilot's default chat is great, but sometimes you need specialized assistance. Custom chat modes let you create focused AI assistants with specific system prompts and tool access - perfect for repetitive tasks or domain-specific workflows.

Creating Your Custom Chat Mode

Step 1: Access Configuration

In the Copilot Chat window, click the "Agent" dropdown and select "Configure Modes":

Step 2: Create New Mode

Select "Create new custom chat mode file":

Step 3: Choose Scope

Select the first option to make this mode available only in your current workspace. This creates better project-specific assistants:

Step 4: Name Your Assistant

Enter a descriptive name for your custom mode. Don't worry - you can change this later.

Step 5: Template Generated

VSCode creates a template file in .github/chatmodes:

.github
├── chatmodes
│   └── package-upgrade.chatmode.md
└── copilot-instructions.md

Configuring Your Chat Mode

Adding Tools

You can expose specific tools to your custom mode either by:

Clicking the "Configure Tools" button above the tools line
Editing the tools array directly in the JSON

Note: If you add an invalid tool name, VSCode will highlight it, but your chat mode will still work (it just won't have access to that tool):

Writing System Prompts

Below the tools array, define your system prompt. This is where the magic happens - this prompt is sent with every user message, giving Copilot specific context and instructions.

Example system prompts:

"systemPrompt": "You are a React component specialist. Always use TypeScript, functional components with hooks, and follow accessibility best practices."

"systemPrompt": "You are a database optimization expert. Focus on query performance, proper indexing, and explain the reasoning behind each suggestion."

Using Your Custom Mode

Once configured, your custom mode appears in the dropdown below the Copilot chat input:

Simply select it to activate your specialized assistant. The mode stays active for the entire conversation until you switch to another mode.

Practical Use Cases

Code Review Assistant

{
  "name": "Code Reviewer",
  "tools": ["readFile", "searchCode"],
  "systemPrompt": "You are a senior code reviewer. Focus on: security issues, performance problems, code smell, and suggest improvements following SOLID principles."
}

Test Writer

{
  "name": "Test Creator",
  "tools": ["readFile", "writeFile"],
  "systemPrompt": "You are a test automation expert. Write comprehensive unit tests using Jest/React Testing Library. Always test edge cases and error scenarios."
}

Documentation Helper

{
  "name": "Doc Writer",
  "tools": ["readFile", "writeFile"],
  "systemPrompt": "You are a technical writer. Create clear, concise documentation with examples. Use JSDoc for functions and include usage examples."
}

Pro Tips

Version control: Commit your .github/chatmodes folder to share custom modes with your team
Project-specific modes: Create modes tailored to your project's tech stack and conventions
Iterate and refine: Update system prompts based on what works best for your workflow
Tool selection: Only include tools your mode actually needs for better performance

Summary

Custom chat modes transform GitHub Copilot from a general assistant into specialized experts for your specific needs. By crafting focused system prompts and selecting appropriate tools, you can create powerful, context-aware assistants that understand your project's unique requirements.

Fix: undefined symbols _RNSBottomTabsCls in React Native 0.76

Thu, 07 Aug 2025 00:00:00 GMT

import { MdxImage } from 'astro-pure/user' import img_xcode_2025_08_07_114332 from './xcode-2025-08-07-114332.png'

Context

"react-native-screens": "^4.13.1",
"react-native": "0.76.8",
Xcode: 16.4

Error Log

Xcode build error: <MdxImage src={img_xcode_2025_08_07_114332.src} alt={"Xcode 2025-08-07 11.43.32"} />

Expanded error:

ld: warning: ignoring duplicate libraries: '-lc++', '-lz'

ld: warning: search path '*********************/Library/Developer/Xcode/DerivedData/hsp-fmfmhonkiseyvxerinenzbgzrnpb/Build/Products/Release-iphonesimulator/FBReactNativeSpec' not found

ld: warning: search path ''*********************/Library/Developer/Xcode/DerivedData/hsp-fmfmhonkiseyvxerinenzbgzrnpb/Build/Products/Release-iphonesimulator/Folly' not found

ld: warning: Could not find or use auto-linked framework 'CoreAudioTypes': framework 'CoreAudioTypes' not found

ld: warning: Could not parse or use implicit file '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks/SwiftUICore.framework/SwiftUICore.tbd': cannot link directly with 'SwiftUICore' because product being built is not an allowed client of it

Undefined symbols for architecture arm64:

  "_RNSBottomTabsCls", referenced from:

      _RCTThirdPartyFabricComponentsProvider in RCTFabric[42](RCTThirdPartyFabricComponentsProvider.o)

  "_RNSBottomTabsScreenCls", referenced from:

      _RCTThirdPartyFabricComponentsProvider in RCTFabric[42](RCTThirdPartyFabricComponentsProvider.o)

  "_RNSScreenStackHostCls", referenced from:

      _RCTThirdPartyFabricComponentsProvider in RCTFabric[42](RCTThirdPartyFabricComponentsProvider.o)

  "_RNSSplitViewHostCls", referenced from:

      _RCTThirdPartyFabricComponentsProvider in RCTFabric[42](RCTThirdPartyFabricComponentsProvider.o)

  "_RNSSplitViewScreenCls", referenced from:

      _RCTThirdPartyFabricComponentsProvider in RCTFabric[42](RCTThirdPartyFabricComponentsProvider.o)

  "_RNSStackScreenCls", referenced from:

      _RCTThirdPartyFabricComponentsProvider in RCTFabric[42](RCTThirdPartyFabricComponentsProvider.o)

ld: symbol(s) not found for architecture arm64

clang++: error: linker command failed with exit code 1 (use -v to see invocation)

Root Cause

The build error occurred due to experimental Fabric components in react-native-screens v4.12.0+ that aren't fully compatible with React Native 0.76.x.

The Technical Details:

Experimental "Gamma" Components: Starting from v4.12.0, react-native-screens introduced experimental native components like:
- RNSBottomTabsCls
- RNSBottomTabsScreenCls
- RNSScreenStackHostCls
- RNSSplitViewHostCls These require building with ENV['RNS_GAMMA_ENABLED'] = '1' flag.
Fabric Registration Issue: In React Native 0.76.x with Fabric enabled, there's a problem with how third-party native components are registered. The codegen generates RCTThirdPartyFabricComponentsProvider that references these experimental components, but they're not properly linked during the build process.
Architecture Mismatch: Your project had:
- Fabric enabled initially (fabric_enabled => true)
- react-native-screens 4.13.1 with experimental components
- React Native 0.76.8 which has incomplete support for these new components
Why 4.11.0 Works: Version 4.11.0 predates these experimental components, so it doesn't try to register RNSBottomTabsCls and similar classes that cause the undefined symbols error.

The Fix

Downgrade react-native-screens to a lower version 4.11.0 (Released May 27, 2024)

Why 4.11.0 is the best choice:

Stable and Mature - Released in May 2024, it's had several months of real-world testing
Major iOS Bug Fixes including:
- Fixed pressables in header not working with modal presentation
- Fixed TouchableOpacity issues on screens
- Fixed sporadic screen content jumps
- Fixed header back button issues
- Improved gesture handling in modals
Not Too New - Avoids the experimental features introduced in 4.12+ (like native bottom tabs that cause your current issue)
Compatible - Fully supports React Native 0.76+ with Paper (old architecture)

Why NOT other versions:

4.9.0: Had build issues with USE_FRAMEWORKS=dynamic
4.9.1: Only a patch fix for 4.9.0 issues
4.10.0: Fewer bug fixes than 4.11.0
4.12.0+: Introduces experimental native bottom tabs (the source of your RNSBottomTabsCls errors)
4.13.0-4.13.1: Too new with experimental features requiring RNS_GAMMA_ENABLED

Installation Command:

yarn add react-native-screens@4.11.0

Summary

This linking error happens when react-native-screens 4.12+ introduces experimental Fabric components that aren't fully compatible with React Native 0.76. The quickest solution is to downgrade to version 4.11.0, which predates these experimental features while still being stable and feature-rich.

References

https://github.com/software-mansion/react-native-screens/releases

Fix: undefined local variable or method 'config' for Podfile in React Native

Thu, 07 Aug 2025 00:00:00 GMT

Context

Upgrading React Native 0.72 → 0.76
Building for iOS Simulator using Xcode 16.4
Running pod install with CocoaPods

Error Log

During pod install

...
Generating Pods project
[!] An error occurred while processing the post-install hook of the Podfile.

undefined local variable or method 'config' for an instance of Pod::Podfile

*********************/ios/Podfile:66:in 'block (2 levels) in Pod::Podfile.from_ruby'
...

Notes

The key line is: undefined local variable or method 'config'.
The stack points to Podfile:66, inside the post-install hook.
Likely cause: config is out of scope in post_install.

Root Cause

The first line mentions that the issue was in Podfile line 66,

*********************/ios/Podfile:66:in 'block (2 levels) in Pod::Podfile.from_ruby'

where in my case was

react_native_post_install(
	installer,
	config[:reactNativePath],  # <-- Here
	:mac_catalyst_enabled => false,
	# :ccache_enabled => true
)

The error undefined local variable or method 'config'... indicates that the variable reactNativePath was not found in config.

Since config is defined in target '<AppName>' block, maybe the code that referencing config[:reactNativePath] is placed outside of the target block, causing that config is out of scope, and hence CocoaPods can’t see config[:reactNativePath]

The Fix

Move the code inside target block, or don’t reference config in post_install. Pass the RN path directly (or declare a constant at the top).

Add this near the top:

react_native_path = File.join(__dir__, '..', 'node_modules', 'react-native')

Then change your post_install call to:

 react_native_post_install(
    installer,
    react_native_path,                  # <- use the constant
    :mac_catalyst_enabled => false
  )

Summary

This error occurs because config is defined inside the target block but referenced in post_install, where it's out of scope. The solution is simple: define the React Native path as a constant at the top of your Podfile instead of relying on the scoped config variable.

Ziqi (Katrina) Ding

Connect Jira and Confluence to Claude Code with Atlassian MCP and CLI

The Problem

The Solution

How to Do It

1. Atlassian MCP

2. Atlassian CLI (ACLI)

Install

Authenticate

Key Commands

Allow ACLI in Claude Code

How Claude Code Chooses

Practical Examples

Summary

Xcode Developer Tool Version Mismatch

Context

The Error

Root Cause

The Fix

Summary

References

Android Studio google pom failed to respond

Context

The Error

Root Cause

The Fix

1. Use Socks Proxy instead of Http/Https proxy for Android Studio

2. Ensure Android Studio is No Proxy

3. Repo config sanity check

4. Change VPN Config

5. Restart Gradle

6. Build Project

Summary

Move your MacOS notification position

What It Does

Why I Chose It

Installation

Basic Usage

When to Use It

Summary

Links

Prevent AI to read your .env file

Keeping Your .env Files Safe from GitHub Copilot

What’s Really Happening

The “Heavy” Option: Dotenvx

The “Lightweight” Option: VS Code Exclusion

How to exclude .env files

How to view .env safely

Why This Matters

Takeaways

Adding a Zigbee device to Zigbee2MQTT and Home Assistant

Environment

Prerequisite

How to Do It

1. Adding the device into Zigbee network

2. Config and connect to HA

Summary

Differences between Model and Zigbee Model

Question

Answer

Zigbee Model

Model

Analogy

Troubleshooting Tips

Clean and Reinstall RN dependencies

The Problem

The Solution

How to Do It

Summary

Set up Zigbee dongle with HA

Environment

Goal

Introduction

Background

Set up with Z2M

Set up with ZHA

Step-by-step Guide

1. Flash official firmware on the ZBDongle-E

2. Preparation

2.1 Uninstall ModemManager

Keeping Your `.env` Files Safe from GitHub Copilot

How to exclude `.env` files

How to view `.env` safely

2.1 Uninstall `ModemManager`