Based on the protocol sheet for the YC600 I published earlier there are still unknown values of which I don’t know what their functions are. It seems that we are missing Today’s Energy and Signal Strength in this method of reading port 4540 @Wadzio, did you find any commands pointing in this direction? Below are some graphs based on full day data.
Here you can see the known values for the power channels. The MPPT label is a wild guess, more likely is the voltage on both channels (around 33 volts DC)
ECU current power represents the overall sum of power from all inverters. So Unknown0 could be the total power for this specific inverter but it seems to have somewhat lower values than ECU total power. I don’t understand why.
Does anyone know what the unknown values and MPPT? values represent?
A bit off-topic but since you mentioned it @checking12, how did the move to zwave JS go? Mine was succesfull, Google Assistant is reacting is a bit slower. I know you are using PiHole, ever tried to move to AdGuard Home? Also does a great job and functions the same way PiHole does. It also supports DNS rewrites.
Migration itself wasnt too easy for my battery powered sensors. Still have them disappear sometimes. Guess devs need to stabilize the js server and ha integration a bit more.
Our experience here in custom component creation shows it needs a little perseverance
Yep,… now that we have a better insight in what is being sent to EMA my concerns have diminished. Together with the missing parameters when using the latest method and well working integration it sure deminises the need to further put effort in this 4540 method unless the additional parameters pop-up.
To make the ECU-R integration fully compatible with inverters that can be attachted to it, it would be a great addition to add support for the YC1000 also. But that’s not up to me …but it could if I only would know how to do that.
Still a lot of questions indeed, the ECU still holds many secrets. What would be the purpose of port 4540 for example? Imagine that we do not extract more parameters from this than the method we now use with the integration, the search for a different approach is no longer valuable. I would find it a loss if the signal strength is no longer visible and it seems it is currently not included. At the moment I have shown with my version of the protocol sheet and the representation of unknown data in the graphs that for the combination of YC600 and ECU-R at least there are no more parameters in it. So far the 4540 method is somewhat confusing and does not add value imho.
I will try and get to writing the ethernet HA plugin this weekend - maybe if we collected this at the same time as the wifi collection method there can be some correlation between some of these unknown values and what we get on the wifi method.
I’ve been following this thread (and the Tweakers discussion) and using the HA integration since my AP Systems setup is operational (1 month now).
First of all a big thank you to everyone involved, using the integration in HA gives me much more control over the details collected by the system.
Although the ECU-R WiFi works well most of the time, I do have a ‘unavailable’ ECU-R occasionally.
It went wel for 2 weeks, but sometimes the ECU-R is unavailable twice a day, several days in a row. Restarting the ECU-R resolves it, but when I’m not around to do that data is lost for an extensive period.
(tried to setup an automation to powercycle the ECU-R, but nu luck with that so far)
I’m really looking forward to using the fixed NIC port on the ECU-R instead of Wifi, even if some of the details like ‘Signal’ are missing.
Have you checked whether the ECU-R has a fixed IP address via WiFi? Is there a stable connection between AP and ECU-R? Personally, I encounter little to no problems with the HA integration at the moment and I am still very happy with it. If the NIC is used, there are two solutions; the proxy method or the 4540 method. The advantage of the proxy method is that it can (optionally) be placed between ECU-R and EMA, whereby the choice could be made to leave the EMA cloud out. in most cases, wired is indeed better. But when I look at the amount of parameters, the current WiFi method seems to be the best solution.
Yes, the ECU-R always has the same Wifi IP (DHCP reservation in a a fully managed Unifi network here).
I’m a little hesitant about using the proxy method (and pulling all DNS traffic through a Pihole, another dependency in the network on which a whole family relies ).
The 4540 method as an option in the integration would be great.
I did notice something strange though: I looked at the ‘entities’ in HA after the ECU-R became unavailable and noticed duplicate entities (1 normal, 1 disabled) for the ECU-R sensors.
No duplicate entries for the Inverter entities, just the 4 or 5 ECU-R entities.
I deleted those (several times, they re-appear after another ‘unavailable’ occurrence) but will make a screenshot the next time this happens.
I started the integration this weekend, I just didn’t get very far due to other obligations.
What I did find, was that I’m having a hard time to have the socket give me data, most of the time I get the ‘failed’ message and have to keep trying over and over again. Makes it a bit harder to debug and make sure you got everything right, when you can only get data every ~5 minutes.
Yes I can imagine, what you could do in pseudo code; If rdata=“failed” then rdata=“APS…END” and take a valid string earlier received. Although the data is old, the program would still be able to go through the whole proces. Damn shame the disassembly shows “unkfloatxx” it doesn’t shine any light to the meaning of those parameters. Sometimes I wonder if it wouldn’t be better to just ask APsystems to provide us a solution so we can integrate the ECU-R into HA. It wouldn’t hurt the features of the device.
UnkFloatxxx are frustrating me also There are some(lot) mathematical calculation which I don’t understand yet. So, I’m attaching some disassembled functions where (for me) are the main calculations for those UnkFloatxxx from ZigBee readouts. Maybe someone will be helpful, smarter than me Maybe someone from Github discussion also will help?
Disasm seems to be concentrated around the processing of the Zigbee data string. This may be useful for the GitHub folks who want to build an integration via Zigbee. Can you also find something around the 4540 port where the send data part is? Perhaps there is more about the way in which the data is built up there. I thought this factor was funny, 0.9399999999999999
i’m looking for some help to get some Data from the ECU-R to Iobroker.
Is there anywhere a script or something like that?
Also i don’t know how to get the new firmware…
Unexpected error fetching apsystems_ecur data: Error using cached data for more than 5 times.
11:14:27 – APSystems PV solar ECU-R (ERROR) - message first occurred at 11:10:27 and shows up 5 times
Using cached data from last successful communication from ECU. Error: [Errno 111] Connect call failed ('192.168.2.99', 8899)
11:14:27 – APSystems PV solar ECU-R (WARNING) - message first occurred at 11:07:27 and shows up 8 times
Using cached data from last successful communication from ECU. Error: Incomplete data from ECU after 3 attempts, cmd='APS1100160001END' data=b''
11:06:27 – APSystems PV solar ECU-R (WARNING) - message first occurred at 11:05:12 and shows up 2 times
My ECU was updated to the latetset firmware (ECU_R_1.2.16009) a few days ago, so that didn’t help.
@ksheumaker : when building a new version for the integration, please note that it now requires a version number in het manifest. More info here: “Custom integrations: Version warning”
…but it could if I only would know how to do that.
).
There are some(lot) mathematical calculation which I don’t understand yet. So, I’m attaching some disassembled functions where (for me) are the main calculations for those UnkFloatxxx from ZigBee readouts. Maybe someone will be helpful, smarter than me 
Maybe someone from Github discussion also will help?
