Agree on that, wifi pull has been stable. It’s almost like the firmware updates increased stability 
Could you share a APS18AA string (hide ecu id if you want)? just curious on the values. First part should be the same as it’s summary, per inverter and channel would a repetitive.
FYI I did get a failed message after sunset, but it’s now 9:20A and sun is shinning, and still getting failed. If I check my HA implementation via the wifi method and the EMA app is showing 5235W of current production.
If I can get it to give me valid data gain, I’ll certainly post it.
What I observed:
After the ECU has sent the data to the cloud query_result gives Failed. About 2 minutes later (probably after the ECU has collected new data from inverters) query_result returns APS18xxx with a new timestamp and data.
Ok, after 4 attempts of query_result I got a valid response again
Here’s the data I received:
APS18AA982AAAAAAA121600004783200006884000000574696000001457120210203104308007000000END80200010441308241005991270000010380000008665010040606602275427300200412065022781273003004160660233772800040041206602326827900END80200011026908242006001270000010320000008615610041506402264527100200409065022754273003004070670232832790040040806602297127500END80200011054908242006001260000010100000008443310040006402196626300200395065022060264003004050650226572710040040706702313827700END80200011131408242005991250000010380000008670110041306402250327000200412065022804273003004120670235382820040041206602338928000END80200011234208242006001250000010460000008730310040906502254527000200412066023146277003004090670233392800040041506702384428600END80200011330408241006001130000002600000002177610040706602313027700200068000000017000003000050010000050000040001000100001200000END80200011352308241006001260000010440000008719210040806502281027300200410065022739272003004120670234212810040041606702378528500END
kind of matches predictions: i have 2 channels, you have 4…
APS18AA702AAAAAAA12160000MINE 0000009200000000829100 00001657 20210201162017007000000END 408000094016 07 224 00 499 10400000 013000000001116 1 0031 800200060200700 2 0032 800200058500700END
APS18AA982AAAAAAA12160000YOURS 0000688400000057469600 00014571 20210203104308007000000END 802000104413 08 241 00 599 12700000 103800000086650 1 0040 606602275427300 2 0041 206502278127 3 0030 041606602337728000 4 0041 206602326827900END
ids… running totals per timeslot , total lifetime, date, inverterid , 7/8, Volts, 00, freq, temp , running total inverter, channel nr1, power W, somtheing, channnerl nr 2 etc
Has anyone tried querying this repeatedly in a loop to see if it’s more stable than the wifi method? I can probably easily adapt my code to use this method instead.
no i haven’t, as it needs to be ethernet connected which i dont have at hand directly. Is wifi available when ethernet is attached?
The current integration is doing pretty good still. Might look at ethernet polling little later when i’m done with zwave JS move
Doesn’t look like getting data from port 4540 on the wifi interface is an option. I get connection refused, but does work on ethernet.
I agree with you, on WiFi you do not get a response when using 4540, even after lengthy inquiries.
I run the query every second. Data is returned for 1 minute every four minutes. But I’ve seen larger data returns of a minute and a half (in these cases the ECU timestamp was the same and no other data changed). Interval between failed and first returned data in all cases is four minutes. No communication errors occur.
This method is simpler than the existing method where the ECU ID must first be requested via a query.
The worst case scenario with this method is that you have to wait four minutes before results are visible in HA. Also a ethernet cable connection is required.
For cloudless operations:
I let the query run with 1 second interval… In the meantime I’ve blocked all the APsystems domains. The current integration via WiFi is failing because of the blocked domains. Good news is that the ethernet query is still going strong! If all goes well for the next 24 hours (because we have to see how the ECU handles this), it also means cloudless operations optional for those who want that and no difficult proxy needed to fake connections. Btw. in this state, more data returns are present and “failed” intervals are shorter, every two minutes.
ECU-R has now detected “no internet connection” after 1.5 hours, Internet disconnected is shown via the ECU-R Access Point in the ECUAPP. Ethernet is still operational and query still runs.
When the inverter is down, the return data remains “failed”. Response is very good and without errors.
In other words, this solution looks stable and very promising. Many thanks @Wadzio! I would vote for this solution 
1 Like
This method does have an issue,… after about 1900 queries per second, the ECU-R node became unreachable. I needed to hardware reset the ECU 
That s mimicking ddos 
I meant it differently than I wrote it down 
. I read the port about 1900 times with an interval of 1 second. After this, the ECU was no longer accessible (also no icmp response to ping). I will measure again tomorrow with a larger interval to be sure. Too bad if it is not possible, sockets are flushed on the ECU side so it is strange that the interface seems to fail.
Why do you ask so often? Unless you are doing tests 
In fact, in the ECU there is a mid(low)-range processor. So don’t expect router performance 
For something completely different. I found such a interesting thing. (this is for those who have a TCP proxy)
After receiving the packet (ports 8895,8896,8897)(xxxx it’s a EcuId)
APS1300051A101AAA0xxxxxxxxxxxxA10100000000000000ENDI sent back to the ECU:
APS13AAA66A108AAA0xxxxxxxxxxxx20210210204215ENDWiredNetworkInfoENDThe ECU responds with a packet confirming the command:
APS1300052A100AAA0xxxxxxxxxxxxA108202102102042150ENDAnd few seconds later ECU sends a packet like this
APS1300187A174AAA0xxxxxxxxxxxx000100000000000000ENDxxxxxxxxxxxx118@IP:yyy.yyy.yyy.yyy@netmask:255.255.255.0@gw:yyy.yyy.yyy.yyy@DNS1:yyy.yyy.yyy.yyy@DNS1:yyy.yyy.yyy.yyy@MAC:yy:yy:yy:yy:yy:yyENDSo (conclusion after firmware analysis) APS can remotely read and set various parameters in the ECU 
Oh, I’m just stress testing. It seems to go beter now that I have it at a two seconds interval. It’s proven to be stable over a longer time period. As I mentioned earlier repeated sequence is one minute data and four minutes “failed” so there’s no need to query that often. I hope this functionality stays in place with firmware updates. Your findings are the reason why I don’t want to use the EMA cloud and block domains.
Here’s the sheet for the YC600 inverter and hopefully the QS1, still some data to work out, but glad we have the YC1000 also. @ksheumaker, what’s your opinion about this latest method of querying the ECU? Do you see an opportunity to make a new integration on this principle?
Sorry if I send my comment not having carefully read the very exhaustive communication here.
Thus there is a risk for me receiving a shitstorm for that.
But browsing all this it seems as if this project tries to reverse engineer the ECU Apps protocol which is used between the APP and the ECU, i.e. you will always need an ECO Hardware?
I’m also having an YC600 and got for a test an ECU-R and must complain that I’m very disappointed about that device. We have 10 of these devices as “balcony PV” in our village at various sides.
Besides it is extremely overpriced (€220 for some minor hardware parts, cost more then the YC600) everyone would need such ECU device. I myself decided NOT to buy such equipment as it seem not even to be satisfying for the normal user.
It seems to work only shortly after restart for a short period of time. Even if ECU is connected with ethernet the WLAN connection to the mobile is not shared, so a device using ECU and other stuff will always seen two WLAN connections etc? It phones all my data to AP systems and private uses seem not even to get access to this. So the ECU in my opinion is a no-go.
I just want to hint that there is another project working under zigbee2mqtt similarly on the same goal, but trying to reverse engineer the ZigBee traffic between the ECU and the YP devices. There is meanwhile a lot of progress as many contributed sniffer data, but in the moment it hangs a bit. Reason is the faulty implementation of the ZigBee protocol. Using zigbee2mqtt on a 4 Euro CC2531 it might be possible to request and receive the data directly from YP600, obsoleting the need for ECU.
If someone is interested the topic is discussed under https://github.com/Koenkk/zigbee2mqtt/issues/4221
Apologize if I disturbed the vibrant discussion here, but I thought a hint to that project might be of interest as well.
Hey, yes that project was known. however, i had an ecu already in my setup (couldnt bare to not know if all panels are producing or not) and looking at the tcp traffic showed it wasnt too hard to reverse engineer.
Your statement ’ It seems to work only shortly after restart for a short period of time’ isnt correct. The WLAN connection from the ECU is responding to queries. There seems also be an port working on the ethernet connection, which we didnt integrate yet.
Another option was to proxy the ‘data to cloud’ traffic and read that. That required a bit more fidling on network level. This option could also make you stop to cloud upload and just mimic the cloud system for the ECU.
From what i have seen what this ECU does:
- collects each inverter data
- buffers it till all are ready
- beams to cloud every 5 minutes (or 15 minutes if system is significantly lager)
- waits for a response that some data set was stored properly
- retries sending data to cloud if a timestamp didnt get confirmed to have been received
For listening on the zigbee network, seems to me personally ltitle more difficult. Yes you are right the money for the ECU is pretty steep if you see the hardware, but it also gives you the cloud system insights which need to be paid for too (even it’s chinese).
all in all, we did a pretty quick project and i’m happy with the results and options to cut it off from the cloud when we are ready for that.
@HAEdwin This looks pretty straightforward so I don’t see why I wouldn’t be able to alter the code to support this query method as well. I’ll probably keep both, and add a new config option in the yaml for the port to connect, and then based on the port, pick the right method.
I’m pretty busy with work right now so I don’t know how quickly I’ll be able to get to it. Might take me a few days to a week.
suggestion for the both options configurator is to make one to choose between ETH or WIFI connection. Then port numbers are predefined and users dont need to think.
I also agree with Sander. I’d assume most customers get their solar system from an installer which just includes the ECU-R as part of the package. I know that’s how mine was done, and here in the US it appears AP systems isn’t particularly DIY friendly.
I have at least a 10 year warranty from my installer, and If I report any issues with generation on a panel or inverter the first thing they will do is log into EMA and check what it’s showing there. I have no desire to remove access to that unless there is something that querying zigbee directly would get us that we can’t get via the IP methods.
I’ve been running my integration querying the ECU over wifi for the last month or so, and have had zero issues with the stability of the box. I agree it’s a lot of money for a cheap microcontroler system with a zigbee radio, but it does work - and I can do my own data collection in HA, and still login to the EMA app or website when I want/need to.
Yes, that is probably the most obvious way. Executing query_result with a 30 second interval always catches the data from port 4540 within the minute that it is available.