REST API over WIFI

On thing with wifi, is on watches, it's rarely connected, but I know on devices like an edge 530, it does get used as the 530 tries to connect wifi  when you turn it on, and one of my widgets gets data before BT is connected.

My target is an app/widget that sends a REST call to a smart home system to activate a smart lock. In this use case the user does not have the phone on him and only the watch. In the door area there is a wifi where to watch is connected to.

If I get you right, this will not work?

Best case is there would need to be an established wifi connection in place, where this isn't common as wifi is a battery drain.

I'm currently using a Watch and BLE to talk to a raspberry pi to control my garage door opener.  Could you do something like that? https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/would-you-like-some-raspberry-pi-with-your-connect-iq

I've not specifically done this, but the watch could talk to the pi with ble and then the pi talking to the home automation system

I have noticed that the newer edge devices which support CIQ3.0 or greater will make use of the WiFi for web requests.  The other thing to keep in mind with the edge devices is that once you start the activity timer, the WiFi gets turned off to save battery life.  While using the WiFi is convenient while testing for app development, it is not really something that you can rely on under normal use cases.  Your use case may actually work out for bike riders as the device will turn on the WiFi once they hit save.  If they are at home once they finish, the widget could also connect and be able to send the unlock command.

I don't see your plan being possible with the way WiFi is implemented on the watches

As the others have mentioned, WiFi is not always available, and the times that it is available depend on the device. Yes, the 530/830 will turn on WiFi when the device is powered up, but will turn it off as soon as an activity is started. For wearables like the fenix6, WiFi is only turned on when explicitly requested (using the Bulk Download functionality of the Communications module).

I'm working on a few tweaks to the simulator that will more accurately reflect the behaviors of actual devices with respect to WiFi/LTE availability. Hopefully it will make it to release.

I worked on a widget to control my garage using web hooks over the last few days.

Here are some my thoughts going through it. Hope this helps.

1. Documentation: Check out WiFi Bulk Downloads Section on this page
2. Simulator v/s Device behavior is very different. I had to test on device to get things right. This is confirmed by post from Travis above
3. There is a delay to connect to WiFi network (~ 5-8 seconds on my set up) after triggering the Sync Delegate with Communications.startSync()
4. Screen is taken over by system as soon as you do this. Trying to push/switch/update view during the sync results in communication errors on device (however works on the simulator)
5. WiFi is disconnected as soon as you report sync complete (with Communications.notifySyncComplete() call).

My original plan was to
Call Open/Close API -> Wait for 3s -> Call Status API -> Repeat last two steps till requested operation complete

The wait above (even when 50ms) results in a re-connection needed on WiFi. I have resorted to
Call Open/Close API -> Report Sync Progress -> Call Status API -> Repeat last two step till requested operation complete -> Report Sync Complete -> Update View

Usually see 20 odd status calls before my garage is completely closed or open.

It is very easy to implement wide range of features/ smart home controls using web hooks.

I feel like the experience working with them on Connect IQ could be improved with
1. Providing a way to customize the message on Sync screen instead of Generic "Transferring..."
2. When a user is interacting with a widget that has a sync delegate, system can activate WiFi if phone is not connected.
3. Have a timeout after which the WiFi disconnects once a Sync is reported complete. I could have reduced the 20 odd Status API calls in my case to 1 or 2 calls, if WiFi was available say for about 3s after sync complete. (Making an assumption 3s of WiFi standby consumes less energy than 20 active web API calls)

I do understand there is lot of moving parts to the system, and various trade off to be considered. Just wanted get these recommendations out there. Appreciate the effort to put out awesome products and SDKs to allow us enhance their capabilities.

Hi Desh,

Did you manage to create the app to control the garage door over wifi? can you share the code?

thanks,

Panagiotis

One thing to consider is using BLE instead of wifi,  Here's some basics I did a few years ago, that includes an example of a garage door app and a Raspberry PI.  I've since added some things, like white lists of BLE MAC addresses, an "auto close" if the door is open too long (it can be overridden), and it will work with any opener (you get the sate of the door with a reed switch and simulate pushing a button.

https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/would-you-like-some-raspberry-pi-with-your-connect-iq

I'm using a pi zero, which is maybe $15 US, and a few components that are another $5 (what's on the white board), and have since added a OLED display, RTC, and BME280 environmental sensor. Connection to it can be less than a second. (as you are pulling into your drive way)

thanks! I will give it a try!