Feature request of a Zigbee (Zigbee End Device) firmware image for b-parasite

[Hedda]

I like to request an optional Zigbee firmware image for b-parasite which could be used as an alternative to the Bluetooth firmware:

https://community.home-assistant.io/t/zigbee-flower-sensors-for-soil-moisture-light-temperature-humidity/272803/

At least the nRF52840 SoC used by Ebyte E73-2G4M08S1C radio module could support Bluetooth, Thread, and Zigbee 3.0 stacks:

https://csa-iot.org/csa_product/nrf52840-zigbee-3-0-for-nrf-connect-sdk/

https://www.nordicsemi.com/products/nrf52840

https://www.ebyte.com/en/product-view-news.aspx?id=445

Would be great if someone with the skills could build the b-parasite application with Zigbee End Device support for nRF5 SDK.

https://www.nordicsemi.com/Products/Development-software/nRF5-SDK-for-Thread-and-Zigbee

https://www.nordicsemi.com/Products/Development-software/nRF-Connect-SDK

[rbaron]

This is not something I plan on working on myself. I will leave this issue open for a while in case someone is interested in taking a stab at this.

[jhbruhn]

I believe the hardware would have to be extended for a useful ZigBee implementation, e.g. a pairing button. Or can we do without that?

[rbaron]

@jhbruhn I don't have a lot of experience with Zigbee other than pairing some Ikea lights, but some ideas for workarounds:

1. Double/triple/n-resets put the device into pairing mode. I think Ikea does 5-6 resets of light bulbs to put them into pairing mode
2. Using the capacitive pads as a capacitive button (e.g. placing your finger over the pads while reseting)

[Hedda]

Some other battery-powered Zigbee devices without a button just enter into joining/pairing mode for a set amount of time (usually 1 or 2 minutes) every time you remove and replace the battery, unleas of course the device has already been joined/paired to a Zigbee gateway/hub.

Harder to come up with a good process for performing a factory reset without a button as normally you have to remove and replace the battery while holding a button to perform a factory reset, but I guess you could short curcit some pins instead. Anyway, a function to perform factory reset is commonlly needed because it must normally be done when migrating to other Zigbee gateway/hub.

[31670253]

https://github.com/smartboxchannel/Plant-Watering-Sensor-Zigbee , one can have a look at this project for guidance maybe.

[stanvn]

I have created a repository with my application for Zigbee. @rbaron I hope you don't mind that I added references to your project, if so please let me know.

[rbaron]

@stanvn , That's pretty cool! I will give it a try soon. I'm happy to onboard this alternative firmware under experimental/ if you feel like contributing. Also happy to add a push button to the hardware so it's more convenient.

[stanvn]

That sounds like a good idea. I think it is best if you add it as a submodule in experimental/, in that way changes I make will automatically be updated.

[Hedda]

For discussion and reference;

Another possible use-case example could be that someway might want to consider making a single multi-protocol firmware image that would is compatible with Bluetooth Low Energy (BLE), Zigbee, and Thread/Matter (OpenThread).

E.i. a single firmware image for nRF52840 so users have the option to use several radio protocols, but only one at a time.

I believe that with the new Matter 1.0 standard being released now and hardware being the same such multiprotocol firmware for different IoT-sensor devices is likely to become more popular in the future with the use case being that the end-user buys one device which has one common shared firmware image but during the initial commissioning/pairing the user select which protocol he/she actually wants to use.

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.thread_zigbee.v1.0.0%2Fthread_multiprotocol.html

E.i. nRF SoC can use several radio protocols, but only one at a time as I understand. With the exception of Thread and Zigbee? Or?

https://csa-iot.org/newsroom/nordic-semiconductor-adoption-of-zigbee-and-emergence-of-new-open-development-model/

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_tz_v4.0.0%2Fble_154_multiprotocol.html

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_multiprotocol_support.html

So not concurrent multi-protocol using several protocols at the same time but instead having one firmware image that supports all but only one protocol is used by the user unless he/she factory reset it to be able to select a different protocol instead, or?

Definitely unclear if Nordic Semi multiprotocol products can offer support for Bluetooth and 802.15.4 running concurrently?

[MattSidney]

Also interested in zigbee being added

[rbaron]

Hey everyone, after finishing the migration from nrf-sdk to nRF Connect SDK (#76), I tried to adapt the zigbee_template to run on the b-parasite with a few extra clusters (#81). I also put together a basic Zigbee2MQTT converter in the PR.

I also started working on a V2 hardware revision with a couple of physical buttons. It needs a few more touches and testing, but hopefully I'll finish it soon.

Meanwhile, I came up with a (let's say... "creative") workaround for factory resetting the board without physical buttons. By reading the RESETREAS register in nRF52 chips, we can identify the cause of a reset:

• "Power up" happens when the device is connected to power (e.g.: when swapping batteries or connecting external power)
• "Reset Pin" happens when the RESET pin is briefly grounded or the device is flashed

In #81, a normal "Power up" reset does nothing (it remembers the previously paired network), while a hard "Reset Pin" reset forgets it (effectively a factory reset). I think it should allow for usual workflows, at least for playing around. It seems to work okay in my simple tests so far, but it would be ideal to test it better.

[Hedda]

I also started working on a V2 hardware revision with a couple of physical buttons. It needs a few more touches and testing, but hopefully I'll finish it soon.

@stanvn being that b-parasite and your project is open source hardware I'm curious to hear your input on hardware redesigns?

https://github.com/stanvn/zigbee-plant-sensor

[stanvn]

Looking good @rbaron. Migrating to nrf-connect SDK is a good choice in my opinion.

@stanvn being that b-parasite and your project is open source hardware I'm curious to hear your input on hardware redesigns?

https://github.com/stanvn/zigbee-plant-sensor

Only one physical button would be sufficient. The rest of the hardware is perfectly suitable for Zigbee. However I think you should consider its location in relation to a (3D printed) case. It would be nice if the button can easily be pressed without removing the case. Maybe a side button?

[drspangle]

Someone in another thread mentioned maybe a Hall effect sensor might be a good choice? One thing I'm starting to realize is that the lack of an external probe in this design is a great tradeoff for simplicity of design, simplifying construction, and incorporating a substantial cost savings. The problem is that it's really hurting the weatherproofing, and 3d printed cases alone don't seem to help with that all that much (in outdoor settings most of all). It would be so great if there was a way to encapsulate as much of the PCB as possible, with the exception of the battery, and I imagine this would make it difficult to incorporate push buttons.

Just my two cents. There's also substantial value in having the button if the waterproofing aspect isn't as critical.

[rbaron]

When I'm developing the firmwares or tinkering with the boards on my desk without the case, having extra features is really convenient.

When deployed in the field, I want the sensors to be so reliable and compact that I forget about them. My ideal IoT sensor is set up once and works for years without me interacting with it and without it getting in the way. In over two years I've seen many different failure modes, and it makes me really think twice before adding features to the project. Any new part is a liability, much more so if it's a moving part. Even adding a concealed push button in this environment is risky due to humidity alone, but I think it's worth it. Adding one with a dedicated water path from outside the case is in my opinion very risky, unless some clever case design.

But let's say we are willing to take those odds. What is the use case for the button? If it's a factory reset button, I would prefer to instead spend an extra couple of seconds to unclip the case before pressing it, the one time a year (hopefully even less frequently) I need it. I would like to see the LED blinking during reset anyway. If it's a "wake up and read the sensors now" button, I would rather look at the previous reading from a couple of minutes ago. Small shifts in the sensor will change its readings, which will most likely happen when pressing the button. A reed or hall effect trigger would also introduce solutions looking for a problem in my opinion.

Take as an example most consumer IoT devices. The reset button is most often concealed (IKEA buttons, outlets, bulbs don't even have one; or the popular ATC/Xiaomi Mijia thermometer). I would say we have a similar use case, except water is always a few centimeters away trying to ruin the party.

[stanvn]

That is actually a really good point. I though having the button available from the outside would become handy. But if it is only used for factory reset there is indeed no point in risking the waterproofness of a case.

[drspangle]

I've changed my mind on this based on what @rbaron said. Ultimately, what's the point in having a button, hall sensor, or anything else if it sacrifices the most essential use case of the sensor -- to sense stuff accurately and reliably? If the device is under maintenance on a benchtop (and still has a removable battery), what's the value in a button when you can just yank out the battery, or even just short the reset pin? And honestly, when do you expect someone would want to reset the sensor in the first place? There is almost nothing happening processing-wise on the device, and no configurable state.

The b-parasite is as pure to the ideal of "it's just a sensor, plug it in and forget about it" as the design can allow and I think that's what sparked my interest in the project in the first place. The lack of probes to corrode and the simple design is ideal for me. Frankly, if it weren't for the need to be able to replace the battery I'd just pot the thing entirely in epoxy, chuck it in my plant pot, and literally forget about it.