-
-
Notifications
You must be signed in to change notification settings - Fork 33.7k
0.31 #3937
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
0.31 #3937
Conversation
* Add discovery support for Netatmo Weather station Only The weather information are currently supported (No battery or wifi status supported) Signed-off-by: Hugo D. (jabesq) <jabesq@gmail.com> * Add unique_id for netatmo sensors to avoid duplicate Signed-off-by: Hugo D. (jabesq) <jabesq@gmail.com> * Update requirements_all.txt and PEP8 fixes Signed-off-by: Hugo D. (jabesq) <jabesq@gmail.com>
* Initial version of "haveibeenpwned" sensor component * 2 flake8 fixes * remove debugging error message * Increase scan_interval as well as throttle to make sure that during initial startup of hass the request happens with 5 seconds delays and after startup with 15 minutes delays. Scan_interval is increased also to not call update as often * update .coveragerc * remove (ssl) verify=False * - use dict to keep the request values with email as key - use track_point_in_time system to make sure data updates initially at 5 seconds between each call until all sensor's email have a result in the dict. * fix a pylint error that happend on the py35 tests
The command line cover value template is optional so we need to check it's not none before assigning hass to it. Fixes #3649 Signed-off-by: Roi Dayan <roi.dayan@gmail.com>
* Slugify & consider_home test fix [due to load valid PR] * undo schema change * Fix slugify error
* Migrate to voluptuous * Remove wrong default
…AKING CHANGE] * Change approved_ips from string to cidr validation Relabel to trusted_networks, better reflecting its expected inputs, everything that ipaddress.ip_networks recognizes as an ip network is possible: - 127.0.0.1 (single ipv4 addresses) - 192.168.0.0/24 (ipv4 networks) - ::1 (single ipv6 addresses) - 2001:DB8::/48 (ipv6 networks) * Add support for the X-Forwarded-For header
* Basic support for Netatmo welcome binary sensors Signed-off-by: Hugo D. (jabesq) <jabesq@gmail.com> * Bug fixes and optimization for Netatmo devices Signed-off-by: Hugo D. (jabesq) <jabesq@gmail.com> * pylint fixes * Bug Fixing and optimization for Netatmo devices Signed-off-by: Hugo D. (jabesq) <jabesq@gmail.com> * Add unique_id for cameras to avoid duplicate And global config to disable discovery for netatmo devices Signed-off-by: Hugo D. (jabesq) <jabesq@gmail.com>
vsure0.11.0
* Fix docstrings * Update docstrings
* Wrap found target in list * Fix test_messages_to_targets_route
* Prevent update from clobbering configured name. * linted * Fixing awkward line breaking.
* Cache condition in helpers.Script The caching is a simple in-memory, per-instance dictionary. We use __str__ to format cache keys. This naive implementation has some disadvantages (e.g., we won't be able to cache two conditions that contain references to distinct-but-equivalent object instances and we don't have any control over the size of the condition cache), but for most simple use-cases the approach should be good enough. Resolves #3629 * Fix docstring style
* Upgrade to latest python-lirc 1.2.3 * update requirements_all.txt
… by Nest (#3751) * Added additional checks which hides functions which are not support (like fans / humidity / cooling) * Fixed pylint and flake8 errors (not test file available) * Fixed pydocstyle error * Refactored Code and Comments as described in pull-request * Added additional comment and requesting retest * Upgraded to python-nest 2.11 which contains previously hidden functions
* Separate platform and presentation units in climate * Fix unit tests Maybe * Fix unit tests some more Maybe * Rename _platform_unit_of_measurement to temperature_unit * Fix tests for renamed attribute
* Add initial SNMPv3 support for better security * Fixed indentation errors * Fixed flake8 E128 on row 65 * Disabled warning about too many instance-attributes * Removed extra code, added Inclusive to make better config validation
* Telstra API component * import PLATFORM_SCHEMA * Exclude Telstra notify component in coveragerc * fix authentication issues * Include title in SMS if it's provided * pass lint * Fix many code styling issues * Confirm credentials are correct on component setup
@@ -0,0 +1,102 @@ | |||
""" | |||
Camera that loads a picture from a local file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copy/paste comment?
* Move test to class with custom config setups and with config validation.
* Updater component - rename opt_out to reporting * Fix tests
* Add support for Neato Connected robot as a switch Signed-off-by: Hugo D. (jabesq) <jabesq@gmail.com> * Add checklist items Signed-off-by: Hugo D. (jabesq) <jabesq@gmail.com> * Add missing docstring Signed-off-by: Hugo D. (jabesq) <jabesq@gmail.com> * [Neato] Add update function to retrieve robot state * Add docstring for update function + catch exception when retrieving state * Change type of HTTPError when updating state * Fix pylint errors
* Add Bbox Routeur bandwidth as sensors Add possibility to monitor max and currently used bandwidth of your xdsl connection for Bbox Routeur * Minor Fixes Unit constant get back into the main sensor file * Unused round removed
* Better known_device.yaml writing * yaml dump
* Adds energy monitoring capabilities to the TP-Link HS110 Energy monitoring works only on the HS110 model * Reverts to using GadgetReactor's module * Updates requirements_all.txt * Refactors tplink switch to use attribute caching * Update tplink.py
* Work better with password-protected Squeezebox / LMS servers, including getting file art. Refactored to only have a single method calling the telent lib. (Should make it easier to convert to the more appropriate JSON interface) * Update squeezebox.py * Update squeezebox.py * Update squeezebox.py * Update squeezebox.py * Update squeezebox.py
…ged (#3981) * Fixed statsd stopping if attribute changed by not the state * Fixed tests which exposed a new bug. * Fixed another issue. whoops
* Initial commit of the iOS component and platform * Allow extra * Add battery to identify, a new function to get devices, and load the upcoming sensor * Add iOS sensor platform, currently for battery state & level * Add discoverability for the iOS app * Convert single quote to double quotes * Load all required components and platforms when loading the iOS component for the best experience * Unify quote style to double * Change to hass_ios * Update push URL, add support for logging based on status code, log rate limit updates * Block iOS from coverage checks for now...
* Fix updater * Add Docker and virtualenv checks * Add log line informing user of update/analytics * Remove str
* Adds support for Pioneer AVR interface port number https://community.home-assistant.io/t/support-for-pioneer-avr/503 telnetlib supports a port number so adding port as an optional config element with a default of 23 resolves this. * Adds timeout to Pioneer AVR timeout in telnetlib defaults to socket._GLOBAL_DEFAULT_TIMEOUT which is not a value, but rather a bare Object used for comparison. telnetlib says the following about the timeout optional argument: "The optional timeout parameter specifies a timeout in seconds for blocking operations like the connection attempt (if not specified, the global default timeout setting will be used)." From the documentation for sockets: "Sockets are by default always created in blocking mode" Catching connect and timeout errors, logging to debug and continuing. * Catches timeout exceptions, logs and continues.
I think collecting specific installation data (like OS release, architecture) is okay, but I wouldn't be comfortable if possibly highly sensitive data from bugs would be sent to some sentry server automatically. As an alternative, I'd suggest to show a persistent notification if a component fails, with a link to open a bug (if possible, even with a filled out bug reporting template). |
Just a small edit for the release note, it should be "Netatmo Welcome camera: add binary sensor" instead of "Netatmo weather station: add binary sensor" as the datas come from from the Welcome camera and not the weather station |
@jabesq thanks |
Change
to
|
* Update wink.py added lambda and smoke detector call in component loading routine to fix broken functionality. * Update wink.py fixed extra space. * Update wink.py applied cleaner refactor per comments * Update wink.py fixed spacing * Update wink.py fixed lint error #1
Hello again friend,
How are you? Having a good day? We sure are. If you aren't having a good day, this might cheer you up...
Every other weekend around here gets a little hectic leading to a big sigh of relief as we release a new version of Home Assistant to the world. And this time is no different. Our developer community has once again built us a beautiful new release with lots of new features and improvements. We hope you like it.
One last thing before we get going though, I should warn you... @balloob got a bit lazy this week and let me (@robbiet480) step up to the plate again to write the blog post and do the release. I guess I didn't do such a bad job in 0.27. You'll never know what surprises I have in store. Now that i've got all that stuff out of the way, let's get started...
Stats Update
Sadly, no big amazing stats to update you with this time, but we did recently pass 7,000 commits! This release featured submissions from 45 contributors. Hopefully with the new updater component we will be able to give you some really good stats in the 0.32 blog post.
Hacktoberfest
October means Hacktoberfest time and our community has really come through with some excellent improvements and additions. As of this writing, we have 194 merged and 41 open pull requests to the home-assistant repository and 209 merged/28 open pull requests submitted to the home-assistant.github.io repository. If you want to get in on the fun check out our Hacktoberfest blog post or the Hacktoberfest website. You get an awesome t-shirt for free if you have 4 pull requests merged in the month of October! We even have tasks that a non-developer can easily accomplish with a tiny bit of work. Better hurry up though, only 9 days left and most of the easy tasks are gone!
This release includes an update to our updater component. The responsibility of the updater component is to check if a new version is available and notify the user if this is the case.
It used to be that this component would check with [PyPi](the Python package manager) to see if a new update was available. This had a couple of problems:
So to work around these problems, we decided to start hosting the version check service ourselves. Since we had to get some infrastructure spun up anyway, we figured we would take it a step further. Which leads me to this bit of the update (the most important part):
What you need to know (the important bit!)
Remember how I mentioned that up there in the title that there is some serious business in this release? Well, we also added some basic analytics to the updater component which get sent to the server and stored so that we get a better idea of our user base.
Each Home Assistant instance running the updater component will generate a unique ID (based on UUIDv4) that will be used for the updater to be able to differentiate between instances. This UUID will be stored in your config directory in a file called
.uuid
.Opting out
There are two ways to opt-out. The first way is by using the new
opt_out
option for the updater. This way the updater will continue to check for updates, but no information about your system will be shared with us.You can also disable the updater component entirely by removing
updater:
from yourconfiguration.yaml
although we would not suggest you do this as you would miss any critical security updates.Finally, you can also reset your unique identifier by deleting the
.uuid
file and restarting Home Assistant.Data stored on the Home Assistant update server
Here is what my production Home Assistant instance looks like from the server side:
arch
x86_64
distribution
Ubuntu
docker
false
first_seen_datetime
2016-10-22T19:56:03.542Z
geo_city
Oakland
geo_country_code
US
geo_country_name
United States
geo_latitude
37.8047
geo_longitude
-122.2124
geo_metro_code
807
geo_region_code
CA
geo_region_name
California
America/Los_Angeles
geo_zip_code
94602
last_seen_datetime
2016-10-22T19:56:03.542Z
os_name
Darwin
os_version
10.12
python_version
3.5.2
timezone
America/Los_Angeles
user_agent
python-requests/2.11.1
uuid
10321ee6094d4a2ebb5ed55c675d5f5e
version
0.31.0
virtualenv
true
In addition to the above collected data, the server will also use your IP address to do a geographic IP address lookup to determine a general geographic area that your address is located in. To be extremely, extremely clear about this bit: The Home Assistant updater does not: store your IP address in a database and also does not submit the location information from your
configuration.yaml
. Our tests show that at best, we get 4 digits of accuracy on your IP address location which is a 5 mile radius of your actual IP location, assuming that it is even correct in the first place (geo IP look ups are very hit or miss). Here's what the accuracy looks like for my data above:The server also adds two timestamps to the data: the original date your instance UUID was first seen and the timestamp of the last time we have seen your instance.
This data is held in the highest security. The update system runs in a secured Amazon Web Services account owned by me (@robbiet480). I personally have 5 years of experience with complex AWS deployments and have an extensive security background. I have audited the entire system and made sure to take every step to protect the data, including limiting who has access (just @balloob and myself). While not directly personally identifiable we absolutely understand some users hesistance to giving this information out. Please understand that we are only collecting this information to better understand our user base to provide better long term support and feature development then is currently possible.
We currently have no plans to publicly expose any of this information. If we did do such a thing in the future we would of course notify you in advance. It must also be stated that we will never sell or allow the use of this information for non-Home Assistant purposes.
We thank you for understanding why we are collecting this data and hope that you leave the feature enabled but fully understand if you feel uncomfortable with this.
Now, back to the fun stuff...
Good evening. I'm Ron Burgundy and here's what happening in your world tonight.
Home Assistant got a crazy idea recently that it couldn't do enough already and wanted to challenge itself even more. I really don't understand how it came up with this kooky idea, but it now thinks that its newest hobby should be a minor career in journalism.
0.31 adds support for the brand spanking new Alexa Flash Briefing API, allowing you to get updates from Home Assistant anytime you ask Alexa to read your flash briefing. What's the use case you ask? Well, now when I wake up in the morning and get my flash briefing, Home Assistant adds this to the end of it for me:
Now I know how to best get to my real job (no, Home Assistant is not my real job, it does seem like it sometimes though) every morning. Obviously not the best home automation example, but I think you get the idea. I could see this being used to tell you any major events that happened in your home overnight or reading you your hyperlocal weather report. Thanks to the audio support you could even replace all of the default Alexa Flash Briefing sources with your own news feeds. Home Assistant supports both text and audio content as well as displaying data in the Alexa app. I also want to point out that unlike the existing Skill integration, the Flash Briefing API does not require HTTPS (but you should still be using HTTPS if possible). For more information, check out the new docs.
Major breaking Z-Wave changes ahead
A rather nasty Z-Wave issue was discovered recently by @lukas-hetzenecker. There was a somewhat large chance that if you had multiple of the same model Z-Wave device they may both try to use the same entity IDs. To fix the issue the internal Z-Wave index is now appended to the end of all Z-Wave entity IDs.
What this means for all you Z-Wave users is that you will need to update your configurations to reflect the change. I personally have quite a few (17) Z-Wave devices and went through the process this week. Here's what I had to do:
zwave.customize
sectionemulated_hue
with Alexa andemulated_hue
uses the entity ID as a unique identifier I also had to remove all Z-Wave devices from Alexa and re-add them.Your todo list may be a little different from mine, I just wanted to outline the steps I took to give you an idea of what you need to think about. It's not a very hard process, especially when using global find and replace in Sublime Text but did take me about 20 minutes to complete.
This is super annoying, I know, especially since we had said in 0.12 that Z-Wave IDs should hopefully never change again, but we are now forced to eat those words. I will state again that Z-Wave IDs shouldn't change in the future but obviously we see how that went. To sum up on this section... sorry but it had to happen.
All changes
approved_ips
from string to CIDR validation (@mweinelt)known_devices.yaml
reading and writing tweaks and fixes (@kellerza)fail
filter added to templates to raise on UndefinedError (@jaharkes)Breaking changes
If you need help...
...don't hesitate to use our Forum or join us for a little chat. The release notes have comments enabled but it's preferred if you the former communication channels. Thanks.
Until next time
Thanks for reading all of the above, especially since this week was a pretty long post. We should be back with a new post around November 5th announcing the arrival of 0.32.
-- Robbie