Forum Replies Created
-
Posts
-
I am not sure what you meant by “the original version have a temp/humidity sensor” — OpenGarage has never had such sensor pre-installed. The firmware supports readings these sensors but you have to solder them on yourself.
Thanks for your feedback.
I’ve been testing OTC on a very old version of OG for a week now. I did experience connection loss a few times, but somehow as I keep trying the cloud connection eventually comes back (though local connection doesn’t always come back). So it looks like when connection is lost it’s not stuck forever. I will have to do some more debugging to check what’s going on. It might also have to do with the fact that I have a very old version of OG. Need to test it on a more recent version of OG as well.
I can confirm that I also encountered issues with the device losing connection, but in my case, it’s local connection (i.e. using local IP) that’s lost. The cloud connection seems always available. I use the cloud connection to trigger a reboot, and the local connection came back alive after the reboot. But after some time, the local connection seems to get lost again. In any case, these are exactly the feedback we need to get to fix bugs. Thanks!
Sorry, no, wired Ethernet is not supported. While it’s possible to develop a version that uses wired Ethernet, the majority of IoT garage door openers use WiFi. I have frankly not seen any that uses wired Ethernet. So I suspect the market will be very small.
OpenGarage works with almost all garage door systems. You can think of it as a WiFi-enabled door button.
1. Yes, the same app can operate multiple OGs. If you use the Blynk app, you can scan the OpenGarage Blynk QR code three times to create three projects, and you can give each a different name so it’s easy to remember. If you use the OpenGarage mobile app, it also supports adding multiple controllers. In either case, you can switch between different controllers within the app.
2. Notification is only supported by the Blynk app — the notification message does include the device name, so as long as each device has a unique name (this can be configured on the controller’s settings page), then you can easily tell which notification is from which controller.
3. I am not sure what type of automatic gate you have, and also how you intend to use OpenGarage with it. You can think of OpenGarage as a WiFi-enabled door button — it can sense the door status, and you can trigger actions remotely. On top of that, you can enable automation so that it auto-closes the door if it senses the door is left open for longer than a specified threshold. If your automatic door already does the closing on its own, then you can just leave OpenGarage automation disabled so they won’t both try to control the door at the same time.
According to this post:
https://community.garadget.com/t/marantec-comfort-250/2193
It should be connected between GND and Impulse ports.Yes, as jagos said: you can keep your existing button — in fact you can install as many buttons as you want and if any of them is pressed, it triggers the garage door action. You can think of OpenGarage as a WiFi-enabled door button.
Yes, some users in the past have requested this feature: i.e. the ability to use both distance sensor and magnetic sensor together. I have added this to the todo list and will consider this for future firmware update.
@orcua: is this a specific question for OpenGarage or a general question about Blynk?
Well, honestly I have never seen any smart garage door opener that supports wired Ethernet. Running a long Ethernet cable into the garage sounds inconvenient and I’d rather stay with a wireless solution.
After beeping, did you hear a click (the relay clicks)?
The Blynk QR code is here:
https://github.com/OpenGarage/OpenGarage-Firmware/blob/master/OGBlynkApp/og_blynk_1.1.png
which is described in the user manual. This is NOT on the product bag: what’s on the product bag is the QR code for opengarage website, that’s NOT the Blynk QR code.Either get a active-high relay, or, if you have an active-low relay — every relay has a normally open (NO) pin and normally closed (NC) pin. Just use the NC pin, that will reverse the logic.
The best way is for you to submit a support ticket, we will check your order and see if we can send a replacement.
Just scan the Blynk QR code again, it will create a new project with a new token. So you can have multiple identical projects at the same time (each with its own unique token). You probably do need to pay a dollar or two to get more Blynk energy points as they only give you 2000 for free initially.
Hmm… Sounds complicated. I don’t know how to exactly reproduce this since I don’t have kind of router setup you have. I have reservations regarding adding the ping test, because it could introduce other issues such as false positives. I still don’t quite understand why the condition WiFi.status() == WL_CONNECTED fails. How is resetting SSID different from a reboot of the router?
I am having trouble understanding how is it possible that when your router is powered down, the condition (WiFi.status() == WL_CONNECTED) is still true? If this is the case, what if the ping also returns successfully? This doesn’t make sense to me. What firmware version are you on? Note that the auto-reconnect logic was not included in earlier firmwares. I’ve tried two different router, as well as my phone’s WiFi hotspot, as soon as the network is down, WiFi.status() == WL_CONNECTED becomes false. I have not seen a counter example so far.
Yes, this feature has been tested. Here is how it’s tested: OG is connected to our WiFi router in station mode, then we unplug the router, wait for a while (we’ve tested gap of both less than a minute, and much longer, like 10 minutes), then the router is powered back, and OG is able to reconnect to the router afterwards, without having to manually reboot it.
Where did you see the condition of “if(WiFi.status() == WL_CONNECTED && WiFi.localIP())” — that is not the condition it’s testing in station mode. The only place I can think of that checks that condition is when the controller is in AP mode itself, which is not the mode you are referring to.
result:1 means the command is successful. You can take a look at the API document to see the result status code:
https://github.com/OpenGarage/OpenGarage-Firmware/blob/master/docs/Yes the firmware already handles re-connection. The specific code is here:
https://github.com/OpenGarage/OpenGarage-Firmware/blob/master/OpenGarage/main.cpp#L1463
the basic logic is that if it gets disconnected from the router, it waits for 60 seconds and if still disconnected, it will reboot to try to reconnect from the beginning.
