Hi. I found the problem. I was including “mqtt” and “sensor” below, which is redundant because it’s already specified in configuration.yaml:
mqtt:
sensor:
- name
The solution was to just write:
- name: "mqtt_temp"
I have the following sensor and I’m getting errors and trying to figure out how to use the Icon_template, as it’s not allowed in the mqtt.yaml.
- platform: mqtt
state_topic: "bbq/iGrill/probe1"
name: "Probe 1"
qos: 0
unit_of_measurement: "°"
icon: mdi:thermometer
- platform: template
sensors:
probe1:
friendly_name: "iGrill Probe 1"
unit_of_measurement: '°'
icon_template: >-
{% if states.sensor.probe_1.state == 'unknown' %}
mdi:cancel
{% else %}
mdi:thermometer
{% endif %}
#value_template: "{{ states('sensor.probe_1')|round }}"
value_template: "{% if is_state('sensor.probe_1', 'unknown') -%}
{{ 'off' }}
{%- else -%}
{{ states('sensor.probe_1')|round }}
{%- endif %}"
Any suggestions?
What’s your configuration.yaml? We cant help you because we don’t know how or if this random mqtt.yaml file is included in your actual config.
No, he’ll have to switch to the new template style for that.
Keep platform: template and below in sensor.yaml. Only move the single mqtt sensor.
Example for those who have a separate yaml file …
configuration.yaml entry
mqtt:
discovery: true
broker: 192.168.1.6
binary_sensor: !include mqtt_binary_sensor.yaml
climate: !include mqtt_climate.yaml
switch: !include mqtt_switch.yaml
sensor: !include mqtt_sensor.yaml
Example in mqtt_binary_sensor.yaml …
- name: "Carport Motion"
device_class: motion
state_topic: "mqtt/cp/master"
payload_on: "Mo_1"
payload_off: "Mo_0"
off_delay: 10
qos: 0
Hi all
I have the following in my configuration.yaml
alarm_control_panel:
- platform: mqtt
#name: Paradox Mak
#unique_id: Paradox Mak
state_topic: "paradoxdCTL/hassio/Arm0"
command_topic: "paradoxdCTL/in"
payload_disarm: '{"password":"3x","Command":"disarm","Subcommand":"0"}'
payload_arm_night: '{"password":"3x","Command":"sleep","Subcommand":"0"}'
payload_arm_home: '{"password":"3x","Command":"stay","Subcommand":"0"}'
payload_arm_away: '{"password":"3x","Command":"arm","Subcommand":"0"}'
and I changed another sensor to this, which is working
mqtt:
sensor:
- name: "Wind Speed"
state_topic: "anemometer/wind"
unit_of_measurement: 'km/h
How should I change the alarm_control_panel? Or it is ok to leave it as it is?
edit: got it. I have to use it below mqtt:
I spent a few hours this morning updating my configuration files based on the MQTT changes. While I did get everything working, I did have to restructure my yaml file such that its now not as well organized. Perhaps you can recommend a solution.
I originally had:
# Unit 1
sensor Unit1:
- platform: mqtt
name: unit1_abc
binary_sensor Unit1:
- platform: mqtt
name: unit1_ijk
# Unit 2
sensor Unit2:
- platform: mqtt
name: unit2_abc
binary_sensor Unit2:
- platform: mqtt
name: unit2_ijk
I was unable to include sensor and binary_sensor twice within the mqtt integration. I tried this both with and without the Unit1/Unit2 identifiers. I also tried including the mqtt integration twice with and without Unit1/Unit2 specified on the same line as was originally done with the sensor / binary_sensor.
I ended up having to reorganize my yaml file such that all the sensor are grouped together and the same for the binary_sensor. I would prefer keeping all of each Unit’s sensors grouped together. Short of creating a separate package file for each Unit, is there a way this can be done?
At least until 2022.9
1 Like
I really love Home Assistant!
But what is happening here about “Move MQTT config schemas and client to separate modules” makes me also heating HA as well.
Hundreds or probably thousands of users are forced to change their WORKING configuration manually.
No info why, no info what will be the benefit, nothing. It’s sad.
I know moth of the contributors are from Europe, but why nobody remember old, good, American proverb: “Don’t fix it if it ain’t broken”?
3 Likes
That’s generally the case for most Breaking Changes so it’s the status quo.
I linked to the reason in an earlier post. It’s part of an architectural decision made 2 years ago and its benefits are explained.
Home Assistant’s success can be attributed to its comprehensive support of IoT devices made by numerous contributors under the guidance of its founder and a small (but growing) team of salaried developers. The founder’s vision includes making the product more capable, flexible, robust, etc. Not all of these enhancements can simply be tacked on to the existing architecture so sometimes that means replacing old ways with news ways (“Breaking Changes”).
I too have been inconvenienced with breaking changes, mostly from not reading “breaking changes”. But overall, Home Assistant just keeps getting better and easier to use.
2 Likes
Eh. Matter of fact is, from a purely technical point of view, it is always possible to avoid user facing breaking changes on an evolving code base, as long as you control the code (ie. cloud dependencies are more complicated). It’s just more work for the developer. And more often than not, HA development is still guided by the devs and for the devs philosophy, the user usually comes second. That’s the nature of many open source projects and to an extent, that’s fine. But as HA progressively turns more and more commercial operation with paid staff, it becomes less acceptable to shift the burden of the work on the paying user base.
In the end the main issue here is that HA still hasn’t managed to stabilize the fundamental structure of the code. At some point within software life cycle management, a project reaches a point of maturity where the fundamental building blocks don’t change that much anymore. The communication APIs between these blocks stabilize and the foundations settle into a system that while staying extensible, stops moving. Breaking changes are mostly necessary while the foundations are still moving, but become much more uncommon once you reach that point of maturity. And being less common, they’re easier to manage.
HA has not yet reached this point. In fact, even though there were improvements on that front, it’s very far from it. The foundations move all the time, and as soon as things seem to head towards stabilization, some general strategic development decisions scramble things up again. This is not a technical necessity to stay cutting edge. It’s simply the way the project is managed. Sometimes it feels like the core devs don’t even want the code to mature because they like to keep this very flexible open sourcey type of approach where you can do far reaching changes on a whim. But at some point, especially when going commercial, you’ll have to stabilize your project or you will end up frustrating your users to a point they’ll just quit and look for something else.
4 Likes
Hi,
followed the different options in the thread, would like to apply this, but I’ve the following error (extract of the configuration.yaml):
Can someone hints me how to proceed?
Thank you in advance!
Hello All,
please can someone advise how will this translate to new format?
- platform: mqtt
name: “Garage Motion”
device_class: motion
state_topic: “blueiris/garagehd”
payload_on: “on”
off_delay: 30
a precision, configuration check is green, but sensor is shown unavailable/Unknown in the dashboards
Just because your configuration is free from (so to speak) grammatical errors the check for validity does not say your code will be working. (Like you could be waiting for a state “on” but the entity returns “true” instead - that would never be covered by the config-check. It’s just a syntax check, not more.
You aren’t showing enough of the working YAML, and you aren’t using code tags.
I have never used a cover device, and this is just a guess that isn’t likely to work. And I am assuming that it’s a switch (the missing part of your YAML).
mqtt:
switch:
- name: "Garage Motion"
state_topic: "blueiris/garagehd"
qos: 1
payload_on: "on"
off_delay: 30
1 Like
It’s likely a binary_sensor being a motion sensor.
mqtt:
binary_sensor:
- name: "Garage Motion"
state_topic: "blueiris/garagehd"
qos: 1
payload_on: "on"
off_delay: 30
1 Like
I already had everything split out and really didn’t want to combine it again, so I did this…
configuration.yaml
---
mqtt:
binary_sensor: !include_dir_merge_list mqtt/binary_sensor/
button: !include_dir_merge_list mqtt/button/
cover: !include_dir_merge_list mqtt/cover/
fan: !include_dir_merge_list mqtt/fan/
light: !include_dir_merge_list mqtt/light/
lock: !include_dir_merge_list mqtt/lock/
sensor: !include_dir_merge_list mqtt/sensor/
switch: !include_dir_merge_list mqtt/switch/
Then tweaked the top of the files to remove platform, dropped the files into their folders where they fit from the prior integrations, and done.
I probably will adjust things with friendly names now that I can and make it all look the same, clean it up, but it’s working again and no broken entities or required name changes.
File Structure…
4 Likes