Forum Replies Created
-
Posts
-
OK, I will check. I don’t think it should have anything to do with static ip vs. DHCP — the only reason for time being invalid would be NTP time sync fails.
By the way, even with DHCP, you can still set a fixed IP, by going to your router’s configuration page, and set a DHCP reservation for the device (basically binding a fixed IP to its MAC address). This is effectively static IP, but managed using the router.
1. No: this is referring to the short wires already on the adapter, and those wires should go to OpenGarage.
2. The long wires are referring to the white wires in the OpenGarage package: on one end, screw the two wires to the adapter’s big metal screws, the other end goes to your garage system’s door button holes.Basically, imagine you how you would install the door button (which is what the adapter is made of) to your garage system. The only addition here is the two short wires on the adapter go to OpenGarage.
You said “set up a nodemcu v2 with a HC-SR04 proximity sensor and a DHT11 T/H sensor in my garage using OG v1.1.0.” — so I assume this is using your own hardware and not purchased from us? Also, did you modify the firmware yourself? The stock firmware does not send T/H readings to Blynk, and you said it stopped updating Blynk. If you modified the firmware yourself you can turn on debugging by uncommenting the #define SERIAL_DEBUG line in defines.h
If at the homepage you see firmware version 1.1.0, then you are all set. It’s possible that a previous firmware that was uploaded to your device used the same flash layout so it didn’t trigger a factory reset. In any case, if the homepage says 1.1.0 then the firmware has been correctly updated.
You can either submit a support ticket or before that maybe try to update to firmware 1.1.0 and see if it helps.
The LCD widget has been removed since it was only used to display IP address and wasn’t that useful otherwise. The current firmware implements a tone-based method for finding IP address: press and hold the on-board button (using a small screwdriver or something that’s thin enough to pass through the enclosure hole) for 4 seconds and release, it will sing tones to indicate the IP address. This is explained in the user manual.
There are some other ways to find IP address as well: you can go to your router’s configuration page to see the list of connected devices, and it should be fairly easy to identify which one is OpenGarage (it may be named ESP_xxxxxx). There is also another (arguably easier) way: the firmware enabled mDNS:
https://github.com/OpenGarage/OpenGarage-Firmware/blob/master/OpenGarage/main.cpp#L1242
which is a broadcast based DNS service. If you know your OpenGarage’s AP name (the first time you plug it in or after factory reset), say, if it’s OG_123456, then after it’s connected to your WiFi network you can access it directly using:
http://OG_123456.local/
This may or may not work depending on whether your router supports mDNS.Not sure about the cause, but it’s possible that software reboot might not be able to fix it and only a hard reboot (unplug and re-plug power) will recover the state.
I suspect this has to do with the flash memory layout. I recompiled firmware 1.0.9 with a different flash memory layout, you can give it a try (attached here) and see if it fixes the options page issue. Caution: before you update the firmware, please make sure to take snapshots or copy your existing configurations, as the new flash layout will cause the controller to lose configuration files and reset it back to AP mode, so you will need to repeat the WiFi setup step to get it log on to your WiFi router again.
This depends on what kind of relay you have. Some relay modules are active low, so if the control signal is low, it activates the relay.
OK, will take a look at it. Quick question: if you reboot the controller, does the options pages show up again?
Are you sure you have any log data to display? Judging from your /jl return results, there isn’t any log data yet, that’s why nothing is displayed on the log page.
About the options page, rebooting the controller should work (I did encounter the same issue once but rebooting resolved the issue). If rebooting doesn’t work, I would suggest doing a factory reset (press and hold the button for 10 seconds or more).
What is your firmware version?
“but this seems to disable the ultrasound distance sensor” — that’s correct, it assumes that you are using one or another, not both, since if you are using both, then it needs to know the logic of the two difference sensor results (AND, OR, or something else).
About your suggestions:
1. Because the ultrasonic distance sensor only senses distance at one spot, you are right that when it’s reporting closed the door may not be fully closed. The solution is to move it close to the door so that as soon as the door is up a little bit, it can sense the distance change. In most cases, the door is fully closed or fully open (unless if there is a power break, or if someone manually stopped the door from closing).2/3. You can add more sensors but the ESP8266 microcontroller has quite limited number of GPIO pins. You have correctly labeled the pins that are used and are spare. GPIO0 and GPIO2 are not usable for sensors: for one, GPIO0 is connected to button, and GPIO2 is the built-in LED, so they are not spare pins; in addition, these two pins must be remain HIGH during booting, otherwise ESP8266 will not boot successfully, for that reason, they should not be used for general purpose sensors since we don’t know the sensor status at booting time.
GPIO16, however, is a spare pin — in the original design it’s tied to RESET to allow hardware reboot, but since then I’ve found that this is not necessary as we can use software reboot. So if you cut the trace of it from RESET pin, then it becomes a spare pin.
GPIO4 and 5 are spare pins and they are also the default I2C pins so they are useful for connecting to I2C sensors or I2C io expanders if you need a lot of more spare pins.
I think the firmware currently only supports full hours — you can only set it to 22 or 23, it doesn’t support granularity of minutes.
Support for magnetic switch has already been added a while back:
https://github.com/OpenGarage/OpenGarage-Firmware/releases
In Options->Basic tab, Sensor Type, you can see options for switch sensor. It should be wired to GPIO4 and GND. Please note that in some early versions of OpenGarage, GPIO4 and GPIO5 are mistakenly reversed. So in case GPIO4 doesn’t work, try GPIO5. These pins are located above the distance sensor, marked GP4 and GP5.If you want to add other sensors, you will need to modify the firmware to support those.
Not really — the controller uses ESP8266, which is not sufficient to process camera images. There are plenty of low-cost security cameras (for example the famous WyzeCam), which are much better for capturing images.
Because the controller doesn’t record or ask for your time zone, the time set there must be GMT+0 (Greenwich) time. For example, if you want it to be closed at 3am your local time, just figure out what GMT+0 time that is, and use that time in the settings. As an example, I am in eastern time zone (GMT-5). So when it’s 3am here, it’s 8am GMT+0. Hope this makes sense.
You need to know the IP address of your OpenGarage and just type in that IP address in a browser to access the homepage (and options page too). If you don’t know the IP address, you can find out on your router’s configuration page, or you can use a thin screwdriver to press the button on OpenGarage for 3 seconds and release, it uses audible sound to inform you the IP address, as described in the user manual:
https://github.com/OpenGarage/OpenGarage-Firmware/raw/master/docs/OGManual.pdfNot sure what’s causing it, but I suspect it may be due to multiple reflections of the ultrasonic wave in the room which resulted in the error in distance sensing. It could be affected by temperature. You can submit a support ticket and arrange for a replacement, to see if it makes any difference.
When the controller is in AP mode, the LED flashes very rapidly (2-4Hz). When it’s trying to connect but not connected yet, it flashes more slowly (0.5 to 1Hz). If it has connected to a WiFi before and lost connection, it will try to re-establish connection, so if you see a slow flashing pattern, it means it lost connection and is trying to re-connect. It could be due to WiFi signal strength is weak.
Thanks for the suggestion. This is certainly doable, in fact, I’ve been thinking of modifying (I should say simplifying) the firmware to make a WiFi temp/humidity sensor based on DHT22. My only hesitation is that from a product marketing point of view, it’s better to say something is designed for a particular purpose as opposed to say it can do all of X, Y, and Z. It tends to confuse users. That said, I agree that technically it’s all possible to extend OpenGarage as you said to support multiple sensors/actuators.
