Here are some sample HA Lovelace cards:
Nice work @PeterH24x7!
I have a couple of ideas for small improvements/simplifications to your config but maybe I’ll wait until you post your github repo and create some pull requests there instead.
For others that might want to do something similar, these are the links I used to learn more about Home Assistant’s YAML working:
Home Assistant Introduction to Energy Management
Energy Management in Home Assistant
Understanding Home Energy Management
Solar Analytics Developer Documentation
Template Designer Documentation
Smart Home Makers - on YouTube
Home Assistant Coding Tutorial APIs - Integrate any Device
Create your OWN Template Sensor with Home Assistant Coding Tutorial
START Leveraging Loops NOW - Home Assistant Coding Tutorial (Templating)
2 Likes
The solution is now on GitHub as follows:
https://github.com/PeterH24x7/-Solar-Analytics-integration-for-Home-Assistant-Energy-monitoring
Can’t say thanks enough for this Peter and Glen
Instructions are very easy to follow - simple enough for someone with little experience in HA or yaml to get going.
I think I get most of how the yaml works… can now fall back on annoying a software engineer relative for some support if needed - will be aiming to get readings for 3 additional clamps I have in my SA setup… one will be for my EV charging outlet charger and another for my aircon which I aim to automate.
Not sure if it’s a result of something else in my HA setup but thought I’d let you know that I have a warning when viewing in the HA Studio Code Server addon “String does not match the pattern of “Deprecated^”” in each of the entity ID lines in the following part of the yaml.
- platform: template
sensors:
sa_dashboard_status:
friendly_name: "Dashboard Status"
value_template: "{{ state_attr('sensor.sa_status', 'dashboard_status') }}"
entity_id: sensor.sa_status
sa_mer_status:
friendly_name: "System Status"
value_template: "{{ state_attr('sensor.sa_status', 'mer_status') }}"
entity_id: sensor.sa_status
sa_mer_percentage:
friendly_name: "PV Performance"
value_template: "{{ state_attr('sensor.sa_status', 'mer_percentage') }}"
entity_id: sensor.sa_status
unit_of_measurement: "%"
I’ll do a bit of reading on strings not matching pattern of “deprecated” this afternoon or tomorrow. But it doesn’t seem to impact on the function.
this might be relevant?? The 'entity_id' option is deprecated, please remove it from your configuration - #44 by virgilm
Hi @ddwdiot
While the warning message is a bit obscure, I think the forum posting you gave is fairly self explanatory… entity_id is deprecated.
Have you tried removing the entity_id from your sensor to see if it avoids the warning?
Thanks @TheOtherGlen… I didn’t want to remove it on the assumption that it was part of the suggested code. Also that everything was working so well. But I thought it might worry others like me in the future.
Have now commented the relevant lines out and restarted and all is still good. Will delete the offending lines when I understand the entity_id deprecation issue better. Have been reading lots about YAML and HA but still at the stage where I have to continually revise.
I’ve commented out all the “entity_id” lines of code - representing legacy efforts to get the Energy function working. Doesn’t seem to have had any impact on the workings of the data and results.
1 Like
Hi all,
I’ve added a proposed update to GitHub as follows:
Use Solar Analytics sourced data to report Consumed, Generated and Import-Export Power (W)
Working Lovelace cards:-
Summary house hold power import/export, consumption and generation:
Current (last 5 minute average) power import/export - showing minimal export as our EV is currently charging:
More updates on github - as per the link provided above.
Hi Peter
Nice work with the doco!
I’ve finally pushed my HA config to github and there are a few things in there you might be interested in. See https://github.com/123go/home-assistant-config
Firstly, rather than put my SA config directly in configuration.yaml, I’ve put mine in a package that is included in the main yaml file (see solar_analytics.yaml in the packages folder). This helps to modularise things and keep the main file a lot cleaner.
Secondly, (and maybe of more interest to you) I’ve used the site_id that is retrieved from the site_list service call to build the URL for the site_data service call. This means your config doesn’t need to hard code the site_id.
Lastly, I’ve created two “calculation sensors” (this is my terminology, not an official term… as far as I know) that hold all the logic for extracting values from the REST services and calculating any totals, most recent values, etc. The benefit of this is that it separates the complicated code and puts it all in one place and greatly simplifies the config for the sensors that are actually usable in HA.
Anyway, hope you can find something useful in there. Let me know if there’s anything that needs more explanation.
Regards
Glen
2 Likes
Thanks again to both of you for all of this. It’s been running nicely for me. And yesterday I updated it with the latest version on github.
I’ve been background reading and poring over the yaml to try to better understand it… then went down lots of dead ends before arriving at some extra sensors. I can now read the latest 5 minute data for any of the SA clamps. I got there by hacking together some of your earlier yaml and things I picked up elswhere. But it turns out it’s a lot like your sa_data_detail (which for me returns data for my stove and oven) - except that it’s the most recent readings. I managed this by using an end date that should be always one day in the future (kudos to my daughter for that bit of the yaml). It’s easily adaptable to return data for any or all 6 of the clamps.
Will copy my code below… welcoming any feedback on how it could be better… there are plenty of bits I don’t truly understand. Maybe it will be helpful for someone else with the same basic skills as me.
Now I can get on with some automations using the SA clamps as triggers. Will also be doing some work to better understand time syntax too… just that I noticed that SA report in Unix time syntax but as if it were in the local time zone. So my time sensor is not right… maybe that’s why your sa_detail_time sensor is reporting the end of the 24 hour period as if it were midnight UTC rather than local time.
Substitute site ID for the #s in the resource template. And note that I am only looking at data for 3 of the attributes… but could easily get the others if needed.
- platform: rest
name: sa_my_clamp
resource_template: 'https://portal.solaranalytics.com.au/api/v2/site_data/######?gran=minute&raw=true&tstart={{ now().strftime("%Y%m%d") }}&tend={{ ((as_timestamp(now()) | int) + 24*60*60) | timestamp_custom("%Y%m%d") }}'
username: !secret sa_username
password: !secret sa_password
authentication: basic
value_template: "{{ now() }}"
json_attributes_path: "$.data.[2].[0]"
json_attributes:
# - "apparentPower"
- "current"
- "energy"
# - "energyNeg"
# - "energyPos"
- "power"
# - "powerFactor"
# - "reactiveEnergy"
# - "reactivePower"
- "time"
- "voltage"
scan_interval: 120
force_update: true
- platform: template
sensors:
sa_my_clamp_power:
friendly_name: "My Clamp Power"
value_template: "{{ state_attr('sensor.sa_my_clamp', 'power') | round(1) }}"
unit_of_measurement: "W"
device_class: power
sa_my_clamp_time:
friendly_name: "My Clamp Time Read"
value_template: "{{ state_attr('sensor.sa_my_clamp', 'time') | int | timestamp_custom ('%d-%m-%Y %H:%M') }}"
Thanks for your work on this, I’ve just added the config to my HA (paitently waiting for data to be populated, nothing yet).
Do the secrets have to be in inverted commas? “username” “password”?
Thanks.
Yes they do
Everything is up and running, no drama’s.
FYI, the secrets in the secrets.yaml do not have to be in inverted commas.
Thanks… will have a better look at my setup and apologies if I wasted any of your time.
1 Like
Thanks for putting this up. I’m pretty new to all this but I can copy and paste.
I’m not sure if what I did is correct of not but based on the instructions I changed the site_id 36304 in the 2 URLs as mentioned.
However there were 2 URLs and 2 sections (Dashboard status and 5min update) that didn’t seem to get data until I changed the 36303 (note the different number) to my site_id
I do get data doing this, the Dashboard status section has gone from unknown to uncertain and the 5min update section now has data.
Is this what I should have done?
Thanks, Josh
Note: mine shows GET360 as the portal as Green Energy Tech installed this if that makes a difference.
Is it working now? I’m not quite sure what your asking… sounds like you’ve done the right thing!
You should replace 36304 or 36303 with your site ID in the 2 relevant places in the yaml
Sorry, it is a little confusing, I’m pretty new to all this. It’s all working fine now. The original instructions on Github are as below:
- Substitute your site_id for the placeholder site_id (i.e. 36303) in the 2x resource URLs below.
Changing just those two URLs with 36303 didn’t work. I had to change another 2 URLs with 36304 to get it to work. The instructions mention 36303 and the config yaml mentions 36304
These snippets are in the original Github configuration.yaml
# Note: site_id value is required in URLs used in gets below - e.g. 36304
# Solar Analytics - get the site status for the specified site_id
resource: https://portal.solaranalytics.com.au/api/v3/site_status/36303
# Solar Analytics - get the site raw data for the specified site_id
resource: https://portal.solaranalytics.com.au/api/v2/site_data/36304?gran=minute&raw=true
# Solar Analytics - get the daily data
resource: https://portal.solaranalytics.com.au/api/v2/site_data/36304
# Solar Analytics - get detailed 5 minute data
resource_template: 'https://portal.solaranalytics.com.au/api/v2/site_data/36303?gran=minute&tstart={{ now().strftime("%Y%m%d") }}&tend={{ now().strftime("%Y%m%d") }}'
I just wanted to check what I did was right and I’m also guessing since mine is working the instructions should be:
- Substitute your site_id for the placeholder site_id (i.e. 36303 and 36304) in the 4x resource URLs below.
Hopefully that makes a little more sense.
Thanks, Josh