E4C5
Skip to content

time sync notification - #1442

Merged
glmnet merged 4 commits into
esphome:devfrom
badbadc0ffee:on_time_sync
Jan 18, 2021
Merged

time sync notification#1442
glmnet merged 4 commits into
esphome:devfrom
badbadc0ffee:on_time_sync

Conversation

@badbadc0ffee
@badbadc0ffee badbadc0ffee commented Jan 3, 2021
Copy link
Copy Markdown
Contributor

Description:

RFC: is this a valid approach to get notified of time synchronizations that are initiated by other clock sources?

Checklist:

  • The code change is tested and works locally.
  • Tests have been added to verify that the new code works (under tests/ folder).

If user exposed functionality or configuration variables are added/changed:

@probot-esphome
probot-esphome Bot commented Jan 3, 2021
Copy link
Copy Markdown

Hey there @OttoWinter, mind taking a look at this pull request as its been labeled with an integration (time) you are listed as a codeowner for? Thanks!
(message by CodeOwnersMention)

@badbadc0ffee badbadc0ffee changed the title On time sync RFC: time sync notification Jan 3, 2021
@badbadc0ffee
Copy link
Copy Markdown
Contributor Author

this is a follow-up to #1441

@badbadc0ffee
badbadc0ffee marked this pull request as draft January 3, 2021 15:26
@muxa
muxa commented Jan 4, 2021
Copy link
Copy Markdown

Would it make sense to have the on_time_sync be part of the base time component, so that all time sources fire this event?

@muxa
muxa commented Jan 4, 2021
Copy link
Copy Markdown

Ah, I think this is exactly what was done in this PR. I just was confused by the extra changes for DS1307

@badbadc0ffee
badbadc0ffee commented Jan 5, 2021
Copy link
Copy Markdown
Contributor Author

Ah, I think this is exactly what was done in this PR. I just was confused by the extra changes for DS1307

Right - that's just because I based the branch on the one from the previous PR. Once that one is merged, this one will look a bit cleaner...

@badbadc0ffee badbadc0ffee changed the title RFC: time sync notification time sync notification Jan 9, 2021
@badbadc0ffee
badbadc0ffee marked this pull request as ready for review January 9, 2021 01:48
@glmnet
glmnet commented Jan 11, 2021
Copy link
Copy Markdown
Member

Is SNTP is forgotten here?

@badbadc0ffee
Copy link
Copy Markdown
Contributor Author

Is SNTP is forgotten here?

It should not. The automation should work for all time sources, I don't see a reason why it shouldn't work with SNTP.

@glmnet
glmnet commented Jan 12, 2021
Copy link
Copy Markdown
Member

Are you sure? I don't see a call to the base method from sntp

@glmnet glmnet added this to the 1.16.0b4 milestone Jan 12, 2021
@badbadc0ffee
Copy link
Copy Markdown
Contributor Author

I don't see a call to the base method from sntp.

And you are right! There was none. I was fooled because sntp logged the exact same debug output "Synchronized time: [...]"
Good find! Is fixed now.

char buf[128];
time.strftime(buf, sizeof(buf), "%c");
ESP_LOGD(TAG, "Synchronized time: %s", buf);
this->time_sync_callback_.call();
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is going to report false positives, i.e. if the clock is actually synchronized because of e.g. home assistant, there is no way this thing is going to realize that.

This code makes sense if this is the only use of a time component in your whole yaml, but as your intention is to have many I'm pointing this out.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your remark is totally valid. but I am fine with this: the 'false positive' in this case is OK.

It may lead to a double write to the RTC in a set-up with DS1307, HA and SNTP enabled for the first synchronization if that happens to be from the HA. If I don't get things wrong, after the initial sync, the SNTP will never sync again, so this is really not a dramatic thing.

Actually, the SNTP component does not care if its own library is responsible for the sync. Independent of this PR, it would write a duplicate "Synchronized time: ..."-log in a configuration with HA and SNTP even it the initial sync was from HA. But as said: I'm OK with that.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ok with that. I'm adding a quick note in the docs so people does not believe is a bug

@jesserockz jesserockz modified the milestones: 1.16.0b4, 1.16.0b5 Jan 17, 2021
@glmnet
glmnet merged commit 4c10539 into esphome:dev Jan 18, 2021
jesserockz pushed a commit that referenced this pull request Jan 26, 2021
* add on_time_sync trigger

* cleanup lint

* fix review remark (sntp didn't trigger callbacks)
This was referenced Jan 26, 2021
This was referenced Feb 3, 2021
micronen pushed a commit to micronen/esphome that referenced this pull request Feb 5, 2021
* add on_time_sync trigger

* cleanup lint

* fix review remark (sntp didn't trigger callbacks)
@github-actions github-actions Bot locked and limited conversation to collaborators Sep 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

0