Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
11.75k stars 1.64k forks source link

Running on Z-Stack 3.0 #211

Closed kirovilya closed 5 years ago

kirovilya commented 6 years ago

I tried running zigbee-shepherd on the Z-stack 3.0. I built the firmware with Z-stack 3.0, then flash it to cc2531 stick.

By default, it does not start.

It was necessary to substitute on fork of cc-znp from HalleyAssist (thank you @splitice) and to little correct a zigbee-shepherd. After that, it was successfully launched and even worked a little.

I tried to connect a xiaomi temperature sensor - successfully connected and sent data. But with the round button it did not work out that way - it could not connect correctly and as a result did not work.

Do you think it makes sense to move towards Z-stack 3.0? What will it give to us? Stable? Touchlink? More devices?

splitice commented 6 years ago

FYI we only run Z-Stack 3.0 these days and can confirm that our fork of ZS works fine.

If you are using our cc-znp you also need to use our zigbee-shepherd or copy over the changes to binding cc-znp since we changed the interface to make it possible to close and restart ZS (e.g for firmware updates)

kirovilya commented 6 years ago

@splitice Thank you for the clarification. What improvements have you got with the Z-stack 3.0?

tb-killa commented 6 years ago

@kirovilya See here: fully compliant ZigBee 3.0 solution: Z-Stack 3.0

Especially: Supports the CC2592 and CC2590 RF front ends which extend up to +22dBm and +14dBm transmit power, respectively, and provide improved receiver sensitivity

Supports Green Power Proxy, allowing energy-harvesting and ultra-low power devices to connect seamlessly to a Zigbee network

splitice commented 6 years ago

We did it for:

tb-killa commented 6 years ago

Are we planning to switch to this version?

Koenkk commented 6 years ago

Yes! When I have some more time I will look into this.

dzungpv commented 6 years ago

Z-stack 3 ZNP has more advance, you can increase NWK_MAX_DEVICE_LIST to 120 without any problem. Now with ZNP Z-stack home 1.2.2, NWK_MAX_DEVICE_LIST 15 is the max i could build

Koenkk commented 6 years ago

@dzungpv that sounds great!

dzungpv commented 6 years ago

@Koenkk This man can do 660 devices: https://sunmaysky.blogspot.com/2018/07/400-zigbee-devices-in-same-zigbee_29.html

kirovilya commented 6 years ago

This man can do 660 devices:

Wow!!! One question: HOW?! :)

dzungpv commented 6 years ago

@kirovilya I am sure he not use ZStack HA 1.2.2, he is an expert on TI forum: YiKai Chen. You can always ask and he will answer you. I have ask him some hundreds question.

kirovilya commented 6 years ago

@dzungpv Understandably. Since this is not a ZNP-firmware (ZStack HA), there are no questions yet :)

ben423423n32j14e commented 6 years ago

I think Touchlink will be extremely valuable as it could allow a way for resetting Hue Lightstrips without a Hue Bridge or the dimmer?

lolorc commented 6 years ago

I'm looking forward to use Z-stack 3, can zigbee-sheperd/cc-znp forks from @Koenkk be simply replaced by @splitice ones ? IOW, has more progress been done in that way ? I'm struggling with all these zigbeer forks ;-)

Koenkk commented 6 years ago

@lolorc I will start working on this once I finished moving to a new place (will have more time then :smile:)

splitice commented 6 years ago

Our fork works with Z-Stack 3.0, you should be able to just use our ZS fork. We believe it to be API compatible.

lolorc commented 6 years ago

so many zigbee-sheperd divergent forks... I guess the changes that have been made for zigbee2mqtt to zigbee-sherperd and cc-znp shoud be merged/rebased against HalleyAssists

@splitice what are you using your zigbee-sheperd fork for ? It might be easier for me to try z-stack 3.0 with it.

hdo commented 5 years ago

@splitice Can you tell us where to find your fork with Z-Stack 3.0 support? Thanks.

EDIT: My bad for not paying attention. I found your fork at HalleyAssist ;-)

splitice commented 5 years ago

Fork is here: https://github.com/HalleyAssist/zigbee-shepherd

FYI we run CC2538+92 hardware which is required for some of the added APIs (increased processing power). Not that it should impact you too much as our firmware with these added MT commands is not currently released. Also be aware Z-Stack 3.0 is heavier than 1.2.

hdo commented 5 years ago

@splitice

Hey thanks. Just noticed that :-)

Do you also offer precompiled firmware for the CC2530 or do i need to compile it from source (TI Z-Stack 3.0 Source).

I don't have the CC2538+98 hardware so hope that it will also run with my CC2530.

Fork is here: https://github.com/HalleyAssist/zigbee-shepherd

FYI we run CC2538+92 hardware which is required for some of the added APIs (increased processing power). Not that it should impact you too much as our firmware with these added MT commands is not currently released. Also be aware Z-Stack 3.0 is heavier than 1.2.

splitice commented 5 years ago

You will need to take care of that yourself. We neither use that hardware nor have the IAR licence to do that for you.

hdo commented 5 years ago

Ok, thanks. I'll try that myself ;-)

You will need to take care of that yourself. We neither use that hardware nor have the IAR licence to do that for you.

ryanbeaton commented 5 years ago

Hi @splitice Do you plan on releasing the CC2538+92 firmware?

Sent with GitHawk

splitice commented 5 years ago

It's a possibility in the future. But for now we have other priorities.

basmeerman commented 5 years ago

Anyone a CC2531 Z-stack 3.0x firmware available? If not where can I find instructions/sources? (it's sort of step 1 in the process of getting the 3.0 compatible version of Zigbee-Sheppard working, whereafter to merge/backport Zigbee2Mqtt to that version)

Koenkk commented 5 years ago

@kirovilya which firmware did you use? For me the pairing process is broken with 3.0

kirovilya commented 5 years ago

@Koenkk As I wrote above - I downloaded Z-STACK 3.0 and builded the ZNP firmware as you described https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/CC2531 I also could not pair some devices (read first post).

tb-killa commented 5 years ago

@splitice would you please share your Defined symbols" list from Preprocessor configuration? I will port them over.

maciejsszmigiero commented 5 years ago

FYI: I am currently running Z-STACK 3.0.2 on GBAN GB-RFTOUSB devices with zigbee2mqtt, both in the concentrator and the router mode, although I'm using Z-Tool instead of zigbee-shepherd for their initial configuration.

Wrote an instruction about it here: https://github.com/maciejsszmigiero/wiki/wiki/GB-RFTOUSB-Z-Stack

Koenkk commented 5 years ago

@maciejsszmigiero thanks for sharing, did you saw any noticeable improvements?

maciejsszmigiero commented 5 years ago

@maciejsszmigiero thanks for sharing, did you saw any noticeable improvements?

Can't really tell since I haven't used older Z-STACK releases, but TI says that:

TI recommends using the newest release in order to take advantages of all improvements and new features.

HKC001 commented 5 years ago

@maciejsszmigiero Thanks a lot for this! I have 3 GBAN devices and think your solution will finally solve my 40 device network issues. Would you mind answering a few questions to help me along?

  1. How many devices are linked to your coordinator, and how many to your router?
  2. Could you explain how you applied znp.patch, line 2 of your instructions? I'm rather new to this.
  3. The Upgrading device's firmware while keeping its configuration is not needed if you're building up a network from scratch, correct?
  4. Is Configuring a new device mandatory, or can I just plug and play like into a Pi + zigbee2mqtt setup like when compiling ZHA 1.2.2a?
  5. Same as above, does ZDO -> ZDO_STARTUP_FROM_APP in Operating the ZigBee stack have to be applied everytime the USB stick loses power, or does zigbee2mqtt take care of that?
  6. Are you running Hass.IO? If so, how did you apply the patch in Using a concentrator device with a zigbee-shepherd..., and get it to not reset with every Hass.IO reset?
HKC001 commented 5 years ago

@Koenkk @kirovilya Would you guys be interested in creating coordinator and router firmware for the CC2538 + CC2592? I'll buy a few devices and ship it to you guys, free of charge.

This option looks good to me. The price is 30% more expensive than the GBAN CC2530 + RF, but if we can get 3.02 working, that means one coordinator to cover a small flat / house with a good signal. It also has micro-USB built in, potentially making it an easy 'pro' version of zigbee2mqtt's recommended coordinator if the CC2531 is too weak.

Why am I making this offer? I already invested in 40 devices for my home. And getting them to work on 1.2.2a is killing me. I want my toilet lights to work properly when I'm taking a sh*t, dammit.

kirovilya commented 5 years ago

:) Thanks for the offer. I have one board with cc2538 (without cc2592) lying around, but for it I need to build a special firmware and I haven’t even flashed it yet. cc2538 + cc2592 is an even more specific combination. I think you better attention to the network structure (routers + end devices) than to change coordinator.

Already, my friends are operating 34 devices through a stick cc2531 (HA 1.2.2) And thanks to the patches suggested above, we can try to run a z-stack 3 on this chip.

Even now there are problems with the operation of some devices that will not disappear with the change of the coordinator chip. We need to change the firmware and the logic of working with it (zigbee-shepherd) ... Or look in the direction of other solutions (deConz)

HKC001 commented 5 years ago

@kirovilya Thanks for the advice. My home is not big but has solid brick walls and probably a lot of internal wiring. There's also 20+ WiFi signals from the neighbours. CC2531 has very poor coverage, and CC2530 + RF has the coverage but I'm struggling with the device limitations. Hope you guys can get 3.02 working soon.

For the devices that won't disappear, I was testing another issue and found the problem is probably with MosquittoMQTT to zigbee2mqtt communication. Removing devices via /bridge/remove, even combined with reflashing the coordinator and deleting everything in \\HASSIO\share\zigbee2mqtt, still leaves the entities in Mosquitto. I have to delete Mosquitto, restart Hass.io and reinstall Mosquitto for the entities to go away.

ptvoinfo commented 5 years ago

@HKC001 Do you need Z-Stack v3? Z-Stack 1.2.2 can be compiled for CC2538 too. But Z-Stack 1.2.2 is tested already with many devices.

maciejsszmigiero commented 5 years ago

@HKC001: The network concentrator also serves as the network Trust Center so it has to keep records of all the devices in the network, even these currently joined to a router.

How many devices are linked to your coordinator, and how many to your router?

I am currently using a network of about a dozen devices, including one joined via a router. Please have a look at the caveats in the Using more than 22 devices in a network section of my Wiki article.

Could you explain how you applied znp.patch, line 2 of your instructions? I'm rather new to this.

You have to use the GNU patch utility, for example the one installed with Git for Windows. Then you enter the directory where you had the Z-Stack installed and issue a command like:

patch -p1 --dry-run <znp.patch

And if this "dry run" finishes without issues you do it again, this time for real by issuing the above command without the --dry-run option.

The Upgrading device's firmware while keeping its configuration is not needed if you're building up a network from scratch, correct?

That's correct. In this case the concentrator will also select the best radio channel for the new network by scanning the whole 2.4 GHz band.

Is Configuring a new device mandatory, or can I just plug and play like into a Pi + zigbee2mqtt setup like when compiling ZHA 1.2.2a?

As far as I can remember zigbee-shepherd based software (like zigbee2mqtt) isn't currently able to configure Z-Stack 3.0-based device correctly.

Same as above, does ZDO -> ZDO_STARTUP_FROM_APP in Operating the ZigBee stack have to be applied everytime the USB stick loses power, or does zigbee2mqtt take care of that?

zigbee-shepherd based software issues ZDO_STARTUP_FROM_APP command on its own during startup, so you don't need to do it manually.

Are you running Hass.IO?

No.

HKC001 commented 5 years ago

@ptvoinfo I thought of using v3 because it supports more devices by default. During my own tests, 32 devices directly connected to a CC2530 + RF in concentrator mode had better perfomance (less lag and no dropouts). When I added 2 CC2531 routers to the mix and paired some devices directly to the router, performance dropped noticeably.

@maciejsszmigiero Thanks a lot!

ptvoinfo commented 5 years ago

@HKC001 I think, the limit of connected devices depends on the limited memory size of CC2530/31. CC2538 has more memory and therefore allows you to add more devices.

maciejsszmigiero commented 5 years ago

@ptvoinfo:

CC2538 has more memory and therefore allows you to add more devices.

CC2538 is a 32-bit ARM µC so every pointer there takes at least twice the memory than on CC253[01], not mentioning that the whole µC core is much more complex, so I assume operating it will need keeping more data which in turn will take even more RAM. That's why any gain in number of supported devices could be significantly less than the 4x that simple RAM sizes comparison would suggest.

TI suggests CC2652R or CC1352P for "networks containing a large number of nodes" in their SWRA635 white paper, but I don't know if there are some ready and low-cost devices using them.

lolorc commented 5 years ago

@maciejsszmigiero ever tried to run zigbee-sheperd from HalleyAssist ? it should be z-stack 3.0 ready as far as I've read

maciejsszmigiero commented 5 years ago

@maciejsszmigiero ever tried to run zigbee-sheperd from HalleyAssist ?

No, but a quick peek at it suggests it also reconfigures the connected device with hardcoded parameters on startup - assuming you mean the zigbee-sheperd from https://github.com/HalleyAssist/zigbee-shepherd.

HKC001 commented 5 years ago

@maciejsszmigiero When compiling with default settings, I'm getting the following errors. Is this normal?

Warning[Pe111]: statement is unreachable C:\Texas Instruments\Z-Stack 3.0.2\Components\hal\common\hal_assert.c 87 
Warning[Pe128]: loop is not reachable C:\Texas Instruments\Z-Stack 3.0.2\Components\hal\common\hal_assert.c 245 
Warning[Pe047]: incompatible redefinition of macro "GPIO_DIR_IN" (declared at line 180 of "C:\Texas  C:\Texas Instruments\Z-Stack 3.0.2\Components\mt\MT_SYS.c 96 
Instruments\Z-Stack 3.0.2\Projects\zstack\ZNP\CC253x\..\..\..\..\Components\hal\target\CC2530ZNP\ 
hal_board_cfg.h") 
Warning[Pe047]: incompatible redefinition of macro "GPIO_DIR_OUT" (declared at line 181 of "C:\Texas  C:\Texas Instruments\Z-Stack 3.0.2\Components\mt\MT_SYS.c 97 
Instruments\Z-Stack 3.0.2\Projects\zstack\ZNP\CC253x\..\..\..\..\Components\hal\target\CC2530ZNP\ 
hal_board_cfg.h") 
Warning[Pe047]: incompatible redefinition of macro "GPIO_TRI" (declared at line 182 of "C:\Texas Instruments\ C:\Texas Instruments\Z-Stack 3.0.2\Components\mt\MT_SYS.c 98 
Z-Stack 3.0.2\Projects\zstack\ZNP\CC253x\..\..\..\..\Components\hal\target\CC2530ZNP\hal_board_cfg.h") 
Warning[Pe047]: incompatible redefinition of macro "GPIO_PULL_UP" (declared at line 183 of "C:\Texas  C:\Texas Instruments\Z-Stack 3.0.2\Components\mt\MT_SYS.c 99 
Instruments\Z-Stack 3.0.2\Projects\zstack\ZNP\CC253x\..\..\..\..\Components\hal\target\CC2530ZNP\ 
hal_board_cfg.h") 
Warning[Pe047]: incompatible redefinition of macro "GPIO_PULL_DN" (declared at line 184 of "C:\Texas  C:\Texas Instruments\Z-Stack 3.0.2\Components\mt\MT_SYS.c 100 
Instruments\Z-Stack 3.0.2\Projects\zstack\ZNP\CC253x\..\..\..\..\Components\hal\target\CC2530ZNP\ 
hal_board_cfg.h") 
Warning[Pe047]: incompatible redefinition of macro "GPIO_SET" (declared at line 185 of "C:\Texas Instruments\ C:\Texas Instruments\Z-Stack 3.0.2\Components\mt\MT_SYS.c 101 
Z-Stack 3.0.2\Projects\zstack\ZNP\CC253x\..\..\..\..\Components\hal\target\CC2530ZNP\hal_board_cfg.h") 
Warning[Pe047]: incompatible redefinition of macro "GPIO_CLR" (declared at line 186 of "C:\Texas Instruments\ C:\Texas Instruments\Z-Stack 3.0.2\Components\mt\MT_SYS.c 102 
Z-Stack 3.0.2\Projects\zstack\ZNP\CC253x\..\..\..\..\Components\hal\target\CC2530ZNP\hal_board_cfg.h") 
Warning[Pe047]: incompatible redefinition of macro "GPIO_TOG" (declared at line 187 of "C:\Texas Instruments\ C:\Texas Instruments\Z-Stack 3.0.2\Components\mt\MT_SYS.c 103 
Z-Stack 3.0.2\Projects\zstack\ZNP\CC253x\..\..\..\..\Components\hal\target\CC2530ZNP\hal_board_cfg.h") 
Warning[Pe047]: incompatible redefinition of macro "GPIO_GET" (declared at line 188 of "C:\Texas Instruments\ C:\Texas Instruments\Z-Stack 3.0.2\Components\mt\MT_SYS.c 104 
Z-Stack 3.0.2\Projects\zstack\ZNP\CC253x\..\..\..\..\Components\hal\target\CC2530ZNP\hal_board_cfg.h") 
Warning[Pe047]: incompatible redefinition of macro "GPIO_HiD_SET" (declared at line 189 of "C:\Texas  C:\Texas Instruments\Z-Stack 3.0.2\Components\mt\MT_SYS.c 105 
Instruments\Z-Stack 3.0.2\Projects\zstack\ZNP\CC253x\..\..\..\..\Components\hal\target\CC2530ZNP\ 
hal_board_cfg.h") 
Warning[Pe047]: incompatible redefinition of macro "GPIO_HiD_CLR" (declared at line 190 of "C:\Texas  C:\Texas Instruments\Z-Stack 3.0.2\Components\mt\MT_SYS.c 106 
Instruments\Z-Stack 3.0.2\Projects\zstack\ZNP\CC253x\..\..\..\..\Components\hal\target\CC2530ZNP\ 
hal_board_cfg.h") 
Warning[Pe188]: enumerated type mixed with another type C:\Texas Instruments\Z-Stack 3.0.2\Projects\zstack\ZNP\Source\znp_app.c 411 
HKC001 commented 5 years ago

@maciejsszmigiero How did you get Z-Tool working with GB RFTOUSB? I keep getting devices not found, even though the device showed up in SmartRF, and firmware was flashed successfully. After flashing, I've tried connecting the stick:

  1. Directly to PC USB only.
  2. Via the debugger only.
  3. With both PC USB and debugger simultaneously.
maciejsszmigiero commented 5 years ago

@HKC001:

@maciejsszmigiero When compiling with default settings, I'm getting the following errors. Is this normal?

These are warnings, not errors. Yes, they are expected.

How did you get Z-Tool working with GB RFTOUSB?

Disconnect the CC debugger from the device when trying to start it up (just disconnecting the CC debugger USB cable from the PC might not be enough).

Make sure that the GBAN serial port ("COM port") is detected by the Z-Tool. Make sure that this serial port baudrate is set to 115200 bps, 8-N-1 mode in the Z-Tool. Then force a serial port rescan in the Z-Tool.

If the Z-Tool sees the serial port, has it configured with the proper settings but still can't communicate with the Z Stack on device it means that likely either:

King-anderson commented 5 years ago

I flashed a CC2530 with Z-stack 3.0.1 firmware. but I got an error. I recorded the Zigbee2mqtt log in a file attached. does anybody know the solution? complete_log.txt

ryanbeaton commented 5 years ago

@msadeghz did you use ZS from HalleyAssist?

splitice commented 5 years ago

please do note that we havent tested the CC2530 in our stack for a long time. It should work though. If you can - disable USB if you arent using it - and any other features you don't need. Memory can be tight on that hardware with ZNP being a real hungry beast.

maciejsszmigiero commented 5 years ago

I flashed a CC2530 with Z-stack 3.0.1 firmware. but I got an error. does anybody know the solution?

The issue is likely that you try to use the zigbee-shepherd-built in concentrator configurator.

See the first paragrah at https://github.com/maciejsszmigiero/wiki/wiki/GB-RFTOUSB-Z-Stack#using-a-concentrator-device-with-a-zigbee-shepherd-based-software-like-zigbee2mqtt

King-anderson commented 5 years ago

@ryanbeaton I've installed ZS from HalleyAssist. The problem is solved. but as @splitice said, it's not stable. thank you.