Ive got this automation working connected to a input_boolean, the problem is that it only sends the payload when switched on, I need it to also send a message when turned off. How do I do that:
Thanks. I got it working but Iâm not sure I like it? So I have a panel (in front end) with 2 automations and another panel with an input_boolean toggle.
I have to toggle both automations to ON and then toggle the input_boolean to ON to get them to turn on. My dashboard will get full of panels quickly.
First of all, I would take the line âinitial: offâ out of the input_boolean definition.
This means that when you (re)start HA, it is switched off by default - if you donât define it, it will remember the last state.
Second, if you take both, the âfromâ and the âtoâ line out of the trigger section it should work in both ways, i.e. when the input_boolean goes from off to on as well as when it goes from on to off.
The automation(s) should be on, read: active, once you have activated them - even after a reboot - unless, you defined an initial_state: "off" somewhere in the automation itself.
I agree re: initial state but if they get out of sync, youâll be happy you have 2 automations. Additionally, if you use lovelace you donât have to display anything you donât want to see on cards - you really only want the switch.
Good point about the âout of syncâ issue - I normally define at least one of the states, from or to.
Having a hard time to see how it could get out of sync, though, but I think that @DavidFW1960 is right: good principle to stick to.
Same for displaying the automations - as soon as you use Lovelace, you donât even have to worry about a default_view any more. Just show the input_boolean, done.
If you turn an automation off or it gets turned off (say restarting too many times) etc, then the input boolean wonât match the automation state so itâs just way better to have the automation detect the state change of the input boolean and then act accordingly. I did discover this the hard way lol.
Oh yeah⌠and then the switch becomes a toggle and you donât know if toggling it is going to activate or deactivate the automation.
ok I took out the initial: off from the input_boolean.
I want to make sure before I remove the ones from the automation. Here is the thing:
I already added a second automation from on to off. So what you suggest is to remove off to on and on to off from each of the respective automations. Right?
Would I also need to remove the second automation then?
Because here is the thing, im not doing a strict mqtt message to an mqtt device. My 2 automations are:
id: â1540843414270â
alias: MQTT T1R1 ON
trigger:
entity_id: input_boolean.notify_home
from: âoffâ
platform: state
to: âonâ
condition:
action:
The reason being that the mqtt message has to be parsed by a file on the rpi3 broker, mqttReceive.py, which reads the msg.payload and using an if-else, calls one or another python file to either turn a relay on or off. So I really need the msg.payload to carry the message. If I leave one automation only, what would I use as payload? OHhhhhh ok, both automations are sending the same payload so yeah, I would do this:
His concern about the possibility of the input_boolean and a single automation getting out of sync is valid - although I think there would only be a small chance of it actually happening.
Itâs also that if you have 2 automations and a switch that you KNOW that if the switch is on, then the automations are on as well, whereas if you only have a toggle, seeing the switch on or off tells you NOTHING. Not to mention the aesthetics of a switch being ON tells the brain the automations are also ON. 2c.
Unless Iâm mistaken (which is completely possible then ignore this) I think you are getting confused about what the automation being âonâ or âoffâ means. I saw this in another thread that you posted too but forgot to get back to you on it.
The automation being âonâ just means that the automation can be run when the trigger is satisfied.
For example, if the automation is âonâ and the input boolean turns âonâ then the automation will run. if the automation is âoffâ and the boolean turns on it wonât run.
You need to generally leave all of your automations in the âonâ state all the time. By default, that is the state they will be in when you create them unless you specify otherwise by configuring "initial_state: âoffâ ".
If you leave the automation âonâ all the time then you can switch your input boolean on and off repeatedly and every time the boolean goes to on it will trigger the automation.
Then when you create another automation (leaving the default initial_state which is âonâ) that triggers on your boolean turning off then every time the boolean turns off then that automation will run.
You donât even have to display the automation in the frontend at all if you donât want to.
Youâre misunderstanding me. I use the input Boolean to turn the automation on or off. Actually, when I am going away for a few days, I use the input Boolean to disable automations I donât want to be triggered (like fixed time ones) when I am not there. I donât need my lounge room lights to come in or my coffee maker for example. So rather than trawling through the automations to see which ones to disable they are controlled by the input Boolean the turns an automation group off or on.
Iâm sorry David that was for the OP. I think they are confused by the automation on/off references. I should have been more specific on who I was addressing.
Ok so youâre saying that I should leave both automations: from off to on, and from on to off. However I remember someone suggesting i remove the from:OFF and to:ON from my automation.
Question #1 - Should I remove the from: & to: fields from both automations?
Question #2 - Im getting confused with this talk of switch and toggle. To me they are the same, so please explain a bit more what you mean by âand then the switch becomes a toggleâ?
Question #3 (which is really Q1 again) - So in the end you are saying that I should leave both automations, remove their from:to: values, even though both automations will be sending the same payload, their state?
If all you want is a widget on the UI that, when turned on will send an âonâ over MQTT, and when turned off will send an âoffâ over MQTT, you only need the input_boolean and one automation with no to: or from: set.
The concerns about âout of syncâ and such do not apply since your automation is directly sending the state of the toggle (input_boolean). When itâs on, itâll send âonâ⌠and the same for âoffâ.
You can also do this with a single MQTT Switch. Something like this:
Kind of⌠you need to at least leave the " to: âonâ " and the " to: âoffâ " in their respective automations. You donât need to explicititly state the "from: " condition because, in this case, there are only two possible states for the boolean to be in (off or on). If it is going " to: âonâ " then by definition it was going " from: âoffâ ". However, there are times when there could be more than two possible states for an entity so in that case a " from: " could be necessary.
SoâŚ
Q1. Only remove the "from: "
Q2. There is a distinction, however slight, between a toggle and a switch. While both only have two states the end result of the action of the device is specifically different.
A switch is used when you want to change the state of the attached controlled device to always match the switch state (or it could always be opposite the switch state too). A toggle is used to invert the current state of the controlled device.
examples are a simple single light switch that if on turns on a bulb. Thatâs a switch. Then a toggle could be a two way switch that will turn the light on if itâs currently off or off if itâs currently on.
Normally âswitchesâ are maintained while âtogglesâ tend to be momentary but donât need to be. It all depends on how the switch is wired or programmed determines the ultimate functionality of the âbinary deviceâ that we call a âswitchâ.
Q3. see Q1
This is general info tho since the code posted above will likely work for what you seem to want to be able to do.
Ok now I ran into something different. I actually have 4 relays on the relay board, so at present I have this:
This just controls one relay on the other side. Now I need to add the other relays which also have on and off. So I added 2 more input_booleans and Ill have to add 2 more automations for each.
Ill add them with only to:on and to:off like you said.
The problem I noticed is that this will send an mqtt message to the broker, as set up so far, with the same payload and to the same topic, so sending ON to any of the new relays, will be âheardâ in the same topic and same payload state value and turn on the first relay as well.
I would have to change the topic for each automation, so:
topic = test_channel for the first automation (ExtLights)
topic = test_another for the sec automation (kompressor)
topic = test_uhother for the thr automation (solenoid)
Obviously Id use a more suitable name like ExtLights_channel, Kompressor_channel and Solenoid_channel. But Its getting cumbersome. Id have to modify my python-if-else for processing the topic first and then the payloadâŚer, I could also send a payload of 01, 02 for ExtLights, 03, 04 for Kompressor, 05, 06 for Solenoid and 07, 08 for the last relay when I need it. This seems cleaner.
I think I agree with all of what you said above *.
The only question that it brings up is that, since I assume that all of these relays existed previous to switching to HA, did you control each of them individually before? If you did then how is making three different booleans to control them any more âcumbersomeâ than your previous setup? You would still need three control devices then as well or am I missing something?
as pointed out above by @swiftlyfalling if you simply want a switch on the GUI to control each relay so that the state of the relay always matches the switch state you can forego the automation completely and just create a MQTT switch for each relay with the correct payload to control each relay on or off. Then you can completely get rid of the automations and input_booleans and just use the created switches.
rpi3 runs script (turn1ON.py, turn1OFF.pyâŚ) and each script writes to a ble characteristic on the relay boards ble module sending the appropriate command to turn it on or off.
How it runs now:
rpi2 with ha toggles automation (which I now understand I can leave ON)
rpi2 with ha toggles ExtLights input_boolean which publishes mqtt message
rpi3 receives message and parses payload
rpi3 calls respective py script based on if-else
So with an mqtt switch I can send the msg to the rpi3 which would emliminate the 8 automations, right? Sounds good. What about the state of the mqtt switch? Does the switch keep track of the state?