Best Implementation Strategy for Bayesian Binary Sensor

Development
21

I just had a kid in October, am working full time, and have two exams in the next 3 weeks for my online MS in CS from GaTech. Maybe I’ll get around to it at the end of the semester :wink: .

2 Likes
22

Good luck with everything. Are you in ATL too?

23

Not too far away @arsaboo, I’m in Chattanooga, TN. I make it down to ATL for MLConf and a few other things from time to time.

24

Could you share the platforms and the associated accuracy? Would be a nice starting point. Tx.

25

Everything is available in my repo. Let me know if you have any questions.

1 Like
26

Hi, just wondering if you ever got around or are planning to to add a value_template sensor? I’ve been experimenting with this sensor for the past few days and think it shows promise especially for presence, but I notice a lot of limitations unless I’m approaching it all wrong. Most of these can be circumvented by creating separate sensors but it would be nice to support some common use cases imo and not make things too messy (it quickly adds up).

I’ve been looking at your code to add it myself, but I’m unsure how to properly listen to events for the entities used within a template. I assume that supporting templates itself doesn’t require any coding, that in essence you just create invisible entities?

A few other ideas I had:

  • set a deactivation threshold. I imagine it as a sort of potential barrier (I’m a physicist sorry :P), once a sensor is triggered it is harder to ‘de-trigger’. I’ve tested a sort of recursive pattern where I use the on state of the bayesian sensor itself as one of the sensors, but that seems like a hack to me (it does work though). It’s easy enough to implement, but I’m unsure if it makes sense since I’m not too familiar with the Bayesian approach.
  • scaling probabilities. Say I have a time sensor, it gives me the time since a motion sensor was last triggered. To me it makes sense that the probability scales with some function of that time. It would be nice if we could provide an upper and lower limit and a ramping function (for instance: linear, quadratic, logit). So instead of the hard border for a numeric state more of a fuzzy border. Probably makes most sense for ‘negative’ sensors.
  • A ‘for’ field that specifies an amount of time a certain state is true. A simpler version of the template, and mentioned in this thread. I am unsure how to best implement this. Can you just start a timer on a state change to a callback like in appdaemon and cancel that callback in case the state changes back again?

Let me know what you think. I haven’t supplied any code or HASS so far, but I assume I would just fork the github and supply a pull-request? In general I assume it will be harder though to change an existing platform, is there some process I would have to go through?