[lawrence_jeff]

Will try your code tonight, at a glance I don’t see anything wrong.

[lawrence_jeff]

You might try my fork of the firmware – I changed several things to make the wifi more resilient. https://github.com/lawrence-jeff/OpenGarage-Firmware

If you want to use an external process to reboot it you can always do a get request to

http://IP/cc?reboot=1&dkey=key

Where IP represents your device and key is your passcode

[lawrence_jeff]

Just to clarify, having two share the same trigger is not what I am recommending nor what I have in the code, that will be inherently problematic in our application. My code uses the 3 wire mode as in the URL you sited, this ensures that only one sensor is active at a time and prevents one from confusing the other.

How this mode works – is that it sets the pin to output mode, sends the pulse to trigger a measurement (ignored by the echo pin) and then quickly shifts the pin to an input so it can read the reply signal (ignored by the trigger pin). I would get this working in your setup if you plan on using more than one sensor – Not sure what issue you are having – i would start with using one sensor and figure out why it isn’t working. Are you powering the sensor with 5v or 3.3?

[lawrence_jeff]

Yes, IMHO the ifft integration is really only good for notifications which is an outbound request. It would involve another service but if you can use IFFT to trigger Blynk it would remove the inbound need; Blynk is fairly easy and you can query and open/close via a Blynk public URL that is then routed to the device (without port forwarding)

Also if you want to do a lot of workflow like this you might look at node-red, you can build flows that evaluate your time conditions, send the text and trigger the door – you can also tie in with Alexa .. you can run it all on your network on pretty much any device (I use a pi zero) I use it for similar things where I alert if the door is ever opened when neither mine or my wife’s phone is present on the home network. (The close after 10 is baked into my fork of the firmware)

Sounds like you have a good setup so probably aware of all this just thought I would mention alternative options

[lawrence_jeff]

I would get 1 GPIO Distance sensing work as an easy first step that makes all the code 1:1 as far as open GPIO to devices – I haven’t had any issues in my setup and it shouldn’t be a current issue since the code won’t power both sensors at the same time.

So starting with a single Ultrasonic sensor – you connect power and GND and the GPIO to both trig and echo.
When you run this you get back 0 for a distance?

[lawrence_jeff]

Sorry -I missed the reply to my earlier message. If the device is still doing this it is probably outputting the reason to the USB diagnostic/firmware output. To debug you may have to take down the device and plug into a PC to see what messages are being output when this happens. If you want guidance on this process I’m sure we can walk you through it.

[lawrence_jeff]

When you say open a port – do you mean on your router via port forwarding?

It seems Blynk is the preferred way the developer use for remote access and it doesn’t require inbound access so not sure if this request would get much priority. I can look at adding it my firmware branch but not sure even with that how confident I would be putting this on the internet… there fundamentally isn’t any sort of protection for brute force attacks on the web API or Denial of service attacks…

Is there something IFTT does that you can’t get via Blynk?

[lawrence_jeff]

If you are hearing the startup melody (you can unplug and replug to verify that is the same sound you are hearing) that only occurs on startup
You can see it in the code here https://github.com/OpenGarage/OpenGarage-Firmware/blob/master/OpenGarage/OpenGarage.cpp see play_startup_tune();
The only other sounds are the closing automatically beeps which are different
It actually happens before Wifi connection occurs but that would only be a second or so behind.

The other thing this could be is your power supply – ESP devices (the wifi chip inside) can do that if they can’t pull enough current. If its easy to swap out that would be a good test… if all else fails you will need to connect it to a PC to see what it output when this happens.

[lawrence_jeff]

If you are doing custom development I would recommend starting with my fork – I add lots of serial debug statements that make it easier to use (as well as a number of improvements). I also improved the compile instructions (which probably don’t help you now that you have worked through it)

https://github.com/lawrence-jeff/OpenGarage-Firmware

[lawrence_jeff]

If you are hearing the notes it means its rebooting.

There could be various reasons for this – one can be if the sensor is not responding quickly enough the watchdog timer will reset the device (at least with stock firmware). Do you ever see odd (high) distance numbers on the webpage?

[lawrence_jeff]

Great to hear – I kept all the API stuff backwards compatible so it shouldn’t break anything. I did add explicit close and open commands I wonder might help with using things like home assistant. The vanilla firmware accepts only a click command so can get out of whack if something else is changing the state. Mine also supports explicitly saying you want to close or open, so if the external stuff gets confused and sends a close when OG is already closed it won’t then open like the native firmware would when receiving the click command (it sees its already closed and does nothing)

Probably wouldn’t take much to tweak – just replace the click=1 with close=1 and open=1 in the appropriate places.

• This reply was modified 7 years, 2 months ago by lawrence_jeff.

[lawrence_jeff]

All working great here! I would love for a mod where you could use the distance sensor for vehicle detection and the magnetic one for the door.

Ok – let me take a look at just moving that scenario from dev to the prod firmware.. need to fight the urge to rewrite lots of pieces to support that.

[lawrence_jeff]

I didn’t understand your response, did you mean No my OG can not see vehicle, if you can’t see the vehicle you can disable detection by setting the vehicle detection threshold to 0 (which I think you probably know as your screenshots appeared to have it off)

The extra pictures require you to manually burn an additional firmware file which can’t be done currently through the GUI – but in your case if you can’t see the vehicle I wouldn’t worry with it.

If I misunderstood and you CAN see the vehicle let me know and I can try to make the firmware handle the scenario where the sensor can be used to detect a vehicle and the door sensor is used exclusively for the door.

[lawrence_jeff]

Oh cool – thanks for the pointer I must have missed this.
I will give this a try – I couldn’t quite get the transition states to work correctly in node-red (what I was using).

[lawrence_jeff]

Great to hear it is working for you- let me know if you see anything with this config you think should be changed, one thing I notice is that I should hide the fake distance. Basically to maintain compat with all the built in code I just set the distance to either a fake high or fake low number – but that shouldn’t be displayed on the homepage

Also is your OG Unit able to see your vehicle with the distance sensor? I was planning on making it so the firmware had a mode where the built in sensor can be used exclusively for determining if you have a vehicle present and the door sensor used the switch. Let me know if this is of interest (I couldn’t remember if you said you were going to be mounting outside)

[lawrence_jeff]

Sounds great.. post if you have any issues with it.

[lawrence_jeff]

@italoc

Did the firmware work ok for you with the magnetic sensor? Love to see a picture if you took any

[lawrence_jeff]

Hi lawrence_jeff,

during this week-end i think to receive a new official opengarage and i try to mount the sensor, and of course i send you some picture.

the GPIO4 and GND contact are located on the LEFT-TOP of the device.

i have installed your firmware on my actual opengarage and seems to work very well and much better than original firmware, but the interface have some difference with your screenshot, for example i cant see VEHICLE TRESHOLD field, it’s normal?

@italoc
I realized why the vehicle status isn’t showing up, the binary was out of date with the master branch. I have updated it so if you flash it you should see the vehicle threshold and presence info.

[lawrence_jeff]

I was thinking in terms of a single door garage with two cars but two garage doors would even be better.

I hadn’t thought of that but it makes sense, my high level thought was to reformat this so you can select what you want each of the 3 available inputs to do with the one tied to the integrated ultrasonic sensor limited to distance related options on the primary garage bay but the others could be mixed and matched
Something like:

What do you want the integrated ultrasonic to do:
Fixed at Bay 1 Only
* Ultrasonic Door State only (no vehicle proximity)
* Ultrasonic Door State plus limited vehicle occupancy (only when closed since the door blocks the sensor when up)
* Ultrasonic Vehicle Occupancy (Door state provided by other input)

What do you want Ext input 1 to do:
Select Bay 1 or Bay 2
* Ultrasonic Door State only (no vehicle proximity)
* Ultrasonic Door State plus limited vehicle occupancy (only when closed since the door blocks the sensor when up)
* Ultrasonic Vehicle Occupancy (Door state provided by other input)
* Switch Door State only (no vehicle proximity)
* Temperature
* Not Used

What do you want Ext input 2 to do:
Select Bay 1 or Bay 2
* Ultrasonic Door State only (no vehicle proximity)
* Ultrasonic Door State plus limited vehicle occupancy (only when closed since the door blocks the sensor when up)
* Ultrasonic Vehicle Occupancy (Door state provided by other input)
* Switch Door State only (no vehicle proximity)
* Temperature
* Not Used

That way if you have a stock device with no additions you could just configure as Bay1 door only or door plus basic vehicle state
If you wanted to improve that a bit you move the Ultrasonic so it can see the vehicle at all times and add a switch to Ext 1 – then set the integrated US as vehicle occupancy and the Ext1 as door state.. .want to add temp/humidity add that as Ext 2.

If you have 3 door with one car each you could set all 3 to Ultrasonic basic occupancy or Door only

I guess you could accomodate a multiple car per door scenario as well – it just starts to provide a lot of options.. if anyone has better ideas how to present these options feel free to reply

[lawrence_jeff]

hm..trying to flash your graphics file, but it just stops almost at the beginning.
Might have a clue as to why? thanks

I have seen that exact error with that flashing tool (in the same spot), I’m not sure why it gets stuck at the beginning like that. Last time I just used the flashing tool built into the arduino ESP environment and that worked fine. I think it uses esptool.py.
I need to find a better way to do on the fly graphic file updates so you don’t need to break out a flashing tool

[lawrence_jeff]

Have you implemented support for adding a second ultrasonic sensor to monitor two car garages? Since I’m unable to update my firmware OTA, I’m looking to replace it with a DIY one similar to this:

OpenGarage DIY

I’m also interested in seeing what your DIY solution looks like.

Support is close for an API only implementation of a second door monitor, something you can use with a home automation setup, Alexa or Apple Homekit but adding support for a second door into the UI or the Android app is quite significant and I suspect wouldn’t be a priority to ever incorporate into the official firmware. So my thought is to add it but in a compatible way with the official firmware so making it available only via an API call.

[lawrence_jeff]

Thank you but at the moment it’s not necessary… for me the priority is the magnetic sensor

i think to upload Graphics-placeat00300000.bin on my opengarege because now i can’t see icon, can i use this tool (i use OSX) ?

https://github.com/espressif/esptool

after flashing i lost all setting?

thanks

That should work – any ESP flashing utility, just burn it to address 300000. This will override the file that has your network settings and all your info so you will lose your log and settings.

[lawrence_jeff]

Hi lawrence_jeff,

during this week-end i think to receive a new official opengarage and i try to mount the sensor, and of course i send you some picture.

the GPIO4 and GND contact are located on the LEFT-TOP of the device.

i have installed your firmware on my actual opengarage and seems to work very well and much better than original firmware, but the interface have some difference with your screens

hot, for example i cant see VEHICLE TRESHOLD field, it’s normal?

Some of the screenshots in the master branch are actually code that is in the dev branch of my repository. It adds a number of features around vehicle detection and use of the additional GPIO pins for temperature or secondary door measurements. It isn’t quite stable yet so I haven’t prompted it to the Master (the pictures were a mistake)

Is there a particular aspect you are interested in – I can get that into the master branch?

[lawrence_jeff]

@italoc Instructions for the magnetic switch can be found at the end of my updated readme. Let me know if you have any questions. If you go through these and wire it up please send me a picture so I can include it.

https://github.com/lawrence-jeff/OpenGarage-Firmware/blob/master/README.md

[lawrence_jeff]

Yes – I was intending to write it up along with instructions on how to add my firmware, I will try to do it tonight. The only part I am unsure on is exactly how to access the header on an official opengarage device, I don’t have one myself I have a custom made one using the same components.

According to the schematic the header is at the top of the board but i don’t see any opening in the case to access it. Do you have the device yet?

Jeff

[Author]

Posts