[lawrence_jeff]

If it makes you feel better, unlock doesn’t work in the US either – at least using the node red bridge, Alexa replies not supported yet.

[lawrence_jeff]

I would look at the code for the IOS/Android app – this is the approach it uses to reflect whether the door is open or closed and to open/close it upon button push.
One relevant file is this one

https://github.com/OpenGarage/OpenGarage-App/blob/a132d0f545a24e5972fc0453ec964d64dc4a6f4b/src/js/utils.js

Jeff

• This reply was modified 6 years, 10 months ago by lawrence_jeff. Reason: Addded link to relevant file

[lawrence_jeff]

Breaking this up a bit
As long as you have the OG setup with Blynk it will keep Blynk up to date upon change (and every 15 seconds) So if we know Blynk knows the status and is available via the internet.

TO RETRIEVE STATUS ON REQUEST
To get status you just do a normal web request (HTTP GET) to http://blynk-cloud.com/auth_token/get/pin (https://blynkapi.docs.apiary.io/#reference/0/write-pin-value-via-put/write-pin-value-via-put)

Where auth_token is your blynk token and pin depends on what you want to read the door state its virtual pin 0.

So you need code that takes the request of “Is the door open” and then makes the request to Blynk to get the value of the pin and then returns the status.

TO CHANGE STATUS ON REQUEST
Same thing here accept the request is http://blynk-cloud.com/auth_token/update/pin?value=value

[lawrence_jeff]

I think you can hack together open and close with Google -> IFTTT -> Blynk

Querying device status is a different matter, I’m not aware of anything there for Google, You need a web service that supports Assistant queries.. IFTTT doesn’t handle that natively, Blynk doesn’t either.. so unless someone has written a bridge service, I’m not aware of any options.

If you want to use Alexa or Apple Homekit as alternatives you can find instructions for both in the forum.

[lawrence_jeff]

My hope was to implement a somewhat generic webhook type notifier so OG can tell any system (whether it is SmartThings or something else (like Node-Red) that a door or vehicle status has changed. This avoids the need for them to have to constantly query OG and watch for the status to change (This is what I currently do for the apple support and it is somewhat inefficient and problematic as the code every 10 seconds asks ‘OG Are you open or closed”?

So the specific case right now is for SmartThings and using that as a POC but I would like to make it more generic on the OG side at least.

Ben’s Smartthings app could then be used to pickup the notification and update the app

at least that was my thought

[lawrence_jeff]

Great to hear – after thinking about this a bit – would this be more flexible if instead of sending refresh:true it sent the new status (door open, door close, etc)
That way you would have the option of either taking the updated status as is (and not rechecking) or you could always recheck exactly like you are today if you want

That would make things a bit more consistent with the other code and allow your app some additional flexibility.

Another thought – is the port specific to OG or is that generic – wondering if you had 2 OGs (in a 2 door setup) or you later wanted to use this for other custom devices if you need to be able to differentiate which device is asking the hub to do an update? IFTTT does this with a specific post endpoint but it could also be in the payload I guess

{[DeviceName]:refresh} for instance

• This reply was modified 6 years, 10 months ago by lawrence_jeff.

[lawrence_jeff]

Np – you’re through the rough part

[lawrence_jeff]

Here is a version hardcoded to make that request to the IP and port you specified

https://github.com/lawrence-jeff/OpenGarage-Firmware/tree/master/Compiled

[lawrence_jeff]

Use 2.3 of the ESP core per the instructions and it should compile as is

[lawrence_jeff]

Yes that makes sense, before I try to fiddle with the UI, can you send me the specific URL for your config (I guess I just need the IP) and I will create you a firmware hardcoded to make that call on update. If it seems to work we can figure out how to incorporate that into the UI.

Thanks
Jeff

[lawrence_jeff]

Doing an HTTP post with that bit of JSON is no issue, but I don’t follow this part
The trick was that the device network ID of the OG had to match the MAC address without the octet separator

What exactly do you mean when you say netwtork ID? Is it the user agent sent by OG in the web request, or from a network resolution standpoint your hub has to resolve the IP back to the name in form MAC Address…

[lawrence_jeff]

Are you running the latest firmware – when you say it shows a false positive what exactly are you referring to, the App, the webpage a 3’rd party service monitoring it?

Is the distance sensor pointing directly down at a flat surface when this happens or is it potentially hitting something angled (like the edge of a vehicle?)

[lawrence_jeff]

Are you trying this on an OpenGarage device or a DIY device. Backing up a bit – with your arduino install can you compile a simple example like the Blink one? That will help make sure your compile env is working before moving on to OpenGarage

If that looks ok – the next challenge is making sure you have the correct directory structure
In your arduino libraries folder (check the preferences sketchbook setting to see where that is set but usually in My documents) you should have a structure like this

– Libraries
—– Blynk
—– pubsubclient
—– OpenGarage
———-Examples
———-main.cpp
———-other files
—–Other Libraries

Then when you open Arduino you should have an option under Fie – >Examples – > OpenGarage

If you don’t see this your structure is not correct

If that is good – I see you are using a newer version of the IDE, you might want to downgrade to an earlier version. Honestly I prefer my compile instructions – they can be found here https://github.com/lawrence-jeff/OpenGarage-Firmware

• This reply was modified 6 years, 10 months ago by lawrence_jeff.

[lawrence_jeff]

@codahq – One challenge off the bat is the HTTPS requirement of smart things, this isn’t available in the current OpenGarage codebase, as all the web calls it currently makes are http. Looks like the change to add SSL would eat a good bit of the ESP’s limited memory

Is it an option to bridge via one of the existing supported solutions – for instance use the change notification to IFTTT to have it then call your update endpoint? Or I saw mention of a MQTT -> Smartbridge adapter that could potentially pickup the change notification from MQTT and then make the HTTPS call on the OG’s behalf

The IFTTT option could at least operate without another device but the MQTT would need something on your network like Node-red to make the HTTPS call

[lawrence_jeff]

I don’t really follow – how would opengarage detect these scenarios any better than the IR sensor already on the door. I understand the premise of how it would stop a door (by moving something in the beam path) but not seeing how it would detect it needs to do that. Can you explain more

[lawrence_jeff]

Yes – working on getting my dev environment back up based on 1.0.8.

[lawrence_jeff]

Are you sure you are using version 2.3 of the core, you get this issue on v4

[lawrence_jeff]

@andyss There are probably a few things to think through on this one to avoid breaking existing implementations. I wonder if you have username and password enabled if you get an error message back specific enough to then try again with a username and password – the OG name and existing key could be then sent without requiring a UI change to hold a custom username and password…

As long as it tried anon first this would keep it from breaking any existing code. I can’t commit to working on this anytime soon (tied up with other things but if you want to take a stab at tweaking the code to do either this or just stick in your own custom info I am happy to help you – compiling your own firmware isn’t too hard.

[lawrence_jeff]

@codahq – Does smartthings support a webhook model? If so and you have the info handy could you point me to it

I am having a problem with some of my polling where they pickup transient door states via the http endpoint – Opengarage itself is smart enough to filter these out and not update the actual door status but the door value in the API does temporarily update.

Having a generic webhook type handler would avoid this constant polling and maybe help in your scenario as well

[lawrence_jeff]

@vrbt150 You are correct it doesn’t currently handle this scenario very well, you should have at least 5 seconds due to the beep warning, you could bump this setting to 10 and it would give you at least 11 seconds to pull in (under the rare chance you show up 1 second before the auto shut time) but its not very adaptive

It handles the similar one that you show up at 21:01 and open the door – it is smart enough not to close it but not if you get there right before and the time triggers. . I wonder if it should instead of cancelling the auto close it should just slide it 5 minutes past the last open time… that way it doesn’t get accidentally left open in the case you arrived later than you thought and still expected it to auto close.

The update to the code wouldn’t take much from memory – Since you are programatically inclined can you file a bug in the Github on this (or submit a pull if really motivated)

• This reply was modified 6 years, 11 months ago by lawrence_jeff.

[lawrence_jeff]

Yes you can send open, close or click to the topic /IN/STATE

Open and close are preferred since they implement logic to make sure nothing happens if you send open and the door is already open.

Username and password isn’t hard to add but the use case I envisioned at least was generally a private broker (like a pi) on the local network where you are already protected by the Wifi security. Are you thinking of using it with a public broker?

[lawrence_jeff]

Make sure to check free heap (/db) if compiling with a new core – I originally started with the RC but it consumed much more memory for the same program.. they may have fixed it since.

[lawrence_jeff]

You have missed a step in the instructions to modify a file – See here https://github.com/OpenGarage/OpenGarage-Firmware/tree/master/Modifications

[lawrence_jeff]

Unfortunately you can’t get the icons via the built in update function (it doesn’t update the place where they are stored)
If you want to use a firmware burning tool you can use the bin Graphics-placeat00300000.bin to get them on the device.

I don’t believe I have seen mention of the IGMPv2 bug, can you provide more detail.

[lawrence_jeff]

Ok I found a sensor that did the same thing as yours using this code – Adding debugging into the code it was failing at this part

while((digitalRead(ECHO)==LOW)&& (micros()<quit_time));
{//Do nothing
};

and exiting out of the loop due to micros() getting larger than the quit_time..meaning it never detects the beginning of the pulse it needs to measure to determine distance. That exit condition was there mostly to stop the ESP from doing a watchdog reset and the code really should quit the function at that point since something is wrong and the measurement after will not be correct.

Looking around a bit I found an article that recommended connecting echo to Trig via a 2.2k resistor instead of directly. Adding that in fixed it for me. It seems some configs are just more sensitive than others.

So I have VCC -> 5v on the nodemcu (VIN)
GND -> GND
D6 –> TRIG

And then TRIG -> 2.2k resistor ->ECHO

[Author]

Posts