Blog
IP Cameras, Arduinos, Kodi and Efergy Energy Monitors now supported
Another month has passed and some great new features have landed in Home Assistant. This month release has been made possible by balloob
This release includes some architectural changes by me. The first is that the frontend is now based on a NuclearJS
IP Camera Support James has worked very hard to add support for IP cameras to Home Assistant which is included in this release. The initial release focusses on providing generic IP camera support. This means that any webcam that can exposes a JPEG image via a URL can be integrated.
Home Assistant will route the requests to your camera via the server allowing you to expose IP camera’s inside your network via the Home Assistant app.
# Example configuration.yaml entry
camera:
platform: generic
name: my sample camera
username: MY_USERNAME
password: MY_PASSWORD
still_image_url: http://194.218.96.92/jpg/image.jpg
To update to the latest version, run scripts/update
. Please report any issues on GitHub
Release notes for June 10, 2015
Wow, almost a month has gone by since the last release and this release is packed. The biggest part of this release is probably one that you won’t notice: the frontend has been upgraded from Polymer 0.5 to the brand new released Polymer 1.0. Polymer has been declared stable by the Google overlords which will allow us to expand functionality that was waiting for this moment to arrive.
This release sets a record for the amount of people involved: 8! Andythigpen
A big improvement has been brought this release by wind-rider. He took the time to revive the Chromecast support and started improving the media player integration. This triggered other people to join in resulting in a revamped media player experience and support for the Music Player Daemon.
Example of the new media player cards
To update to the latest version, run scripts/update
. Please report any issues on GitHub
Release notes for May 14, 2015
Almost three busy weeks have past since the last release. We used this time to finally make the overhaul to use UTC as the internal date time format. We added a bunch of test coverage in the process to make sure the transition went smoothly. Pleas see the blog post about the UTC refactor for backwards incompatible changes.
This release includes a significant startup boost for the frontend and a fix for Wemo discovery after their latest firmware upgrade.
I would like to give a big shout out to our newest contributor fabaff
To update to the latest version, run scripts/update
. Please report any issues on GitHub
UTC & Time zone awareness
I have recently merged code to refactor Home Assistant to use only UTC times internally. A much needed refactor. I’ve added some extra test coverage to time sensitive parts to ensure stability. The code has been live in the dev branch for the last 9 days and will be soon released to the master branch.
From now on all internal communication will be done in UTC: time changed events, datetime attributes of states, etc. To get the current time in UTC you can call homeassistant.util.dt.utcnow()
. This is a timezone aware UTC datetime object. homeassistant.util.dt
There is also such a thing as local time. Local time is based on the time zone that you have setup in your configuration.yaml
. Local times should only be used for user facing information: logs, frontend and automation settings in configuration.yaml
.
Setting up your time zone
Setting up a time zone happens in configuration.yaml
. If you have no time zone setup, it will be auto detected using the existing detection code using freegeoip.net
homeassistant:
time_zone: America/Los_Angeles
Compatibility
The changes to the code are mostly backwards compatible. The old hass.track_time_change
and hass.track_point_in_time
use now internally two new methods: hass.track_utc_time_change
and hass.track_point_in_utc_time
. The usage of the old methods have not changed and should be backwards compatible.
This refactor adds a new migration for the database adding a utc_offset
column to events and states. This information is currently not used but can prove useful in the future when we start analyzing the historical data.
Backwards incompatible stuff
All built-in components have been upgraded. The following list is only for people that run custom components:
-
hass.track_time_change
andhass.track_point_in_time
will now return a time zone aware datetime object. Python does not allow comparing a naive with an aware datetime object. - the sun attributes for rising and setting are now in UTC. The methods
sun.next_rising(hass)
andsun.next_setting(hass)
are backwards compatible, just be careful if you used to read the raw attributes. - the API sends all times in UTC. If you use anything else besides the frontend to talk to HA, make sure it handles it differently.
Release notes for April 25, 2015
It’s been a month since the latest update and a lot has happened again. Here a quick overview of the new things.
Line Charts
James
ISY994 hub support
Ryan
He has created an extensive getting started guide which can be found on the ISY994 component page.
# Example configuration.yaml entry
isy994:
Logbook
I (Paulus) have added a logbook component. The logbook component provides a different perspective on the history of your house by showing all the changes that happened to your house in chronological order. See the demo for a live example.
# Example configuration.yaml entry
logbook:
Release notes for March 22, 2015
A new version of Home Assistant has just been pushed out. It contains bugfixes contributed by jamespcole
Script
Andythigpen has contributed a script component. This allows users to create a sequence of service calls and delays. Scripts can be started using the service script/turn_on
and interrupted using the service script/turn_off
. A separate page has been added to the frontend to see the status of your scripts.
# Example configuration.yaml entry
script:
# Turns on the bedroom lights and then the living room lights 1 minute later
wakeup:
alias: "Wake Up"
sequence:
- alias: "Bedroom lights on"
execute_service: light.turn_on
service_data:
entity_id: group.bedroom
- delay:
# supports seconds, milliseconds, minutes, hours, etc.
minutes: 1
- alias: "Living room lights on"
execute_service: light.turn_on
service_data:
entity_id: group.living_room
Release notes for March 11, 2015
It has only been a little over a week since Theodor introduced YAML support for Home Assistant but so much has already happened that it is time for a summary of recent changes. Before mentioning the highlights I want to thank andythigpen
Monitor local resources.
Theodor has contributed a new sensor platform to allow you to monitor disk usage, memory usage, CPU usage and running processes. This platform has superseded the process component which is now considered deprecated.
# Example configuration.yaml entry
sensor:
- platform: systemmonitor
resources:
- type: disk_use_percent
arg: /home
- type: memory_free
- type: process
arg: kodi
Experimental Z-Wave support
There is now experimental support for connecting Z-Wave networks using a Z-Wave USB stick. Right now it only integrates Z-Wave sensors into Home Assistant. Our goal is to get this tested by more people before adding support for other Z-Wave devices.
The new component is built on top of python-openzwavescripts/build_python_openzwave
to install it on your machine. Alternatively you can use the Docker image which is ready to go.
The development was done using an AEON Z-Wave USB stick and an AEON Z-Wave MultiSensor.
# Example configuration.yaml entry
zwave:
usb_path: /dev/ttyUSB0
Voice control
An initial version of voice control for Home Assistant has landed. The current implementation consists of two parts.
The first part is a component called conversation
that exposes the service conversation/process
. This service is capable of processing text and translating them into commands for devices. For now it will only support commands in the format of Turn <Friendly Name> <on/off>
.
The second part is an upgrade to the frontend to use the speech-to-text in Chrome to allow users to speak commands. If you’re using Chrome, you can test this out in the demo.
# Example configuration.yaml entry
conversation:
New logo for Home Assistant
It is well known that you are either a good programmer or a good designer. It’s rare you’ll meet someone that is both. That’s why it wasn’t surprising to anyone that the logo that I made was mediocre — at best. Luckily, Jeremy Geltman
The new logo follows Googles material design spec. It uses the blue color that Home Assistant uses in the interface and it comes in two versions: a high detailed version (for homescreen icon etc) and a simple version (for favicon etc).
The old logo, the new detailed logo and the new simple logo.
Home Assistant moving to YAML
Home Assistant is now using YAML
The new file is named configuration.yaml and if it can’t be found in your config directory, Home Assistant will instead try to find the old configuration file, home-assistant.conf.
The home-assistant.conf.example has been replaced with an updated configuration.yaml.example.
Users of Home Assistant should migrate as the old configuration format is deprecated.
Streaming updates
Home Assistant has learned a new trick to get the latest information from the server: streaming updates. No longer will the frontend poll every 30 seconds for updates but instead it will keep a connection open and get the latest changes pushed as soon as they happen.
A new toggle has been added to the sidebar to turn streaming updates on and off. This preference will be saved on a per-browser basis using local storage. The toggle will also indicate when there is an error setting up a stream after which it will fall back to use polling.