Workday sensor triggering at midday not midnight

Configuration
1

Hi all,

like my topic says, the workday binary sensor is state changing at 11am, not midnight (note: i may be reading the history incorrect)
the binary sensor was was working correctly in 0.96.1
but since i’ve upgraded to 0.102.3 this midday switching is seen

note: all my events based on a time e.g. alarms, sunset etc are still working as expected

workday
workday1063×232 22.2 KB

yaml

binary_sensor:
  - platform: workday
    country: AU
    province: VIC
    excludes: [sat, sun, holiday]

does anyone have any insight?
my partner doesn’t like our “wake-up for work” lights turning on over the weekend.

cheers!

2

dum question is the computer clock right

3

That was my initial assessment too, but all logs when something is triggered manually is accurate.
E.G. If I activate one of my Lifx lights at 9am, the history in HA shows that I activated that light at 9am.

4

I believe there is a bug in this code (that has been there since it was first written.)

First, it’s not just updating at midnight, it updates periodically (every 30 seconds) for some reason. Second, and more importantly, it’s calling datetime.today() to get the date, but it should be calling homeassistant.util.dt.now().today(). The former uses the environment’s time zone setting (OS, docker container, etc.), whereas the latter uses HA’s time zone configuration.

To see if this is why your workday binary sensor is updating at the wrong time, enter the following into the Template Editor and let me know what you get.

{{ now() }}
{{ now().tzinfo }}
{{ now().astimezone() }}
{{ now().astimezone().tzinfo }}

I suspect the problem didn’t start because of upgrading from 0.96.1 to 0.102.3, but rather when you made some change to the environment in which HA runs. E.g., did you maybe start using hass.io?

5

There are no dumb questions :rofl:

6

I realise that it would require people to include sensor.date (no bad thing in my book along with all the associated ancillaries) but this would trigger only on a new local day ?
What have I missed ?

ie should be added to default configuration ???

7

It looks like a bug, maybe you could create PR to fix it?

8

I’m not sure what sensor.date has to do with a workday binary sensor.

9

Sorry, I was aiming at what I would use if I was doing it within HA.
Your homeassistant.util.dt.now().today() is the Unix request to get the current day, I assume ?
And when would this be updated ? (frequency)
I was kindof aiming at something that would need fewer requests and “IF”

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

was part of the standard configuration, then all those requests and updates would be done and just part of overhead.
The date part would update once per day and at the right time for any (local) ‘day’ sensor
I realise that the workday is probably written with direct access to the OS but why does it need to be (probably along the lines you are suggesting using the homeassistant.util.dt ‘thang’ but my ignorance of the distinction is probably meaning that I’'m at a slight tangent to reality (normal for me :crazy_face: )

10

I think you misunderstand. workday is an integration in HA which creates a binary_sensor that indicates whether or not it is a workday based on the configuration of the entity. homeassistant.util.dt.now().today() is Python code (which is part of HA) that I’m suggesting should be used within the implementation of the workday binary sensor code instead of what it currently uses.

To be clear, I’m not talking about templates or scripts or automations, I’m talking about Python implementation code.

11

@culloden_spectre, you’re leaving us hanging here. :slightly_smiling_face: Can you try entering what I showed above in the Template Editor and telling us what you get? I’d like some verification that an incorrect time zone setting in the environment is causing the problem before I consider trying to fix it.

12

Hey Phil,

currently on site this week for work and unable to get to the machine physically or remotely.
as soon as i can (Saturday local time, Aus) i will.

appreciate the effort!

1 Like
13

Ok so, with the help of the fine People above me I have worked out where I have gone wrong.
On my latest Docker install (0.102.3HA) i didnt set the TZ environment variable, but i had done it on the previous version (0.96.1).

running:

{{ now() }}
{{ now().tzinfo }}
{{ now().astimezone() }}
{{ now().astimezone().tzinfo }}

yeilds:

#Previous Docker
2019-12-20 09:08:01.058755+11:00
Australia/Melbourne
2019-12-20 09:08:01.060178+11:00
AEDT

#Current Docker
2019-12-20 09:13:39.476343+11:00
Australia/Melbourne
2019-12-19 22:13:39.477162+00:00
UTC

so i have made the changes to the new Docker container with the environment vairable TZ=Australia/Melbourne, and im sure this will solve the workday sensor switching

@pnbruckner seems you were spot on the money, appears the workday sensor is not using the HA configured TZ.

1 Like