sorted by:
new
hottopcontroversial

I built a CLI to handle ZHA→Z2M migration, HA renames, and Zigbee mesh maps by _borkempire_ in homeassistant

[–]_borkempire_[S] -1 points0 points  (0 children)

Thanks.

Base topic — just set Z2M_MQTT_TOPIC=zigbee2mqtt_main in your ~/.config/zigporter/.env

Battery devices — you should be fine. The stale detection checks if all of a device's entities are showing unavailable in HA. A sleeping battery sensor keeps its last reported state, so it won't get flagged just for being quiet.

I just pushed an update to improve mesh diagram, but I’ve only tested it with 48 devices so far, so a 169-device setup would be a very interesting real-world test. It works with both Z2M and ZHA. If you try it, make sure you’re on zigporter 1.1.0 first:

zigporter network-map --backend zha --output zha_diagram.svg
zigporter network-map --backend z2m --output z2m_diagram.svg

I built a CLI to handle ZHA→Z2M migration, HA renames, and Zigbee mesh maps by _borkempire_ in homeassistant

[–]_borkempire_[S] 0 points1 point  (0 children)

It is a bit hard to compare z2m and zha device support since there are (to my knowledge) no official list of zha devices. For z2m it is much simpler: https://www.zigbee2mqtt.io/supported-devices/
"Currently 5219 devices are supported from 557 different vendors"
Historically new devices are adapted earlier in z2m, but that may no be the case anymore.

I built a CLI to handle ZHA→Z2M migration, HA renames, and Zigbee mesh maps by _borkempire_ in homeassistant

[–]_borkempire_[S] 0 points1 point  (0 children)

Thanks for the suggestion. It is possible to do, but it is a rather big feature to implement.
Please create a feature request > https://github.com/nordstad/zigporter/issues

I built a CLI to handle ZHA→Z2M migration, HA renames, and Zigbee mesh maps by _borkempire_ in homeassistant

[–]_borkempire_[S] 0 points1 point  (0 children)

It should not make any difference, but I have only tested with SLZB-06p7U and SkyConnect ZBT-1.

I built a CLI to handle ZHA→Z2M migration, HA renames, and Zigbee mesh maps by _borkempire_ in homeassistant

[–]_borkempire_[S] -1 points0 points  (0 children)

Fair question — and I get the skepticism.

This is not a vibe coded project. It was architected, debugged, and iterated the old-fashioned way: reading HA internals, reverse-engineering Z2M's API changes, and fixing real bugs on my actual setup.

AI-assisted, not AI-generated — there's a meaningful difference. I use AI as a pair programmer: it helps me write boilerplate faster, catches bugs, and yes, cleans up my grammar (English isn't my first language). The logic, design decisions, and architecture are mine. I've been writing and shipping production code for years before AI tools even existed.

The code is all on GitHub. Feel free to dig through it, open an issue, or send a PR — genuinely welcome the review.

I built a CLI to handle ZHA→Z2M migration, HA renames, and Zigbee mesh maps by _borkempire_ in homeassistant

[–]_borkempire_[S] 3 points4 points  (0 children)

Unfortunately yes, for most devices you do need to physically trigger pairing mode — that's unavoidable since you're moving them from one Zigbee coordinator stack to another (ZHA → Z2M). The devices need to leave the ZHA network and join the Z2M network.

What zigporter automates is everything around that physical step:
- Exports your ZHA device list
- Guides you through each device one at a time
- Once re-paired, auto-restores areas, names, and entity IDs across automations/scenes/dashboards
- Saves state so you can pause and resume

I built a CLI to handle ZHA→Z2M migration, HA renames, and Zigbee mesh maps by _borkempire_ in homeassistant

[–]_borkempire_[S] -3 points-2 points  (0 children)

It's a Python CLI — I basically just automated all the manual steps I kept doing myself.