I believe @WyzeXiZ is the product manager for the Pan V4., though the user profile indicates they haven’t logged into the forums since December, so they may not see the tag (depending how their notifications are set up).
I would recommend creating a support ticket and asking the agent to forward it on to the engineers/devs.
Since this is practically the same info given out by Settings⇾Device Info, it appears there’s code duplication in the Wyze codebase, and this API call is doing its own thing. I suspect that the dev team turnover at Wyze is so severe that there is no continuity across product lines.
Device Info is showing the correct internal IP address for me, so this is likely different.
I don’t believe that’s the case. I follow a lot of them on Linked-in and they don’t have severe turnover. Do you have any specific data for this?
It’s a little more complex than that. Different products have a lot of differences. Lots of different suppliers, different PMs, different team/devs, different SDKs and authentication routes, different kernals and OS’s (Linux vs FreeRTOS), and coding. Lots of things. A lot of variables.
This is something they should really resolve though since it’s possible this could affect local streaming and access fails, slower or less secure cloud relays, home automation breakage (as is in this case) from Home assistant, node-RED, custom scripts; device discovery and mapping, potential forced cloud dependency issues, firewall and access control issues, debugging and diagnostics issues, breakage and loss of backward compatibility, etc.
My guess is since the IP address shows up in the device info page of the app but isn’t showing in the API call, there may be some kind of API-level Redaction or filtering. They did talk about how they did a lot of new stuff with this model including architecturally, so it’s probably related to attempts at restructuring privacy, security, or other architectural differences and they didn’t notice this effect. Most beta testing users aren’t analyzing API logs. There could also be conditional logic based on the product_model or firmware version or some kind of RBAC set to expose more fields to the app via privileged tokens or internal endpoints or something than to external API Calls. This is pretty common to give the mobile app elevated access. It could be using Relay or NAT Traversal, so the app shows it for convenience while the API omits it because it’s not used for routing, or it may be reporting the IP to the app via a different channel (local discovery or multicast) while the API is relying on cloud-reported metadata.
There are a number of explanations. It just needs to be brought to the attention of the PM or a competent engineer. I’m sure it’s just that they aren’t even aware this is affecting people since things are running well through the app.
That’s exactly my point; it’s different. If the code were the same, that code would be called at different places in the code, and would give exactly the same result.
The fact that the results are different, then the same logic is present in different places, and can get out of sync; exactly what happens here.
I misunderstood your previous comment, my apologies. We agree they seem to be treating the external API call differently than the app. Though it could simply be related to giving the app elevated access rather than duplicate code or one of the other examples I gave. It’s hard to know without access.
I would recommend OP submit a support ticket and then post back here if there is no resolution within a reasonable period. Then I can send that support ticket number to an employee to escalate it and look into it more thoroughly, but they generally like things to go through support tickets first so they can be tracked better.
I tried submitting a ticket. they told me to buy a subscription. totally went over their heads. plus the fact you can’t open a ticket online or at least anywhere I can find is stupid.
to confirm in the app the device info page shows the local IP. the API call does not. which means something is not updating things on the wyze end. I personally feel that’s why the camera is so flaky. I have also seen it not showing an IP on device info and yet on my router it’s connected with an IP and accessible.
definitely very buggy and they are getting horrible reviews on Amazon now.
Thanks for trying to submit a support ticket @bmszero I agree that the person didn’t understand you. Can you give me the ticket number of the interaction you had with the support agent? That should be sufficient for me to be able to ask an employee to review the issue and pass it on to the applicable Dev team to look into.
I just did some googling and found through the AI chat bot you can open a ticket so I did that and provided detail specific to this issue. It is 4533239. In the old ticket the tech again said they would give me some money back bc the new cams dont have the feature the old cams gave for free. My question was what was I getting for free? I have literally never had a subscription to anything free or otherwise. So not sure what she is talking about. Anyways, that ticket I gave you should suffice. And the reason I am pushing this is bc some automations make API calls and get the local IP and then interact with the camera. Without that call working, 10,500+ people who download the integration are broken for new cameras. I forked the github project and tried to work a fix but it all comes down to the API not returning the proper data like it does with every other camera.
All my cams have DHCP reservations just to make it easy to keep track of - is that not an option here? if the IP never changes is there a need to query it? The DHCP reservation gives it an entry in DNS using whatever hostname you want.
This should be the case and has been my experience. They used to have this nice full-page ticket submission form on the Support site, but for the past year or so it’s been necessary to use the abbreviated form that the chatbot serves up, and then the first response you get after creating a ticket is from the “Wyze-E” AI gatekeeper, which frequently misinterprets the actual problem. I usually wait until I’ve seen that message and then use the opportunity to describe the issue in detail in e-mail when I reply to that. At that point, the correspondence proceeds with human agents.
Dave I don’t think u have a good grasp on networking. Your router assigns a static IP if u choose or defaults to DHCP which assigns dynamic ip. some cameras allow you to specify a static ip. wyze does not. and as said a few times this is an API call to wyze which is not returning the IP as other camera models do. I know why they are doing it. it breaks people’s ability to automate at home locally without a subscription. even with a subscription it still doesn’t work.
I’ve been a network engineer for over 25 years, so I think I know the basics.
Your router allows you to set a DHCP reservation so that DHCP always assigns the same IP to the camera and even gives it the hostname of your choice in DNS. While not every consumer router in history has offered this, it has been many, many years since I’ve encountered one that doesn’t have it, even ISP ones.
If your camera IP never changes and you can even assign a friendly hostname to it, my question is do you really need to poll the camera for its IP ever?
I don’t even need to know the IPs of my cameras but I use reservations to keep them in a certain range for organization (as I do with most of my devices) and also so I have a name I recognize in DNS rather than “Wyze-35nnfjsba35”
No router sets a static IP, that’s only possible to do on the device itself (which as you say, Wyze does not support). If a DHCP server detects that an IP is in use and it didn’t assign it, the router will often report it as “static” but that’s just an assumption on the router’s part.
That’s not the function of this API. Look elsewhere. It’s not polling at all. Calling a piece of code isn’t necessarily polling; it depends on what the caller is doing.
For this particular API call, it’s only done once per camera.
There was I believe a case where another 3rd party software was called out for polling the Wyze servers too much. Don’t confuse it with this API call. That’s a different case, and a different API call.
