0.87: SmartThings, Areas and Entity Registry UI.


#84

Looks like the sensors from ST are coming…


#85

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.


#86

After config Base_URL and ssl… still got error after input token “Unable to setup the SmartApp. Please try again.”… any port need opened ?


#87

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


#88

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.


#89

Thank you.
Removing the device class part of the mqtt message solved the issue.


#90

@Balloob Any idea when 0.87.1 will be released?


#91

Don’t ask him and don’t tag him, it comes when it’s ready


#92

Fair enough. He mentioned it to me a few days ago. I was just wondering.


#93

Ok, np :wink:

Have a nice weekend


#94

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.


#95

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?


#96

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! :wink:


#97

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”. :slightly_smiling_face:


#98

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.


#99

This worked for me:

  • removed port number from base_url (using duckdns)
  • reboot hassio
  • add token

hope it helps.


#100

This worked for me:

  • removed port number from base_url (using duckdns)
  • reboot hassio
  • add token

hope it helps.


#101

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: %

#102

I believe it is listed as a breaking change:

MQTT platforms will now flag mistyped configs from configuration.yaml correctly 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.


#103

Aha seem to have missed this. Thanks!