It is the other way, you can get things from smartthings in Home Assistant.
Great work on this release. I’m keen to see how the new Area’s part works out.
The docs for the update to Transmission are missing, wrong etc. I found a link to the docs preview for 0.87. Not sure what went wrong here, but hopefully this will save some others the hassle of trying to work out what to actually change.
1 reply
Fixed the transmission docs, should be live soon.
Actually, gettting this error with Transmission now when HA is starting up.
Error during setup of component transmission
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/setup.py", line 148, in _async_setup_component
component.setup, hass, processed_config) # type: ignore
File "/usr/lib/python3.5/asyncio/futures.py", line 380, in __iter__
yield self # This tells Task to wait for completion.
File "/usr/lib/python3.5/asyncio/tasks.py", line 304, in _wakeup
future.result()
File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
raise self._exception
File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run
result = self.fn(*self.args, **self.kwargs)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/transmission.py", line 64, in setup
username = config[DOMAIN][CONF_USERNAME]
KeyError: 'username'
My config is valid (posted below), I don’t use a username and password. The old way worked fine. Is this something simple to fix or a bug? Happy to open an issue on GitHub if need be.
transmission:
host: 192.168.1.7
turtle_mode: true
monitored_conditions:
- current_status
- download_speed
- upload_speed
- active_torrentsAlready fixed in dev, will be part of 87.1 https://github.com/home-assistant/home-assistant/pull/20575
1 reply
HomeKit Controller errors out on startup; Leviton Smart Decora Switches do not load. Gaaah.
Regarding asuswrt, the device tracking appears to be working over SSH, but the sensors do not.
Looking forward to testing out the Yeelight Flow functions… but the docs are lacking. What do the values in the dictionary relate to?
ie: TemperatureTransition: [1900, 1000, 80] what are the functions of those values??
Also, there is no indication of how to correctly code for the other transition functions we have available…
The linked Yeelight doc has different syntax so is not really any help.
1 reply
Pumped to see the entity registry UI! Areas is going to be awesome. Thanks for all the hard work everyone!
Welcome back Ben!
Looking forward to playing with this release.
I’ve been loving lovelace since receiving the solid nudge in the last release.
Super frustrating hey.
I even double checked the breaking changes, perhaps I can not read or do not understand the wording of the breaking change (if listed).
On a side note, after sorting all of my RF433Mhz sensors, I noticed no automation’s were working (I have in excess of 100), at all. I had to completely delete my config folder, and files, delete the docker image and roll back to 0.86.4.
Everything working again, so must be something to do with 0.87.0 and the entity registry changes. Need to investigate further before updating again.
Cool - will one be able to specify area in configuration.yaml ?
That’s what I’ve been waiting on as all other platforms like Alexa, homekit and more it’s so tedious using UI only to define it. With hope.
I can’t seem to be able to add entities to an area I’ve created. That should work in the integrations page according to the blog.
In the docs text, there is link for API reference, for specific functions, I think that’s what you are looking:
https://yeelight.readthedocs.io/en/stable/yeelight.html#flow-objects
1 reply
Are you referring to this??
1 reply
- MQTT platforms will now flag mistyped configs from
configuration.yamlcorrectly as invalid, instead of just ignoring them. (@emontnemery - #20562) (mqtt docs) (breaking change)
Oh seems like area has to be created via UI only. Adding things to area is via the integration panel.
Hopefully there will be a way to add via yaml, I’m always a bit sceptical about UI as I have the impression that whatever I configure via UI is not portable and yaml can be taken to different installation or shared.
Isn’t UI-created stuff portable, but kept “deeper”? In .storage or smthn, within HassOS…
Hi, With 0.87, asuswrt working for me with no issues. Sensors detected and working normally.
This is my config:
1 replyBlockquote
asuswrt:
host: 192.168.0.1
username: !secret router_user
password: !secret router_password
sensors:
- download_speed
- upload_speed
I’m coming across an issue with the new QR code component. Its giving me a lot of errors in the log relating to connection to the camera (not at home so can’t add exact error). Can only use one camera per image processing platform? I have the same camera used for face detection and would like to use it for the QR code component too. Maybe this is whats causing the issue.
That’s the link I was referring to which doesn’t explain the syntax for the HA integration…
1 reply
Whats unclear there ? You provide array of transitions, their api is in the docs, also some samples are in the docs ? Under the hood, HA integration passes declared array of transitions to yeelight lib.
1 reply
Great update! Like all others of course. I love the utility_meter. Turned my 1500 line package file comprised of input numbers, templates and automations into about 70 lines… Great Job guys keep up the good work I am thoroughly enjoying Home Assistant and the many things it can do. Cant wait for future updates to see what else HA can bring. Thank you again.
1 reply
FYI, people can be (any maybe should be?) running the " Check Home Assistant configuration" addon (if using Hass.IO).
This addon will check check whether your configuration files are valid against the new version of Home Assistant before you actually update your Home Assistant installation. This add-on will help you avoid errors due to breaking changes, resulting in a smooth update.
It caught a bunch of those changes to MQTT switches, sensors, and lights for me.
1 reply
Nice to see Danfoss Air as a part of the components.
Does anyone know if there is a request for the Danfoss Icon (Floorheating)?
There are common responses you could look for, such as “Invalid config” however the results are displayed in the addon log.
I’m not sure how you would get that into NodeRed.
I’m sure you could build a new addon that did the same thing, taking the source of the current one, then grep the results for “Invalid config” and post how many occurances of it there are to MQTT or something. But that’s all above my skill level.
Hopefully the SmartThings hub can integrate the Samsung Robot Vacuums in a future update as well.
I have some issues with my zigbee2mqtt Xiaomi (QBKG12LM) switch.
Some json key necessary for this switch is not allowed anymore (command_topic_prefix):
Feb 07 15:38:01 raspberrypi2 hass[2084]: 2019-02-07 15:38:01 ERROR (MainThread) [homeassistant.components.mqtt.switch] Exception in async_discover when dispatching ‘mqtt_discovery_new_switch_mqtt’: ({‘name’: ‘0x00158d00024f0e7f_switch_left’, ‘unique_id’: ‘0x00158d00024f0e7f_switch_left_zigbee2mqtt’, ‘command_topic_prefix’: ‘left’, ‘platform’: ‘mqtt’, ‘device’: {‘name’: ‘0x00158d00024f0e7f’, ‘model’: ‘Aqara double key wired wall switch (QBKG12LM)’, ‘manufacturer’: ‘Xiaomi’, ‘sw_version’: ‘Zigbee2mqtt 1.1.1’, ‘identifiers’: ‘zigbee2mqtt_0x00158d00024f0e7f’}, ‘payload_on’: ‘ON’, ‘availability_topic’: ‘zigbee2mqtt/0x00158d00024f0e7f/availability’, ‘payload_off’: ‘OFF’, ‘command_topic’: ‘zigbee2mqtt/0x00158d00024f0e7f/left/set’, ‘value_template’: ‘{{ value_json.state_left }}’, ‘state_topic’: ‘zigbee2mqtt/0x00158d00024f0e7f’},)
Feb 07 15:38:01 raspberrypi2 hass[2084]: Traceback (most recent call last):
Feb 07 15:38:01 raspberrypi2 hass[2084]: File “/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/mqtt/switch.py”, line 66, in async_discover
Feb 07 15:38:01 raspberrypi2 hass[2084]: config = PLATFORM_SCHEMA(discovery_payload)
Feb 07 15:38:01 raspberrypi2 hass[2084]: File “/srv/homeassistant/lib/python3.5/site-packages/voluptuous/schema_builder.py”, line 267, in call
Feb 07 15:38:01 raspberrypi2 hass[2084]: return self._compiled(, data)
Feb 07 15:38:01 raspberrypi2 hass[2084]: File “/srv/homeassistant/lib/python3.5/site-packages/voluptuous/schema_builder.py”, line 589, in validate_dict
Feb 07 15:38:01 raspberrypi2 hass[2084]: return base_validate(path, iteritems(data), out)
Feb 07 15:38:01 raspberrypi2 hass[2084]: File “/srv/homeassistant/lib/python3.5/site-packages/voluptuous/schema_builder.py”, line 427, in validate_mapping
Feb 07 15:38:01 raspberrypi2 hass[2084]: raise er.MultipleInvalid(errors)
Feb 07 15:38:01 raspberrypi2 hass[2084]: voluptuous.error.MultipleInvalid: extra keys not allowed @ data[‘command_topic_prefix’]
Any idea what can be done?
3 replies
The native SmartThings integration will be very very helpful. Does this run locally or go via the Internet even when the two devices are on the same LAN?
1 reply
same here mqtt issue from my dafang camera (dafang-hacks)
2019-02-07 16:17:43 ERROR (MainThread) [homeassistant.components.mqtt.binary_sensor] Exception in async_discover when dispatching 'mqtt_discovery_new_binary_sensor_mqtt': ({'name': 'dafang motion sensor', 'unique_id': '7811dc711e62-motion-sensor', 'device': {'identifiers': '7811dc711e62', 'connections': [['mac', '78:11:dc:71:1e:62']], 'manufacturer': 'Xiaomi', 'model': 'Dafang', 'name': 'Xiaomi Dafang', 'sw_version': 'Dafang Hacks'}, 'icon': 'mdi:run', 'state_topic': 'myhome/dafang/motion', 'device_class': 'motion', 'platform': 'mqtt'},)
Traceback (most recent call last):
File "/usr/src/app/homeassistant/components/mqtt/binary_sensor.py", line 67, in async_discover
config = PLATFORM_SCHEMA(discovery_payload)
File "/usr/local/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 267, in __call__
return self._compiled([], data)
File "/usr/local/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 589, in validate_dict
return base_validate(path, iteritems(data), out)
File "/usr/local/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 427, in validate_mapping
raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: extra keys not allowed @ data['icon']
“command_topic_prefix” is no longer a valid configuration option, and yet the device sent it as part of the discovery string (it sent ‘command_topic_prefix’: ‘left’). That’s the error.
You can always configure the switch yourself and configure it properly, until whatever device that is gets updated to properly support the changes.
You can look at the discovery string and get all the information you need to manually configure the MQTT switch.
“icon” is not a valid configuration option, and yet the device sent it as part of the discovery string (it sent 'icon': 'mdi:run' ). That’s the error.
You can always configure the binary sensor yourself and configure it properly, until whatever device that is gets updated to properly support the changes.
You can look at the discovery string and get all the information you need to manually configure the MQTT binary sensor.
Thanks, that’s a real shame. If I were to go down the MTQQ route does that run locally?
1 reply
Is there some chance of getting compatibility with the new SmartThings app? The old one no longer supports Samsung appliances, but the new one does. I have 2 Samsung ACs that are visible in the new app, but not the Classic.
I’d probably say don’t bother switching if you’ve already got the MQTT bridge and it’s stable. But the new integration is definitely the way to go if you’re just coming into it fresh, in my opinion.
The solution was to update zigbee2mqtt to dev branch. see:
zigbee2mqtt Issue
Sorry I couldn’t see it.
Chrome search (Ctrl-F) doesn’t work for me in the Lovelace raw editor, unless the search string is in view at the time. Love the new look, though.
What’s unclear? It’s asked in my first post… What are the functions of the three numbers in the array? The API docs don’t list an array like this HA component so they don’t explain it. In the API example there are only two numbers in an array and even then, they specify a duration value by name. Surely the HA doc’s should be complete enough to not required referencing an external website, especially one which doesn’t even have the same syntax
1 reply
Sorry @JClumbo - I deleted my post… because it was my issue. I can set up ‘predefined’ incoming IP addresses that can use the (incoming) port forwarding and it was configured to be too restrictive. Once I removed that it worked for me… and actually very well.
I’m very impressed with this integration. The only thing maybe it should have within the ST app is the usual ‘enabling’ of which devices are to be exposed. In HA Lovelace new devices end up in the ‘unused entities’ which sort of achieves the same thing but I feel it should be done within ST from a logical and security perspective.
https://yeelight.readthedocs.io/en/stable/yeelight.html#yeelight.TemperatureTransition That’s the api for that method, and numbers in the array are parameters, in that order. So looking at the docs, first is degrees, second duration and third brightness. All described in the docs. If you got idea how to improve that docs, its welcome for sure.
1 reply
Outstanding work in this release. I was having difficulty connecting Tasmotized Sonoffs and SmartThings hub via MQTT. This could not have come at a better time. I was wondering if there would be any consideration for adding in support for SmartThings temperature sensors? I’m using Samsung Multi Sensors, and now they are reporting the binary sensors open/close and acceleration on/off. Thanks again for adding this in, keep up the great work!!
1 reply
Followed instructions but can’t get hassio to accept ST token.
Enter Personal Access Token:
Unable to setup the SmartApp. Please try again.
Seems a few users are getting “Unable to setp the SmartApp. Please try again.” when integrating ST. I am also getting the issue. I have SSL enabled through duckdns and I have regenerated the token several times. I am not seeing any log error in the main system, but is there another log area I should be checking?
1 reply
it creates a meter per source.
If you want to aggregate, I propose you add a sensor.template that sums all of the sensors and then feed that sensor.template into the utility_meter.
The rest of us were using SSH, not password.
As I said, it would just be nice if the HA docs had ALL the information required without needing to cross-reference to the Yeelight API docs. That can be as simple as describing the function of the three values in the array, and giving details of the values to be used for each of the available functions. But thank you for your work on this, I hate to sound negative. This is a great addition to the Yeelight component
1 reply
Just updated to 0.87.0 getting error on my sense energy monitor.
Any suggestions?
1 reply
SmartThings integration worked for me. The only thing that didn’t come across was my First Alert Smoke/CO sensors. Would have been nice to have them in HA.
1 reply
unfortunately I got roasted last time I tried that… not going to go down that path again
EDIT: I gave in and tried… hopefully it’s worthy 
Hi @balloob I have created a pull request to include some additional infomation on the custom_effects in the Yeelight docs. Hopefully it is ok. Thanks for your awesome work on this project by the way.
sorry for the late reply… this is in my consumption package for all my power sensors.
utility_meter:
downstairs_monthly:
source: sensor.emoncms_downstairs_kwh
cycle: monthly
dryer_monthly:
source: sensor.emoncms_dryer_kwh
cycle: monthly
freezer_monthly:
source: sensor.emoncms_freezer_kwh
cycle: monthly
heater_monthly:
source: sensor.emoncms_heater_kwh
cycle: monthly
kitchen_monthly:
source: sensor.emoncms_kitchen_kwh
cycle: monthly
range_monthly:
source: sensor.emoncms_kitchen_kwh
cycle: monthly
solar_monthly:
source: sensor.emoncms_solar_kwh_with_adj
cycle: monthly
sump_monthly:
source: sensor.emoncms_sump_kwh
cycle: monthly
usage_monthly:
source: sensor.emoncms_usage_kwh_sub_solar_offset
cycle: monthly
downstairs_weekly:
source: sensor.emoncms_downstairs_kwh
cycle: weekly
dryer_weekly:
source: sensor.emoncms_dryer_kwh
cycle: weekly
freezer_weekly:
source: sensor.emoncms_freezer_kwh
cycle: weekly
heater_weekly:
source: sensor.emoncms_heater_kwh
cycle: weekly
kitchen_weekly:
source: sensor.emoncms_kitchen_kwh
cycle: weekly
range_weekly:
source: sensor.emoncms_kitchen_kwh
cycle: weekly
solar_weekly:
source: sensor.emoncms_solar_kwh_with_adj
cycle: weekly
sump_weekly:
source: sensor.emoncms_sump_kwh
cycle: weekly
usage_weekly:
source: sensor.emoncms_usage_kwh_sub_solar_offset
cycle: weekly
I too had trouble setting up MQTT bridge and was waiting for this release.
Great work.
I only use ST as a hub to capture some Zigbee temperature sensors.
Are there any plans to incorporate tenperatre senors ? Or should i revert to the painful process of fault finding my MQTT bridge ?
After submit ST token. Nothing changed still on submit popup page
Looks like the sensors from ST are coming…
After upgrading it will ask for username and password. immediately after entering them I get 404: Not Found roll back to previous version and I do not have any problems.
Hi all,
I’ve some problem with mqtt after the update.
I have a light and some sensor controlled from a second raspberry (with a python script) that I send to home assistant via mqtt autodiscovery.
I’ve read that there’s been some breaking changes with mqtt but I don’t understand what I’m doing wrong.
This is the message I send from the second raspberry (through paho mqtt library):
client.publish("homeassistant/light/soggiorno/config",
'{"device_class": "light", "name": "Lampadario Soggiorno",\
"state_topic": "homeassistant/light/soggiorno/state",\
"command_topic": "homeassistant/light/soggiorno/set"}')
And this is the error I get in home assistant log
Exception in async_discover when dispatching 'mqtt_discovery_new_light_mqtt': ({'device_class': 'light', 'name': 'Lampadario Soggiorno', 'state_topic': 'homeassistant/light/soggiorno/state', 'command_topic': 'homeassistant/light/soggiorno/set', 'platform': 'mqtt'},)
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/homeassistant/components/mqtt/light/__init__.py", line 60, in async_discover
config = PLATFORM_SCHEMA(discovery_payload)
File "/usr/local/lib/python3.6/site-packages/voluptuous/validators.py", line 207, in __call__
return self._exec((Schema(val) for val in self.validators), v)
File "/usr/local/lib/python3.6/site-packages/voluptuous/validators.py", line 286, in _exec
raise e if self.msg is None else AllInvalid(self.msg, path=path)
File "/usr/local/lib/python3.6/site-packages/voluptuous/validators.py", line 282, in _exec
v = func(v)
File "/usr/local/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 267, in __call__
return self._compiled([], data)
File "/usr/local/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 811, in validate_callable
return schema(data)
File "/usr/local/lib/python3.6/site-packages/homeassistant/components/mqtt/light/__init__.py", line 36, in validate_mqtt_light
return schemas[value[CONF_SCHEMA]](value)
File "/usr/local/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 267, in __call__
return self._compiled([], data)
File "/usr/local/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 589, in validate_dict
return base_validate(path, iteritems(data), out)
File "/usr/local/lib/python3.6/site-packages/voluptuous/schema_builder.py", line 427, in validate_mapping
raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: extra keys not allowed @ data['device_class']
It seems something related to device class?
Any hint?
Thank you
device_class is not a valid configuration option for an MQTT light, and yet the device sent it as part of the discovery string (it sent "device_class": "light" ). That’s the error.
This is down to invalid options no longer being silently ignored, but raising an error now.
You can always configure the light yourself and configure it properly, until whatever device that is gets updated to properly support the changes.
You can look at the discovery string and get all the information you need to manually configure the MQTT light.
1 reply
Thank you.
Removing the device class part of the mqtt message solved the issue.
I’m having the same issue @lctang. The “Enter Personal Access Token” page is just sitting there and the ‘SUBMIT’ button is greyed out.
I have ‘base_url’ set and in the ‘docker log’ output I’m not seeing anything indicting a problem
Running hass on Docker 18.06.1-ce on Ubuntu 18.04.
Why not? That’s the second reference I’ve seen about this.
Why would the software developer who gets paid to develop this software have an issue getting a question directly asked to him in the forum he created to specifically get support on the software he developed?
Am I missing something obvious?
1 reply
All very reasonable questions. Based on his forum profile (joined 649+ days ago), I see he does not spend a lot of time here (I base that on my own near-obsessive level of participation in a mere 120 days).
I think it’s reasonable to assume he spends most of his time interacting with Home Assistant developers on Github, vetting PRs, refining the architecture and, just generally leading the project forward. Therefore asking/tagging him is a distraction from his core responsibilities. Long story short, it’s probably not the best use of his time.
However, I do understand how this might be misconstrued as being some sort of cult-like deference to Dear Leader. Don’t interrupt his thoughts and never invoke his name in vain! 
Yeah, that’s why I asked. I was kind of starting to get that kind of vibe.
Especially after he specifically jumped on a user a few days ago about tagging a couple of other dev’s in a post and directly asking them a question about…um…development, calling the user rude and then abruptly and immediately closing the thread.
I would think tho that just ignoring the tag would be just as effective (and will come off as a little less condescending) as telling people they aren’t allowed to directly ask a question of “dear leader” or his “generals”. 
I don’t recall that thread-action but do empathize with the notion that some recent responses seem to be the result of, how to put it politely, too much work and not enough play.
This worked for me:
hope it helps.
Shouldn’t this also be listed as a breaking change? https://travis-ci.org/thibmaek/homeassistant-conf/builds/490939492
Seems like friendly_name is no longer supported on sensor.mqtt
Failed config
sensor.mqtt:
- Invalid config for [sensor.mqtt]: [friendly_name] is an invalid option for [sensor.mqtt]. Check: sensor.mqtt->friendly_name. (See ?, line ?). Please check the docs at https://home-assistant.io/components/sensor.mqtt/
- platform: mqtt
friendly_name: Ink level (Cyan)
icon: mdi:alpha-c-box
name: printer_ink_level_cyan
state_topic: homeassistant/sensor/hp-printer/color-cyan
unit_of_measurement: %
I believe it is listed as a breaking change:
MQTT platforms will now flag mistyped configs from
configuration.yamlcorrectly as invalid, instead of just ignoring them. (@emontnemery - #20562) (mqtt docs) (breaking change)
The Template Sensor allows for friendly_name but no such option is listed for MQTT Sensor. Whereas in previous versions an invalid config variable would be ignored, in 0.87 it is reported.
Aha seem to have missed this. Thanks!
For some reason I can’t find a link to a new “UI to manage the entity registry”. What do I miss?
Thanks!
1 reply