I don’t know that the comment about worse performance is proven or warranted. The multi-pan setup turns the radio into a dumb stick, that just passes tagged spinel messages to and from to the host where they are directed with the CPC daemon to Zigbeed or OTBR. Zigbeed is the NCP app running on the host, which is usually more powerful with more resources than the radio. Zigbeed is configured with pretty high capabilities by default. the real limitation is that the host has to be ARM.
See comments by grobasoz and agners here → https://github.com/grobasoz/zigbee-firmware/issues/27
grobasoz comment: “Now to the big issue I have with Multiprotocol - and my personal opinion only. A “normal” Zigbee Coordinator on a “significant” network (ie 100+ devices) actually spends quite a bit of radio time managing the network, let alone handling the device messaging.”
agners reply: “Agreed, I think the multiprotocol solution might not be for large networks. A person with that many devices, likely will have multiple coordinator/border router capable 802.15.4 radios in the house already 
It is mainly a good solution for new users: People don’t have to choose between Thread and Zigbee at the start, they can mix and match. For power users Thread and Zigbee networks on separate channels definitely make sense (along with dedicated radios). That said, I like the concept of having a rather dumb radio and most of the protocol on the host. So it still might make sense to have the (Multi-)PAN firmware running along with zigbeed on the host. We’ll see how well that works in practice.”
the take away from that to me, is just run RPC, with only zigpeed, no thread 
1 Like
Yes, or just use 2 adapters and run RPC on both but run only zigpeed via one and Thread via the other.
Hey Tube,
I have your EFR32 coordinator working well. Recently installed some mercator zigbee GPOs and am having an issue with uncommanded power offs at random times. Sometimes nothing for weeks but sometimes several a day where both outlets on a GPO switch off. Generally it affects only one of the GPOs at a time.
I am trying to troubleshoot but not sure where to start.
I do not believe it is your devices fault at all but would appreciate some assistance in determining the issue.
I am logging these:
homeassistant.components.zha: debug
bellows: debug
zigpy: debug
zigpy_znp: debug
zhaquirks: debug
I believe I have a 2 minute log section in which one of the GPOs turned off but nothing stands out in the log at all Just things like this:
2022-08-20 05:49:31.672 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 128 (incomingRouteErrorHandler) received: b'aab28c'
2022-08-20 05:49:31.672 DEBUG (MainThread) [bellows.zigbee.application] Received incomingRouteErrorHandler frame with [<EmberStatus.MANY_TO_ONE_ROUTE_FAILURE: 170>, 0x8cb2]
2022-08-20 05:49:31.672 DEBUG (MainThread) [bellows.zigbee.application] Processing route error: status=EmberStatus.MANY_TO_ONE_ROUTE_FAILURE, nwk=0x8cb2
If it matters the device is shown as this in zha:
IEEE: 84:unsure if sensitive
Nwk: 0x8cb2
Device Type: Router
LQI: 224
RSSI: -44
Last Seen: 2022-08-26T15:49:48
Power Source: Mains
Quirk: zhaquirks.tuya.ts011f_plug.Plug_TZ3210_2AC
Is there any chance you have these GPO devices exposed to Amazon Alexa? Alexa has a feature called “Hunches” that very often causes issues like this. Hunches can be disabled easily in the Alexa App settings section.
with debug logging on, you should see a command to turn the device on/off being sent if HA/ZHA is sending the command. If not there, then the device is doing this on its own.
No Amazon connections.
Thanks Tube, let’s assume there’s no commands causing it. Any other things it might be, overloaded network or some other glitch that could trigger a device to turn off?
1 Like
I’ve had a bulb randomly come on before with no indication of why, I think it’s just device FW issues.
Anyone using ZHA should update to the newest 2022.8.7 release. It includes a fix that will substantially decrease disk writes to the zigbee.db database.
If on a Network EFR32 it also switched the tcp connection and results in much faster serial connects:
2 Likes
I suspect firmware too but i have to buy their hub if i am to be able to update. Need linus tech tips to get involved 
Today my gpo turned off at 13:15:41 according to home assistant logs and history. I searched for “off” in the log and this is all i see. I think it’s just s status report which makes sense, but it doesnt reveal why it went off.
2022-08-27 13:15:40.830 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'000401040b0101400100004890c0b28cffff08186c0a050521f90002'
2022-08-27 13:15:40.831 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=2820, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=72), 144, -64, 0x8cb2, 255, 255, b'\x18l\n\x05\x05!\xf9\x00']
2022-08-27 13:15:40.831 DEBUG (MainThread) [zigpy.zcl] [0x8CB2:1:0x0b04] Received ZCL frame: b'\x18l\n\x05\x05!\xf9\x00'
2022-08-27 13:15:40.832 DEBUG (MainThread) [zigpy.zcl] [0x8CB2:1:0x0b04] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True, *is_reply=True), tsn=108, command_id=10, *direction=<Direction.Client_to_Server: 1>, *is_reply=True)
2022-08-27 13:15:40.832 DEBUG (MainThread) [zigpy.zcl] [0x8CB2:1:0x0b04] Decoded ZCL frame: TuyaZBElectricalMeasurement:Report_Attributes(attribute_reports=[Attribute(attrid=0x0505, value=TypeValue(type=uint16_t, value=249))])
2022-08-27 13:15:40.833 DEBUG (MainThread) [zigpy.zcl] [0x8CB2:1:0x0b04] Received command 0x0A (TSN 108): Report_Attributes(attribute_reports=[Attribute(attrid=0x0505, value=TypeValue(type=uint16_t, value=249))])
2022-08-27 13:15:40.833 DEBUG (MainThread) [zigpy.zcl] [0x8CB2:1:0x0b04] Attribute report received: rms_voltage=249
2022-08-27 13:15:40.852 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xDCEF](TS0011): Device seen - marking the device available and resetting counter
2022-08-27 13:15:40.852 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xDCEF](TS0011): Update device availability - device available: True - new availability: True - changed: False
2022-08-27 13:15:41.162 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'33fbb1a9112a15b658924a24ab1592499c1fb36a9d0c9874fade6283fc7e2fa7ef62a27e'
2022-08-27 13:15:41.163 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8430fc7e'
2022-08-27 13:15:41.164 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'00040106000101400000005194c170c2ffff0718010a0000100004'
2022-08-27 13:15:41.166 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_RETRY: 64>, groupId=0, sequence=81), 148, -63, 0xc270, 255, 255, b'\x18\x01\n\x00\x00\x10\x00']
2022-08-27 13:15:41.167 DEBUG (MainThread) [zigpy.zcl] [0xC270:1:0x0006] Received ZCL frame: b'\x18\x01\n\x00\x00\x10\x00'
2022-08-27 13:15:41.168 DEBUG (MainThread) [zigpy.zcl] [0xC270:1:0x0006] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True, *is_reply=True), tsn=1, command_id=10, *direction=<Direction.Client_to_Server: 1>, *is_reply=True)
2022-08-27 13:15:41.171 DEBUG (MainThread) [zigpy.zcl] [0xC270:1:0x0006] Decoded ZCL frame: OnOff:Report_Attributes(attribute_reports=[Attribute(attrid=0x0000, value=TypeValue(type=Bool, value=<Bool.false: 0>))])
2022-08-27 13:15:41.171 DEBUG (MainThread) [zigpy.zcl] [0xC270:1:0x0006] Received command 0x0A (TSN 1): Report_Attributes(attribute_reports=[Attribute(attrid=0x0000, value=TypeValue(type=Bool, value=<Bool.false: 0>))])
2022-08-27 13:15:41.172 DEBUG (MainThread) [zigpy.zcl] [0xC270:1:0x0006] Attribute report received: on_off=<Bool.false: 0>
2022-08-27 13:15:41.227 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'43fbb1a9112a15b658904124ab5592499c01bf699d0c9874e8de1388f77b3f8eebcdd66a8fdec7dbd0d769ad4623ad8aef7e'
2022-08-27 13:15:41.228 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8520dd7e'
yeah, it sucks. you can check here for any FW, I believe ZHA_Toolkit HACs integration just added a way to reference this and check but I haven’t had a chance to try it yet.
Just got my new coordinator - the look and feel of which are great! - will appreciate some help.
The coordinator is the CC2652 Ethernet/USB V2 type.
Since I could not get the version with WT32-ETH01 preassembled I got it separately and it’s fitted nice and cozy inside.
I’m running latest HA and ESPHome versions.
ESPHome FW flashing is not working for me (jumpers are set to ESP32 flash mode).
I got this FW: tube-zb-gw-cc2652p2-v2_2021_09_17.bin and tried to flash it with the recommended tool, but it fails with:
Connecting...
Chip Info:
- Chip Family: ESP32
- Chip Model: ESP32-D0WD (revision 1)
- Number of Cores: 2
- Max CPU Frequency: 240MHz
- Has Bluetooth: YES
- Has Embedded Flash: NO
- Has Factory-Calibrated ADC: YES
- MAC Address: 0C:B8:15:4C:D7:C4
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
- Flash Size: 4MB
Unexpected error: The firmware binary is invalid (magic byte=0A, should be E9)
So I tried taking the configuration given in this file: https://github.com/tube0013/tube_gateways/blob/efabbeaf09d3efdff894a6cd42d0eb54e53ac078/models/current/tubeszb-cc2652-eth_usb/firmware/esphome/source/tube_zb_gw_cc2652p2v2.yml
and flashing it with ESPHome itself, but this config fails validation with
Failed config
external_components: [source /config/esphome/zigbee-over-tcp.yaml:9]
- [source /config/esphome/zigbee-over-tcp.yaml:9]
Source is not a file system path, in expected github://username/name[@branch-or-tag] or github://pr#1234 format!.
source: my_components [source /config/esphome/zigbee-over-tcp.yaml:9]
Trying to remove external_components produces an error on not recognizing zeroconf component.
I could really use a push in the right direction!
Thanks.
I uploaded a zip of the bin file to github (same folder as the bin), try that, looks like the bin didn’t download correctly.
current ESPHome versions make the serial connection flakey so it’s complicated to go the route of self compilation.
Thanks, that worked like a charm.
Very much appreciated.
If you signed up on the waiting list for a PoE Coordinator recently, please check your email/spam, I sent an update out yesterday. I’d like to honor the people who are on the waiting list before listing stock in the main site.
1 Like
Hello @tube0013
I am in over my skis a little and hoping you might be able to help
I recently purchased your POE coordinator and am now a bit stuck on where to go next having plugged it in and seen it recognises in HA as an ESP device
My setup involves ZHA running with a Sonoff stick on my Intel Nuc. This all sits in a server cupboard in the centre of my house and has built a nice stable mesh.
My HA instance and home network tend to my home office which is some 50m away from the house and all connected via cat 7 with plenty of ports at either end.
My thinking was that I could introduce the coordinator via Ethernet into my ZHA network and it would effectively extend my ZHA reach into the office. Currently I am running a separate Sonoff Ziggee bridge just for the office which is not optimal.
I’m struggling to work out how to achieve this using your excellent piece of hardware - would be kind enough as to point me in the right direction ?
Many thanks
Zigbee doesn’t work this way. There is only one coordinator per network.
What you could do is use z2m as a second network at the out building.
Thankyou
So I could connect your coordinator at the outbuilding via Ethernet and install Z2M on the HA machine back at base ?
Out of interest is it impossible to achieve what i first suggested using your router/extender too ? I am guessing yes as it involves the zigbee mesh needing to have a point of linkage
Thanks v much for the reply
Yes.
A zigbee router routes wirelessly over the mesh. There isn’t anything to extend a zigbee mesh via a wired connection analagous to adding a wifi access point.
If there is a good midway point, you could possibly place a router device between the two buildings to extend the mesh. Some have even set up directional antennas to help. Not worth the headache of trial and error IMO, unless you enjoy the challenge of a new project.
Depending on the number and type of devices needed for the outbuilding, wifi devices could be less trouble than adding z2m, assuming you already have an access point set up.
1 Like