Help me tie it all together

Configuration
, ,
1

Firstly, this may be a long post so I apologize in advance. Secondly, thank you to this community of HA enthusiasts. It has been a tremendous help for a noob like me. Please be forewarned I am in way over my head, but determined to learn, with a little hand holding along the way.

I’ve setup a decent infrastructure of sensors around the home, and want to tie it all together. I am a little lost on what to do next.

We are using a combination of espresense BLE detection, motion sensors, occupancy sensors (aqara fp2), pressure sensors etc. Now I want to be able to tie all of that together to detect who is where in the home.

Alongside, I want to be able to implement Home, Away, Just left, Just Arrived, extended away states.

Here is what our rooms look like:

Office, Gym, Kitchen, Garage : ESPresense BLE tracking
Kitchen: ESPresense BLE tracking + motion sensor
Living room: Aqara fp2 occupancy sensor + 2 x ESPhome pressure sensor in the sofa
Bedroom + Bathroom : sensors coming soon

For Home/Away status, I have unifi integration setting our status to away after 5 minutes of not being connected to Wifi.

Now that you know what I am working with, here is what I am looking for.

How can I get status tracking per person using multiple entities and devices. How do I actually tie it all together? Is it input selects? Template sensors?

I am dealing with different devices and would like to create a logic of “Check this device AND this device” = In room name

I have used a few tutorials, but noticed they’re a bit outdated and way out of my scope. So before diving in, I thought I’d ask the forum on what the next best step would be.

References:

https://gergo.io/comprehensive-room-presence-detection/

Thanks everybody

1 Like
2

Your first reference looks like it’s seven years old - can that be right? Home Assistant moves very fast, so I should ignore that one. :grin:

The second one is more recent - although generally it’s a good idea to avoid video tutorials if possible because they can’t be updated easily.

My advice would be to do this slowly in stages - your outline sounds very ambitious. Start with one person, one device and one room, then show us what you have done and we may be able to comment - it’s quite difficult to give general advice.

But to answer your specific question, I think most people would tie it together with template sensors.

3 Likes
3

Seven years old, but still a valid concept. :slight_smile: Phil had some really good ideas back then. The code part is not really outdated, it should still work, but the second tut uses new techniques, like input_select and is therefor more up-to-date.

And it’s still in use with some users, me for example. :laughing:

If you want to use it, @BlackMamba08, you should first start with the basics. For the first days I’d use just “home” and “away” and would implement the in-between states later. You’ll need quite some time to adjust all the different devices, and get used to the way they work and interact with HA.

The in-between states are a goody, that is nice to have, but not necessary for the basic functions. :slight_smile:

It’s hard to say, what your next steps should be. Presence detection is so individual, you need to find a concept, that fits you and your household. Everybody has different needs and wishes.

As a suggestion, start by setting up some input_selects, one for each person you want to track. For the beginning, use only two states, “home” and “away”.

Now you can start to write one or more automations, that react on the state changes of your various sensors.

Start small, use one sensor at a time and let it change the input_select of the user. And on your way you will stumble over things, that work for you, and some that don’t. So over time you’ll get a fine grained control, on how to react on changes.

If you have that running smoothly, add rooms and your other states like “just arrived” to the input_select.

But this is only one example. That’s why presence detection is and has to be so individual. Depending on what you need the presence for, you might be ok to work with one input_select with states like “away, dining_room, living_room”. Or you might need more than one like “home, just arrived, just left, away” and “living room, dining room, and so on” to get the automations perfectly fitted.

It depends so much on your wishes and needs, that it might make more sense, if you think about, what you want from your presence detection specifically.

We can help you with the technical side, but the concept must be from you, otherwise it won’t fit your home. :slight_smile:

1 Like
4

Thank you both for your reply. @paddy0174 @Stiltjack

I totally understand the difficulty in giving conceptual advice based on a “wish list” of automations.

We have a working “Home” and “Away” setup already using Unifi Network. It puts us to away after 5 minutes of not being on the Wi-fi. Its been working great so far.

So just to confirm, with the input selects, as I understand the input select is simply a dropdown menu - we still need to write an automation that tells the input select which option to select, is this correct?

I will definitely take your advice and start small but I want to know which option is viable going forward as I add more functionality.

Would it be to create input_select for all the states then write an automation for each sensor when triggered to change the input select?

Or would it be template sensors in one automation that update the input_select based on state changes?

If the latter, can template sensors use a state of 2 different entities to then change the input select? For example if Living Room occupancy is detected via mmwave AND couch pressure sensor is ON = update state of person.person via input_select to “Living Room”

Knowing the functionality will help me know which route is more future-proof as I build my eco system

Thanks!

5

Jep, that’s correct, you need one or more automations to change the value of the input_select. And on this change, you react with the automations that actually do something with the state, like turning the light on. In these automations the trigger would always be a change of the input_select.person.

Let me give you a stripped down example from my own presence detection automation.

  - alias: 'Presence detection pat'
    id: 'Presence detection pat'
    initial_state: 'on'
    mode: queued
    trigger:
      - platform: state
        entity_id: 
          - here is a list of all my entites belonging to this person
        to: 
    action: 
      - service: input_select.select_option
        target:
          entity_id: input_select.presence_state_pat
        data:
          option: >-
            This is where the magic happens. Here you decide, which state the person should have and select it. Eg. the value here is "home" or "away" (in a minimal version)

As triggers I use a list through different template and “normal” sensors, as well as device_tracker entries or whatever gives me a value, where I can work with and decide if someone is here or not.

If any of these sensors change, the automation is triggered and my presence will be evaluated.

And in the option field, you calculate if you are here or not. Something like, if sensor AB is true AND sensor BC is “> 200” OR sensor CD is home and so on.

This is where your concept changes into calculateable software in the form of a Jinja template. As stated in the code, this IS where the magic happens.

In my case I use a point system, where I award points to different sensors, so I can make eg. the phone-BT more “valuable”. If I cross a threshhold (in my case 70 points), I’m home.

Sounds simple enough, but the “magic” is something that needs to be developed. I found it quite hard to come up with a basic system, that would fit my needs. But since I now have it in place for years, it turned out to be quite robust.

6

At the conceptual level, the approach @paddy0174 is advocating is really important and helpful (at least in my experience.)

One set of automations that are all about setting the state values of Input_Select and/or Input_Boolean helpers (maybe call those “Determination” automations), and another set of automations all about doing things when those state values change (maybe called “Reaction” type automations.)

This approach gives you excellent capability to evolve and grow your home environment. For example, you can add new sensors or processes for determing presence in a room, and all the reaction automations that do something when presence is detected now all “just work” better. Or, you can refine the reaction automation without the complexity of having to go touch every different sensor device involved.

This also greatly simplifies the automation logic as your plans evolve… to for example, enable things to happen differently when “It’s Dark Outside” or when “Vacation Mode” is True.

This is largely about ongoing maintenance and evolution of your home automation environment. Which is where most of your work will be :slight_smile:

7

Thanks for the cudos! :smiley: :+1:

This is version 2.0 if you will, I have another input_select called residence_state. The values are “morning, day, evening, night” and change by a combination of time of year, sun elevation and time itself.

Together with the input_select.person this gives an easy to handle state for my living space.

Something like, IF input_select.residence is changing to evening or night AND input_select.person is home, the light should be turned on.

I find it easy to use, that’s why I implemented it for myself, but that doesn’t mean it will fit others. :slight_smile: So if you have any questions, please ask. :slight_smile:

8

Thank you so much. I have created input selects for both our home/away states and another with all of our various rooms. I now know exactly what an input_select does and that’s huge for me. I will try some basic automations and test them in real life (lol) and see what needs to be improved.

Posting a snippet with your code with the explanations was extremely helpful. You are talking to someone without any programming knowledge. I learn HA by reading, watching and using other peoples explanations then adding my own entities/ids and seeing what each snippet of code does by flipping back and forth between UI and YAML. This time last year I gave up on HA cause I couldn’t set up a complex motion sensor/lighting automation. I came back determined to push forward and was able to learn so much by just using this approach of learning + trial and error + using the vast resources of automations from other people.

I now have some automations that I couldn’t even imagine being able to setup last year.

I have a few follow up questions for you if you don’t mind.

1.) Using templates as triggers sounds incredibly powerful. Can you provide me an example on your personal use-case for this?

2.) Edit: This was a question about template sensors, but I read your post many, many times and I get it. JInja is daunting but understanding WHAT The code does is more important than seeing the code - for someone like me.

Anyway, a code snippet of your template sensor would still help

3.) Points system is great. it solves a lot of questions I had in my head on how this would all come together. So thank you for that.

9

Thank you for your advice. Can I ask if you and @paddy0174 are talking about the same path?

Patrick posted a code snippet of his “presense detection” automation. This includes all the devices and entities used to detect this person.

So if I get everything right - both of you are saying to use that as a basis automation to change the input select. Then I would have other “sets” of automations that use the state of the input select as a trigger.

So at first I thought you were both referencing different routes to take - but now I understand conceptually its the same thing.

Thanks!

10

Sorry for spamming replies. I really want to make sure the time and effort ANYONE puts in to reply is greatly appreciated.

Thanks for this as well. residence_state is exactly what I had in mind as well. We are in the process of finding alot of our automations aren’t necessary of even desirable ALL the time. A residence_state solves all the questions I had about that.

Sometimes for me, I have ideas but can’t conceptualize how they literally come together. Seeing your replies and examples of your own house just explained to me - makes alot of sense.

Thank you again and again!!

11

Exactly. I was trying to support/encourage consideration of that “two step” approach.

That said, there is definitely no “one way” or even “best way” to do this. It really should all be about what makes sense and seems logical and intuitive to you. If you look at this path and think “that seems dumb, why would you do that!”, that’s honestly OK and you just need to find a different paradigm that works better for you. All I can say is that this approach works and “seems right” to me, and helps me get my head around and manage my automations.

Btw, I also have (totally independently) the same state values for residence_state (though I call it “Home State”). I also have a few other helpers such as “Outside Temp” (Hot, Warm, Cool, Cold, Icy), “Holiday Time” (True, False), and “Its Dark Outside” (True, False) that use this same technique.

12

We all are.

4 Likes
13

Thanks to you too, you’re very welcome! :slight_smile: Glad I can help! :smiley:

Sometimes it just needs this small little thing, to see the bigger picture. And we’re all here to help and get further together!

So, enough with the romance, we’ve things to do here. :laughing:

It’s actually nothing fancy, it’s just a minor detour. If you can’t take a sensor or whatever value directly as a trigger or condition, you setup a template sensor, in this case a binary_sensor to get the complicated things done, and just give out a “yes” or “no”.

There is an example for this in the docs, but it is very well hidden under alerts, but it describes it perfectly:

It is exactly, what you might want to do, but you don’t use this binary_sensor with an alert, you just use it with your automation.

template:
  - binary_sensor:
      - name: "BlackMamba08 BT devices"
        state: "{{ states('binary_sensor.bt_mobile') == 'on' or states('binary_sensor.bt_keychain') == 'home' or states('binary_sensor.bt_hallway') > 0 }}"
        device_class: presence

Now you take this binary_sensor into your presence automation and use it as a trigger.

  - alias: 'Presence detection pat'
    id: 'Presence detection pat'
    initial_state: 'on'
    mode: queued
    trigger:
      - platform: state
        entity_id: 
          - binary_sensor.blackmamba08_bt_devices
          - next template sensor
          - or device_tracker
        to: 
    action: 
    [...]

Afterwards you can use this template sensor in your “action template” as well, to decide what to do. I’m using my points system here.

Something like IF binary_sensor.blackmamba08_bt_devices is on for ten minutes, add 12 points ELSEIF binary_sensor.blackmamba08_bt_devices is off for five minutes add 6 points and so on.

Does that make sense or did I miss something important to explain? :slight_smile:

Again, you’re very welcome, I’m glad, I can help! :+1:

As I said above, it’s normally only one little thing, that puts it all together. If I haven’t been clear enough, let me know! :slight_smile:

In Germany we have a saying: “Two idiots, one thought”, that is normally used, if two people do the exact same thing, independend from each other. :rofl:

Exactly what I’m doing, in my case it’s called “Light_mode” (-> Dark Outside), “Workday” and “The Outside”… :rofl:

So now we have proof, it IS a good system to work with. :laughing: But as you said, it needs to feel right, than do it, otherwise choose a different approach.

2 Likes
14

Perfect reply. I totally understand.

I do now have a technical question. Which is great because progress has been made

alias: Location Updater BlackMamba (TESTING AGAIN)
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.blackmamba_s_watch
    to: null
  - platform: state
    entity_id:
      - binary_sensor.couch_sensor_blackmamba
    from: "off"
    to: "on"
condition: []
action:
  - choose:
      - conditions:
          - condition: state
            entity_id: input_select.blackmamba_location_selector
            state: Away
          - condition: state
            entity_id: sensor.blackmamba_s_watch
            state: not_home
          - condition: state
            entity_id: binary_sensor.couch_sensor_blackmamba
            state: "on"
        sequence:
          - service: input_select.select_option
            target:
              entity_id: input_select.blackmamba_location_selector
            data:
              option: Living Room
      - conditions:
          - condition: state
            entity_id: sensor.blackmamba_s_watch
            state: not_home
        sequence:
          - service: input_select.select_option
            target:
              entity_id: input_select.blackmamba_location_selector
            data:
              option: Away
      - conditions: []
        sequence:
          - service: input_select.select_option
            target:
              entity_id: input_select.blackmamba_location_selector
            data:
              option: "{{ trigger.to_state.state | replace('_', ' ') | title }}"
  - if:
      - condition: state
        entity_id: sensor.blackmamba_s_watch
        state: not_home
      - condition: state
        entity_id: binary_sensor.couch_sensor_blackmamba
        state: "off"
      - condition: state
        entity_id: binary_sensor.aqara_presence_sensor_presence_sensor_2
        state: "off"
    then:
      - service: input_select.select_option
        target:
          entity_id: input_select.blackmamba_location_selector
        data:
          option: Away
mode: queued

This is the code I have now. It comes from a combination of your help, an extracted blueprint I found online and A LOT of switching back and forth from YAML to UI.

It works quite well but of course I need more tweaking.

Right now I’ve added 2 entities.

The watch updates the input_select based on the ESPresense room I am in, however, if watch detects not_home/away, and living room couch sensor is ON, the input_select = LIving Room

1.) The issue I am having is that if I go from the kitchen (ESPresense) to the living room. The watch is still connected to the kitchen since I have a timeout of 30 seconds so the state doesn’t change. I am already sitting on the couch. By the time the state changes for the watch, the couch sensor has already been ON and does not trigger the state change. So the input_select stays as “Away” as the watch is now not_home.

I know the solution is a template sensor. How would you tackle this?

2.) How would I implement a points or “value” system. I would love to do something like "If BlackMamba watch is in office, and office motion sensor detected motion within last 5 minutes = full amount of points (I am in the office for sure)

OR

If Blackmamba watch is kitchen, but living room presense sensor detected presence AND couch sensor is ON = I am most likely in the living room and not kitchen

Would you reccommend a points system like your example, or a bunch of template sensors checking the state of all of the rooms sensors?

I think I’ve made a lot of progress and learned alot over the past few days. Especially regarding iBeacons, API’s, scripts, input_selects, template sensors and blueprints.

I was able to extract a blueprint and use chatGPT to make my spotify music follow me room by room using the input_select mentioned above. Quite cool…