Wyze Server Changes

[SecKatie]

• Discussion of changes coming down the pipeline from the Wyze cloud service
• Our responsibilities as a community
• Ranting & raving
• Improvement suggestions/community development support

[vidvisionify]

While this conversation with them is promising, actions speak louder than words. We've been promised RTSP for the v3's since it released almost a year ago.

Will this update just be killing binary sensors? Will the Lock still have full functionality?

[SecKatie]

The lock should still have full functionality. I do not yet know how restrictive they want to be though so we might still be seeing dropped requests.

[JoeSchubert]

I think that functionality would still be fine, if it's the polling that they don't like. As I had said in the closed discussion, it looks like by default the lock is polling its state every 10 seconds. To lock/unlock, it really doesn't need to know its state. Unfrotunately, a slower poll time would also mean that anything relying on door_locked, door_open would be delayed by up to whatever the polling interval would be... But those properties are also basically "binary sensors".

[fresnoboy]

I'm still trying to understand the dataflow that's an issue. If the camera and relay are local, does the video actually go through their servers? If not, what's the issue? They already are doing motion detection on the uploaded stream as is. I can understand why that would be a big problem for them if the video is being roundtripped through the server, but why should it do that? The V2 RTSP implementation stays local, but I though for local devices the stream stayed local as well?

I'd be happy to have BlueIris do the motion detection etc...

[vidvisionify]

I added to the thread on their forum, because the maybe-later tag should be reconsidered.
https://forums.wyzecam.com/t/home-assistant-integration/3971/682?u=vidvisionify

[tggman]

In your UPDATE note to your users, you indicated that "... They want me to disable the binary sensor devices as these are absolutely pummeling their servers. I will release an update tonight that removes them entirely until we can find another way to implement them"

Just a comment and a suggestion some might find useful. I've been using https://github.com/kevinvincent/ha-wyzesense alongside your ha-wyzeapi without issue since day one. While not a perfect solution for all, I've found Kevin's "Local API" approach to be VERY reliable and SUPER fast. In fact it's so fast and reliable, that I've put extra effort into keeping these v1 contact and motion sensors in service. I've even written yaml code to keep an eye on the battery life, have HA warn me when the battery reaches a critical level (84 reported), and proactively replace the batteries every 8 months.

You can find the latest code for this integration here: https://github.com/kevinvincent/ha-wyzesense/releases/tag/0.0.11

[SecKatie]

Quick note for anyone reading: this only works for v1 sensors and not for the newer v2 sensors. There is currently (2021-8-19) no solution for the v2 sensors.

[prashantapradhan]

I use @kevinvincent's integration too, I love it, but it is not maintained; it hasn't been for a while. It can break at any HA upgrade, and it is only for Wyze Sense. I loved @JoshuaMulliken's integration. I hope Wyze opens up API. Otherwise, we will have to move on the Aqara or something. Bummer about the lock binary sensor too, I love that integration, just for automated 9 O'clock security check.

[SecKatie]

I think that the lock is still reporting state info

[prashantapradhan]

That is awesome. Just confirmed that the lock is still reporting the state. Thank you.

[ejpenney]

Agreed with the above. I've used the ha-wyzesense integration since day one. I have cameras, a lock, and door/motion sensors and the only impact to me with this change was the loss of motion sensors on the cameras. A bummer but not catastrophic. I've also found locally driving the sensors is super fast anyways. Do monitor batteries though!

[krayj]

There is an official Wyze Skill (integration) for Amazon Alexa. It has no problems getting up to the second live data from those Wyze binary sensors which allow Amazon users to create automations based on the real-time state of those sensors. How are they facilitating that? I am forced to conclude that Wyze have either already created fully functional callback methods or hooks into their API or they are just tolerant of the increased polling traffic coming from Amazon for that integration to work. Why couldn't the integration do whatever the Amazon skill is doing? I wish that topic had come up in conversation.

[tggman]

Another potential workaround:
I've successfully tinkered with setting up what I call a Command Pipe communication bridge between Home Assistant and Amazon Alexa. I basically pass a unique task ID to Alexa using an exposed input_number entity from Home Assistant and which Home Assistant controls. That unique task ID is then used as a trigger by an Alexa routine to perform various Wyze API related tasks such as turning on a light or whatever. This command pipe is a two way street so Alexa can ask Home Assistant to perform tasks as well.

Obviously this too is not for everyone since it requires a functioning Amazon Alexa Integration within Home Assistant (which is no easy task) or a Nabu Casa account.

[SecKatie]

The bulbs still work with the updated integration.

[hellboyfishman]

Could their overloaded servers be the issue I'm making calls to the bulbs? My bulb integrations work fine for on/off but not brightness, color, etc, more than 60% of the time. If it isn't related I can always open a bug report and start pulling logs but I thought I'd just ask first.

[tony-fav]

Could a MITM approach work for sensor? Just witness the update being sent to the Wyze servers?

[SecKatie]

Potentially. It might require significant hardware hacking of the v2 sense hub.

[SecKatie]

@everyone please update to the latest version of HA to comply with Wyze Labs request to disable binary sensors.

[tggman]

@JoshuaMulliken the manifest at https://github.com/JoshuaMulliken/ha-wyzeapi still shows v2021.7.12 (but the files are dated today). Is this the latest/updated version?

[SecKatie]

The latest version should be 2021.8.1

[tggman]

Yes, but did you forgot to update the manifest file?
https://github.com/JoshuaMulliken/ha-wyzeapi/blob/master/custom_components/wyzeapi/manifest.json

Not a big deal to me but I thought you might want to know.

[SecKatie]

Ahh yes good catch. I did forget the manifest

[nijhawank]

I was trying to understand your original code (before the recent changes to remove the binary sensors). I was expecting something similar to web-sockets as I couldn't imagine continuous polling to determine such state changes but these latest news confirmed that Wyze didn't have it or supported it only for apple push notifications and similar for android.
If Wyze supports that we won't have to do continuous polling and there won't be any unnecessary load on their servers.

[SecKatie]

Yep we had to do continuous polling because they do not provide a state change event api or a websocket api or any push functionality really.

[JoeSchubert]

Just curious... I saw on the Home Assistant page that you can do group polling instead of polling for each device.

From a technical perspective would it be possible to poll wyze for all the devices on the account, say every 30 seconds, then just let them get their states from that? In the docs it's "DataUpdateCoordinator" that notifies entities of changes.

This would alleviate a significant number of requests if it could be done, or if they could implement that as an API endpoint.

For instance, assuming a 30 second poll interval this would be 2,880 polls/day vice the 2,880/day per device. That number would never increase based on devices... Like right now 10 devices would become 28,800/day, 20 would become 57,600 and do on. I know the locks are defaulted to 10 secs, so those are what... 14,400 requests/day by themselves each.

Granted some devices may need to be configured to poll more often, but the user can go override the entity for it and set that option on their own.

Just a thought.

[zackoch]

Be warned, this is a rant - feel free to scroll on by 🤣

I'm torn. I get it, but they've also sort of shot themselves in the foot.

Why the hell are they using an http req based API for an army of IoT devices? Like that's their main product?! C'mon.... I see this as one of those cases where it was easy to implement, but never got migrated to a proper technology / solution once they got off the ground. Now they're stuck with a huge user base, and "50%" of those "expensive" legit http requests, and frustrated because the other 50% of the requests are coming through their private API like crazy, costing them an arm and a leg.

I get it, they're saying "why should we have to pay for people costing us all sorts of money by using our private API wrong?"

But that's the problem/mindset that so many companies refuse to step through, and they continue to develop on that poor choice of scale out methodology.

The fact of the matter is this - they shouldn't have to be paying for those "expensive" 50% cost of the LEGIT HTTP requests, let alone the non-legit ones.

Do we see the implementation issue here? If they'd used a proper pub/sub solution initially, we BOTH - as users and Wyze themselves, wouldn't have ever even faced this problem.

They need to think about their strategy moving forward in my opinion. Take a moment to think about how all those crappy Chinese IoT companies make money with a similar strat... The margins are slim on the hardware costs, just like Wyze, but why are they not getting pounded by expensive infra? Because they used a proper solution like pub sub. (Annnnd they're probably mining data, but we'll just sweep that under the rug for now haha)

So Wyze realizes this and starts to raise their product prices because their dev costs are expensive (they're actually making craptastic stuff into great products!) and also the infra costs are getting out of control; this forces them to come up with stupid ideas to try and make money for subscriptions to object detection / post processing enhancements, which we all know was ass, and likely very few subscribers actually signed up for.

So we're back to what I'd mentioned before - simply thinking about their scale strategy and using the proper solution to prevent unnecessary waste in infra costs would have saved them a ton of money, saved face with regard to poor monetization strategies, probably made their infra less complex, and not dug such a big hole they have to figure out how to climb out of.

[SecKatie]

Hey, rants are a valid topic haha. Thanks for sharing your feelings

[krayj]

Here's something to think about. Wyze already published an official integration for Amazon Alexa giving Amazon users the ability to monitor the status of Wyze binary sensors (the very things they are saying are the root cause of this issue) in near real-time, to be used in Amazon Alexa automations. I can only conclude that they've already built out a proper callback/notification functionality into an API somewhere to facilitate this...or they'd be seeing the same problem hitting them from Amazon which would be significantly more users & traffic and I don't even have to fact check that to know it's an absolute certainty. So why haven't they just made that aspect of the API available so that the Home Assistant integration can get status of those sensors in a more elegant way? They've already developed the solution.

[prashantapradhan]

Fair point @krayj

[LordNex]

Mine isn’t. But I thinks that’s because I haven’t synced or calibrated it with the app in a while since I normally use ZHA to control it Benjamin Powers On Aug 19, 2021, at 5:23 PM, Joshua Mulliken ***@***.***> wrote:  I think that the lock is still reporting state info — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#232 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACGXNJBE4X7JOSJWXRBTM73T5V75LANCNFSM5CMXSGHA>.

[tony-fav]

I know some people are already running Bluestacks on PC to view camera streams on mobile. Well, this blocking instance has me prototyping using Bluestacks + Wyze App + Tasker + AutoNotification + MQTT Client to get the Wyze app notifications and publish the text to MQTT. Then I've got a python script parsing that text and re-publishing it to MQTT for Home Assistant. It's a mess of a process, but it works in this pinch. I was trying to do this with an extra phone, but the Wyze app works weird with a locked phone.

[jrm523]

I am so perplexed at this issue.. I would LOVE for the chance to not have to use their servers for anything and to keep all of my Wyze traffic local. It just seems weird that they wont give us a local only option but then are complaining about their servers getting pounded with requests.

I have a love/hate relationship with Wyze. On the one hand, they have made some significant changes to the industry and made some really great products. On the other hand, I have always been frustrated by their lack of support for integrations and local network access.

[krayj]

I am so perplexed at this issue.. I would LOVE for the chance to not have to use their servers for anything and to keep all of my Wyze traffic local. It just seems weird that they wont give us a local only option but then are complaining about their servers getting pounded with requests.

I have a love/hate relationship with Wyze. On the one hand, they have made some significant changes to the industry and made some really great products. On the other hand, I have always been frustrated by their lack of support for integrations and local network access.

I don't think it's perplexing at all. You can't sell people on service subscriptions once they have local control and can replace your services with something that's readily available elsewhere. Even if it's not a service that wyze is monitizing now, facilitating local control means they forfeit any future ability to monitize something into a monthly subscription.

I think they've realized they can't rake in the big bucks by reskinning and re-selling other company's hardware on slim profit margins. They have no financial incentive to put in any effort at all into facilitating local control. Because of that, I'll go on predicting it'll never happen. I dare them to prove me wrong.

[ejpenney]

I think they've realized they can't rake in the big bucks by reskinning and re-selling other company's hardware on slim profit margins. They have no financial incentive to put in any effort at all into facilitating local control. Because of that, I'll go on predicting it'll never happen. I dare them to prove me wrong.

I tend to disagree but I may be biased. Maybe I'm naïve and optimistic, but the core complaint here is that Home Assistant users make up a tiny percentage of their userbase and therefore didn't justify the load on the servers. Giving power users local API access wouldn't have any real impact on their ability to monetize functionality. The people who care already aren't willing to pay. Additionally, I can't speak for anyone else here, but my experience has been that power users (IE Home Assistant geeks) are the ones providing purchasing advice to less technically inclined friends and family. In combination with all the other disappointments I've experienced regarding Wyze products, currently when I'm asked for product recommendations I say "Stay away from Wyze, you'll do better just about anywhere else."

That's definitely NOT good for business, and I think giving us local API access and/or callback functionality would be a tiny price to pay to sway my views back into the positive. But, as I said, I'm obviously biased.

[krayj]

I think they've realized they can't rake in the big bucks by reskinning and re-selling other company's hardware on slim profit margins. They have no financial incentive to put in any effort at all into facilitating local control. Because of that, I'll go on predicting it'll never happen. I dare them to prove me wrong.

I tend to disagree but I may be biased. Maybe I'm naïve and optimistic, but the core complaint here is that Home Assistant users make up a tiny percentage of their userbase and therefore didn't justify the load on the servers. Giving power users local API access wouldn't have any real impact on their ability to monetize functionality. The people who care already aren't willing to pay. Additionally, I can't speak for anyone else here, but my experience has been that power users (IE Home Assistant geeks) are the ones providing purchasing advice to less technically inclined friends and family. In combination with all the other disappointments I've experienced regarding Wyze products, currently when I'm asked for product recommendations I say "Stay away from Wyze, you'll do better just about anywhere else."

That's definitely NOT good for business, and I think giving us local API access and/or callback functionality would be a tiny price to pay to sway my views back into the positive. But, as I said, I'm obviously biased.

I guess you missed yesterday's official Wyze announcement, press release, and video (in the wake of their latest US $100M additional investor funding). They released a video where they literally came right out and said they were losing their asses on hardware sales and that the only way they could keep the company afloat last year (and secure their additional funding) was through their subscription service.

Link to the discussion on Reddit: https://www.reddit.com/r/wyzecam/comments/popyyu/the_future_of_wyze_powered_by_100m_in_funding/

Link to the actual video they released: https://www.youtube.com/watch?v=JMn0tXyL82c&t=1s

The topic we're discussing here is Wyze making it possible for total local control...so that all the traffic is local. If they did that, this wouldn't be impacting their servers at all, so your argument is totally off the mark here. My previous assertion that "I think they've realized they can't rake in the big bucks by reskinning and re-selling other company's hardware on slim profit margins." was so accurate that they literally came out and made a video officially saying exactly that.

[dakahler]

Are you still looking for help on this? Would love to get it closer to working again.

[SecKatie]

Yeah come join us in the IRC if you want to get involved. @yoinx is driving most (all of it really) of the development right now so in order to sync up and not step on any toes please join us on #wyzeapi on Libre.IRC