Ginobean,
Sorry to hear that. You should definetly give Wyze Support a ping via email at hello@wyzecam.com. Be sure to include all the details so they can assist you in the best way.
Best of luck,
Kenner
Your experience is both unfortunate and I am sure not what Wyze intends. My authentication token seems to be holding for several weeks now. In my case I receive a notification every time motion is detected by my outside mounted Pan camera.
I wonder if something else is causing the token to expire? What kind of automation were you attempting in ifttt?
As a side note, the IFTTT Wyze applets need to provide an orthogonal API experience, to the extent that this is possible and reasonable.
For example, there’s an applet to ‘Turn off push notifications when I am home’, but it doesn’t allow me to choose a camera and/or sensor to associate the applet with! That doesn’t make any sense, and it’s indicative of poor basic design of the IFTTT-Wyze integration.
Additionally, if you browse the wyzecam forums, you’ll see that these IFTTT integration issues have been ongoing for the past year or so. That’s quite surprising and less than impressive, given that there’s a very limited feature set available via the IFTTT-Wyze applet API.
At the time when I tested the two applets that I needed, after the authentication tokens had expired (failed) silently, the applets would run but not do anything in terms of actually toggling the notifications on/off or enabling motion detection on/off for the particular device!
So, had I not explicitly tested these corner cases, I would have simply assumed that they were working fine when they were actually FAILING silently…
Again, this seems like pretty basic stuff and I’m a little surprised that this wasn’t solidly implemented. I’ve been a professional programmer for many years and I don’t understand why this Wyze-IFTTT isn’t rock solid, after having been out there for more than year… It seems like pretty basic stuff…
I am having difficulty understanding your issue about applying the applet to a specific camera. I cannot NOT apply it to anything but a specific camera (or sensor). I am also a programmer by trade so I understand what you are saying I just can’t replicate the issue.
My test applet uses location as the “this” trigger, so for instance when my phone returns home (geofencing), it triggers a Wyze action for the “that” portion of the applet, in this case I told it to turn motion tracking off for my front door camera. I had to select a camera to apply this command to, there was no way not to do so.
Could you provide a screenshot perhaps illustrating the issue?
Take a look at this screenshot. This is what I mean by lack of orthogonality in the Wyze-IFTTT API. There’s NO option to select a camera or motion sensor.
Ah I see your problem. That particular IFTTT function is meant to be application level not camera level. It turns the ability of the APPLICATION to generate notifications to your phone on or off.
It is probably not as clear as it could be. But that was never meant to be specific to a camera it affects ALL devices/cameras that might generate a notification for your account.
To be objective, it would be a good idea to somehow differentiate between APPLICATION notifications and EVENT driven notifications. And there should be a way to use IFTTT to manipulate either set. That functionality is missing at this time.
I can see where it would be desirable for instance to turn notifications for inside cameras off when you arrive home but leave notifications on for outward facing cameras.
Currently this is an all or nothing option.
If you make it orthogonal, so that the user can specify the ability to turn notifications on/off for a specific camera or motion sensor, the problem goes away.
As it is, the design of the IFTTT-Wyze API is lacking these orthogonal functionalities. It’s like having one switch to control 3 lights, instead of having 3 switches to control each of the 3 lights independently.
The former (one switch to control 3 lights) is too coarse a level of granularity. Whereas having 3 switches to control 3 independent lights allows the user to control each light individually. Which I believe is the most common case.
In terms of the Wyze-IFTTT API, I can think of almost no case where having coarse level functionality (APPLICATION level notification switching) would ever be preferable to having fine granularity functionality.
The easiest route, in terms of providing orthogonal functionality at the Wyze-IFTTT API level, is simply to look at the current functionalities supported by the Wyze app, on iOS and Android, and duplicate these functionalities at the Wyze-IFTTT API level.
In the app, note that each each camera and motion sensor has fine level granularity settings.
Allow access to most these fine level granularity settings at the Wyze-IFTTT API level and you now have a flexible, easy to configure, orthogonal design that can be used as a basis for building IFTTT-Wyze apps that can satisfy 99.99% of user needs.
Additionally, fix the issue with token authentication expirations. It’s a little disturbing that IFTTT can no longer access the list of cameras after a couple days, which suggests that some kind of authentication token is being rejected/expired within a fairly short period of time. I would suggest taking a close look at IFTTT authentication token handling and what IFTTT recommends in terms of how to handle this correctly.
This problem still persists. IFTTT has been un-usable for over a month now. Not sure why it is taking this long to fix this problem that was clearly recently introduced with the app/firmware update a month ago to add multiple cameras. WYZE need to test their updates before rolling it out and crippling existing functionality. But furthermore they need TO FIX the problem when it’s clearly identified.
1 Like
Of the available IFTTT Wyze functions only the notifications function is application level. All of the other functions, accessible from the “that” portion are specific to an individual camera or device.
So while I tend to agree in principle, i myself use the turn off/on notifications at the application level. I like being notified of something happening when I am away from home but to be honest I tend to turn my phone off when I am home so notifications are of limited use to me at home.
I have not looked much at the available Wyze “trigger” type functions to be honest but I will now just so I can speak intelligently about the “this” side of the Wyze namespace.
Okay, I just took a peek at the trigger versions of the Wyze API available to IFTTT and ALL of them are specific to a device.
So in conclusion the ONLY IFTTT function that, to use your words, is not orthogonal is the notifications function. All of the other functions are indeed specific to a single device and therefor as granular as you can get.
So I think your only remaining issue is that the notifications API in and of itself is not granular. I think this is something worthwhile pursuing and I will have a look to make sure it is not already a wishlist item.
From what I can tell the issue does not appear to be very clearly defined yet. For instance I experienced the issue, 2 or 3 times and then it went away. For over 20 days I have not had a repeat.
Others, like yourself, seem to experience it continuously or very frequently. Several versions of the firmware have been released since then as has a new version of the app at least in beta versions.
I would suggest calling support and see if they can assist you in downgrading to a previous version and see if that helps?
@rbruceporter, if you look at the wyzecam forums you’ll see that there have been issues with the Wyze-IFTTT integration for the past year.
Maybe I’m missing something, but this stuff looks to me to be pretty basic stuff to implement.
The best thing might be simply to have a different programmer(s) look over this and possibly rehaul it, as the 3-4 days I spent testing out the corner cases convinced me that it was flaky and unreliable.
A different perspective (different programmer), working on these issues, might make all the difference here…
I understand but I have been unable to replicate any of the issues myself. I suspect that means at the very least there may have been external factors causing the issues.
And of course it is not a good idea to base your own opinion on others experience. As a programmer I am sure you are aware that to a non programmer things can easily look like a code problem that are not. For instance last week there was a fairly widespread internet issue in my area. The first time I noticed was when Alexa could no longer control my Hue lights. Since Alexa was obviously connecting to the internet I assumed Hue was as well and therefor it was an Amazon issue. It actually turned out that Amazons servers were fine, Hues were not, but it acted like Alexa was the issue.
Sometimes a problem may just need a fresh perspective, one that a different programmer can bring to the table.
Each programmer brings their own toolset and preconceptions to a problem and the danger of having just one person be the only one to look at the issue is that they may no longer have a fresh perspective on the issue.
And then there’s the danger of simply blaming other components for the problem. Which may or may not be true. But assuming, at first, that the problem is with the component that you are responsible may help to focus your efforts so that you are able to prove fairly conclusively either that the problem is indeed NOT with your component OR that the problem is indeed with your component.
Additionally, adding some logging may help to localize the scope of the problem itself.
Again, this is where a fresh perspective would probably bear more fruit in this particular case…
1 Like
To clarify something here… the ability to toggle notifications on a per camera basis has not (at least not yet) been implemented. The only option for notification control via IFTTT right now is the global switch.
Here is the #wishlist topic requesting this and many more IFTTT features. You can hop over there and vote for and/or comment on it:
This thread took a few directions, but the main point is that the ifttt connection with wyze is unstable. Does wyze know this and is working on it?
For example, I have a web hook that turns a camera on. When I set it in ifttt i can see the cameras i have as options. It works for a seamingly random amount of time. Eventually, sooner than later, the webhook stops working. Going into the setting of the applet the camera options now say no camera available. It will eventually fix itself and work again, to also eventually quit working again. A fix is to edit the wyze-ifttt connection, sign into wyze through ifttt, and grant access again. The cameras options show up again.
In summary, ifttt is unreliable currently. Is this a bug wyze knows about and is working towards fixing?
1 Like
I don’t know if they are working on a fix or even if the problem is deemed to be on Wyze’s end. Have you submitted a support request?
I have not! That would be a perfect result of starting this thread. How do I do that?