5 ms·
Yes, your explanation is plausible. When I thought about it, the best theory I could come up was that they assumed the smartphone would usually be away from th
by jasode 9y ago
Yes, your explanation is plausible. When I thought about it, the best theory I could come up was that they assumed the smartphone would usually be away from the home -- as in, you're sitting at your job and use the remote app to raise the temperature an hour before you commuted home. If that was the common use case, Trane needed a centralized cloud server (like Nexia[1]) to enable that since the wifi thermostat at home would likely be behind an ISP firewall.
smartphone at the office --> cloud --> thermostat home
The problem is that the engineers made the command flow with the cloud as the only method of communication instead of enabling a secondary communication that lets 2 wifi devices talk directly. Obviously, direct wifi communication is technically possible since people buy inkjet wifi printers and their wifi laptops print directly to them every day. People would be livid if they couldn't print their paper just because the internet down or the vendor's cloud server had an outage for "maintenance". The data sent from the computer to the printer does not roundtrip up to the cloud and back down to the printer.
[1] http://www.nexiahome.com/ http://www.nexiahome.com/
- Piskvorrr 9y agoOh, it's theoretically possible all right. I'm not buying any wifi-direct printer ever again, though. (Because, as I said earlier, local networking is hard, and most attempts at it fail miserably - people are livid when their damn printer refuses to print, and they don't give a damn if it's a cloud issue or their computer refusing to play nice with their printer)
- jasode 9y ago>their computer refusing to play nice with their printer Yes, you reminded me of a very good point about local wifi communications: If 2 devices are on wifi, it's easier if both are configured as clients that talk to a 3rd server (such as cloud). When both act as clients, they don't need to know each other's ip address to communicate. The other option of configuring one of the wifi devices as a server is more difficult especially for non-techies. Now, you have an extra complication of discovering the ip address of the printer/camera acting as a "server" to receive commands. This requires a weird dance where the server device has to "broadcast" itself and you have the client computers "find" it. For my Canon wifi printer, I had to press and hold down the power button a certain way so the computer could "discover" it. For my wifi camera, I had to go the DOS prompt and enter an obscure ARP command[1]. The difficulty is compounded when the "server" device has no builtin LCD display so you're basically "flying blind" as to what ip address it got from the wifi router's DHCP. However, the HVAC wall controller has a large LCD display and touchpad so configuring it as a server on local wifi shouldn't be that difficult. [1] https://www.axis.com/ro/en/support/faq/FAQ2551 https://www.axis.com/ro/en/support/faq/FAQ2551
- Piskvorrr 9y agoYeah, that's what I'm talking about two posts up: Shouldn't be a problem, but a large number of unknowns enter into the equation - such as the client AP isolation, where two WiFi client devices don't see each other: the AP just drops packets coming from one destined to the other. The user's network might have this on, and the user may not even be aware of it. Even if thus is OK, finding a server in the local network is not straightforward, even with Zeroconf/Avahi. And those are just a few out of many issues.