Omlet Auto Door for Chicken Coop

[dpwood (David Wood)]

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.

[icornish72]

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

[dpwood (David Wood)]

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.

[Tillsy]

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!

[dpwood (David Wood)]

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.

GitHub - williamschey/hassio-omlet-smartcoop-door: Home Assistant integration...

You are a rare and valuable tester of the double device scenario, so please stick with us.

[ztox]

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.

[peregrines (Felix)]

Sounds like a nice option! Did you already try it out?

[Tillsy]

@dpwood

You are a rare and valuable tester of the double device scenario, so please stick with us.

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:

1. Not turning on
2. Toggling itself back off again in the interface

eg the two bugs you nailed in your version. Hopefully an early fix. I’ll post in GitHub too.

[dpwood (David Wood)]

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.

[dpwood (David Wood)]

v0.9.0 is published, which brings the best of both repos, and a load of new entities.

More entities to come.

[AnthonyBe]

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)?

[Tillsy]

@Tillsy

Hey @OmletDave I notice the light is limited to a maximum of 10 minutes. Makes sense for battery power but on mains, and in my use case, impractical unless I repeatedly turn it off and on again every 10 minutes. Can it be upped or, preferably, disabled - at least via API? If I trigger it via API in Home Assistant the intent obviously is I am controlling when it comes on and off so it shouldn’t go off on its own except maybe an overall failsafe (which I would personally make two hours).

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.

[tinutac]

@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).

[Tillsy]

@tinutac

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:

1. 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.

2. 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?

[tinutac]

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)

[dpwood (David Wood)]

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.

[tinutac]

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

[dpwood (David Wood)]

I think you did a good job explaining it. You want to use time control so the door remains autonomous in case it goes offline, but regularly update the open/close time to keep up with the changing dawn/sunset. It’s a good idea, and also allows you to fix the door times when the clocks change.

I think @Tillsy wrote up a good solution. His python script might be unnecessary though. The Time:Set Time action will work on the open and close time entities and is available in automations. Hopefully it’s suitable and will avoid some complication.

I use node-red for nearly all of my automations, so the way I do it probably won’t suit you so well, but for what it’s worth:

At 3am every morning, get the day’s dawn and sunset times using the SunCalc module with a little script, add an offset to those and use the time:set_time action to set them on the door.

I choose 3am as it’s after the clocks change where I live (UK we jump from 01:00->02:00, and 02:00->01:00). So by the time it runs, the calculations will be for the changed clock. It’s also sufficiently before dawn on the longest day of the year to ensure it runs before it’s needed.

I’m happy to share the script, but I think @Tillsy’s solution is probably more appropriate.

[tinutac]

I’ve added an automation for now based on the suggestions of both of you (@Tillsy & @dpwood) :-).
So … triggering it every Sunday at 15:00 and using set time. Since my coop door is configured on my time zone I’m now testing it like this (which, at least in theory should also solve the time zone/dst issue):

actions:
  - action: time.set_value
    metadata: {}
    data:
      time: >-
        {{ as_timestamp(state_attr('sun.sun', 'next_rising')) | 
        timestamp_custom("%H:%M", true) }}
    target:
      entity_id: time.omlet_autodoor_open_time
  - action: time.set_value
    metadata: {}
    data:
      time: >-
        {{ as_timestamp(state_attr('sun.sun', 'next_setting')) |
        timestamp_custom("%H:%M", true) }}
    target:
      entity_id: time.omlet_autodoor_close_time

Still using my other automation to open/close so I’m for now just checking that the time gets adjusted correctly. Still wondering if once a week is often enough. My approach might be quite naïve but I’ve just started with HA so we’ll see how it evolves.

First time I hear about node-red. Adding something on my “to check out” list.

Thanks both for you input

[dalgibbard (Darren Gibbard)]

One thing to consider (maybe @OmletDave can confirm?) is that the settings on the device are likely held in some sort of EEPROM chip, which may be prone to wear over time…
This count is most probably somewhere in the 100,000+ range (typically), so maybe it’s not something to care about too much if you’re only setting it weekly anyway

I suspect overall it’s all good anyway, just thought i’d add a thought point.

I guess one alternative if it is a concern, is to use Home Assistant to do the Open/Close activity, with a backup timer on the device for late-morning, and late-afternoon, on the off chance that the automation doesn’t run?