Forum Replies Created
-
Posts
-
The OpenGarage mobile app does not use cloud connection yet, so it cannot show settings and history when you are remote, and you can only access them when you are on the local network.
That’s a known issue with firmware 1.0.4. From 1.0.5 we have added capability for the device to re-connect once it detects the connection to router has lost. I need to add some descriptions in the user manual about how to update firmware, but here is a quick walk-through:
1. Download the new firmware from:
https://github.com/OpenGarage/OpenGarage-Firmware/raw/master/Compiled/og_1.0.5.bin2. Open a browser and type in OG’s IP address. Then click on the ‘Update’ button at the bottom of the homepage.
3. Select the file you just downloaded, and type in device key (if you’ve never changed it, it should be opendoor by default).
4. Wait till the upload to complete. In some rare cases (due to WiFi signal quality) the upload may fail. In that case, just repeat the steps.
First, check your Options page and make sure the blynk authorization token is still there (this token needs to match your Blynk’s project auth token), and ‘accessibility’ is set to Direct + Cloud. The reason to check this is that in some cases, upgrading from 1.0.4 to 1.0.5 may trigger a factory reset of options, in which case you need to set the token again. If both are set correctly, try to reboot OpenGarage and see if that makes it work.
This QR code issue is only discovered recently, and it’s due to a bug in Blynk. The video was made a year ago so we couldn’t have anticipated this issue when making the video a year ago. Also, I emailed the Blynk team and they said they are working to fix this issue for the next iOS app update.
We are getting close to get our own cloud proxy working and put it to real use. It seems this is a good time to part ways with Blynk as it has started becoming a liability for us…
@siri: put the photo of what in the first with the video? Did you mean the QR code? That’s already in the user manual. This is an open-source project, and we are a very small team with only 2 people. I am not sure what’s your expectation, but please be patient as we have limited resources.
The connection from your phone to the cloud server is through secure channels, the connection from the device to the cloud is currently not secured, though someone would have to know your 32-byte authorization token in order to cause any problem. For that reason, the authorization token should be kept for yourself.
If you don’t want the cloud connection, you can disable it by setting ‘accessibility’ to ‘Local only’.
Your wife can use the same Blynk login as yours and therefore will not need to create a separate account. Once logged in, you should see the same OG project.
We are working on our own cloud support so that in the future we can bypass Blynk and use our own service. Blynk has worked well in the past. Pretty much the only reason to use Blynk is its cloud access feature, and it was fairly easy to use. But their frequent updates sometimes introduce bugs that are unexpected.
We will surely add the distance reading to the OpenGarage app.
It appears that this is a bug with Blynk’s QR scan on iOS. Just received another report of the same issue. Here are the details:
Apparently the problem is that the widgets have no associated pins, hence they are not getting any value. This seems to be an issue with Blynk’s QR code scan feature for ios, that is, after your scan, the associated pins for the widgets are lost. I just tried to scan the QR code again on my android phone and there was no problem at all.I took screenshots of the pin assignment for each widget:
https://goo.gl/photos/LgKTPh6VYedoinW96
You can follow the screenshots to set up your pins (you need to first stop the project from running by clicking the square icon at the top-right corner. Then you can click on each widget to configure it, and finally click on the triangle icon to run the project again). Note that all pins are ‘Virtual pins’, not digital or analog pins. If you have trouble figuring it out, send a support ticket and we can configure it for you (but will have to know your login credentials).My understanding from talking to Samer is that the geofence does not actually trigger any garage door action (because the plugin he is using does not support triggering action). It does send you a notification that you are within some certain range to the garage door, and you can then trigger door action if you want.
The OpenGarage API is available here:
https://openthings.freshdesk.com/solution/folders/5000283224
everything is implemented through HTTP GET requests, which most services support.Make sure the ‘accessibility’ is set to ‘Local + Cloud’. Once you change the settings, make sure you reboot OpenGarage for the setting to be effective.
I can’t think of any reason. The OpenGarage wires are connected to the internal relay, which is in open circuit state unless if the relay is activated. I can’t imagine how two open circuit wires will affect your door pushbutton.
I’ve never seen this issue. Did you build you own OpenGarage or did you buy from us? If you are using a relay board, note that many relay boards are ‘active low’ type, and that could explain the reverse logic. If you are using your own relay, and use a MOSFET to drive it, make sure you have a resistor between gate and source to keep the MOSFET off during startup.
You should be free to explore without worrying about bricking the thing — ESP8266 comes with a built-in bootloader that’s very robust. I’ve never seen a case where the bootloader is corrupted. Because OpenGarage firmware supports over the air (OTA) update, there is actually no need to update firmware through the USB cable — of course you still need the USB cable to provide power — but the firmware can be uploaded through the webpage. Also, OpenGarage firmware is written in Arduino with ESP8266 core, it does not use Lua / nodemcu at all.
You said you measured ‘high level’ all the way — could you clarify you which two points are you measuring this voltage?
OpenGarage is completely open source, you can find the circuit design at:
https://github.com/opengarageI am not sure what you mean by ‘the voltage output of the relay’ — the relay does not output any voltage itself, it’s a switch. The on-board relay is rated 3 amp contact current. If your water pump exceeds 3 amp, you should NOT use the on-board relay but you can use an external relay with larger current rating, or solid state relay.
Just reference dht.h in main.cpp. You can define the dht pin anywhere, but I would suggest defining it in defines.h as that’s where all hardware pins are specified.
Yes, I think this is a great alternative use of OG — a while back I saw a project here:
that uses the same ultrasonic distance sensor for sump pump monitoring.I think the stock OG firmware can already be used as a water level sensor — you can set the threshold to an appropriate value you want, and you can change the mount from ‘ceiling mount’ to ‘side mount’ if you need reverse logic.
Hi, I am not sure how this is possible either. One explanation about why Blynk works is that when you access Blynk you are accessing the Blynk server which is always alive. OG may be experiencing network connectivity issues but as long as it communicates with the Blynk server once in a while to update its status, the Blynk server thinks it’s online. How far is OG away from your router? I am wondering if the issue could be due to poor WiFi signal reception. Also, in addition to the home router, do you run a secondary router or range extender? Knowing the network setup can help identify potential causes of the poor connection.
