Jump to content

How to use Solaredge info in HA

stevehoyt

By stevehoyt
in Home Assistant

Recommended Posts

stevehoyt Advanced

stevehoyt

Posted
Posted

 

@shbatm @photogeek54

I have recently added the Solaredge nodeserver to my PG3 running on polisy. I need some help understanding what I should see and/or how to use the data in HA.

As an example in my Admin console I see the info in the screen capture below for Energy last 15 min.

i.e. production, consumption, purchased, self consumption, feed in and since last update.

When I look at the data in HA for this node, I have a sensor entity id called "sensor.energy_last_15min". So far so good. Upon further inspection under attributes, I see custom control 0 -4 which has the rest of the data. So here is my problem/question(s). I have no idea what each custom control represents, but I can figure it out by comparing what I see in the admin console to the values for the custom control. 

1) Assuming that is the intended way things should work, does that mean I need to use YAML in my cards to get at that info. So far I am just slugging my way into YAML by uneducated copying of stuff. I have got a few things to work but only by luck. 

2) Is it unreasonable given this architecture to be able to have these custom controls broken out into specific attributes with a representative name. 

Thanks for any help.

I am running the latest HA and version v 02.05 for solar edge. I have not yet got the latest version 0.2.061 to update. Still working on that.

 

 

Screenshot 2023-06-04 at 10.11.16 AM.png

Link to comment
shbatm Advanced

shbatm

Posted
Posted

I would suggest trying the beta version of the Home Assistant integration, which must be installed with HACS.

One of the primary feature differences is that Node Servers get a lot more love in the re-write.

1. Add the custom repo (first link in post above) to HACS

2. Search for and install the IOX integration in HACS.

3. Restart Home Assistant (this should override the default integration with the beta).

4. In HA Devices & Services menu, find the ISY/IOX integration, click configure, and make sure 'Use node servers' is checked in the options.

  • Like 1
Link to comment
shbatm Advanced

shbatm

Posted
Posted

Looks like there's a few differences in the node server files compared to what I had available to test with that I'll need to fix.

Can you please take a backup of your polyglot from the web interface, delete the 'backup.db' from the zip file, and send me the rest in a message? All your private credentials and info should be in the dB file, the rest is the node server definitions and profiles so I can narrow down the format changes.

Link to comment
Mecheng70 Advanced

Mecheng70

Posted
Posted (edited)
On 6/4/2023 at 4:08 PM, stevehoyt said:

 

@photogeek54

 

Screenshot 2023-06-04 at 10.11.16 AM.png

Stupid question here, how do you get "Battery 2.3" and those other nodes?  I have the Node Server but none of those nodes show up in AC.

 

I can't tell you how many times I have pressed the "Load Configuration" button.

Edited by Mecheng70
Link to comment
shbatm Advanced

shbatm

Posted
Posted

@stevehoyt - I've tried to tackle most of the errors from your log files but I couldn't pin-point one of the errors loading the Natural Language file from one of the node sesrvers yet.

I've pushed a new release of `pyisyox`, but have not yet updated the Home Assistant integration.

Would you be able to run some tests from a command-line for me?

The following commands should install the package (assuming you have Python >= 3.10 and pip installed) and then connect to the IoX device, dump all of the config files to a "./.output/" directory and output the events to the log. Ctrl+C to disconnect. 

pip install pyisyox==1.0.0a7
python3 -m pyisyox http://polisy.local:8080 admin "password" -o -v
Link to comment
Mecheng70 Advanced

Mecheng70

Posted
Posted
1 hour ago, stevehoyt said:

@Mecheng70

Sorry for the late reply I was out of town. Are you running version 0.2.25

I did not have to do anything to see my batteries. I may be mistaken, but I think this is part of additions being added to the latest test versions. 

Evidently the issue is with my site name.  My site name has a "/" in it and both the solaredge poly node servers are not working when communicating with the eisy.  I was on for 1.5hrs with michel yesterday.  Currently waiting for the non-production node server to roll to 1.1.01.  Right now only 1.1.0 is showing up.  Did communicate with the photogeek.

I was able to get around it by changing the name in the URL and launching it.  

Link to comment
  • 2 weeks later...
Michel Kohanim Wise Elder

Michel Kohanim

Posted
Posted

Hi @shbatm,

@stevehoyt contacted us with a request to fix and/or enhance the SolarEdge node server. The issue is that he has not been able to tell us exactly what the issue is. Is it that ISY has no VA (it definitely does) or that it has VA for the wrong property. Or, it should be W or ... 

Please outline exactly what it is that's missing and/or requires enhancements and we'd be delighted to.

With kind regards,
Michel

 

Link to comment
shbatm Advanced

shbatm

Posted
Posted (edited)
5 hours ago, Michel Kohanim said:

Hi @shbatm,

@stevehoyt contacted us with a request to fix and/or enhance the SolarEdge node server. The issue is that he has not been able to tell us exactly what the issue is. Is it that ISY has no VA (it definitely does) or that it has VA for the wrong property. Or, it should be W or ... 

Please outline exactly what it is that's missing and/or requires enhancements and we'd be delighted to.

With kind regards,
Michel

 

Hi @Michel Kohanim - The comment was that the ISY Control names don't appear to differentiate between Real (W), Apparent (VA), or Reactive (VAR) power categories. All of the UOM are supported, but the controls are not specific to the category--the last list I saw only included "CPW" for current power and "TPW" for total energy used, and "PPW" for polarized power used.

This came up in the Home Assistant integration, since Home Assistant now enforces Device Classes having specific units that match, and an error was being thrown for "CPW" (translated to Power device class, units of W/kW) having units of "VA". 

I have added a workaround on the HA integration side to segregate Real, Apparent, and Reactive power device classes, but suggested Steve reach back out here to see if its something to consider including in a future update, considering all of the other controls added over the past few years for the Node Servers.

Edited by shbatm
Link to comment
Michel Kohanim Wise Elder

Michel Kohanim

Posted
Posted

@shbatm, thank you very much for the details. 

17 hours ago, shbatm said:

ISY Control names don't appear to differentiate between Real (W), Apparent (VA), or Reactive (VAR) power categories

I am not understanding the relationship between control names and categories. For instance, GV0 for the inverter node has a UOM of VA (reactive power). Are you saying that HA requires control names to be specific strings that belong to specific categories? In short, just changing the NLS strings for properties would fix these issues for you?

With kind regards,
Michel

Link to comment
shbatm Advanced

shbatm

Posted
Posted (edited)
53 minutes ago, Michel Kohanim said:

I am not understanding the relationship between control names and categories. For instance, GV0 for the inverter node has a UOM of VA (reactive power). Are you saying that HA requires control names to be specific strings that belong to specific categories? In short, just changing the NLS strings for properties would fix these issues for you?

 

Sorry for the confusion. There's no hard requirement for the ISY control names to match device classes in Home Assistant. The integration uses known ISY control names to try to guess what HA device class the device might fall into, but for things like the GV* controls, or ones where we know the units won't match (LUMIN/VOCLVL), it just doesn't assign a device class. The user can manually force a device class in Home Assistant if they want.

The only hard matching 'requirement' is within HA--that if you set a device class, the units must be one of the expected for that class. The actual mapping of ISY's UOMs to HA's Units is independent of all of this. Device classes aren't required, they just enable some additional things like long-term statistics, pre-set icons, unit conversions, etc.

The change I made on my side and referenced above just adjusts the "guess" that "CPW" can represent any of the power classes and the unit needs to be checked to see which one to prevent a unit error.

The suggestion for the change on the ISY side to include more control names is only a suggestion for future consistency across node servers (e.g. so you don't have some using CPW and some using GV0)--as far as the Home Assistant side is concerned, it's not required. 

 

EDIT:

53 minutes ago, Michel Kohanim said:

In short, just changing the NLS strings for properties would fix these issues for you?

Just wanted to add--the current HA integration doesn't use the NLS or any profile info from the Node Servers, only what it can interpret from the "fixed" ISY core family schemas and documented API--it's about 90% educated guessing as to how to properly display things from the context given in the REST response. The new python module (pyisyox) that I'm working on actually requests the NS profile info from the device to get the details of how to display properly, but this is still in "alpha" testing.

Edited by shbatm
Link to comment
shbatm Advanced

shbatm

Posted
Posted
On 6/18/2023 at 10:38 AM, shbatm said:

I've tried to tackle most of the errors from your log files but I couldn't pin-point one of the errors loading the Natural Language file from one of the node sesrvers yet.

@stevehoyt I found the original issue with loading your node servers in Home Assistant, it was related to Windows/DOS vs Unix line endings in the profile files for WeatherLink. Better guards for this were added and the HACS version has been updated.

Link to comment
Michel Kohanim Wise Elder

Michel Kohanim

Posted
Posted
23 hours ago, shbatm said:

Just wanted to add--the current HA integration doesn't use the NLS or any profile info from the Node Servers, only what it can interpret from the "fixed" ISY core family schemas and documented API--it's about 90% educated guessing as to how to properly display things from the context given in the REST response. The new python module (pyisyox) that I'm working on actually requests the NS profile info from the device to get the details of how to display properly, but this is still in "alpha" testing.

@shbatm, AHHH, makes sense now. Thank you very much. Please do not spend too much time on pyisyox yet because we are making it much easier to access properties, an associated NLS, directly from /rest/nodes rather than having to parse different NLS files and map them. If you are not already in our slack channel, please submit a ticket and I'll add you. It should make integration much easier.

Thanks again and with kind regards,
Michel

Link to comment
shbatm Advanced

shbatm

Posted
Posted
3 hours ago, Michel Kohanim said:

we are making it much easier to access properties, an associated NLS, directly from /rest/nodes rather than having to parse different NLS files and map them.

That would be extremely helpful. I jumped back in on Slack, just ping me if there's anything you'd like me to test. I'll hold off on progressing further with pyisyox on the profile downloads piece--I was at the point of trying to tackle Z-Wave node defs, so a good place to stop. Just FYI -- my intent is that once this module is stable, the original pyisy will be deprecated--I know there are still a few node servers out there that use that module. The new one has been re-written from the ground up to be much faster and fully asynchronous. 

  • Like 3
Link to comment
  • 6 months later...
  • 2 weeks later...
Guest
This topic is now closed to further replies.
Go to topic listing
×
×
  • Create New...