Looks like the sensors from ST are coming…
1 Like
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.
After config Base_URL and ssl… still got error after input token “Unable to setup the SmartApp. Please try again.”… any port need opened ?
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.
Thank you.
Removing the device class part of the mqtt message solved the issue.
1 Like
Don’t ask him and don’t tag him, it comes when it’s ready
2 Likes
Fair enough. He mentioned it to me a few days ago. I was just wondering.
Ok, np 
Have a nice weekend
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?
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!
1 Like
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”. 
1 Like
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.
1 Like
This worked for me:
- removed port number from base_url (using duckdns)
- reboot hassio
- add token
hope it helps.
This worked for me:
- removed port number from base_url (using duckdns)
- reboot hassio
- add token
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!