Until today i used the version from captndelta. I did have som issue’s (log flooding, no UoM and no textual config), but that should be fixed with this version.
This binding hasn’t made it into 3.0 did it? This binding is one of the ‘problems’ that keep me from updating. So if i can help with this binding in any way, please let me know. I have just installed it and will report back in a while. Great thanks!
I’ve updated the Enphase binding to better handle different envoy versions. It’s still a 2.5 version. You can find the kar file here: Release Enphase 2.5.x binding (28-12-2020) · Hilbrand/openhab-addons · GitHub If this version works oke. I’ll create a 3.0 version.
Downloaded it and will report back in a while. I noticed the previous version had some “test” channels.
Different question: The relay is that some additional device you need of you’re using a 3 phase envoy? I’m currently looking after some more solar panels and will need to switch from singel phase to 3 phase.
Isiepel,
The relay connects to the envoy and connects/disconnects the micros from the grid if the power grid has problems, to stop islanding ect. They are for both single & three phase systems.
It would be wonderful to see this binding in OH3, I just switched to OH3 and am missing my Enphase data.
Thanks for your efforts on this one Hilbrand!
Cheers,
Two weeks without problem, so i guess it worked as expected. Enphase is the only binding keeping me from upgrading to 3.0, so i hope it get’s a port soon. Thanks!
I’ve created a pull request for the openHAB 3 enphase binding. You can find it on openhab-addons pr 9883 Including installation instructions for as long it’s not merged yet.
Here is the output from my Envoy-S Metered, Production and Consumption CT (Stromwandler/CurrentTransformer) are installed. The type eim is the data from CT.
http://envoyip/production.json?details=1
I extract all the data from my device using http binding and JSON transformation.
It will be nice if U extend the Thing channels with all the available data.
P.S. - Data refresh (production.json) can be set to 1sec or les without any problem.
{
"production":[
{
"type":"inverters",
"activeCount":18,
"readingTime":1611243851,
"wNow":3,
"whLifetime":4031547
},
{
"type":"eim",
"activeCount":1,
"measurementType":"production",
"readingTime":1611244736,
"wNow":-11.939,
"whLifetime":4070747.841,
"varhLeadLifetime":2.023,
"varhLagLifetime":1696448.807,
"vahLifetime":5427814.82,
"rmsCurrent":1.287,
"rmsVoltage":721.03,
"reactPwr":281.239,
"apprntPwr":309.4,
"pwrFactor":-0.02,
"whToday":17195.841,
"whLastSevenDays":73897.841,
"vahToday":20793.82,
"varhLeadToday":1.023,
"varhLagToday":5183.807,
"lines":[
{
"wNow":-3.907,
"whLifetime":1357820.548,
"varhLeadLifetime":0.617,
"varhLagLifetime":560711.884,
"vahLifetime":1831382.324,
"rmsCurrent":0.446,
"rmsVoltage":239.093,
"reactPwr":96.598,
"apprntPwr":106.694,
"pwrFactor":-0.05,
"whToday":5670.548,
"whLastSevenDays":24481.548,
"vahToday":6933.324,
"varhLeadToday":0.617,
"varhLagToday":1722.884
},
{
"wNow":-3.605,
"whLifetime":1356569.863,
"varhLeadLifetime":0.151,
"varhLagLifetime":571694.04,
"vahLifetime":1862125.294,
"rmsCurrent":0.486,
"rmsVoltage":241.336,
"reactPwr":99.337,
"apprntPwr":117.401,
"pwrFactor":0.0,
"whToday":5774.863,
"whLastSevenDays":24721.863,
"vahToday":7108.294,
"varhLeadToday":0.151,
"varhLagToday":1746.04
},
{
"wNow":-4.427,
"whLifetime":1356357.43,
"varhLeadLifetime":1.254,
"varhLagLifetime":564042.883,
"vahLifetime":1734307.202,
"rmsCurrent":0.354,
"rmsVoltage":240.6,
"reactPwr":85.305,
"apprntPwr":85.305,
"pwrFactor":0.0,
"whToday":5750.43,
"whLastSevenDays":24694.43,
"vahToday":6752.202,
"varhLeadToday":0.254,
"varhLagToday":1714.883
}
]
}
],
"consumption":[
{
"type":"eim",
"activeCount":1,
"measurementType":"total-consumption",
"readingTime":1611244736,
"wNow":1142.869,
"whLifetime":3494792.154,
"varhLeadLifetime":2695137.802,
"varhLagLifetime":1718172.286,
"vahLifetime":7110429.289,
"rmsCurrent":7.44,
"rmsVoltage":720.81,
"reactPwr":-554.301,
"apprntPwr":5362.783,
"pwrFactor":0.21,
"whToday":10997.154,
"whLastSevenDays":100066.154,
"vahToday":24532.289,
"varhLeadToday":7834.802,
"varhLagToday":5237.286,
"lines":[
{
"wNow":82.572,
"whLifetime":668760.365,
"varhLeadLifetime":807797.626,
"varhLagLifetime":572150.694,
"vahLifetime":2015671.925,
"rmsCurrent":1.142,
"rmsVoltage":238.986,
"reactPwr":-215.117,
"apprntPwr":272.959,
"pwrFactor":0.3,
"whToday":959.365,
"whLastSevenDays":17551.365,
"vahToday":7144.925,
"varhLeadToday":2637.626,
"varhLagToday":1726.694
},
{
"wNow":458.961,
"whLifetime":1899279.729,
"varhLeadLifetime":1191924.317,
"varhLagLifetime":573644.573,
"vahLifetime":3081267.732,
"rmsCurrent":2.963,
"rmsVoltage":241.262,
"reactPwr":-272.561,
"apprntPwr":714.794,
"pwrFactor":0.64,
"whToday":6300.729,
"whLastSevenDays":57012.729,
"vahToday":9142.732,
"varhLeadToday":3186.317,
"varhLagToday":1746.573
},
{
"wNow":601.335,
"whLifetime":926752.06,
"varhLeadLifetime":695415.859,
"varhLagLifetime":572377.019,
"vahLifetime":2013489.633,
"rmsCurrent":3.335,
"rmsVoltage":240.561,
"reactPwr":-66.624,
"apprntPwr":802.287,
"pwrFactor":0.75,
"whToday":3737.06,
"whLastSevenDays":25502.06,
"vahToday":8244.633,
"varhLeadToday":2010.859,
"varhLagToday":1764.019
}
]
},
{
"type":"eim",
"activeCount":1,
"measurementType":"net-consumption",
"readingTime":1611244736,
"wNow":1154.807,
"whLifetime":2332710.273,
"varhLeadLifetime":2695135.779,
"varhLagLifetime":21723.479,
"vahLifetime":7110429.289,
"rmsCurrent":6.153,
"rmsVoltage":720.589,
"reactPwr":-273.062,
"apprntPwr":1471.555,
"pwrFactor":0.78,
"whToday":0,
"whLastSevenDays":0,
"vahToday":0,
"varhLeadToday":0,
"varhLagToday":0,
"lines":[
{
"wNow":86.479,
"whLifetime":383819.816,
"varhLeadLifetime":807797.009,
"varhLagLifetime":11438.81,
"vahLifetime":2015671.925,
"rmsCurrent":0.696,
"rmsVoltage":238.879,
"reactPwr":-118.519,
"apprntPwr":166.395,
"pwrFactor":0.52,
"whToday":0,
"whLastSevenDays":0,
"vahToday":0,
"varhLeadToday":0,
"varhLagToday":0
},
{
"wNow":462.566,
"whLifetime":1362567.111,
"varhLeadLifetime":1191924.166,
"varhLagLifetime":1950.533,
"vahLifetime":3081267.732,
"rmsCurrent":2.477,
"rmsVoltage":241.188,
"reactPwr":-173.224,
"apprntPwr":586.999,
"pwrFactor":0.78,
"whToday":0,
"whLastSevenDays":0,
"vahToday":0,
"varhLeadToday":0,
"varhLagToday":0
},
{
"wNow":605.763,
"whLifetime":586323.345,
"varhLeadLifetime":695414.605,
"varhLagLifetime":8334.136,
"vahLifetime":2013489.633,
"rmsCurrent":2.981,
"rmsVoltage":240.522,
"reactPwr":18.681,
"apprntPwr":718.161,
"pwrFactor":0.85,
"whToday":0,
"whLastSevenDays":0,
"vahToday":0,
"varhLeadToday":0,
"varhLagToday":0
}
]
}
],
"storage":[
{
"type":"acb",
"activeCount":0,
"readingTime":0,
"wNow":0,
"whNow":0,
"state":"idle"
}
]
}I had looked at this before. But on my system I get mostly 0 values on this call. So this means I have to adapt the binding to handle both situations when it contains useful information and when not. So at this moment I have no plans to support this because it would make it more complex. I’ve also limited information on what all these field mean, and what the unit is. That doesn’t make it easier either.
You get always response 0 because probably U don’t have Envoy-S Metered with installed Current Transformer for production and consumption data.
I think U need to add edditinal Thing type eim to the binding and corespondent channels.
All what U see in this JSON response is:
type inverters - production summary from inverters
type eim - production CT (summary and separate phase L1, L2, L3)
type eim - total-consumption CT (summary and separate phase L1, L2, L3)
type eim - net-consumption CT (summary and separate phase L1, L2, L3)
type acb - battery
Unit:
wNow - Power (Watt)
whToday - Watt Hour Today (Wh)
whLastSevenDays - Watt Hour Last 7 days (Wh)
whLifetime - Wat Hour Lifetime (Wh)
varhLeadLifetime - Capacitive Reactant Energy Lifetime (varh)
varhLagLifetime - Inductive Reactant Energy Lifetime (varh)
vahLifetime - Apparent Energy Volt Amper Hour Lifetime (VAh)
rmsCurrent - Current (A)
rmsVoltage - Voltage (V)
reactPwr - Reactant Power (var)
apprntPwr - Apparent Power (VA)
pwrFactor - Power Factor (cos fi)
vahToday - Apparent Energy Today (VAh)
varhLeadToday - Capacitive Reactant Energy Today (varh)
varhLagToday - Inductive Reactant Energy Today (varh)
May be U find time to extend the functionality of the binging.
Hi Hibrand,
I installed the Enphase binding version last night
[binding Enphase 2.5.x (19-01-2020)] (Release Enphase 2.5.x binding (19-01-2020) · Hilbrand/openhab-addons · GitHub)
it seems to me that it works well, I can read the Envoy values
but i get this error;
2021-02-16 13:45:04.413 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing ‘openhab-binding-enphase’[
I’m using openHAB 2.5.10 Release Build.
I congratulate you,
thanks for your help.
Duminik
The error suggest it could not install the binding. But that doesn’t make sense if you can read values. So I’m not sure what happens. What did you do to install the binding?
i installed the file
org.openhab.binding.enphase-2.5.12-SNAPSHOT in the addons folder
before installing the binding I did a cache cleanup with the command;
sudo openhab-cli clean-cache
as recommended
Yesterday, my installer finally got my new Enphase battery system installed, provisioned and working. It’s awesome.
However, they had to upgrade all the firmware including the firmware for the com modules which changed the authentication protocol. That, paired with the fact that this binding doesn’t support storage makes me want to go in and fix it. Is anyone still maintaining this binding? Anyone using it?
I am going to mess with the binding for my local use, but would like to publish changes that all can use so I need feedback so I can make good design choices.
I maintain the binding, but not actively working on it currently. So go for it.
Just got my solar system installed - Enphase gateway, inverters, and 10kWh battery. Hoping I can get this working once the utility company issues Permission to Operate post final inspections. Thanks for this binding!
Is anyone else experiencing weird negative values on a system without consumption metering? My Envoy regularly reports a negative value for the latest power, sometimes well in excess (negatively) of my system’s production capability (screenshot attached). I also get similarly weird negative numbers from my inverters. Is this a number conversion/scaling issue or something else (like signed integer vs. unsigned integer)? Is there a way to expose the actual value being read from the Envoy pre-conversion/-scaling? (edit: I managed to decrypt my installer password and the Envoy webpage itself is reporting negative values for some of the inverters. It sems the Envoy can’t do it correctly!)
Any luck in getting the authentication to work? I only have production and consumption data every 15 minutes. I would like to get shorter time windows (eg 15 sec, or 1 min…) and I would like all my inverters to show up like they did in the past.
Sorry…I was travelling the last few days.
Yes, I got it to work. However, I haven’t messed with in several months. I will try to dig it up later today and get the code in my github updated, then will give you access.
-Joe
Alright, I have resurrected the code and have the code working to get the JWT retrieved. Turns out, I still need to incorporate the switching between versions function.
@kumootje are you still interested in this? I can work on it over the next few days, but I will deprioritize if it’s not that big of deal to you
I’m certainly still interested. However, I won’t have the time in the next 2 weeks anyway to experiment. So do it on your own pace.
Just curious to know what’s the highest frequency of updates on the production and consumption numbers (like “Latest Power” & “Produced Today”). Now I’m only getting 15 minutes values…
And if the individual inverters are also accessible.
