Large Zigbee Network Experiences

One thing that I did notice, is that when the switch would change from 0.2 watts to 2.1 watts of use every 15 seconds or so it would report power back to the zigbee network. Not that bad when you have a few switches, but it gets a bit much when you are over 100 switches in the same network. So I changed the reporting structure for those switches. Here is a bit of code I used to generate a MQTT message to send to the reporting topic for the bridge to adjust the settings. Use at your own risk. I fed this code the devices from the Zigbee network. I also utilized a delay to only process one of these every 5 seconds until complete. I could be wrong on the calculation, but I thought 10 was .1W so 100 is 1W and 1000 is 10W. So I should only get reporting when the difference is 10 Watts or more now. Really calmed down the amount of messages on the network, and power reporting was not something I need overall.

// Check if msg.payload is already an object or a string
let data;
if (typeof msg.payload === "string") {
    // Parse it if it's a string
    try {
        data = JSON.parse(msg.payload);
    } catch (e) {
        // Handle any parsing errors
        node.error("Error parsing JSON: " + e.message);
        return null;
    }
} else if (typeof msg.payload === "object") {
    // Use it directly if it's already an object
    data = msg.payload;
} else {
    // Handle unexpected payload types
    node.error("Unexpected payload type");
    return null;
}
// Specify the model you are looking for
let targetModel = "VZM31-SN"; // Replace with your desired model

// Check if the model matches
if (data.definition && data.definition.model === targetModel) {
    // Extract the friendly name
    let deviceFriendlyName = data.friendly_name;

    // Set the friendly name in the payload
    let newPayload = {
        id: deviceFriendlyName,
        cluster: "haElectricalMeasurement",
        attribute: "activePower",
        minimum_report_interval: 15,
        maximum_report_interval: 3600,
        reportable_change: 1000
    };
    msg.payload = newPayload;
    return msg;
} else {
    // If the model does not match, return null or handle as needed
    return null;
}

Oh, and this is for Node-Red where I do most of my work.

The latest firmware for the P model (CC2652P) supports 50 direct routes. Not sure on the E model.

At 272 devices and when I do an update the adapter disconnects in Z2M. It is getting a crazy amount of messages during the update process. So not sure what the issue is. Network is still stable and working as long as I don’t try to update a device. Will continue to troubleshoot this one.

For now that seems to be the top for me. 272 and it started to have more issues with updating and joining. So splitting into two networks of about 200 devices and should be completely solid. Will mark this as the solution for now.

1 Like

200 seems to be the accepted number as the current max for Zigbee 3.0 devices with Zigbee 3.0 coordinators. See Zigbee networks: how to guide for avoiding interference and optimize for getting better range + coverage - #55 by Hedda - Community Guides - Home Assistant Community

It’s interesting that you made it to 272. Were any of those older devices?

2 Likes

All devices were mains powered routers and they were all running the latest firmware from Hue/Signify or Inovelli. Network remained functional and I think had I not needed to update it would have continued to be solid. The update caused lots of messages to the coordinator that seemed excessive. I think routes had not fully settled down and had I waited 24-48 hours before updating it would have been fine, but still good to split at this point.

I was hoping the Conbee3 would have worked as it is supposed to be able to handle 500 devices directly, but that is still a disaster in Z2M and I am heavily invested in MQTT for device control with Node-Red and do not want to move to Phoscon and recreate device drivers for all my things that they do not yet support. So two Sonoff Zigbee E dongles with 7.4.0 Zigbee firmware it is for now. Running channels 25 and 26 and splitting the house in half. Front yard plus one side. Back yard and the other side.

The layout almost forms a yin and yang design with the coordinators hanging in the middle.

2 Likes

Ah that facepalm moment has happened. I knew I should have mapped to the full device id path instead of using dev/ttyACM0 and dev/ttyACM1. Was updating both adapters and plugged them in the wrong order and started Z2M. Of course I was not done with all my changes and did not backup…and now the networks are still there, but the coordinators do not know about the devices/groups/binding etc…

Oh well, guess I am becoming more of an expert via trial by fire with every day. :slight_smile:

Going to give the SkyConnect a go as well. With the Sonoff devices I have to restart after every 10 or so joins as the devices start joining and then leaving the network. Tried multiple firmwares and version of Z2M. Will report back on the SkyConnect experience later.

If you are looking to experiment with different options I’d suggest giving TubeZB a shot. Don’t have to worry about mapping by device-id, can place centrally and all powered by POE. I feel your pain by the way. Out of curiousity whats your HA setup? HAOS, docker, etc?

1 Like

I run Stacks on Portainer on an Intel NUC. So Docker Compose in essence. Core setup is 2 Docker containers for Z2M (with USB devices now mapped by ID :wink: ), one EMQX Docker for my MQTT server, Shelly devices connected to MQTT for blinds/pool control/rgbw led lights, Node-Red 18 Docker where I use NRCHKB to build out all my devices for Apple HomeKit as well as build out all my automation/circadian lighting/etc… and a small Home Assistant docker for a few devices that are not conducive to Node-Red work natively. I try to do almost everything via MQTT commands for speed and efficiency.

So far everything is coming together nicely. I already had the SkyConnect in hand. 92 devices up and running from about.2 hours of work and it looks solid as well. I like the EZSP devices with 7.4.0 firmware. Seems to be really good.

1 Like

SkyConnect with Z2M? Thats a tad of a risk, no? Z2M uses experimental due to the chip that the sky uses… (Dont quote me on that lol)

It’s the EFR32 chipset, same as what he was using on the sonoff dongle. Just FYI, TubeZB also puts out EFR32 coordinators. I know I sound like a walking advertisement but he really makes great devices with awesome support.

Would love to know how to get the 7.4.0 firmware for one of those PoE devices. Looks like I would need to compile my own version. Not the end of the world, but would be nice if they had it somewhere easy to pull from. Just want to make sure before I venture to another coordinator. :rofl:

@tube any idea on when 7.4.0 will be available on git hub for the EFR32 chipset?

@tube any chance I could get an adapter based upon MGM240? :smile:

I had one on my silicon Labs fw builder repo, but I think the Artifacts expired. Anyway it’s building now, let me flash a device to make sure it works.

1 Like

Soon

I’ve been running one for a while now on my own network, I only have a few more MGM21 modules and will likely move to the MGM24 once those are gone.

I know. I just bought your last two. So I guess you can get some MGM24s now and I can get those. :slight_smile:

I’m looking at rebuilding my whole Zigbee mesh soon (Remember those Juno CCT tunable wafers… I’m told there’s a firmware update coming that will finally make them functional)…, If rebuilding from scratch, I’d be in for the MGM24 version of the POE coordinator. (Have the MGM21 running Z2MQTT, and a Sonos -P running ZHA. -Along with a separate Smartthings hub (I dislike very much)

Would love to get them all on one single mesh, maxing out at around 150 devices. -so no, not a cool as CScott…