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.
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.
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).
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.
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.
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.
Given how Home Assistant evolves rapidly from one release to another, itās almost a given that there will be surprises after an update.
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.
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.