Solved : Input_number and MQTT

Configuration
1

Hi,

I am using HA 0.91.1.

I have a input_number (slider) and I want to publish the value to MQTT. Whenever I move the input slider, there is no value on mqtt (publish).

This same script used to work with version 0.83, but its not working. I went through the forum with similar questions and none helped to solve the problem.

Can you please help me fix the problem. Thanks.

input_number:
  alarmminutes:
    name: Minutes
    icon: mdi:timer
    initial: 5
    min: 1
    max: 44
    step: 1
    unit_of_measurement: minutes  
    
automation:
  - alias: WaterMotor run time slider
    hide_entity: True
    trigger:
      platform: state
      entity_id: input_number.alarmminutes
    action:
      service: mqtt.publish
      data_template:
        topic: 'home/watercontrol/timer/run/set'
        retain: true
        payload: "{{ states.input_number.alarmminutes.state | int }}"

# MQTT in (subscribe)        
  - alias: Set waterpump runtime slider
    hide_entity: True
    trigger:
      platform: mqtt
      topic: "home/watercontrol/timer/run/set"
      # entity_id: input_number.alarmminutes
    action:
      service: input_number.alarmminutes
      data_template:
        entity_id: input_number.alarmminutes
        value: '{{ trigger.payload | int}}'
2

have you tried to paste your payload template (without double quotes) to the template editor? Is it showing correct values?

as an option, replace it to

"{{ states('input_number.alarmminutes') | int }}"

btw, are you trying to save that data between HA restarts?
if so, itā€™s already saved by recorder (need to be enabled), just donā€™t use initial: in your input_number configuration.

3

@AhmadK Thanks. Yes the value is changing when I move slider. (template editor)
But the mqtt topic is not receiving the new changed value.

4

try to post any value to the topic using HA UI and check if it appears in the mqtt broker log

5

I used MQTT publish from HA UI and posted a new value on the topic and I can see the value changed in mqtt logs (checking in a mqtt app subscribed to the topic).

6

then create a test automation that publishes a set value into the topic at a certain time and trigger it from UI to see if it works.
just donā€™t copy-paste, write it from scratch.

7

@AhmadK Thanks for you help.

Actually I missed adding this one in the automation section.

initial_state: 'true'

Now the automation works (the same script).

8

Hurray! :wink:
I hate that new default behaviourā€¦ oh well

Actually, it should be
initial_state: true

1 Like
9

If you upgraded from 0.83 to a newer version, your automations were probably turned off due to a revised ā€˜restoreā€™ feature added since 0.83. This is a documented behavior and the solution is to simply turn on the automations.

You didnā€™t ā€œmissā€ adding it, the automation was probably just off. All you had to do was turn it on (via Lovelace UI or the States page).

Adding initial_state: true accomplished the same thing. However, it has also excluded this automation from Home Assistantā€™s ā€˜restoreā€™ function. In other words, should you ever decide to temporarily turn off this automation, it will automatically be turned back on when Home Assistant restarts. If this is the behavior you want, great!

On the other hand, if you want automations that you turn off to stay turned off, donā€™t tag them with initial_state: true. By default, after a restart, Home Assistant restores the previous state of all automations. The option initial_state: true overrides this behavior.

NOTE:
Be advised that if Home Assistant fails to startup successfully, it may prevent it from restoring the previous state of all automations. In that case, all automations could be off when Home Assistant finally does restart successfully. If your Home Assistant system is prone to unsuccessful restarts, then use initial_state: true to ensure an automation is always on.

I donā€™t have that problem so thatā€™s why I donā€™t use initial_state: true for any of my automations.

1 Like
10

Itā€™s not that easyā€¦
My Home Assistans doesnā€™t seem to be prone to unsuccessful restarts, but at least once straight after update I noticed that 3 of my key automations that I intentionally had left without initial_state to have their states restored by HA became disabled - I definitely didnā€™t do that.
Perhaps that sort of ā€œrecoveryā€ should be complemented by a diagnostic message in HA log.

11

Given how Home Assistant evolves rapidly from one release to another, itā€™s almost a given that there will be surprises after an update. :wink:

Perhaps of no help to you but Iā€™ve not experienced that problem and Iā€™ve upgraded from 0.89 -> 0.90 -> 0.91 (and none of my automations are using initial_state: true).

Nevertheless, I do like your suggestion that, in the event Home Assistantā€™s canā€™t restore the states of all automations, and defaults them all to ā€˜offā€™, it should (minimally) report that operation in the system log (as a WARNING). That just seems like basic good manners as opposed to covertly shutting off all automations.

If you post that as a Feature Request, Iā€™ll vote for it.

1 Like
12

from my experience voting for feature requests barely happens.
I create a new issue instead :wink:

1 Like
13

Sure but donā€™t forget that GitHub issues are not for feature requests (it states that within the Issue template). Iā€™ve seen Issues unceremoniously closed for asking to add new functionality.

1 Like