Hey! I have a iSmartgate Pro and I wasn’t happy with the current app that was out there and it didn’t seem to do what I wanted it to do; open and close my garage door. So I have been working for a couple week now on app with Claude code and it has been stable.
I have the Pro model with the wired door sensor. It should also work with the wireless sensor. It should also work with all of the iSmartgate models and the Gogogate2. If anyone is able to test with those models I would appreciate it.
Any other feedback would be appreciated as well. Just be kind I am new to this and still learning. I just hope it can help some people like it has helped me.
Thanks to everyone who’s installed Garage Gateway, it has meant a lot to see others who can get something out of it too! I’ve just submitted v1.0.3 for certification, and it’s a big one. Here’s what’s new:
New: Gate support
The app now
openings your iSmartGate/GogoGate2 hub has configured as gates (not just garage doors) and pairs them under a dedicated Gate device.
Sensor-backed gates get the full open/closed status and control.
Momentary / pulse gates (the kind with no position sensor that just toggle on each trigger) are supported as a one-tap pulse button.
New Flow cards
Started opening / Started closing triggers
Status changed trigger (with the new status as a token)
Pulse the gate action
A low-battery alarm for wireless tilt sensors
Fixes
Fixed a polling crash that could make GogoGate2 hubs show as unavailable — if you’re on a GogoGate2, this one’s for you.
Fixed an issue that stopped a second door from loading correctly.
Refreshed the driver images.
I could use your help testing
My own setup is garage doors only, so I’d especially love reports from anyone running:
An actual gate (sensor or pulse type)
A GogoGate2 hub
If you hit anything odd, drop a note here or open an issue on GitHub and I’ll jump on it. Compatibility reports of any hub model are always welcome too. Thanks again for the support and enjoy the app!
First of all, thanks for the app. I have an iSmartGate hub and, until now, I’ve been using the iSmartGate app. It’s quite limited in terms of the available flow cards, so it took a bit of work to create flows such as detecting when the garage door has been left open for a certain amount of time, or triggering a flow when the door starts opening or closing. That’s why I decided to switch to this app.
I use two simple flows:
“When Garage Door opened → and it’s between a certain time → turn on light”
“When Garage Door closed → and it’s between a certain time → turn off light”
However, I’m running into some issues where the app isn’t reporting correctly what’s happening with the door.
Looking at the Homey DEV page…
As soon as the door starts opening, “garagedoor_closed Position booleanTRUE true” changes to “garagedoor_closed Position booleanFALSE true”. At that point the door is not open, it just started opening. Even the native iSmartGate Android app does not report it as open yet because the tilt sensor has not changed state. At exactly the same time, “door_status Status enum” changes to “opening”, which is correct.
This causes my lights to turn on immediately, instead of waiting until the garage door is fully open, as per flow.
Once the door is fully open, “garagedoor_closed Position booleanFALSE true” remains unchanged, which is at that point correct, but the “door_status Status enum” stays as “opening”, which is not correct as the door is already fully opened.
When I start closing the garage door, “garagedoor_closed Position boolean” changes to “true” for less than a second (literally blink of an eye change) before going back to “false” and the “door_status Status enum” briefly changes to “closing” before immediately changing back to “opened”, even though the door is actively closing. Once the door is fully closed, it still reports “garagedoor_closed Position booleanFALSE true” and “door_status Status enum opened”, even though both are incorrect because the door is fully closed. They are only updated to the correct values after 10+ seconds after the garage door has already closed, which causes my lights to turn off with a 10+ second delay.
I understand my explanation might be a bit confusing so I’ve linked the video. Hopefully this can be fixed.
Let me know if you can’t open/download .mov and I’ll covert it in .mp4
Thank you! This was genuinely one of the most useful bug reports I’ve gotten, and first one. Reading the actual capability values off the DEV page told me exactly what was happening, so I was able to pin down the root cause and fix it.
What was going wrong: your garage door has a single tilt sensor, which only knows two things — fully closed or fully open. While the door is moving it still reports the old state (it reads “closed” until the door lifts, and “open” until it fully seats). The app was reporting that raw sensor value directly, and polling too slowly, so the status lagged and flip-flopped exactly as you described.
What I changed in v1.0.4:
The app now tracks the door’s transition properly, so door_status correctly shows Opening and Closing during travel and then settles on the real state — no more getting stuck on “opening” (your point 2), and no more “closing → opened” blink (your point 3).
It now polls quickly while the door is moving and refreshes the instant a command is sent, so the state reaches “closed” within a couple of seconds instead of the 10+ second delay you saw (point 3).
The Opened / Closed flow triggers now fire at the real moment the door finishes moving, not when the command is first sent.
On your point 1 (lights turning on immediately): for the cleanest timing, key your flows on this app’s “When the garage door opened” and “When the garage door closed” trigger cards (or on the door_status = Open/Closed), rather than the door’s generic open/closed state. Those app triggers now fire precisely when the door actually finishes — so your “turn on light when opened” will wait until the door is fully open. Give it a try and let me know if the timing behaves the way you’d expect.
If you could run through an open/close cycle and check the DEV page again, I’d love to know whether it now matches what the door is actually doing. Thanks again for taking the time to document this so clearly — it made all the difference.
Thanks for your quick reply and for troubleshooting this.
I installed the test version, and looking at the developer page, it seems all the variables are correctly reflecting what the door is doing: open, closed, opening and closing.
However, the flows that use cards which are supposed to wait until the opening or closing cycle has finished are no longer triggering my lights at all. It’s strange because everything looks correct on the developer page (for the door status). Those flows do work when tested manually, although that’s expected as it’s just a simulation and simulating it doesn’t actually change any variables on dev page but at least I ruled out there’s something wrong with the lights.
On the other hand, the simple “Opened” and “Closed” cards work fine and trigger lights (not the “‘Which door’ opened/closed” cards) but as before, they turn the lights on or off immediately when the open or close command is sent, rather than after the door has finished moving.
To summarise, the developer page looks correct and the values accurately reflect what the door is doing, but the rest of the flow is not being triggered correctly.
I’ve attached the flows that I tested below.
This is the only one that turns on/of the lights, but it does it immediately when the open/close command is sent.
This one doesn’t do anything at all with the lights, it’s like it just doesn’t execute the whole flow, although everything looks good on the developer page and works when manually testing.
You nailed it — that report pointed me straight at the problem. The door-status values were correct because that part was working, but this app’s own trigger cards (“[[device]] opened / closed”, the ones with the door picker) had a bug that stopped them from firing at all. (The plain “Opened/Closed” cards that fire immediately are Homey’s built-in ones, which react to the command rather than the door finishing — that’s why they were early.)
After updating, rebuild your “wait until finished” flows on the “[[device]] opened” / “[[device]] closed” cards (the ones where you pick the door). They should now fire exactly when the door actually finishes opening or closing — so your lights come on once it’s fully open and go off once it’s fully closed, no early triggering and no delay.
Thanks again — you basically found a bug that had been hiding since day one. Let me know how it behaves for you.
Unfortunately no change after installing v1.0.5. Flows still don’t trigger, as before. The only ones working are the plain “opened/closed”.
I did notice a change on dev page…
Once the door starts opening the ID “garagedoor_closed” changes immediately to “Position boolean false true”, although the "door_status " is shown as “Status enum opening”. So it’s recognising it’s “opening” but immediately sees it as “open”. Same when closing it. Immediately changes “garagedoor_closed” to “Position boolean true true”, although the door is fully open and the "door_status " is shown as “Status enum closing”.
You were right to flag it again — turns out the fix in 1.0.5 was only half the story. There was a second, deeper issue: the app wasn’t fully registering its trigger cards with Homey, so even though they were “firing,” Homey was silently discarding them. (Interestingly, the condition and action cards worked because they were registered — the triggers were the one type that slipped through.)
Then give your “[[device]] opened / closed” flows another go. They should now actually run, right at the moment the door finishes moving. Really appreciate your patience testing these iterations — you’ve helped squash a bug that would’ve hit everyone building flows.
I’ve tested it and it’s almost there. The only thing I’m noticing on the dev page is that “door status” takes about 10 seconds to update from “opening” to “open” once the door stopped moving. When closing the door, though, it’s almost perfect. There’s only a 2 to 3 second delay, which although not instant, I can live with. I tested this multiple times to rule out any network related delays. The delay is consistent across all tests.
I just hope it can help some people like it has helped me.
New: Gate support
New Flow cards
Fixes
I could use your help testing
