Incredible work @sillyfrog, thank you so much for doing this!
It works great for me with a single hub and blinds.
Have set it up to adjust blind position based on sun azimuth/elevation.
Cheers!
@pss Do you have a link or more info as to how you have implemented the sun azimuth/elevation calculations? I’m looking at doing the same (taking into account awnings etc), I have recently figured out all the math and data sources, but if there’s existing solutions, keen to check it out 
Mine is really simple, but it’s worked for me to lower the blind just before the sun hits the western facing window. I have another automation that will raise it after sun down.
Sensor for the elevation
sunelevation:
friendly_name: 'Current Elevation'
value_template: >
{{ state_attr("sun.sun","elevation") }}
Automation to lower blind
- id: '1590553743089'
alias: Lower Sun Blind
description: ''
trigger:
- above: '20'
below: '30'
entity_id: sensor.sunelevation
platform: numeric_state
condition:
- condition: state
entity_id: binary_sensor.sunrising
state: 'off'
action:
- entity_id: cover.sunshade
service: cover.close_cover
I can’t remember why I have the above 20 below 30 condition… I think it might have been a hack way to fix something before I added the Sun Rising = False condition… but it works, so I’m not fiddling with it.
I’d be interested to see others code, there’s probably a more efficient and accurate way of doing it 
1 Like
Confirming that this is working for me as well - nice to have the battery levels compared to the Homekit integration.
I’m using the following very basic automation to drop a blind to 73%, shading the couch from the afternoon sun (As long as it’s at least 1 minute before sunset):
- id: '1597724710692'
alias: Blinds - Afternoon Shade
description: ''
trigger:
- above: '180'
below: '285'
entity_id: sun.sun
platform: numeric_state
value_template: '{{ state.attributes.azimuth }}'
condition:
- before: sunset
before_offset: 00:01:00
condition: sun
action:
- data:
entity_id: cover.stairway_blinds
position: 73
entity_id: cover.blinds_stairway_west
service: cover.set_cover_position
mode: single
I am using the sun entity provided by HA similar to @dgaust and @ch1ppo (see 1, 2 and 3). My dead simple use case is to lower the blind when the sun is casting a lot of light through a north facing window. I set the blind being opened as the trigger and the elevation/azimuth values as the condition. I worked these values out from a SketchUp model I have of the house and suncalc.org.
I note others put the sun position as the trigger, I guess this is functionally the same as putting it as a condition? Not sure, this is the first automation I’ve done.
- id: '1599048836786'
alias: Dining blind solar control
description: ''
trigger:
- device_id: XX
domain: cover
entity_id: cover.dining_2
platform: device
type: opened
condition:
- condition: and
conditions:
- condition: template
value_template: '{{ state_attr("sun.sun", "elevation") < 50 }}'
- condition: template
value_template: '{{ state_attr("sun.sun", "azimuth") < 30 }}'
action:
- device_id: XX
domain: cover
entity_id: cover.dining_2
position: 30
type: set_position
mode: single
I also just realised I can use my solar panel generation as a ‘sensor’ for when it is a sunny/overcast day, as HA has an integration for my solar inverter. Could use this so the blind automation only runs when it is sufficiently sunny.
Thanks again for aiopulse2, works like a charm.
Actually this automation didn’t work reliably. I have changed it so the trigger is the sun position, see here if interested.
Hi all, sorry for not being active for a few months - my day job has been very hectic and I wasn’t actively tracking this thread. Well done for the development of aiopulse 2!
After what I thought to be the difficult part of this project (reverse engineering the pulse protocol), developing the home assistant plug-in actually took a considerable amount of time to get it to a state of quality that the home assistant developers were happy to merge into the main product.
As such, I’d suggest we look at merging aiopulse and aiopulse2 together into a single module that the acmeda integration can use (or at least enable the acmeda integration to work with both modules). Would people be open to either of these approaches and which would be the prefered approach?
@atmurray FYI: The current PR I have done is available here: https://github.com/home-assistant/core/pull/39501
It’s heavily based on your work, plus I have also been working on a “best practice” example (and pulling across lessons learnt), so hopefully it should not be too hard (that PR has now been approved).
The protocol in the end is completely different, needs to have an IP address entered etc, so not sure unifying them (aside from keeping it simpler for users) would make a huge amount of sense, but happy for any feedback/thoughts you may have. You could probably even review that PR if you had the time since you are likely familiar with the code and implementation with the HA side of things (I also had the same experience, the HA part took much longer than the actual speaking with the hub! Hence working on the example to hopefully help others).
Looks like the PR missed the 0.115 beta. Does that mean we have to wait for 0.116 before this gets merged in?
@Michael_Griffin I would imagine so, yes. But even then, unless it’s been reviewed, it will miss that as well. That said, I think if you have contributed before, you can also review existing PR’s (I’m still new to the whole process as well).
Has anyone else’s battery status suddenly disappeared in Automate v2? Not sure if it’s the beta 0.115 or my setup.
Haven’t had this issue, battery status is there.
I have noticed at times that when I issue an ‘All blinds open’ command using a scene, 1 or 2 out of the 6 blinds can ignore the command and become unresponsive (not being available in home assistant) for a few minutes.
I’m not using the Beta yet, but it should be pretty similar, so if you have any logs that would be great.
If you crank up the logging, that’ll give you a lot of information about what’s happening. Especially if dropping out, that should help.
@pss : I have 8 blinds and have not seen that issue, but I’m not using an HA scene to open them all at once - I have an idea what it could be (the hub is too slow to accept all commands at once, I have other rate limiting for getting more detailed info) - so if you can get some logs (and maybe post a new issue on the GitHub library), that would be good.
An example of cranking up the logs just for aiopulse2:
logger:
default: info
logs:
aiopulse2: debug
Thanks, I have enabled the logging. The problem happens once a week at most so could take a while to get a readout. Agree the problem is likely to be the hub’s ability to accept multiple commands.
Yeah, I enabled the logging
{'hubId': '1002079', 'name': 'My House', 'mac': 'c4:4f:33:36:b2:39', 'onlineLatest': 1599811850.950494, 'mfi': {'PD': 'a7809d94adde10a3', 'manufacturer': 'Rollease Acmeda', 'model': 'MT02-0401-067001'}, 'firmware': {'version': '1.0.0', 'RFversion': 'B10'}, 'shades': {'H4C': {'is': True, 'ol': True, 'mp': 100, 'vo': '12.3D24', 'ls': 1, 'rs': -81}, 'YB2': {'is': True, 'ol': True, 'mp': 0, 'ta': 0, 'vo': '12.4D24', 'ls': 1, 'rs': -82}, '6V4': {'is': True, 'ol': True, 'mp': 100, 'vo': '12.3D24', 'ls': 1, 'rs': -81}, 'HFX': {'is': True, 'ol': True, 'mp': 0, 'ta': 0, 'vo': '12.2D24', 'ls': 1, 'rs': -93}}}
It doesn’t seem to be throwing an error anywhere in the logs.
I deleted the integration and re-added, and now the battery and connection strength entities haven’t been re-added.
For reference my log shows the below and I do get the battery values.
I am running version 0.114.4 in Home Assistant OS.
'shades': {'LLJ': {'is': True, 'ol': True, 'mp': 100, 'vo': '12.0D24', 'ls': 1, 'rs': -91}, '8LJ': {'is': True, 'ol': True, 'mp': 100, 'vo': '11.8D24', 'ls': 1, 'rs': -78}, 'HMU': {'is': True, 'ol': True, 'mp': 100, 'vo': '10.6D24', 'ls': 1, 'rs': -89}, 'LSQ': {'is': True, 'ol': True, 'mp': 100, 'vo': '11.3D24', 'ls': 1, 'rs': -90}, 'ROI': {'is': True, 'ol': True, 'mp': 100, 'vo': '10.8D24', 'ls': 1, 'rs': -85}, 'MA0': {'is': True, 'ol': True, 'mp': 100, 'vo': '10.7D24', 'ls': 1, 'rs': -94}}}
I upgraded my lab to the 0.115 beta today and found this stopped working entirely - so have gone back to Homekit for the time being.
For those having issues with the HA beta, I have now run this (correctly - silly issue with docker swarms/compose that meant I was not running the beta when I thought I was) - and found the issue with the sensors. I have run against 0.115.0b9. It was a change to UNIT constants. I have now fixed this and pushed to the github repo. Please let me know if you have any more issues, and if so, logs would be ideal (HA notified me in the UI that something was wrong) - it could be in aiopulse2 or automate.
Cheers.
From the logs, I think its in sensor.py of automate. I changed the references of UNIT_PERCENTAGE to PERCENTAGE and they’ve now returned.
I’ll preface this comment by saying that I’m a newbie to Home Assistant.
I’m having difficulty getting this integration to work.
I’m running HA 0.114.4 inside of Docker.
- I used pip install to added aiopulse2 to my container. I checked that it was in the python path by opening a python instance through a Docker console and importing the library.
- I’ve added a copy of automate-ha-dev to my config/custom_components folder in HA
- Added debug level logging of aiopulse2 to configuration.yaml
- Restarted HA
But I still can’t see Automate Pulse Hub v2 in the Integrations.
Have I missed a step?