[binding request] APSystems Micro-Inverter EZ1-M

[LukaNoah]

APSystems has provided the EZ1 microinverters with a local API (description attached). With a binding, you would have the inverter as a thing and would not have to update the items with scripts. Unfortunately it doesn't work with the HTTP binding because json with multiple values are returned. There is already a HomeAssistant integration... For beginners it would be perfect to have a binding.

Best regards Heiko

1701255814508-apsystems-ez1-local-api-user-manual.pdf

[deibich]

I'm also interested in the local API. Is anyone already developing a binding? If not, I'll start developing one in the next few days. The API description looks very straightforward, and it should be possible to get something up and running quickly.

[deibich]

Hey, made a first version.

Source & Readme: https://github.com/deibich/openhab-addons-apsystemsez1/tree/APsystemsEZ1/bundles/org.openhab.binding.apsystemsez1 Release: https://github.com/deibich/openhab-addons-apsystemsez1/releases

I'll create a topic in the forum and make the addon available in the marketplace over the weekend, if I find the time.

[2relativ]

Hey, made a first version.

Source & Readme: https://github.com/deibich/openhab-addons-apsystemsez1/tree/APsystemsEZ1/bundles/org.openhab.binding.apsystemsez1 Release: https://github.com/deibich/openhab-addons-apsystemsez1/releases

I'll create a topic in the forum and make the addon available in the marketplace over the weekend, if I find the time.

Thank you :) Just installed my new inverter and this binding. Will test it. So far, no issues. How can I support this to go from marketplace to an official binding?

[lsiepel]

Hey, made a first version. Source & Readme: https://github.com/deibich/openhab-addons-apsystemsez1/tree/APsystemsEZ1/bundles/org.openhab.binding.apsystemsez1 Release: https://github.com/deibich/openhab-addons-apsystemsez1/releases I'll create a topic in the forum and make the addon available in the marketplace over the weekend, if I find the time.

Thank you :) Just installed my new inverter and this binding. Will test it. So far, no issues. How can I support this to go from marketplace to an official binding?

Did a short quick scan, allready looks solid. You might want to adjust the thing-type.xml with labels to 2-3 words < 23 chars and capitalized. Most important are lower-case-hypen naming convention for channel names as that would be breaking if you move it from marketplace to openhab itself. Good to see that is allready done!

[deibich]

Hey, made a first version. Source & Readme: https://github.com/deibich/openhab-addons-apsystemsez1/tree/APsystemsEZ1/bundles/org.openhab.binding.apsystemsez1 Release: https://github.com/deibich/openhab-addons-apsystemsez1/releases I'll create a topic in the forum and make the addon available in the marketplace over the weekend, if I find the time.

Thank you :) Just installed my new inverter and this binding. Will test it. So far, no issues. How can I support this to go from marketplace to an official binding?

Did a short quick scan, allready looks solid. You might want to adjust the thing-type.xml with labels to 2-3 words < 23 chars and capitalized. Most important are lower-case-hypen naming convention for channel names as that would be breaking if you move it from marketplace to openhab itself. Good to see that is allready done!

Thank you for taking a look at the code. I will change the labels and submit a pull request soon.

[2relativ]

Moin, was mir noch so aufgefallen ist und ich nicht ganz nachvollziehen kann. Ab und an sind bei Energy Lifetime diese Einbrüche. Aber das ist so kurz, dass ich da nicht einmal drauf zeigen kann. Ich bin mir auch noch nicht sicher, woher das kommt. Ob vom Inverter, meinem Setup oder der API.

Edit: Ich sehe die gleichen Einbrüche zur gleichen Zeit auch bei den Panels. Es muss also ein zusammenhängender Faktor sein.

[lsiepel]

was mir noch so aufgefallen ist und ich nicht ganz nachvollziehen kann. Ab und an sind bei Energy Lifetime diese Einbrüche. Aber das ist so kurz, dass ich da nicht einmal drauf zeigen kann. Ich bin mir auch noch nicht sicher, woher das kommt. Ob vom Inverter, mei

English please.

[2relativ]

Ah, shoot. Sorry. 😅 Too early in the morning. What I was saying is that I noticed some drops in the total energy channel. I see the same drops on each panel. Does anyone else notice this? Or is my setup faulty?

[2relativ]

Another little feedback: At least while on mobile it is irritating that channels are labeled the same by default. Example "Energy lifetime". You can link both panels and the device itself and you can't really tell on mobile. Maybe change the labeling a little bit?

[2relativ]

Ah, shoot. Sorry. 😅 Too early in the morning. What I was saying is that I noticed some drops in the total energy channel. I see the same drops on each panel. Does anyone else notice this? Or is my setup faulty?

Regarding this with the drop ins... I set the pull intervall to 20 seconds. I oriented myself by the shelly binding which also has 20 seconds as default. Now the graph looks nicer 😁👍🏻 maybe set the default to 20 seconds?

[deibich]

Ah, shoot. Sorry. 😅 Too early in the morning. What I was saying is that I noticed some drops in the total energy channel. I see the same drops on each panel. Does anyone else notice this? Or is my setup faulty?

Regarding this with the drop ins... I set the pull intervall to 20 seconds. I oriented myself by the shelly binding which also has 20 seconds as default. Now the graph looks nicer 😁👍🏻 maybe set the default to 20 seconds?

I see those drops too. But don't know why. The binding should just forwards the response from the inverter to the channels. I expect the inverter to response with invalid data.

Each response from the inverter comes with a message which can be SUCCESSor FAILED. The API does not describe the key in detail. It might indicate whether the request was successful or not. At the moment The binding does not check the value of this key.

You can set the log of org.openhab.binding.apsystemsez1 to DEBUG to analyze the response from the inverter if you like. The log contains the key value pair message.

I'll review my log in the coming days.

[deibich]

Another little feedback: At least while on mobile it is irritating that channels are labeled the same by default. Example "Energy lifetime". You can link both panels and the device itself and you can't really tell on mobile. Maybe change the labeling a little bit?

Yeah this comes from the reuse of the same channel-types. I'm not sure if same channel-type can get different descriptions in different channel-groups. I'll check it out. Otherwise different channel-types must be defined.

[deibich]

I have analyzed my logs, and the drops in the graph seem to be related to unsuccessful responses from the inverter. For example:

[DEBUG] [temsez1.internal.APsystemsEZ1Handler] - Response from endpoint /getOutputData: EZ1OutputDataResponseData [message=FAILED, deviceId=XXXXXX, data=Data [p1=0.0, e1=0.0, te1=0.0, p2=0.0, e2=0.0, te2=0.0]]

The binding now drops responses that are not successful (message is not SUCCESS).

Occasionally, the inverter responds with a SUCCESS but leaves the data object empty. This happens to me exclusively with the /getOnOff endpoint.

[TRACE] [temsez1.internal.APsystemsEZ1Handler] - Raw Response: {"data":{"status":""},"message":"SUCCESS","deviceId":"XXXXXX"}
[DEBUG] [temsez1.internal.APsystemsEZ1Handler] - Response from endpoint /getOnOff: EZ1OnOffResponseData [message=SUCCESS, deviceId=XXXXXX, data=Data [status=]]

status should be 1or 0

[Gehetzter]

First of all I really like to thank @deibich for creating this binding!

I've got two requests for improvement:

1. Could you please send the requests to the device only if the corresponding channels are linked? I only use the power and energy values but see all 4 api requests in the log. Sometimes the getOnOff request fails and I get a warning in my log then but I don't even use it. Maybe there are people running this thing over a mobile network with limited data volume. Could benefit too.

2. It would be great to retry a failed request. Maybe for a configurable amount in advanced settings?

[deibich]

Thank you for your input.

First of all I really like to thank @deibich for creating this binding!

I've got two requests for improvement:

1. Could you please send the requests to the device only if the corresponding channels are linked?
   I only use the power and energy values but see all 4 api requests in the log.
   Sometimes the getOnOff request fails and I get a warning in my log then but I don't even use it.
   Maybe there are people running this thing over a mobile network with limited data volume. Could benefit too.

Currently the binding just polls all five endpoints. This was easier to start with in the first place. Since there is not much data send and I use the binding in my home WIFI this was not considered by me.

A simple check if the corresponding Channel is linked should be easy doable.

2. It would be great to retry a failed request. Maybe for a configurable amount in advanced settings?

Do you talk about a failed request in terms of "network failure"? Currently the Thing goes offline if a request fails. But the binding sends a request every "refreshIntervalSeconds" and comes back online if the inverter is available then.

[Gehetzter]

Do you talk about a failed request in terms of "network failure"? Currently the Thing goes offline if a request fails. But the binding sends a request every "refreshIntervalSeconds" and comes back online if the inverter is available then.

No, I don't mean a network failure, even though I don't know what's causing this in my case. In my setup sometimes a response from the inverter doesn't contain the SUCCESS message, but I'm sure the inverter sends the data like this. Data is then dropped by the binding, which is great, but an instant retry would be great, to not miss a point in time, e.g. when I pull every minute and one response is dropped I'm missing the data of this specific minute. Wouldn't care if the data comes in correct a bit off in time because of the retry.

[deibich]

So you experience the same as described in a previous comment: https://github.com/openhab/openhab-addons/issues/16449#issuecomment-2156739376 , too?

Should be possible to implement a simple retry. Also a second parameter with a configurable timeout for a failed request as a advanced setting, like you already described, would be nice.

I was a quiet busy in the past but think I could implement the basic functionality in the near future.

[Gehetzter]

So you experience the same as described in a previous comment: #16449 (comment) , too?

Yes, you're right. I haven't noticed that it's exclusively the /getOnOff, but you could be right. Should be possible to implement a simple retry. Also a second parameter with a configurable timeout for a failed request as a advanced setting, like you already described, would be nice.

I was a quiet busy in the past but think I could implement the basic functionality in the near future.

I would be very pleased if you could include it to your roadmap, no need to rush, your private life comes first. As a workaround I've just changed the log level of the binding to get rid of the entries in frontail...