Issues after migrating from ZHA to Z2M

Configuration Zigbee
1

Hi,
yesterday evening, I tested out Z2M by migrating some devices from ZHA to Z2M. However, a few things are not working as intended. First of all, here’s the (still small) network:

image
image842×543 26.5 KB

  1. How could the network be disconnected, i.e. not everything is connected to the coordinator? But still all the entities are reachable.
  2. In my MQTT Broker, I now get messages like this every 2 minutes:

2025-10-22 08:57:14: New connection from 172.30.32.2:53282 on port 1883.
2025-10-22 08:57:14: Client closed its connection.

  1. I have an automation to turn on lights at a specific brightness level, but it does always only work once. It’s similar in the dashboard, I can toggle the lights by clicking the power button without problems. However, say the following scenario.
  • Turn on lamp, set brightness to 100%
  • Turn off lamp
  • Turn on lamp by moving the slider up to 100% again, not using the power toggle button
  • Lamp stays off, but shows as on in the dashboard

This last issue is actually annoying. It always works when I set the brightness to another level than what was set previously or when I use the power toggle. But since the automation looks like the following, it does only work once until the brightness is changed somewhere. Minimal example for the automation:

alias: test
description: ""
triggers: []
conditions: []
actions:
  - action: light.turn_on
    metadata: {}
    data:
      brightness_pct: 100
    target:
      entity_id: light.flurlicht_vorne_1
mode: single

I also checked the Z2M logs. The payload is exactly the same in both cases, no matter whether I turn on the light using the toggle switch or by moving the brightness slider up

2

For the third point I found a workaround at least which is to turn on the light twice. Once with a brightness setting and once without

alias: test
description: ""
triggers: []
conditions: []
actions:
  - action: light.turn_on
    metadata: {}
    target:
      entity_id: light.flurlicht_vorne_1
    data:
      brightness_pct: 100
  - action: light.turn_on
    metadata: {}
    data: {}
    target:
      entity_id: light.flurlicht_vorne_1
mode: single

It’s not very clean, but works… For the other two points I’m interested to learn more

PS: I found, other people have the same issue here. What I still find odd though, is that in the Z2M log, both MQTT commands are identical, whether I add brightness in the UI or not. Is the logging lying?

3

I am following your post to learn from your issue, if you don’t mind [g]. Using HA for over a year now, just moved from ZHA to Z2M. I don’t understand enough myself, but I have thoughts. . .

For point 1 & 2 (which I presume are about the same thing, I can’t read the language in the map image). . . point 2 looks like my log, ad nauseum. I thought those messages were about each device that checks in and then logs off. The 5 digits after the IP address identify a particular device. Note the fine print lower right, for the bulb below. That decimal format net.address also shown in the IEEE address column of the Z2M devices listing.

Screenshot 2025-10-22 at 9.32.45 AM
Screenshot 2025-10-22 at 9.32.45 AM1334×780 76.1 KB

If point 1 was about not having a link from a device to a router or the coordinator, that can take some time to resolve (no route doesn’t mean it’s disconnected).

About the automation, I haven’t had such issues with Innr or Hue bulbs. Looking through the settings for a device, I don’t understand it all (yet?). But one thing that stuck out was “state action”.

Screenshot 2025-10-22 at 9.40.40 AM
Screenshot 2025-10-22 at 9.40.40 AM2732×780 136 KB

If I were banging my head similarly, I’d enable that on the light bulb to see if it makes a difference for the automation. Meanwhile I hope someone with knowledge of that Z2m option would pass by and comment.

4

That is supervisor, nothing to worry about.

5

Every two minutes? Quite an amount of log spam…

Do you have an idea about why my network graph is in two parts?

6

Good idea, but setting this to true did not change anything. Just tried it.

7

Device sleeping at that moment ? I regularly have devices that are not connected, but as long as they work, I don’t care.

afbeelding
afbeelding1396×1048 256 KB

2 Likes
8

These are mains-powered leds. I don’t think they would go to sleep?

9

You can always re-run the map and see if it is connected now

10

Just did, still the same. Also, I have one light which apparently only wants to connect directly to the coordinator, not another router. Is that possible, or something else broken there? The problematic bulb identifies as TS0505B_1_1

11

I think, I understand now, why the network map seems to be disjoint. In the legend, it states “Only highest-rated siblings are shown, which should roughly match the actual connections of the network.”

Therefore, not all the mesh connections are depicted, but only one per device which makes it look so sparse. In the data view, I can see that the devices can actually see each other.

@francisp in your network map the connections look much more dense though. How did you create that map?