Thanks, I’ll take a look at it. Meanwhile, let me know how beta1 works.
It works, most of the informations are unavailable, the others are generally correct and it works. I’ll check tomorrow morning with the solar part working.
1 Like
Great. The unavailable sensors are related to 3-phase inverters. I will find a way to not create them in case of single-phase inverters. At least you now have a working component, just use the sensors needed.
Then I will see if I can add the battery info. But for that you need to tell me which values are needed, because there are hundreds of values in that excel file, and I feel 80% of them is not needed.
If you use FIMER website/software for monitoring, and it shows the battery info, let me see what info it provides so we can make a comprehensive list.
Thank you.
This is what I found: inspecting with developer tools, for every value in the Fimer web dashboard there is an associated html ID. Those ID are the same used inside the sunspec excel file. For example, battery state of charge (SoC) has “soc” ID and the same iD on modbus value 41375.
Tomorrow I’ll try to match any relevant value to the ID in the dashboard. The new energy dashboard in HA uses just 5/6 sensors to create the chart.
Excellent job Federico. I’ll wait for your list. Meanwhile I’m fixing some issues on beta1…
Good night,
Alessandro
@monkeypr00f Federico, v2.0-beta2 is out, if you reinstall via HACS you should see it. Before reinstalling, first delete it from the integrations, so that all previous sensors are deleted and recreated from scratch, then reinstall from HACS and choose beta2, then add the integration again. Now you won’t see the unavailable sensors anymore. Let me know if that is the case. Thanks.
It’s correct, the unavailable sensors are not there anymore. Btw I’m working on the data, the two values we can use with the dashboard are these ones, the first is the total consumption (solar + grid + batteries), the second the solar power (probably even the batteries effort will increase that value, i’ll check later after sunset). Using Sunspec the state of charge of the batteries is not retrieved, even if the module is available both in the integration and in the modbus.
There’s a problem. Those are power sensors of the production, not energy sensor. Where are you using those in the Energy Integration? I found an issue on the component, STATE_CLASS was not being set correctly, I think I’ve fixed it in v2.0-beta5 just released. The main sensor of the component to be used with the energy integration is Total_Energy, which is the lifetime sensor of the energy produced by the inverter.
Ciao Alessandro I waited a couple of days just to see if everything is working…and i can say it does!
Still i don’t understand why HA shows the daily amount of KWh instead the realtime production inside the circle animation, btw the data inside the chart are correct.
Do you think it is possible to retrieve the power from/to the grid and from/to the batteries?
Inside the 65234 module (batteries) there are a couple of values:
| Address | Name | Label | Index | Type | Units | SF | Value | Subvalue | R/W | Conformance Notes |
|---|---|---|---|---|---|---|---|---|---|---|
| 41375 | SoC | State Of Charge (SoC) | uint16 | Pct | SoC_SF | supported | R | State of Charge (average of battery units) | ||
| 41376 | W | Total Batteries power | int16 | W | W_SF | supported | R | Sum of Batteries Powers |
And in 65233 those may be relevant for the in/out flows? Unfortunately values in Wh from 41292 and over are not supported.
| Address | Name | Label | Index | Type | Units | SF | Value | Subvalue | R/W | Conformance Notes |
|---|---|---|---|---|---|---|---|---|---|---|
| 41275 | Wph1 | Watts L1 | 1 | int16 | W | W_SF | supported | R | Total Active Power on Phase L1 | |
| 41276 | Wph2 | Watts L2 | 1 | int16 | W | W_SF | supported | R | Total Active Power on Phase L2 | |
| 41277 | Wph3 | Watts L3 | 1 | int16 | W | W_SF | supported | R | Total Active Power on Phase L3 | |
| 41278 | W | Watts | 1 | int16 | W | W_SF | supported | R | Total Active Power | |
| 41279 | VArPh1 | Reactive Power L1 | 1 | int16 | W | VAr_SF | supported | R | Total Reactive Power on Phase L1 | |
| 41280 | VArPh2 | Reactive Power L2 | 1 | int16 | W | VAr_SF | supported | R | Total Reactive Power on Phase L2 | |
| 41281 | VArPh3 | Reactive Power L3 | 1 | int16 | W | VAr_SF | supported | R | Total Reactive Power on Phase L3 | |
| 41282 | VAr | Reactive Power | 1 | int16 | W | VAr_SF | supported | R | Total Reactive Power |
I tried to retrieve the values name from this graph in the inverter dashboard, but it results in a different naming convention.
It’s possible, if we know which modbus registers represent the needed values. Unfortunately it’s difficult for me to identify those without having that system. You can ask FIMER for support on this, asking specific questions about what you need.
Great news, thanks. 
Because the Energy integration focuses on energy budget, it’s not a real-time monitoring solution. I use my smartmeter (Elios4You Pro) and Shelly EM plus Shelly Plugs to monitor consumption etc. real-time, and I use the Tesla Card addon to show it:
It’s possible, if we know which modbus registers represent the needed values. Unfortunately it’s difficult for me to identify those without having that system. You can ask FIMER for support on this, asking specific questions about what you need.
That’s a beautiful card. Would love to have that in HA natively.
What application provides that?
It’s provided by the FIMER Energy Viewer App, it collects the data from the energy monitor, but that monitor is serial connected with the inverter and you can read the data from inverter’s TCP modbus only.
It’s a really good implementation the one you built and similar to what i was expecting from HA. Thank for the suggestion of the energy monitor, there is a monophase version that is fast to embed, i’ll think about it if in the next few days i can’t get some punctual information from FIMER. Most of the values we need are unavailable or they need to be templated to provide some useful information!
I use Elios4You since 9 years, I know there’s a zigbee version now, the wifi version I use has two big limitations:
-
The wifi interface is obsolete, it reuires 802.11b data rates enabled, this has a huge impact for modern mesh wifi networks. I bypassed the problem with a small TP-Link TL-MR3020_V3 with OpenWRT, basically I had to create a dedicated WLAN for the device, and then connect the TP-Link Access Point to one of my mesh nodes via ethernet cable. So now the limitation of the Elios4You won’t impact my main wifi mesh network.
-
The device doesn’t provide an open interface to pull data: luckily someone reverse-engineered the protocol used by the mobile app and someone created a basic Node-Red flow which I modified to have more info:
I don’t know if their new model, zigbee based, can be used without their proprietary gateway, I think so but if you are interested you should first ask them. If you do, let me know, I might think to upgrade it. I must say that it is a very reliable meter, very accurate readings (I compare data with other devices I have, Shelly EMs, and the inverter too) and they also provide a cloud data app to save data and export it if needed, with a very cheap subscription cost per year.
Regarding your REACT2 system, are you sure it doesn’t have embedded meters? Ask FIMER about that, and also which registers tab in that excel file contain meters’ data.
So it’s a mobile app? the monitor is a meter, so data must be available through the VSN700. My VSN300 has a webserver embedded, does the VSN700 provide the same? Because I finally found a way to pull data from VSN300 via http (FIMER tech support told me that access via http/REST was blocked for internal decision), the card answers with a JSON structure. I was thinking to write another component that is based on this, instead of modbus. All data you see here is available via a python script from shell, in JSON format.
Ciao Alessandro,
as you said the monitor is a meter, but unlike your inverter that provides a separate interface for the meter, VSN700 or 300, REACT2 provides an embedded interface, so basically you connect to the inverter webserver, not the one from the meter.
Using bearer authentication is quite easy to retrieve local json.
But you can also access the VSN700 directly?
The VSN300 uses a custom X-digest authentication header, luckily I found an example of implementation of that authentication and then I managed to create a python script to pull data from the VSN300. I wonder if the VSN700 uses the same kind of authentication or it’s different. When you pull that json data using token authentication, do you point to the inverter address or the vsn700 address? Or it’s only 1 IP for both?
