Rebuild binding - enphase envoy

What is the most straightforward way to rebuild an older binding? I would like to make some changes to the Enphase Envoy binding located here: https://github.com/HentschelT/openhab2-addons/tree/master/addons/binding/org.openhab.binding.enphaseenvoy

This binding appears to be compiled at the time of 2.3.0-snapshot. It does not appear that the binding was ever part of an openHAB release.

I have seen the instructions for new bindings here: https://www.openhab.org/docs/developer/#setup-the-development-environment, but I’m not exactly sure what to do with somewhat older existing bindings.

I’m currently running openHAB 2.5.0 released version.

Any pointers would be appreciated. Thanks.

I can’t say if this is the best approach but I would approach it as follows:

  • Create a skeleton per that guide
  • Copy over the relevant parts from the 2.3 binding into the skeleton
  • Fill in the gaps

@jswim788 Biggest change between 2.3 and 2.5 release is build system. Earlier used Tycho, later uses Bnd Tools. Code and API didn’t change much, however how runtime and compile dependencies are handled is different. Rich answer is a good pointer.

You can start here:

But due to the recent changes related to openHAB version 3.0.0 you need to start of the 2.5.x branch of openhab-addons

Where do I select the 2.5.x branch? When I got to this point in the Eclipse install, the ‘Stream’ only had a ‘master’ choice. Did something go wrong, or is there another place to select 2.5.x?

thanks

Did you get any closer to fixing that binding? I would love to help. I’m not sure how much i can help with coding / eclipse because i have a C# and VSTS background, but willing to help test, log and improve the functionality. I did some bug reports / feature requests to captndelta, but it seems he lost interest or lacks time to support/develope the binding.
As i try to avoid cloud stuff, i really like this binding is local only.

No, I didn’t get any further. I have realized that I don’t need this binding. The binding doesn’t do any control; it only collects data. For now I’m using the http binding to get the basic stats. This won’t get the individual inverters, but I’m not that interested in the lower level details. I have a script below that can be used for them if desired. My Items are:

Number EnvoyPower             "Solar Power [%.2f W]" { http="<[envoy:600000:JSONPATH($.wattsNow)]" }
Number EnvoyEnergyToday       "Solar Energy Today [%.2f Wh]" { http="<[envoy:600000:JSONPATH($.wattHoursToday)]" }
Number EnvoyEnergy7Days       "Solar Energy 7 Days [%.2f Wh]" { http="<[envoy:600000:JSONPATH($.wattHoursSevenDays)]" }
Number EnvoyEnergyLifetime    "Solar Energy Lifetime [%.2f Wh]" { http="<[envoy:600000:JSONPATH($.wattHoursLifetime)]" }

And my services/http.cfg has:

# Enphase Envoy
http:envoy.url=http://192.168.86.210/api/v1/production
# refresh every 10 minutes
http:envoy.updateInterval=600000

That works fine for me.

I did experiment a bit with getting the inverter data too. I have a couple of curl lines in a shell script that will post the data to an Item which you can then parse inside openHAB. If I were going to revisit this, I think I’d convert to python - and then bring it inside with jython and the new rules engine.

I’m slowly beginning to realize that bindings aren’t the answer to everything in openHAB. There are plenty of tools to connect and get data as needed.

#!/bin/sh

envoyProd=`curl --anyauth -u envoy:003302 http://192.168.86.210/api/v1/production 2>/dev/null`
envoyInverters=`curl --anyauth -u envoy:003302 http://192.168.86.210/api/v1/production/inverters`


curl --header "Content-Type: text/plain" --request POST --data "$envoyProd" http://192.168.86.212:8080/rest/items/EnvoyProd 2> /dev/null
curl --header "Content-Type: text/plain" --request POST --data "$envoyInverters" http://192.168.86.212:8080/rest/items/EnvoyInverters 2> /dev/null