-
-
Notifications
You must be signed in to change notification settings - Fork 40
Ignore state change events while Home Assistant is starting and initializing entity states, override controllers correctly on startup #292
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
865882b
to
f3c9e95
Compare
…ntroller needs to be overridden 65 seconds after starting (after entity states are ready)
f3c9e95
to
21978e3
Compare
I updated the PR with a new commit that adds a new
|
c74ed8b
to
fed9fc5
Compare
…after startup delay
fed9fc5
to
7e58810
Compare
Wow this is amazing, thanks for contributing. I will test on my instance for a bit before merging. |
My main concern is whether this will make developing EC more dififcult because a restart takes 70 seconds. Option 2: would be to add all input entities from configuration to a list and periodically check those entities (e.g. every 15 seconds). As long as the entities are not ready, EC can be in pending state. Once all entities have a real sensor value, EC can go to the correct state. Is there any harm is calling the |
Thanks for the feedback @danobot! I like the idea of adding all entities to a list and checking them periodically. I'm not familiar with the entity states while HA is starting up, but can check to see if they are all in the 'unavailable' state or something like that. On a related note, I've been struggling to get the test suite running on my machine. I'd like to add tests for any changes and make sure I'm not breaking anything. But I'm getting an error when I run the command in
|
I never got the unit tests to work. Back when I looked into it there were some challenges mocking the "passage of time" to validate EC does a thing after timeout. See issue #101. This was a huge blocker because everything depends on timers and timeouts in EC and I eventually gave up on unit tests altogether. My process now is to run any change in my prod HA instance and observe for a couple of days |
@ndbroadbent is this still good to merge? I ran this version on my instance for months and forgot about it |
Also waiting on this, it really helps! |
@danobot I am still running this branch on my instance as well and it hasn't given me any problems so far. I think this approach is a bit unsophisticated and could be refined, as you mentioned:
I like that idea better if it's possible, but not sure how to implement it. I guess we can check for when a sensor changes from unavailable to on/off? Maybe could also have a timeout in case the sensor stays unavailable and show an error. I would also really like to help with unit tests, I've been wanting to contribute a few more features but it would be really nice to have some test coverage. I am a Ruby on Rails developer during the day, and we have a library called timecop that is used for mocking and stubbing time. I saw there's a pytimecop port that might be helpful. This way you can control the time precisely in the tests and don't need to wait for the actual amount of time. So that might be a good way to go |
Mate I tried to get tests going before and eventually gave up due to time limitation. if you could establish the test pattern using pytimecop that would be great. |
Not sure about the hardcoded
STARTUP_DELAY = 70
, since every installation will have different startup times and entities from different integrations. This is probably quite specific to my HA instance running on a server, and with most of my entities coming from Zigbee2MQTT. I also wouldn't want to need to configure this for every single entity controller instance. Not sure if there's a nice way to make this configurable.Description
This fixes an annoying issue I've experienced where I can't work on my HA config or perform upgrades late at night, because it would always turn on the bedroom lights while my wife was sleeping.
Checklist
conventional commit
formatting.develop
and targetsdevelop
Please open an issue before embarking on any significant pull request, especially those that add a new library or change existing tests, otherwise you risk spending a lot of time working on something that might not end up being merged into the project.
License
By submitting a patch, you agree to allow the project owners to license your work under the terms of the project license. Thank you for contributing!
Related Issues
Closes #285
Also: #231