Zigbee2mqtt: pairing APsystem YC600

[petsch9]

Hi,

Did someone manage to connect/pair with the APsystem YC600 micro omvormer.
They should connect with zigbee but it is not pairing at all.

Any sugestions are welcom.

Kind regards,
Peter

[kadzsol]

Looking for the same information... There is no reset button, powering off/on does not help either. I suspect we have to send a proprietary signal to trigger pairing. Maybe somene with an official ECU-R gateway can do a test and sniff?

[Poquaruse]

Hi all!

Here is what I've found out (with my limited knowledge of Zigbee).

• The inverter is only active when it's powered via DC (e.g. the sun must be shining). AC alone is not enough. This is consistent with what I've read on other forums: the inverter itself is only powered via DC!
• Once the inverter is powered via DC, I see "Link Status" packets on Channel 16. Otherwise the channel is empty. If I'm too far away from the inverter, no packets are received. Therefore, I'm fairly certain that the inverter is the source of these packets.
• In these packets there is a specific PAN ID. I assume that this means that the inverter is trying to join a "private" network. That's why it doesn't join the "normal" zigbee2mqtt network I'm running.

Next steps I'll try:

• Start another instance of zigbee2mqtt using Channel 16 and the specific PAN ID. (Waiting for another 2531 to arrive...)
• Checking if the inverter connects to that network.

[kadzsol]

Nice stuff! Now we are one little step further and seem to understand why some people cannot see any packets. I have read on internet that the YC600 has a zigbee communication range of 10-20m. Also, AP systems has confirmed to someone posting on a forum, that they use a proprietary zigbee protocol. This also seems to be in line with your finding. We have to crack this stuff! I am going to order my own 2531 now :-)

[petsch9]

Great i cant wait

[Poquaruse]

Unfortunately, I had just a few minutes of sunlight left today... But here is what I did.
In the config, I set the following parameters:

advanced: pan_id: 0xae14 # sniffed from the link status packets channel: 16 log_level: debug

The I started zigbee2mqtt and sniffed the traffic using another 2531.

44 185.546362 0x0000 Broadcast ZigBee ZDP 108 Permit Join Request

45 198.038446 Broadcast IEEE 802.15.4 70 Beacon Request

46 198.040590 0x26c7 ZigBee 88 Beacon, Src: 0x26c7, EPID: 03:00:12:11:10:90:ff:ff

And that's about it... Then, the "link status" packets continued. No device joined. :-( What puzzles me a bit is that 0x26c7 responds with a Beacon?! I thought that the device trying to join sends a beacon request and then the coordinator answers with a beacon?!

Any ideas where to go from here?

Tomorrow, I'll try and enable zigbee-herdsman debugging, too.

[Poquaruse]

Apparently, the ECU-R (APSystem device to connect to the inverters) needs the inverters' UID. So perhaps there is some kind of authentication going on there?! See https://youtu.be/3UGMGZRTJQI?t=868

[kadzsol]

My zigbee knowledge is very limited, so I was reading some documentation to jump start my knowledge :-) What I understand is that it is always a zigbee device which is sending beacon requests and coordinator is responding with a beacon frame. If coordinator enables permitjoin and is shown in beacon frame, the device can decide to send association request to coordinator to join the network. So it is always the device who decides which network to join from the available/permitted networks. It seems, that the YC600 decides not to join your network, despite the fact that you coordinator permits it. Feeding in the ID of the inverter in the ECU APP (as shown in the video you have linked) is probably the key, I guess the ID somehow needs to be included in the beacon response frame of the coordinator. When de device recognizes the own ID in the frame, it will join.

[Poquaruse]

With herdsman logging enabled: still no luck. Nothing to see...

What I understand is that it is always a zigbee device which is sending beacon requests and coordinator is responding with a beacon frame.

Yes, that is my understanding, too. However, here we see that the inverter (e.g. NOT the coordinator) seems to respond with a beacon! From the sniffing logs you cannot see which device sent the beacon request, but you can see that the inverter answers immediately.

I too assume that you need to tell the inverter a "secret" (probably related to the UID). I don't have any idea how to accomplish this... A sniff from a successful pairing with a physical ECU-R would be very helpful, I guess...

[kadzsol]

Yes, we have to find someone owning an ECU-R and able to make a sniff. Other option is we do some crowd-funding to buy an ECU-R for testing purposes. It costs around the 200 euro, I would not mind to donate some money if we can crack this thing.

[kadzsol]

There is a German forum out there with people that are also interested in having home brewed solution for the YC600 so I have posted a message there to join our forces: https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/knx-eib-forum/diy-do-it-yourself/1409938-pv-micro-inverter-diy-auswertung-m%C3%B6glich

[manoficons]

'franck102' in this discussion
https://community.openenergymonitor.org/t/zigbee-inputs/11166/10
seems to have an ECU device. Perhaps he is willing to help with some sniffing.

[kadzsol]

Thanks for the thread. He seems to have an ECU-C and not an ECU-R. Nevertheless, I have registered there and i am going to post a question about sniffing. An ECU-C sniff might also give some hints for us how to proceed.

[Poquaruse]

That would be great! I guess there isn't much of a difference between the ECU-C and -R when it comes to the zigbee connection.

[manoficons]

ECU-C seems to be the "bigger" device. With swiching output options and more.
https://global.apsystems.com/wp-content/uploads/2018/04/4271801031_APsystems-Energy-Communication-Unit-ECU-C-User-manual_Rev1.5_2018-1-16.pdf

Zigbee section should work in the same way as in ECU-R.

[Poquaruse]

In case somebody who owns an ECU-R (or ECU-C) stumbles across this thread and is willing to help, I'll try to summarize the steps to obtain a successful sniff of the connection between the YC600 and ECU-R...

• Set up a CC2531 for sniffing. See https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html for details. In case the CC2531 has the TI sniffing firmware (instead of the ZBOSS one): TI offers a software to stream the sniffed packets to WireShark.
• Use the APSystems app and remove one inverter from the ECU-C. This should disconnect the inverter from the ZigBee network so that as a next step we can observe the joining process.
• Start sniffing on channel 16. (At least for me, channel 16 seems to be the only channel that the YC600 is sending Link Status packets on...)
• Re-add the inverter to the ECU-C using its UID.
• Check that the inverter has successfully been added in the app.
• Wait until values show up in the app. (So now we know for sure that the inverter is back in the ZigBee network.)
• Stop the sniffing process and export/save the PCAP file.
• Upload the PCAP file here for dissecting. :-) (Please be aware that the ZigBee key is -- hopefully -- included in the PCAP file...) It would also be very helpful to know the entered UID so that we can check how it is used to authenticate.

To anybody who is willing to help: Thanks a lot in advance!

[samr037]

I'd like to order it from some trustworthy website like Amazon, opening it without leaving any marks, sniff the trafic, and then ship it back ;). Amazon doesn't have it, only PV retailers, but there's shipping costs and they're not very clear about return policies...

[manoficons]

Some statement from the manufacturer (not very useful)
https://community.smartthings.com/t/apsystems-yc600-microinverter-monitored-by-the-samsung-hub/166100

[manoficons]

One more guy having the ECU-R and wants to use zigbee connection
https://domoticz.com/forum/viewtopic.php?f=28&t=22368&start=140

[kadzsol]

One more guy having the ECU-R and wants to use zigbee connection
https://domoticz.com/forum/viewtopic.php?f=28&t=22368&start=140

Thanks for the info. Registered there and posted a message :-)

[kadzsol]

I'd like to order it from some trustworthy website like Amazon, opening it without leaving any marks, sniff the trafic, and then ship it back ;). Amazon doesn't have it, only PV retailers, but there's shipping costs and they're not very clear about return policies...

Creative :-) Let us hope someone out there with an ECU will voluntair to make a sniff. If no, I do nnot mind to help with the shipping costs.

[iboot700]

One more guy having the ECU-R and wants to use zigbee connection
https://domoticz.com/forum/viewtopic.php?f=28&t=22368&start=140

Thanks for the info. Registered there and posted a message :-)

And there I am...

Hope I can help out, I have a CC2531 available and the ECU-R paired with a YC600 and QS1. I’ll try the procedure above to sniff the traffic and post the results here. Might take a few days.

[kadzsol]

Great, thx!

[Poquaruse]

I’ll try the procedure above to sniff the traffic and post the results here. Might take a few days.

Great, thank you very much! Let us know if any problems arise during logging where we might be able to help!

[boons605]

One of my friends has a bunch of YC600's and en ECU-R. I've only got 4 YC600's, but I do have a CC2531 stick with sniffer firmware. We're planning to sniff next weekend (2020-10-03, CEST time zone, looking at how much of a morning person I am, I'd say in the afternoon).

[kadzsol]

Great, I cannot wait!

[petsch9]

Great, I can not wait either.

[iboot700]

In case somebody who owns an ECU-R (or ECU-C) stumbles across this thread and is willing to help, I'll try to summarize the steps to obtain a successful sniff of the connection between the YC600 and ECU-R...

* Set up a CC2531 for sniffing. See https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html for details. In case the CC2531 has the TI sniffing firmware (instead of the ZBOSS one): TI offers a software to stream the sniffed packets to WireShark.

* Use the APSystems app and remove one inverter from the ECU-C. This should disconnect the inverter from the ZigBee network so that as a next step we can observe the joining process.

* Start sniffing on channel 16. (At least for me, channel 16 seems to be the only channel that the YC600 is sending Link Status packets on...)

* Re-add the inverter to the ECU-C using its UID.

* Check that the inverter has successfully been added in the app.

* Wait until values show up in the app. (So now we know for sure that the inverter is back in the ZigBee network.)

* Stop the sniffing process and export/save the PCAP file.

* Upload the PCAP file here for dissecting. :-) (Please be aware that the ZigBee key is -- hopefully -- included in the PCAP file...) It would also be very helpful to know the entered UID so that we can check how it is used to authenticate.

To anybody who is willing to help: Thanks a lot in advance!

I gave it a try tonight but I'm not sure I've succeeded. I've not been able to find the Zigbee key. Removing the inverter is easy but to add it again I had to power cycle the ECU and inverters to get the process to 100% but still the automatic system check in the app fails. As it is dark right now I'm not able to check if the inverter is back in the network, I'll try tomorrow if it is light.

Anyhow, I've attached the file so you can have a look. If there is anything interesting in there it is probably around line 327, here the connection process was finished according to the app.

YC600_zigbee.zip

[kadzsol]

Thanks a lot! Let us see what we can learn from this sniff.

[krikk]

please be aware that the yc600 is powered from dc, so it is only working when you have enough sun... (no sniffing at night )

[kadzsol]

I went through the sniff but could not find anything from the YC600 (similar like "46 198.040590 0x26c7 ZigBee 88 Beacon, Src: 0x26c7, EPID: 03:00:12:11:10:90:ff:ff"). Maybe it was not powered any more (no sun)?

[Poquaruse]

Thank you very much for the sniff! As the others said: there needs to be (enough) sun for the inverteres to be powered.

However, from the sniff we still can see a few things!

• There is only one active device (source 0x0000) -- that seems to be the coordinator, e.g. the ECU-R. That is what I would expect at night.
• There are a few "malformed packets". This might happen due to bad reception or interference, I guess. (Or it could be the "special" protocol -- let's hope not!)
• There are a few "read attributes" packets, for example 300 and following. This could be the ECU-R asking the inverters (which are not available) for something, perhaps for data?!
• There are a few "unknown command" packets, for example 327 and following. This could also be the ECU-R asking for input. In them there are two data fields, containing similar data: for example in 327 we see "Data: 01a3d8801000022928" and "Data: 80971b01a3d8801000022918". Perhaps, we can see the serial numbers (encoded?!) in these packets?!

My first guess would be that the ECU-R is trying to make the inverters send data (which are now connected because of no sun). Would be great to see what happens when all inverters are powered!

Thanks again!

[iboot700]

Thanks for your comments. I gave it another try during daytime and at least the pairing procedure was a lot faster and less complicated. The sniffing is started before adding the YC600 to the ECU-R together with 2 QS1 inverters which I did not remove. I stopped as soon as all inverters showed data. I also included the UIDS and short addresses. Hope it helps.

YC600_zigbee_2.zip

[kadzsol]

Many many thanks! I see interesting information in this trace, like UID's! I hope we can understand what is going on and can create our own fake ECU :-)

[Poquaruse]

Thank you very much! I had a quick look at the sniff and it's quite interesting. For better reading I filtered the route packets and the link status packets: ((!(zbee_nwk.cmd.id == 0x08)) && !(zbee_nwk.cmd.id == 0x01)) && !(zbee_nwk.cmd.id == 0x02).

• There are no beacons! That is pretty strange as it might imply that the ECU and the inverters aren't really "paired" and that there is no encryption in place...
• The source 0x0000 (e.g. the ECU?!) sends a lot of "read attributes" packets. They contain the UID and some padding (which always seems to be the same).
• The source 0x5471 (e.g. one of the inverters) seems to answer with an "unknown command" packet which includes the inverters UID and some data.
• At 61 the ECU sends some other "unknown command" in which I do not recognize a UID. Data: 01a3d8 and Data: 80971b01a3d8. This command is sniffed multiple times (possibly due to its broadcast nature...).
• At 83 we see a packet by 0xcaec -- probably the response to this?! Data: a5a53052 and Data: a5a5a5a5a5a5a53052
• At 89 we see the ECU responding once more. Data: 01a3d8fbfb06dc000000000000e2fefe and Data: 80971b01a3d8fbfb06dc000000000000e2fefe.
• Next we see responses from the inverter -- which are "malformed" according to Wireshark... :-/ I don't know if this is due to the "special kind of zigbee" which APSystems uses or due to reception/sniffing problems. It happens multiple times. What we can see is a quite long list of "Attributes" which are sent in a "read attributes" packet. (see 99 or 123)
• At 151 and 153 we see quite a lot of data sent by the ECU. This is answered by the inverter.

This could be the "non-standard" pairing process. E.g. not really pairing in a network, but authenticating the ECU using some kind of challenge/response-scheme which incorporates the UIDs (and probably some magic).

• From 241 on we can see the ECU querying the inverters for data and the inverters responding to that ("unknown command" packets and "read attributes" responses).

I guess there is some good news: there doesn't seem to be a fancy type of encryption going on. However, unless I'm mistaken, there is a non-standard authentication using "unknown commands" to make the inverters send data to the ECU using "read attributes" packets. Now we need to figure out how these work and try to understand it. And then we need to emulate it -- a thing I'm not even sure zigbee2mqtt is able to do...

[kadzsol]

Nice analysis! It will not be an easy task to understand this protocol. Coming weekend I will separate the trace of one device and make a flow-chart out of it. Maybe someone here can comment/help how to create/emulate the packets sent by the ECU using zigbee2mqtt?

[kadzsol]

I have also checked the previous sniff when there was no communication with the inverters. The mailformed packages are also present in that sniff. Would it mean a reception problem?

[iboot700]

I followed this guide (https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html) and stopped after I added the Trust center link key in Wireshark. Is this correct or might this cause issues?

The reception should not be an issue I would say, the panels are on the garage roof and the measurement is done inside the garage directly below the panels en 2m from the ECU-R.

[iboot700]

Sniffed some more... This time 3 minutes with the ECU-R switched off, after this I switched on the ECU-R (paired with the converters). Maybe it helps to understand the process.

ECU-R_switch_on_paired.zip

[iboot700]

And even more. This time the readings should be as noise free as they can be.

1 - Measured normal operation for about 10 minutes where you can see the status update of the inverters every 5 minutes (for 3 inverters)
2 - I've requested the grid profile for the connected inverters (around 17 parameters per inverter). I suspect these will explain a lot of the attributes you see.
3 - Removed all inverters from ECU-R
4 - Paired only YC600
5 - Updated the grip profile for the YC600 (takes a long time!)
6 - Removed YC600 and only paired QS1

Hope it helps, if you have any questions just let me know

Zigbee_snif.zip

[boons605]

I'm currently sniffing with an ECU-R.
We've got 5 inverters online here, the ECU-R had been offline for a while before starting the first sniff.

Afterwards, we removed all the inverters from the ECU-R and paired only the YC600 with UID 406000008105

The ECU-R is not connected to the internet. At the time of pairing, the app showed 18W and 19W for the connected panels.

ECUR_Pairing_And_Turnon.zip

[kadzsol]

Lot of stuff to analyse. Thanks guys!

[kadzsol]

Sniffed some more... This time 3 minutes with the ECU-R switched off, after this I switched on the ECU-R (paired with the converters). Maybe it helps to understand the process.

ECU-R_switch_on_paired.zip
I have looked into this sniff and I seem to understand (sort of :-):

• When the ECU is off, we see only link status packes of the inverters (1-20)
• When the ECU-R comes on, it boradcasts 5 packages (21-25). 2 times to 0x000, 3 other times it uses the addresses of the specific inverters.
• After that, it sends 6 packages with the same data in it (27-32). In some packages I see the specific addresses of the inverters, in some others only 0x000. Is this data some sort of previously generated shared key?
• Shortly after this the inversters are starting with the exchange of data with the ECU. The rest of the sniff seems to me quite similar to the data exchange part we saw after the pairing process in the previous sniff.

[Poquaruse]

Thank you guys so much for the sniffs! 👍 That's great! As soon as possible, I'll try to have a thorough look at them.

[kadzsol]

One more observation:

The packets with "Unknown Command: 0x00 & Unknown Command: 0xa5" are only present in sniffs when pairing is going on.

In the sniff I can also see that this is a Manufacturer specific "something" (ID 0xa5a5 = AP systems?)

[kadzsol]

Google-ing on "0xa5a5 & zigbee" gave me the attached reference from Jennic (now NXP):

zigbee device profile reference manual.pdf

Page 29 shows a code snippet with profile ID 0xa5a5. Could it be that the ECU/YC600 is based on the API/microcontroller of Jennic/NXP?

[manoficons]

Could it be that the ECU/YC600 is based on the API/microcontroller of Jennic/NXP?

If the YC600 was easier to open, without breaking it, I would already had a deep look inside. But everything under the black cover seems to be "glued" with a white silicone mixture.

[kadzsol]

Some instructions how to send/receive zigbee commands using a PC: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/434159?CC2531-Send-and-Receive. Could not find something similar after scanning the docs of zigbee2mqtt. Unfortunately, my CC2531 is still on its way from China, so cannot try for myself

[kadzsol]

My CC2531 arrived today! I will start experimenting this weekend.

[kadzsol]

I have managed to get my sniffer up and running using zboss framework. I can see the link state packages of my YC600 on channel 16. So far so good.

I have spent the rest of my free time to find out how to transmit custom zigbee frames back into the network to see if I can trigger the YC600 to send more information.

This does not seem an easy task with the CC2531.

1. https://github.com/Tropicao/zigbridge/blob/master/doc/firmware_instructions.md
   This source says that in order to communicate with other devices on the network, one has to build its on framework based on TI' Z-Stack 3.0. It includes a GenericApplication which can be reused and compiled with IAR Embedded Toolchain for 8051. This tool is not free, altough they have a 30-days trial available. Programing language is C++.

2. I was also searching for some low-level tools which would enable us to inject frames into the network. Sort of hacktool one can use to experiment with feeding back some (modified) commands from our traces. So I found https://github.com/riverloopsec/killerbee. It does support the CC2531, but only for sniffing... Other (fully) supported devices do not seem very cheap but I will dig into this topic further to see if there is a reasonably priced alternative.

Comments/ideas/feedback is welcome!

[Poquaruse]

Hi all!

I finally had the chance to take a closer look at the provided sniffs. Thank you very much for providing them! Here is a short summary of what we can learn from them.

• The inverters and the ECU-R never form a "normal" network. Instead, they use channel 16 to communicate without much encryption. However, there is some kind of authentication going on (see next point).
• To make an inverter send data, the ECU-R needs to kind of "trigger" it. This seems to be done using the inverters' UIDs. And once you think about it, it does make sense: The inverters are usually mounted in a way that it is close to impossible to get to them and push a button just to connect to them. Imagine that an ECU fails and you need to climb onto your rooftop to push a button in the middle of a bunch of panels just to bind them to another ECU. That's ridiculous. Therefore, the inverters just don't have any buttons. Also, I think this is obviously some kind of security measure. Like this it's harder to "connect" to the inverters without knowing the UIDs.
• Once you enter the UIDs into the APP, the ECU-R can send "special" packets on channel 16 and when an inverter sees its UID, it responds. There seem to be several different kinds of packets which obviously trigger different kinds of answers.
• As @kadzsol correctly pointed out, one would need to send custom commands without being in a network. That does not seem to be possible with zigbee2mqtt as far as I know. :-(

To be honest: I haven't found an (easy) way to send custom commands. Perhaps we could take a look at zigbee-herdsman's core to find out how to do that. But that is probably way (!) beyond my skill-level...

[kadzsol]

Xbee is also an interesting device which is able to generate/send frames in API mode: https://subscription.packtpub.com/book/hardware_and_creative/9781784395582/1/ch01lvl1sec12/switching-to-api-mode Cost is around the 20-25 euro. Anyone experience?

[boons605]

You mean this?

Got this laying around here for a work project I was going to pick up again the coming weeks.

[kadzsol]

Ja, precies. Would be nice if you could test if it is able to generate frames which are similar to what we see in the sniff. With the frame generator included in XCTU (free download of Digi) it seems relatively easy to do this. If this works, we could create a development/test environment in which we send frames with xbee and sniff with cc2531.

[boons605]

I can try this. Nevermind what I wrote about getting up on the roof, I missed the part about the development environment.

[boons605]

Ok. Sending stuff using XCTU is easy and capturing that with the CC2531 is easy too. Now to send stuff that looks remotely like what we captured. Looks like I have some learning to do in the ZigBee world.

[boons605]

It has taken a bit of fiddling with XCTU, since this is my first actual experience with ZigBee, but I have set up a ZigBee network on channel 16 / 0x10 and have managed to send some data across the network.

However, this doesn't remotely look like what the APS devices are sending, since this is a 'normal' network with a coordinator and two routers.

[kadzsol]

Great that you have managed to set up a network! If I understand correctly, you have 3 xbee devices participating in your network able to echange data with each other?

According to the documentation, there is a frame generator in XCTU which can be used to generate custom frames. I wonder if you can evaluate this generator to see if we can use it to imitate the messages the ECU-R sends?

[boons605]

These frames have already been generated using the frame generator. The frame generator generates frames in the XBee API format.

My guess is that we need to figure out if the XBee API offers possibilities to send frames that look like what the ECU-R sends and, more importantly, pick up the frames that the YC600 sends, since we already concluded that the ECU and YC don’t form a network. The XBee does and the receiving end as currently configured only receives frames for the PAN it is associated with.

Also, have we been able to identify which packets are sent by the ECU-R and which by the YC600?

[kadzsol]

In the sniffs (like above) you can clearly see the packets of the ECU-R (source 0x0000). Before the pairing it sends "many to one" route requests and the inverters (e.g. 0xcaec)) only sending link status frames.

[boons605]

Well. The only way I can get the XBee to work is in a ‘normal’ network. The frame generator only helps me generate API commands.

I started reading up on CC2531 firmware development since apparently I need a device that allows a little more freedom.

[kadzsol]

Bummer. So we know how to "listen" but do not know how to "talk". I am afraid we will need to develop our own tool first :-(

[manoficons]

Which hardware uses the ECU-R to build and operate this "non-standard" network? Has anyone opend the box to see what is inside?

[kadzsol]

Which hardware uses the ECU-R to build and operate this "non-standard" network? Has anyone opend the box to see what is inside?

https://github.com/Koenkk/zigbee2mqtt/issues/4221#issuecomment-703176688

[krikk]

only the inverter itself is unable to open, the ecu-r should be more easy because it does not have to be waterproof...

[boons605]

Which hardware uses the ECU-R to build and operate this "non-standard" network? Has anyone opend the box to see what is inside?

#4221 (comment)

The link in that comment points to a thread on the TI message board which also moves in the direction of setting up a network with a coordinator and routers. Because that’s how it seems to work in the zigbee world.

Yesterday evening I was reading up on firmware development. Didn’t have chance to try things yet.

[npeter]

I opened my ecu-r.

The zigbee chip is in the left/bottom corner. There is a blank metal case behind the label. No details.

[npeter]

[kadzsol]

Great!! https://fccid.io/2AFGR-APS2530S Some sort of clone of the CC2530?

[manoficons]

The user manual of the APS2530S says Zigbee PRO protocol. Does that mean, that this protocol must run on the CC2531 to make it work?
https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/151438?zigbee-pro-stack-on-cc2531-dongle-and-using-USB-

[iboot700]

i've followed this guide to setup the CC2531 as a sniffer. This includes using ZBOSS V1.0 which is not supporting Zigbee Pro, this is supported from V2.0. See documentation here
However, I'm no Zigbee expert so I have no idea if this influences the sniffs we have made.

[kadzsol]

how to sniff zigbee pro: https://community.smartthings.com/t/zigbee-sniffer-recommendations/9689/3
differences zigbee and pro: https://www.eetimes.com/zigbee-and-zigbee-pro-which-feature-set-is-right-for-you/

After reading stuff on internet, I think we can still see/detect frames of Zigbee Pro protocol with a Zigbee (Zboss 1.0) sniffer, Only parsing of the information might not work. I have asked this question on the Zboss forum.

[iboot700]

I reverted my CC2531 back to the original TI firmware and sniffed using the zigbee pro protocol during the paring of the YC600 with the TI package sniffer. To analyze you will need this software, it can be downloaded here

The only line which obviously stands out is line 24 but I'm not able to find anything interesting. Maybe some of you can?

pair_YC600_TI_ZBPro.zip

[kadzsol]

Did you use sniffer of sniffer-2?

[iboot700]

Sniffer
Sniffer-2 is not compatible with the CC2531

[kadzsol]

Thanks, I have managed to open the sniff. Line 24 is indeed a large one. Let me try to understand what is happening in this sniff.

[npeter]

I sniffed my system (1 QS1, 3 modules connected) with the TI fw as descriped https://github.com/Koenkk/zigbee2mqtt/issues/4221#issuecomment-700925206.

pair_QS1_TI_ZBPro_2020-11-03.zip

Still tying to understand whats going on.

[kadzsol]

Very difficult to interpret these types of sniffs. It seems I have to learn a lot. Finally got some time to download and install IAR Embedded Workbench for 8051. Went for the 4k limited source installation mode to have enough time to expremiment. Anyone who knows a good tutorial for beginners?

[kadzsol]

The limited 4k edition of IAR is useless. Do not waste time on it. Use the 30-days fully functional trial version.

Finally managed to get a working IAR for 8051 installation and was able to compile the genericapp example provided by TI.

[npeter]

I installed TI Code Composer Studio and was able to run TI zigbee example on an LAUNCHXL-26X2R1 board. Could see some zigbee communication with sniffer. But sill a long way to go.