if you install appdaemon then you can create a small app to do this easy.
it can also set input_booleans or switches back to off if wanted.
“if you install appdaemon then you can create a small app to do this easy.”
‘Easily’ for one guy is not very easily for another, if this HA open source automation system is going to flourish beyond tech geeks in the future it needs to have very easy to use components enabling the cheapest hardware to work with it…
I wish I had the time and knowledge to code contribute myself, but alas, in an ever increasingly technical world my forte is hardware not software.
Thanks for the idea in any case, I am not ungrateful.
i know they go in that direction, but i dont know if its a good thing for HA.
its just as easy as putting it in the yaml.
its
a) install AD (if you are on hassio, thats just another addon)
b) ask for the app i have or copy something from anybody else
c) configure some yaml for the app, just like in HA
I could finish this conversation by just saying
What’s an app ?..
but that would be cruel 
i would gladly give you the answer, but you already know that 
but i think the most important thing to know is that people tend to think that appdaemon is for people who know how to program things.
but it isnt just that. (it can be if you want to, and with some startertips that isnt difficult either)
besides that it includes dashboard its also a platform where people can share preprogrammed components that can be configured with yaml to make it usable for everyone.
so for features like this it is:
install AD, copy an app (piece of prepogrammed code), set the sensors you like to return to 0 in the yaml.
i think anyone can do that, dont you?
Yes sure, but to be blunt, why not just fix the obvious missing binary sensor type (this is a feature request thread and post after all).
I’d regard your appdeamon solution as yet another clever ever more complex kludge to ‘fix’ the real issue.
We could do that cludge feature fix stuff forever, for every feature requested here, but does it make it easier for the next guy starting out ? No it doesn’t…
i dont see it as an issue.
i think most feature request are asking for stuff that is already there or obsolete.
but oke, i see that it could be usefull to have it but then just as an option in the existing sensor
but then also for input_boolean, switch, and maybe some more components.
On some sensors (e.g. mqtt sensor), there’s an expire_after option. Maybe some code copying and there you go, feature request completed 
PD: I’m not a programmer, just user
Same issue, different guy. I should add them all here as I find them.
I should add that I have conversed with the RFLink hardware guy a few months ago. He says he didn’t write the HA component, so he can’t add a momentary sensor. That would also sort it like they have in RFXtrx component.
Another one, same trouble different novice user.
More.
Hi, I was googling for more than 2 hours how to reset binary switches to off, and now I got here. Heureka!
I have the same issue, that a simple, cheap RF Transmitter is sending its signal, when it is triggered. In my case a window contact. When opened, it sends endless code into the wild. It only stops when closed. But IT JUST STOPS SENDING CODE.
For HA the window contact is still opened, because it listens to a “close” signal, which the sensor does not provide.
So I also need something like: “listen to the code every 10 seconds” - “if you dont receive code anymore, put the sensor back to closed”
Or something like a button to manually reset the binary_sensor to off/closed/0/disabled.
You know?
Greetings from Leipzig
PLeaaase! 
do you have appdaemon installed?
such an app is quite simple.
import appdaemon.plugins.hass.hassapi as hass
class setvalueback(hass.Hass):
def initialize(self):
self.listen_state(self.set_back,self.args["entity"])
def set_back(self, entity, attribute, old, new, kwargs):
if new == self.args["listen_for"]:
self.set_state(self.args["entity"],state = self.args["set_back_state"])
now you can just add yaml after yaml for every entity you like.
in the yaml you put:
app_name:
module: py_file_name
class: setvalueback
entity: the_entity_you_want_to_change
listen_for: the_state_you_want_to_listen_for
set_back_state: The_state_you_want_to_change_back_to
in case of a binary sensor, just listen for on and set back to off
I too would like the state reset to be built in to the binary-sensor. I have NO desire to attempt adding a layer of complexity to home-assistant upkeep by adding appdaemon. The directions indicate that installing it in the wrong location can cause HA to stop working, the updating of it is separate from HA to be honest, it seems silly that you can not assign a state to the binary-sensor via an automation or have it done automatically from the creatng yaml code (as in binary_sensors.yaml).
i never knew it was possible to install AD so that you can cause HA to stop working, unless you really have no clue what you are doing. bu then again thats why they invented hassio 
Fortunately, the developers of HA built in the necessary function to resolve the issue (off_delay, starting in version 0.81) making AD a Rube Golberg. What surprises me though is that the original question that was asked in August of '18 never got that answer. The OP had to go to a different group to the get the answer. Just glad we have an elegant and simple solution to the problem now.
2 Likes
I needed to recreate a push button, I did as below not elegant but it works. instead of switch you can put your binary_sensor
automation:
- id: Apri cancello 12
initial_state: 'on'
alias: Apri cancello 12
trigger:
platform: state
entity_id: switch.cancello12
from: 'off'
to: 'on'
action:
- delay:
milliseconds: 800
- service: homeassistant.turn_off
entity_id: switch.cancello12If a device has tasmota on it the rules allow for automations based on sunrise/sunset, you can use timers, you can set variables and increment or decrease numbers you set, turn on/off rules as desired based on (essentially) if/then/else statements… but it’s still an art form, apparently, because I’m having a hard time with complex rules. I’d rather have the automation be local so if my HA is down or not available my dining room light still works as intended.
Glad to have recently learned about the off_delay tag for binary sensors, though - will help for single code sensors
This idea may be useful: