pairing APsystem YC600
petsch9 opened this issue · 816 comments
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
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?
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.
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 :-)
Great i cant wait
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.
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
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.
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...
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.
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
'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.
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.
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.
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.
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'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...
Some statement from the manufacturer (not very useful)
https://community.smartthings.com/t/apsystems-yc600-microinverter-monitored-by-the-samsung-hub/166100
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
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 :-)
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.
One more guy having the ECU-R and wants to use zigbee connection
https://domoticz.com/forum/viewtopic.php?f=28&t=22368&start=140Thanks 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.
Great, thx!
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!
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).
Great, I cannot wait!
Great, I can not wait either.
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.
Thanks a lot! Let us see what we can learn from this sniff.
please be aware that the yc600 is powered from dc, so it is only working when you have enough sun... (no sniffing at night )
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)?
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!
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.
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 :-)
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...
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?
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?
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.
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.
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
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.
Lot of stuff to analyse. Thanks guys!
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.
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.
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?)
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?
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.
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
My CC2531 arrived today! I will start experimenting this weekend.
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.
-
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++. -
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!
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...
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?
You mean this?
Got this laying around here for a work project I was going to pick up again the coming weeks.
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.
I can try this. Nevermind what I wrote about getting up on the roof, I missed the part about the development environment.
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.
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.
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?
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?
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.
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.
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 :-(
Which hardware uses the ECU-R to build and operate this "non-standard" network? Has anyone opend the box to see what is inside?
Which hardware uses the ECU-R to build and operate this "non-standard" network? Has anyone opend the box to see what is inside?
only the inverter itself is unable to open, the ecu-r should be more easy because it does not have to be waterproof...
Which hardware uses the ECU-R to build and operate this "non-standard" network? Has anyone opend the box to see what is inside?
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.
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.
Great!! https://fccid.io/2AFGR-APS2530S Some sort of clone of the CC2530?
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-
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.
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?
Did you use sniffer of sniffer-2?
Sniffer
Sniffer-2 is not compatible with the CC2531
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.
I sniffed my system (1 QS1, 3 modules connected) with the TI fw as descriped #4221 (comment).
pair_QS1_TI_ZBPro_2020-11-03.zip
Still tying to understand whats going on.
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?
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.
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.
i also running an YC 600 and would like to use the zigbee connection. May an other point is getting the firmware and decompile it. May if a firmware update with ECU R is possible we could do it like this ?
@gamer123 Can be an other route to try. I have some experience with dismanteling some Android phone ROM's but you always needs special tools for that. Not sure what format the ECU-R firmware would need.
In the meantime I have made some steps with creating a CC2531 based "low-level transmitter".
- I have found an old (zigbee 2.x based) sample applicaton which we might be able to alter to suit our needs:
It was written for the CC2530 and IAR 7.5, but I have managed to compile it with IAR 10.30.
-
I can flash my CC2531 with the generated hex file. Directly after flashing the red LED of my CC2531 goes on. I do not know yet what it means. :-)
-
Next week I hope my other CC2531 dongle will arrive so I can listen in real time with Wireshark what is going on in the "air".
In te meantime I will try to use the debugger/simulator in IAR to figure out what the red LED means.
Still a lot of things to learn/do!
I starte analysis of data frames from QS1 to ECU-R focussed to the long once (APDU payload with lenght 94).
So I wrote a Java Script (node.js) to convert *.psd files into a *.txt wich can be imported by Excel.
Now it was possible to identify some structures and data and its potential meaning.
But there's still a lot of unknown data (and APDU data frames)
See the following tables
Global data
Protocol related data
@kadzsol thats true i do have a tool. The used chip is shown upper here. If some one owns a firmware update may he or she can provide it to me, then i can try to decompile it. #4221 (comment)
@npeter looks very good did you used the data they are provided here in github ?
As far as i understood is the main thing is to get into touch with the zigbee of the YC or QS1. The ECU triggers the YC and after that the YC start sending data without building a network. And the available zigbee firmware and stuff is not able to send own telegrams in a not available network. But the good thing is no
crazy enrcyption.
@gamer123 I have just googled for about an hour but was not able to find a firmware (update) file. Maybe if you have an installation account you can grab it at APS site, but I doubt. It seems a very closed system, also for updates if I read this:
You may try to decompile the ECU-R app to learn something if you have the time?
https://play.google.com/store/apps/details?id=com.apsystems.ecu_r&hl=nl&gl=US
@kadzsol I do have an installation account but was not able to find any firmware in there.
@npeter Great work! As I already own the ECU-R for me it would be sufficient to convert this data to mqtt so I can pick it up from there. If you are willing the share the script I can help to analyze the frames. Looking at the raw data coming from the YC600 it should contain the following info:
My 2nd cc2531 has arrived today! My setup is complete now. I can develop in IAR, compile the code and upload it to the transmitter device. While it transmitts, I can see the packages real time in Wireshark.
I have recompiled the GenericApp example from Z-stack 3.0 to behave as a coordinator on channel 12, and I can see it in Wireshark:
Now it is time to test if I still can program in C... :-)
@iboot700
Great! You are welcome to support the analyzing of the frames. The data shown by you is exactly what i'm still looking for. I try to find a way to share the script and some data.
It's also my first priority to have a specific YC/QS1 zigbee-mqtt gateway.
@kadzsol, @gamer123
A second step could be to replace the ECU-R as proposed.
I continued with my analizys of the data QS1 frame.
See the table below
still some work todo
Hi,
I have just bought 2 Heckert panels and a YC600. I have a cc2531 on my rpi4. Anything I can do to help?
@dash042 Let me try to summarize the status of our project for you. Feel free to jump in any part you like/can.
-
One use case of npeter is interpreting the sniff results of an earlier (officially) paired inverter. So If you have an ECU and already paired your YC600, the inverter will transit information to this real ECU, which in turn uploads the information to the APS cloud. With a cc2531 you can grab the Zigbee information transmitted and interpret it with the a script of npeter. So you do not have to get the information from the APS cloud but have it as output of his script. After that you could do whatever you want with the information, like feeding it into other systems for further processing.
-
I myself busy with writing some software to simulate the pairing process. This is needed to trigger the inverter to start sending information to this simulated/fake/virtual/etc ECU. Once we managed to pair without having to have a real ECU, the script of npeter can be used to interpret and use the information in other systems.
Completing the use cases #1 & #2 would yeald us a minimum system which would enable us to get information from the inverters without using an ECU and the APS cloud.
Status of use case 2:
I have setup a development environment and managed to compile sample applications provided by TI. They run fine on my cc2531.
I have modified one of the samples to transmit my own frames. Unfortunately, this does not work yet. When I try to debug it, my application hangs at the hardware initialization code. This is kind of strange, as I did not modify that part. So kind of stuck here.
Very nice:) 2 days ago my CC2531 arrived. I am still waiting for the flash euipment. then i can start testing with my YC600
@kadzsol thank you! I didnt spend 200€ on this proprietary ECU...
Maybe I can have a look at the "tiggering-app" you wrote? is it on github?
I'll get myself a second cc2531 for testing
@dash042 Nice if you want to help with coding. First please download IAR embedded workbench for 8051 and install it. You need to apply for a 30 days FULL license, After that download and compile the Z-stack 3.0 sample application GenericApp. Once that is done, I will tell you the changes I did to the code of GenericApp to start transmitting my own frame.
https://www.iar.com/iar-embedded-workbench/#!?architecture=8051
Short summary about the state of my PV POC:
- PV system: Three modules, QS1 and ECU-R
- TI sniffer2 fw running on a CC2652 EVA board
- ESP8286 connected via serial link
- Tasmota 9.2.x with a proprietary extension working as sniffer2-zigbee-mqtt gateway (xsn_96_qs1.ino)
-
- command the sniffer, decode and extract (all) zigbee frames
-
- distributes them via MQTT (WiFi)
- Smart home center using iobroker as MQTT broker
- iobroker sonof adapter to connect ESP/Tasmota/MQTT
- iobroker influxdb adapter as database
- iobroker lovelace adapter for visualization
- iobroker javascript adapter for programming
-
- JS script (pvMonitor.js)
-
-
- decode zigbee frames, extract QS1 data
-
-
-
- prepare PV data and store states in iobroker db
-
System Overview:
Next steps - Short term:
- Test, refactor and improve xsn_96_qs1.ino
- Test, refactor and improve pvMonitor.js (focus to QS1)
- Validate, improve, try to complete understanding of the QS1 data frame
Next steps - Mid/long term (ideas and dreams):
- Replace CC2652 EVA board by cheaper CC2652 module
- Replace sniffer2 fw inside CC2652 to replace APSystems ECU-R
@kadzsol i would use also a spearated gateway for as a fake ECU i think a sonoff zigbeebride would be great because it is cheap wifi an ESP8266 with tasmota can run on it custom firmware files for CC2531 can be flashed directly via tasmota via serial comunication on this board ... but for now it is may relevant in the future.
Do you have somewhere the code changes listed will try it too.
Has someone created a pairing sequence out of a sniffs to toggle YC/QS to send data ?
btw i odered a second CC2531 to sniff and send at the same time ..
Hi @gamer123, i have added the following peace of code to the static void zclGenericApp_HandleKeys( byte shift, byte keys ) function of the GenericApp example in order to transmit my own zigbee frame:
afAddrType_t TransmitApp_DstAddr;
TransmitApp_DstAddr.addrMode = (afAddrMode_t)AddrBroadcast;
TransmitApp_DstAddr.endPoint = 0;
TransmitApp_DstAddr.addr.shortAddr = 0;
endPointDesc_t TransmitApp_epDesc;
byte TransmitApp_TaskID;
// These constants are only for example and should be changed to the
// device's needs
#define TRANSMITAPP_ENDPOINT 1
#define TRANSMITAPP_PROFID 0x0F05
#define TRANSMITAPP_DEVICEID 0x0001
#define TRANSMITAPP_DEVICE_VERSION 0
#define TRANSMITAPP_FLAGS 0
#define TRANSMITAPP_MAX_CLUSTERS 1
#define TRANSMITAPP_CLUSTERID_TESTMSG 1
// This is the Cluster ID List and should be filled with Application
// specific cluster IDs.
const cId_t TransmitApp_ClusterList[TRANSMITAPP_MAX_CLUSTERS] =
{
1 // MSG Cluster ID
};
const SimpleDescriptionFormat_t TransmitApp_SimpleDesc =
{
TRANSMITAPP_ENDPOINT, // int Endpoint;
TRANSMITAPP_PROFID, // uint16 AppProfId[2];
TRANSMITAPP_DEVICEID, // uint16 AppDeviceId[2];
TRANSMITAPP_DEVICE_VERSION, // int AppDevVer:4;
TRANSMITAPP_FLAGS, // int AppFlags:4;
TRANSMITAPP_MAX_CLUSTERS, // byte AppNumInClusters;
(cId_t *)TransmitApp_ClusterList, // byte *pAppInClusterList;
TRANSMITAPP_MAX_CLUSTERS, // byte AppNumInClusters;
(cId_t *)TransmitApp_ClusterList // byte *pAppInClusterList;
};
TransmitApp_epDesc.endPoint = TRANSMITAPP_ENDPOINT;
TransmitApp_epDesc.task_id = &TransmitApp_TaskID;
TransmitApp_epDesc.simpleDesc
= (SimpleDescriptionFormat_t *)&TransmitApp_SimpleDesc;
TransmitApp_epDesc.latencyReq = noLatencyReqs;
uint8 tmp;
uint16 len;
static byte TransmitApp_TransID = 0;
// This is the buffer that is sent out as data.
byte TransmitApp_Msg[ 10 ]; // max len = 10
tmp = HI_UINT8( '0' );
tmp += '0';
TransmitApp_Msg[2] = tmp;
tmp = LO_UINT8( '0' );
tmp += '0';
TransmitApp_Msg[3] = tmp;
len = 10;
uint8 AF_DataRequestDiscoverRoute = TRUE;
tmp = AF_DataRequest( &TransmitApp_DstAddr, &TransmitApp_epDesc,
1,
len, TransmitApp_Msg,
&TransmitApp_TransID,
0, // no ACK required
AF_DEFAULT_RADIUS );
Before you can do any coding, you need to create/setup a dvelopment environment and compile examples: #4221 (comment)
@kadzsol until here it was no big deal
i used this project.
For the code in my project are some buttons in this function programmed. see here:
the value you handover in this function are not used in you code ? ( byte shift, byte keys )
i removed now all this gibberish
So comiling is possible but with a warning.. so i think i am working in the wrong file ? Or am i wrong ?
should we create a discord channel ?
@gamer123 I have found my discord login so yes, let us do it :-) I am also kadzsol on discord :-))
Indeed, the values I handover in that function are not used. I just hardcoded some code for now for transmittion of a many-to-one route request. This is the first frame the ECU sends when it is powered on. My idea was to send this hardcoded frame when I press the switch button on my transmitter cc2531 and see the manyto-one route request comming in on my sniffer cc2531. But is is not working....