Automations doesn't trigger sometimes

Thanks Marius!

I have changed it to a binary sensor. Just for my understanding. What is the benift to change it from a sensor to binary_sensor? Would my previous configuration work?

well, it is a dedicated platform:

Binary sensors gather information about the state of devices which have a “digital” return value (either 1 or 0). These can be switches, contacts, pins, etc. These sensors only have two states: 0/off/low/closed/false and 1/on/high/open/true. Knowing that there are only two states allows Home Assistant to represent these sensors in a better way in the frontend according to their functionality.

and since you are creating ‘binary’ sensors, this would be the optimal platform to use. Regular template sensors can represent almost anything, which is the beauty of templates of course, and yes, it would have worked, albeit with the state you gave them (True/False)

2 Likes

Check out the comments I just added in that issue. It’s not clear exactly what was going on there, but it was clear there was at least some user error.

1 Like

Are you sure this wasn’t your problem all along? Even in your original post the entity_id of the humidity sensor was wrong.

I think you’re fooling yourself about creating a template sensor and thinking that will work any better than a template trigger. If you want or need the template sensor, then by all means. But that won’t make your automation work any better, because basically the template trigger will work exactly the same way as the template sensor and state trigger. You’re making your system more complicated than it needs to be without improving the situation.

100% sure. If it was a typo it never would work right? Now it works a few days and then suddenly the trigger won’t work for a day or something.

So which is the right entity_id? sensor.room_sensor_mijia_humidity which you showed in the earlier posts, or sensor.bath_mijia_humidity which you’re showing in your more recent posts?

Phil, I was suggesting creating the binary sensors so that he could include sensor.time (and all the other required entity_id’s) and then COMPARE it (not necessarily replace) to the functions of his automations (constructing an exclusive OR) and then build evidence of it not operating as it should.
My feeling is that he won’t find it but this a) taught him alternatives b) he read the docs (though not well, but I’m assuming English is not his first language) c) a man convinced against his will …

@Mariusthvdb , good catch on the sensor/binary sensor I was going to come back and review but got distracted. He also is making the newbie mistake of the inverse of > 37 is not < 37 but should be <= 37 or even more simply not > 37 . He also did not add in the sensor.time entity_id: we’d discussed.

Phil has spent 9m (so far) on his reply, it’s gonna be a long one !

Understood. You were suggesting a way to diagnose the problem, and not necessarily suggesting a solution.

Why use the template sensor’s entity_id parameter with sensor.time? That would just complicate things and could potentially mask the real problem, or at least distract from the real problem.

IMHO, the best way to diagnose the problem is to use the debugging tools built into the system. I.e., enable debug for homeassistant.core and check home-assistant.log when things are “working”, and later when things are “not working”, and see what the differences may be in the way the entities’ states are changing. I’m pretty confident there is nothing wrong with template triggers, and the real problem lies in the behavior of the sensors being used in the automation. Either they are malfunctioning, or at least, not behaving in the way the OP expects, whether that be the entity used in the trigger, or one of the entities used in the conditions.

He expressed an interest (earlier in the thread) in ‘constructing’ an entity that changed on a minute by minute basis. (So I was subtly pointing him at sensor.time)

I would agree that if 99% of the system works well ALL the time and only when interacting with ‘this’ and ‘that’, does it ‘not’ (still don’t know how that was ascertained even) then the most likely fault lies with ‘this’ or ‘that’ rather than the whole system running the other 99% sucessfully

The correct one is: sensor.room_sensor_mijia_humidity!

Thanks guys, i will also fix the “newbie” mistake :wink:

Regarding the sensor.time. “He” has not yet figured this out. Something about, time, work :slight_smile:

Ok, thanks. But that’s not what was in your original automation, so that automation must not have ever worked. It’s kind of hard to help if you post something other than what you’re actually using.

I would suggest enabling debug so you can see exactly what is happening in your system. That way we’re not guessing. Also, I would suggest not going down the path of “the template trigger doesn’t work.” It does. It may not work the way you expect, but it works. We can help you figure out why your automation doesn’t work as you expect, but we need accurate data.

Add this (or something similar) to your configuration to enable debug data that can help shed light on what’s happening:

logger:
  default: info
  logs:
    homeassistant.core: debug

That will generate a lot of output in home-assistant.log. You’ll probably have to use grep or some other searching technique to find the messages that relate to this problem. Or you can minimize other data with:

logger:
  default: error
  logs:
    homeassistant.components.automation: debug
    homeassistant.components.script: debug
    homeassistant.core: debug
    homeassistant.helpers.script: debug

If you need help interpreting what you see in home-assistant.log, let us know.

1 Like

Naobana, To reiterate we were testing and gathering evidence, you changed things and have no guarantee it will be any better.

I think you did well to get where you did but the binary vs multi-state is a biggie
HA stores all its states as text (well not all but it’s complicated) But we tend to uses numbers as numbers, booleans as booleans etc. This also keeps it clear in our minds what we are dealing with, what form it should be presented and what we have to do with it.
So Booleans are clean and are True or False (again the system garbles this with true/false, on/off, 1/0 etc.) Booleans are quick. clean and definitive (definately preffered)
I have ‘some’ sensors (binary) configured as you did but these are special circustances, I first did it for a Portugeuse Guy who’s system was set in English but needed window sensors to display (for his family) in Portugues rather than Open/Closed
(Though I don’t think HA has gotten round to ‘some’ languages yet, give it time )
(My wife has an occupancy sensor that is “In Residence”/“She’s Out, It’s Party Time !” - This works, but to be honest I cringe every time I look at it as I know it’s bad programming practice and is consuming more resource than it should/needs to :blush:)

And Hey ! We ALL started where you are, We ALL made stupid mistakes !
It has been AGES since I made one though … (Last Friday I think :rofl )
Mistakes are the way you learn. And though Phil appears gruff he IS REALLY good at this stuff and bends over backwards to help people (Stick with him !)
I think he corrected me last week about something, and that helps, as otherwise I’d be continuing through (HA) life believing somthing that wasn’t true.

There are others here who can split hairs about nothing (but you need to form your own opinions about that and sort the wheat from the chaff)

Keep on trying, reading and learning YOU WILL MAKE IT ! :+1:

Edit: And in comparison to Phil (or worse still … Taras), I’m a newbie too ! :crazy_face:
Edit2: Just looked it up, I have been on the forum longer than Phil (Just shows you that ‘time served’ does not equate to proficiency )

1 Like

sensor.time is one of a suite of sensors created when you add : -

sensor:
  - platform: time_date
    display_options:
      - 'time'
      - 'date'
      - 'date_time'
      - 'date_time_iso'
      - 'time_date'
      - 'time_utc'
      - 'beat'

to your config.
The first is sensor.time, which updates every minute
sensor.date updates every day
The rest - just read the docs


Not all of them are useful but …
1 Like

@Mutt

Thanks, ill keep trying :slight_smile:
First i will fix the > in the template triggers and after that i will focus on the sensor.time.

@pnbruckner

Totally agree with you regarding typo. The reason is that i have removed, out of desperation :wink: , some sensors hoping that it will fix something! Resulting in some bad copy pasting…

Thanks guys, ill keep you posted.

ps. new binary_sensors config:

binary_sensor:
  - platform: template
    sensors:
      temp_water_heat_more_than_37:
        friendly_name: "temp >= 37"
        value_template: >-
          {{ states('sensor.sonoffth_18b20_temperature') | float >= 37 }}
      temp_water_leiding_less_than_37:
        friendly_name: "temp <= 37"
        value_template: >-
          {{ states('sensor.sonoffth_18b20_temperature') | float <= 37 }}
      humidity_badkamer_more_than_75:
        friendly_name: "humidity >= 75"
        value_template: >-
          {{ states('sensor.room_sensor_mijia_humidity') | float >= 75 }}

@Mutt @pnbruckner

Hi guys,

I found the problem. The solution with the sensor.time helped me found out. What I found out was that the condition was not true when trigger was trigged. *shame

Trigger = true: 07:51:23
Condition = true: 07:51:28

Myy initial thoughts regarding the trigger and the condition where bit… blurry i guess :slight_smile:

However; i learned a lot of this and all of my automations are working fine now!

With a healthy amount of shame :wink: Thanks again!

1 Like

No shame involved.
Merely a learning experience !
:rofl: