@niwi I’m looking at doing exactly the same with the Shelly Uni on our two Eglu doors. Did you connect the two load terminals on the Uni to the two terminals that Amau96 suggested above? Also, did you find a way to power the Shelly Uni from the 12v supply going into the Eglu panel? If so, mind sharing how?
@russg On the Shelly I used “Load 1” (upper black cable) and the black cable under “Load 1” for opening and closing the door. They are connected the same way as in the solution from amau96. My chicken light and my heater are not from Eglo, so I have no use for “Load 2”.
I have electric power in my Eglo coop. Because of this I use two power supplies, one supply for the 12V input of the Eglo control decice and one for the Shelly. It might be possible to control both devices with just one power supply but I haven’t tried it out since I had a spare power supply anyway.
Please write if you discover a way to measure with the Shelly Uni if the door is open or close. I still hope this is somehow possible with the digital inputs of the Shelly.
Maybe i will try to design an esp32 controller. i just need some time, completely dropping the controller from eglu. my chicken coop: https://kippencamera.nl
I did the same thing about a year ago to a couple Omlet doors using some Arduinos with wifi. I spent a lot of time poking around the board to see if there was an exposed contact somewhere else that could tap into instead of tapping into the button legs, but the conformal coating makes it pretty much impossible. The button leg tap works great though. I have HA control the open/close schedules based on the sun with offsets. I really wish the folks at Omlet would incorporate a schedule like that since it can all be calculated offline if you know the Lat/Lon and time. But that would likely mean input and display changes that would raise the cost.
my initial plan was to use a solar panel as power supply. unfortunately this doesn’t worked well.
at the moment the housing is connected to an 12 V power supply supported by an ups and 2x 18650 cells.
the relais 1 and 2 are in interlock mode to switch voltage from positive to negative to open and close the chicken coop door.
relais 3 sends 12v to a buck converter to reduce voltage to 5v for relais 1 and 2 (the intention was to save energy because of the solar panel power supply)
relais 4 sends 12v to a buck converter to reduce voltage to 3.3v to switch the light on/off.
light and motor needs an current-limiting resistor.
i will post more details after i rework my support board.
I want to go down this road too someday. Have you figured out how the OEM controller determines when the door has reached its fully open or closed position? I have ideas but I’ve never dug into it.
How do you plan to determine door open/closed with your controller? You can always take the easy road and add some dedicated hall sensors.
What cameras are you using to get this viewpoint? That would be game changing for us to be able to see when eggs are in the nest box. Are you manually closing the divider between the roosting bars and nest box or are your girls just well trained to sleep on the bars?
Hi! im just using cheap camera’s from imou. The imou Versa. you can use the software from dahua to place a camera name over the imou watermark, this will remove the watermark. to stream the camera’s i’m using motioneye. I never use the divider, they just sleep in the roosting bars compartiment.
As far as I can remember I used 10 ohm because 0,5 amp for the motor sounds reasonable (5v * 10ohm).
I’m going a different route, using a DRV8833 motor driver, INA219 current sensor, and DS3231 RTC. Plus something to detect the fully open/closed states – undecided if that’ll be two reed switches or maybe a distance sensor or something else. Ultimately I want my “smarter” controller to be connected to Home Assistant but not dependent on it to operate.
And for anyone who doesn’t want to hack up their original Omlet cable (me!), the connector is the same Molex type as a 4-pin ATX. If you’re hacking up an ATX extension cable, the black pair will be the motor and the yellow the crush switch.
I’m making good progress… just in time for Omlet to release their own Wi-Fi controller. I think mine will be better.
EDIT: I ordered the new controller, for science. ESP32-S3-WROOM-1 in N16R8 form. Convenient TX/RX/GND header holes, another set labelled for i2c. Holding Reset button on boot enters programming mode.
I’m not prepared to fiddle with it right now but seems like it should be easily hackable.
Very excited about your work here! I’m looking to get a coop and having a home assistant controllable coop door is one of the most important deciding points for me. Looking forward to seeing your progress! Fingers crossed for an integration with HACS. Have you spoken to the Omlet team at all? They may be willing to share information that makes building an integration easier
I reached out to the Omlet team and they said they would forward the suggestion for making an API to their dev team. It might be worth it for others to do the same. My biggest complaint with the Omlet (other than the lack of a documented API) is that it does not let you power via mains and leave the battery in (for backup in case of power outage). You have to choose one or the other. I’m thinking about seeing if a 6V lantern battery could be spliced into the power supply for the door. You can then get a 6V lantern battery that has a built-in trickle charger for powering off of the mains. Presto! You now have a battery backup system that’s mains powered.
Since people are discussing automating a coop door I thought is share our setup We have an auto door on our coop, not an Omlet though (I didn’t come across it before). It’s from Ghost Controls who makes an economy gate controller.
I haven’t tied it into Home Assistant yet (I’ve wanted to), but it has three terminals that you close momentarily to toggle, open, or close the door so it would be pretty plug and play with many wireless relays. As it is, it comes with a doorbell to cycle the door, but usually we just let it run off it’s photocell.
There have been times however when the birds start laying away from the coop that I want to get them in for an extra couple hours and it’d be nice to be able to use HA for the scheduling instead of the photocell. It’s a long way from our house, and I’m not sure zWave will reach (~160’ and a wall or two). Anyone have experience with zWave LR?
Now that they have a WiFi controller and an app, has anyone tried inspecting the comms between the app and the omlet api server to see if it’s unencrypted? I have a pool pump controller that uses plain HTTP and was easy to reverse engineer and build a custom HA plugin for…
I’ve done some basic analysis of the communication flow. Sadly it all uses HTTPS and MQTTS. I also dumped the FW and found a couple of the destinations. The MQTTS destination is where all the events reside. The rest seem to be around device maintenance, just looking at the strings in the binary file.
Really happy to see people are keen to play around with the new Smart Autodoor control panel. I’ve been the lead on the technical side of the project here at Omlet, and wanted to pop in and share a few things.
From the outset of the project, we’ve been keen to open up the control panel to hobbists, as we know our customers love to make their chicken coops their own, with customisations to suit their needs, and we knew the same would be true with the smart autodoor.
We have designed the API we use internally for controlling the door with this in mind, and in the next few weeks we should have a developer section added to our Smart Knowledge base website
We are in the process of finalising the documentation to ensure everyone has a smooth experience when they get started. We’ve built a PHP and Typescript SDK to help people hit the ground running, and are just finishing off support for Webhooks, so you’ll be able to use door open / close events (and others) to trigger actions in other systems.
I’m a Home Assistant user myself, so support is on our radar, but we don’t have anything to announce on that front at the moment.
To address the comment about using the battery as backup in case the mains failed - this is something we considered during development, but decided not to implement in this revision. Using the battery pack for backup power would require the addition of another diode to the board, to prevent the mains power from trying to charge the batteries when connected. The voltage drop across this diode would lead to reduced battery life, as the voltage would reach the point at which it can no longer power the ESP and motor sooner. Roughly 15% shorter battery life, if I remember the calculations correctly.
As we know a high number of our users like to run their control panels on battery (I’m currently seeing a little over 50% of our smart users running on battery), we decided that this impact would be too great for those users, and opted against implementing the backup option