Forum Replies Created
-
Posts
-
I don’t really know. PIN_SWITCH is clearly defined in defines.h. Is it possible that your defines.h is not at version 1.0.8?
The read count is retired because the current Blynk app can detect and report device offline status. The read count was originally put in place as a ‘heartbeat’ so that you can tell if the board is online. Because Blynk can now report it anyways, the read count is no longer necessary.
That’s part of the ESP8266 core. Did you install ESP8266 core, or selected Generic ESP8266 as board?
I’ve improved the noise filtering and I believe the distance sensor reading is now more robust and clean. The new firmware is numbered 1.0.8 and it’s available at Github, also directly from the following zip file:
http://raysfiles.com/og/ogflash.zip
The main difference of 1.0.8 with 1.0.7 is the added median filtering to smooth out sensor data, and also reversed some compilation flags in response to a few reports that firmware 1.0.7 seems to break the device (stuck at boot). My suspicion about the ‘stuck at boot’ problem is that it has to do with changes in the compilation flags, hence I reversed the flags and will see if this solves the stuck at boot problem.I suspect this has to do with the way the new firmware is compiled (some compilation flags have changed since the previous version). I’ve reversed those flag changes and updated the reflash zip file:
http://raysfiles.com/og/ogflash.zip
it’s now named og_1.0.8.bin. Give it a try and see if it works. If not, please submit a support ticket so we can arrange to have it returned to us in order to check why the new firmware isn’t working for your particular unit.The button is inside on the circuit board. There is a hole on the enclosure — you can use a small screwdriver or something sharp to pass through the hole to reach the button.
If OTA update fails, you can try to use a microUSB cable and a computer/laptop to update firmware.
I have prepared a zip file that contains necessary tools to reflash the firmware through USB. Please download it here:
http://raysfiles.com/og/ogflash.zip
take a look at the README.txt and give it a try to see if it works.There is a new firmware that we released recently (1.0.7) which compiled the code with ESP8266 core 2.3.0, and that may have addressed the connection issue.
I have prepared a zip file that contains necessary tools to reflash the firmware through USB. Please download it here:
http://raysfiles.com/og/ogflash.zip
take a look at the README.txt and give it a try to see if it works.I have prepared a zip file that contains necessary tools to reflash the firmware through USB. Please download it here:
http://raysfiles.com/og/ogflash.zip
take a look at the README.txt and give it a try to see if it works.@chalina: when you say you can’t get this to upload, what specific error message do you get?
Yes, I noticed that core 2.4 just got released, so will be working on that next. You said you tried to compile og with core 2.4 and it will not work. What error messages did you get?
I am not sure actually if this is supported in the firmware. In the official firmware 1.0.7 this option has been removed. Jeff Lawrence can confirm whether this is supported or not.
The issue is now fixed by compiling the firmware with Arudino core 2.3. Also the WiFi reconnection issue is fixed in the upcoming firmware 1.0.7 (will post shortly).
A couple of thoughts after quickly reading through the posts (sorry if I missed something you already discussed): there are a number of spare pins that OG doesn’t use, particularly if you use your own custom hardware, these can be easily freed up. For example, GPIO4, 5 (these are also the I2C SDA/SCL pins), GPIO16 (on OG circuit it’s tied to Reset in case some application requires putting OG to deep sleep, using GPIO16 tied to Reset pin can wake up ESP8266 from deep sleep, but since this is not used currently, GPIO16 can be freed for something else), GPIO2 (connected to ESP8266 module’s internal LED, but is free to use); in addition, GPIO13 can be freed if you don’t want buzzer.
Next, if you have N ultrasonic distance sensors, you only need N+1 pins, because you can have all of them share the same TRIG pin, but each having their own individual ECHO pin. Of course the problem is if these sensors are too close they can end up interfering with each other on the reflected signals, but if they are put far away or facing different directions, it should be fine. Be careful that since HC-SR04 requires 5V and ECHO pin outputs 5V, you should have a 1K resistor in line from each ECHO pin to ESP8266’s GPIO pin, this is enough to serve as a simple level shifter. There is a new type of sensor called HC-SR04P, that can be powered with 3.3V and won’t need the in line resistor.
Finally, IO expander as you mentioned is also a good idea. I am more familiar with the PCF8574 I2C IO expanader, which is very common and cheap.
I am not sure if this is easy to implement. If there is an app that supports sending an HTTP command when the phone connects to your WiFi, that would do it, but I don’t know if such an app exists.
I actually have set up my Google Pixel phone (which supports Google Assistant) to accept voice command — when I get close to home, I just pull my phone and say ‘open my garage door’, and that’s pretty convenient. Not as convenient as automatically opening the door, but still pretty fast. In fact, I think this is more reliable because if you are at home and your phone accidentally disconnected and reconnected to your WiFi, you don’t want it to automatically open your door.
OK, so this has to do with Log data I guess. Note that the Blynk history graph is already a visual form of log. If that’s not sufficient to you, yes you will need to modify the firmware to send log data to the cloud server. I don’t know if there is any limit on the data size, but assuming there is no limit on the data size, this is fairly easy to do on the firmware side.
@chalina: because we recommend using the Blynk app for remote access, we don’t actually recommend setting port forwarding for OpenGarage. You may have seen such instructions in our Tutorial on how to set OpenGarage to work with Amazon Echo or Google Home. Now that Blynk also supports HTTP API:
https://blynkapi.docs.apiary.io/
there is no need to use port forwarding anymore — you can use Blynk’s HTTP API for remote access even with Amazon Echo and Google Home, where the secret key is the Blynk token.Regarding Log and setting Options: without port forwarding, these are currently only supported when you are on your home WiFi. The reason is that options and log data are considerable amount of data and should not be sent to the cloud server. The good thing is that options generally don’t need to be changed frequently. Also, if you use IFTTT or MQTT notifications, the notification history is essentially the same as the Log data, so that’s an alternative way to keep log.
Thanks for the information. Indeed support for WPA2-Enterprise has been added to the ESP8266 library, and it can be integrated into the firmware now. The only thing is that we don’t have a WPA2-Enterprise router in house to test (they seem rather expensive), so ideally we will need to find some users to help test this feature.
One thing that caught my attention recently is that the rebooting issue may be related to 5G network — check if your router is a 2.4G only or 2.4G/5G hybrid network. The WiFi chip is only compatible with 2.4G, and if it somehow got connected to 5G (likely because you have set the same SSID name for both), it could result in the rebooting problem. I personally use Netgear 2.4G/5G dual networks, and haven’t had any problem, but it’s not tested comprehensively on other 2.4G/5G hybrid routers so I can’t say for sure.
If the problem still persists, you can submit a support ticket and get it replaced.
The sensor (which is a ultrasonic distance sensor) can actually be used to detect water level. I haven’t tested it myself, but I’ve seen a sump pump monitor project that uses exactly this sensor:
