Feature to make binary sensor entity to automatically reset back to 'off or 0' after fixed time delay in HA

I refer to resetting the entity in HA here of course, not the actual physical sensor device reporting back to the system, which is a dumb ‘transmitting in the blind’ RF device.
i.e. cheap 433Mhz RF door opening, window opening, battery PIR detectors, doorbells and smoke detector style of things, mainly the low cost ones that send ONLY one RF code when triggered and can’t ever send an OK or OFF to negate the trigger. Most users seem to be using RFLink or Sonoff RF Bridge to receive these devices…

There are components that do this for you in hardware already like the RFXtrx binary sensor component so it seems useful.
It also seems to be very hard to do this in HA unless you do a bunch of custom configuration steps and automations that are most suited only to very experienced coders. For using a large number binary sensors this become onerous to create as well.

RFXtrx binary component seems to use the off_delay parameter to fix this easily…

Perhaps one automation for all say HTTP Binary sensors could be enough to address the issue. It would be triggered by state change (to ‘on’) and could even have a custom delay read from attributes before resetting it to off.

Yes, triggered by a state change on the binary sensor, state then reset by a delay parameter, would fix the missing support. I think it may also need a parameter to define the ‘at rest’ state after HA reset.

To clarify, do you really mean HTTP in this context or MQTT actually ?

I think this would relate to any binary sensor, it doesn’t matter if it is HTTP or MQTT.

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 :slight_smile:

i would gladly give you the answer, but you already know that :wink:

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 :smile:
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! :slight_smile:

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 :wink: