Re auth, that’s all for the Cloud side of the communication, as most of the configuration state (name etc), appears to be stored there for use by the app. I’ve not used the feature, but I’m guessing this is how the sharing of accounts and access etc is done.
ls for limitsSet makes sense (I didn’t really look at that data). There is a lot of talk in the serial docs about handling blinds with and without limits and the handling in the protocol. It would make sense for all current model blinds to always have a limit set.
Re HomeKit, the protocol is documented here: https://developer.apple.com/homekit/ You need an Apple ID / Developer account to download. I have had a look, there’s a fair bit going on in the protocol - but I think we’d be better off sticking with this format (the JSON and/or the port 1487) as my understanding is you can only have one “account” (Apple ID) paired with the hub at a time. So if you were to pair this integration with the Apple ID, you would not then be able to use the native Apple stuff.
I have just pushed a working module mostly using websockets, and a little bit of the serial style connection for the device names (this connection is then dropped when it’s no longer needed).
It has only had basic testing, and is more a proof of concept. When I get a chance I’ll try and integrate with HA. The main thing is going to need is an interface to prompt the user to enter an IP address/host name for the hub. It should be easy, but have not started on that side yet at all.
I have done all testing so far using the demo.py script, this allows me to connect, list the blinds etc, and control them. I’ll post again if/when I get anywhere with the actual HA integration.
I tried out your demo.py script and it works well for me. Your documentation says that you have an update command, but it crashed the demo app any time I tried it. Otherwise, the listing and controls worked just fine for me.
Sorry, yes, probably a few things like that that were left around. I have cleaned that up now, and fixed a number of other things, including changed the module name to aiopulse2 so it does not conflict with aiopulse.
I have also attempted an integration, which you can see here. To use, drop the automate folder into a custom_components folder in your config folder. Then make sure the latest aiopulse2 is in the python path for HA (this includes the HA core folder, if you put it in there, it’ll work, but site-packages is more correct).
This however is not working as intended, in that the WiFi signal strength is not grouped with the actual cover device (the battery is sometimes - not in the code pushed at the moment). There are still a bunch of print statements in the code etc. I have spent way more time on the HA integration than the actual code to speak with the hub, so if anyone here has half a clue how HA hangs together, I have posted my issues here. It’s really close, but HA is lacking any actual documentation (that I can find) as to how to integrate a cover device with additional “sensor” devices (I have tried looking at a bunch of other integrations, but they all do it slightly differently, and I have been unable to actually find a combination that works for me - very frustrating! Any help appreciated!)
Copy the automate folder to your config/custom_components folder in HA.
Restart HA
You will then be able to add the Automate Pulse Hub v2 integration via the HA UI (Configuration > Integrations > + ). Just enter the IP address of your Pulse v2 Hub, and you should be away
Again, if someone can give this a go on their setup that would be great.
If any one is up for following the above steps and making sure it working with their setup, that would be appreciated. Please let me know how you go as I only have 1 hub etc, it will be good to get some more testing. I can then start the process to get it integrated into HA. I still have a lot of clean up to do (documentation etc), but the core code is there, and should now be pretty stable.
It currently does not work with devices that have tilt as I’m not sure of the keys it will use (I can guess, but best to see some real data). So if someone does have a device that has tilt, it would be great if we can work to capture some traffic (or I can put together a test script) to round this out (otherwise I’ll submit it with just up and down support).
I had a crack, installed it on my setup and it works quite well. Only have DC rollers, so can’t test any other devices but I’ll give it a go over the next week or so and see how it goes.
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.
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
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):
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.
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?
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).
@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).
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.
