Thanks for testing it so quickly! The multiple doors isn’t something I can test but I think I’ve spotted my mistake and I’ve pushed a fix. I’ve also added refresh interval config. Can you pull latest, and then remove and re-add the service please?
I’ve got several improvements to put in before I’d consider “publishing” it, but I’m glad it’s doing the job.
Okay I deleted the integration which removed the associated devices.
Pulled the latest code and setup again.
The devices were recreated the same though - strangely also showing their past history which is odd? It’s like it didn’t properly clear it all out?
Bit more feedback as I’m a little early getting ready for work so have a few moments to quickly play.
Turning on the light DOES actually work now. However the integration doesn’t appear to know that, it immediately toggles its status off again, so the two are out of sync at that point.
Thus if you try turning it on a SECOND time, even though it is actually on, the Smart AutoDoor controller becomes confused and gets into an infinite “pending” state for the light.
Second door has no sensors still in case I wasn’t clear in above post.
I’m surprised the sensors didn’t load. It was an obvious mistake when I spotted it. I suggest deleting it all, including the folder from custom_components, restart and add the integration via HACS (it’s now compatible). You’ll need to add the github address as a custom repository.
If it’s still not working, raise an issue with debug logs and we can work it through there.
I’ve also changed the light behaviour to accomodate what you’ve described. Onpending wasn’t considered “on” so the slider was returning to off. If their API gets stuck when you try to turn it on when it’s already onpending then that’s a concern, but outside of our control, and we can try to work around it.
Dave
How does your integration differ from this one I’ve been trailing for about a week now → GitHub - williamschey/hassio-omlet-smartcoop-door: Home Assistant integration to monitor and control Omlet Smart Coop Door
I think so far the only difference is the level of community engagement from you has been phenomenal, so I’d be happy to switch and support yours if it continues to gain traction 
William contacted me on the weekend. If I’d known about his work, I wouldn’t have bothered doing my own. We’re going to cherry-pick the best of both and join forces.
I’ve nuked and switched to your native HACS version. Sensors for the second AutoDoor came up a treat, light working a treat, everything working an absolute charm! Your sir are a legend!
Splendid! Thank you for confirming.
However… I’ve decided to retire this integration!!
Wouldn’t it be the way that after months of dormancy, two people decided to write an integration on the same bloody weekend!!
@williamschey got his PR to HACS before me, it’s good work, and he’s already granted me access to his repo so we’ll collaborate on his version.
You are a rare and valuable tester of the double device scenario, so please stick with us.
Many thanks!
Can confirm - the HAC install works a treat. Thanks all for your work to this point!
I’d still love to see an ESPHome variant of the Smart Autodoor, if only to run a BT proxy on the board. I’m using a govee H5074 hygrometer (ziplock taped) inside the lid of a heated waterer for a remote freeze warning. Improved BLE connectivity would be nice.
Sounds like a nice option! Did you already try it out?
G’day mate
I left it a week so you guys could get your two integration in sync, and have swapped over.
Good news is the sensors and doors are working just fine.
Bad news is the coop light is back to:
eg the two bugs you nailed in your version. Hopefully an early fix. I’ll post in GitHub too.
Hiya, they’re in good sync now but still in the dev branch.
Should all be published very soon along with the light fixes. I’ll look into the icon colour too, I suspect it’s device class related.
v0.9.0 is published, which brings the best of both repos, and a load of new entities.
More entities to come.
Hi @OmletDave, currently there doesn’t appear to be any way to identify the source of a triggered event within the Omlet app or in the API data, e.g. differentiate between ‘door opening’ triggered by light level in the morning, versus ‘door opening’ triggered by someone clicking ‘open door’ in the app or on the Omlet door controller.
Is this something you’d consider adding into the API (and the app)?
I solved this by creating an automation that triggers when the light turns off - if my main coop door is still closed (eg I’ve turned on the light, opened the nest, but not yet light enough to open the coop) then turn the light back on.
Thus every 10 minutes when the light turns off it simply turns on again. According to HA’s historical data throughout the week the light turns off for around 2 seconds… though that is likely inaccurate as I presume the polling time of the integration (or the API) is creating a lag. But whenever I’ve been up early I’ve seen the light on so it’s overall working, even if a workaround.
@dpwood @williamschey thanks for a great job!
I’ve installed my home assistant yesterday and your integration is the first one I’ve started playing with.
I saw that there is a way to set the light level (which I can’t really trust for my coop which is under a lot of trees). I’m now still triggering it through my Google Home (based on sunset/sunrise) and only using home assistant to monitor it.
I was wondering, how would you go about implementing the following scenario: set the door on time based opening and update the open/close time via HA based on the sunset/sunrise. (My internet connection is quite sketchy there so I would like to have a fall back).
Two ways you could go about it:
Personally I entirely run off the light sensor from my weather station on my house roof, but have a “time” based trigger set as a fallback. eg at the moment in the middle of summer the coop door is opening around 5:00am based on light level, but I have a failsafe of 5:30am set that will occur regardless.
Create an automation that triggers say an hour before sunrise each day that sets the open and close times based on the current sunrise and sunset values in Home Assistant. This way the open/close times are automatically set each day and the door does it on its own without Home Assistant.
Now the complication with #2 is this integration doesn’t yet expose an action item to set the open and close times via an automation, and because the times are an entity of the main door object it is actually quite tricky to set it. Don’t worry normally anything and everything is super easy in Home Assistant, this just happens to be a unique touchy.
So either you could wait for the guys to develop this for you (raise the request via Issues · williamschey/hassio-omlet-smartcoop-door · GitHub) OR you could do it via some trickery.
First would be a Python script here - How to manually set state/value of sensor? - #9 by rodpayne
#--------------------------------------------------------------------------------------------------
# Set the state or other attributes for the entity specified in the Automation Action
#--------------------------------------------------------------------------------------------------
inputEntity = data.get('entity_id')
if inputEntity is None:
logger.warning("===== entity_id is required if you want to set something.")
else:
inputStateObject = hass.states.get(inputEntity)
inputState = inputStateObject.state
inputAttributesObject = inputStateObject.attributes.copy()
for item in data:
newAttribute = data.get(item)
logger.debug("===== item = {0}; value = {1}".format(item,newAttribute))
if item == 'entity_id':
continue # already handled
elif item == 'state':
inputState = newAttribute
else:
inputAttributesObject[item] = newAttribute
hass.states.set(inputEntity, inputState, inputAttributesObject)
Then an automation something like…
alias: Automatically Set AutoCoop Open/Close Time
description: ""
triggers:
- trigger: sun
event: sunrise
offset: "-01:00:00"
conditions: []
actions:
- data_template:
entity_id: time.nest_door_open_time
state: >-
{{ as_timestamp(states.sun.sun.attributes.next_rising) |
timestamp_custom('%I:%M %p') }}
action: python_script.set_state
- data_template:
entity_id: time.nest_door_close_time
state: >-
{{ as_timestamp(states.sun.sun.attributes.next_setting) |
timestamp_custom('%I:%M %p') }}
action: python_script.set_state
mode: single
This would trigger an hour before sunrise each morning and then use that script to override the state of the open time to be the latest sunrise and the close time to be the latest sunset.
Disclaimer this is theoretical I’ve made this code up and not actually tested or know if it’s even compatible, might be best to log an issue via Issues · williamschey/hassio-omlet-smartcoop-door · GitHub and have the capability added to the integration?
Hi,
Thanks a lot! I’ll test it sometime after Christmas. Since I’m only using HA for 2 days only I’ll need to dig out where you can add scripts and then start playing
For my own curiosity I plotted the light level during a day. (azimuth in yellow)
Using time control might not be as reliable as you’d hope. For most of us, our clocks change twice a year. I don’t think Omlet got their implementation quite right, and I suspect the daylight savings time (DST) transition will cause your door to open or close an hour earlier or later than you and your chickens expect.
Your Omlet account settings capture your timezone, and this is used to ensure the correct time is set on the autodoor. However, the open/close times are captured—and, I believe, stored—as local times. This means your autodoor’s clock will be correct, and the 19:00 close time you programmed will remain 19:00 even when the clocks go forward. Unfortunately, nobody told the birds, so they’ll be shut out an hour earlier than expected. While this might work for an alarm clock, it’s less ideal for animals that can’t read the kitchen clock.
I tested this theory by changing my timezone by +1 hour. The clock on the door advanced by an hour, but the open/close times remained unchanged, causing my door to operate an hour early. This suggests the open/close times are not timezone-aware. Ideally, they should be stored in UTC or as local time plus an offset, and then displayed in local time.
This creates other oddities. For example, if your Home Assistant (HA) instance is in a different timezone than your door, the “Next Update” sensors will show times that are hours off. To be honest, this is something the integration could handle better, but it would require making the integration timezone-aware.
That said, I do use time-based control for the door, and I have it adjusting daily based on dawn and sunset. I found light levels too unreliable. However, if you plan to programmatically adjust your open/close times, you need to account for DST to avoid unwanted surprises. Also, be cautious about setting a time that has already passed. For example, if your door is due to open in 1 minute and you decide to bring the open time forward by 2 minutes to align with earlier sunrises (inadvertently setting it to a time in the past), your door won’t open until the following day.
As for adding support to the HA-Omlet integration to trigger open/close actions based on the sun… I personally feel this is beyond the scope of the integration. Home Assistant has all the necessary information to allow your to automate it, and I think this logic belongs in an automation.
I probably haven’t explained clearly what I mean. My idea is to use HA to update the open/close time on the autodoor with a given frequency (weekly + DST change). In case the autodoor would go offline (due to wifi problems) then the door would continue working correctly since the open/close time would have been adjusted from the HA. So once a week do a autodoor.opentime = sunsrisetime+offset, autodoor.closetime = sunsettime+offset. I think that’s also what you mean when you say you use time-based control and have it adjusting daily. That’s what I want to do (just with another frequency, maybe). How do you do the adjusting?
I’m currently triggering a door open/close automatically via Google Home and I have already tested it via HA also (so I’ll use it when I’ll fully migrate). Thus, indeed, the integration triggering the open/close based on the sun is really not needed and that’s certainly not what I’m asking about 
