robthebold
Well-known member
- Joined
- May 11, 2019
- Messages
- 300
jfran2 said:I find that curious too, that the car's location and state of charge are always spot on, but the commands from the app don't seem to be able to be executed. One would think that if the data can flow one way, it out to be able to go the other.
Unlike people, the physical world -- including the stuff bulit by us humans -- often doesn't respond to our philosophical implorations.
One case is the connecteddrive system, which seems like it should work one way but actually works differently. Requests for the status of the vehicle work like:
(your device) -> ( ( 0 ) ) -> (BMW server) -> ( ( 0 ) ) -> (your device)
(Where ( ( 0 ) ) is the "internet cloud" between devices.)
So that's simple: your device requests the latest status from the BMW server which returns it to you -- and usually quickly and reliably.
What you don't see going on is that the BMW server has been hanging on to that last status value for possibly quite a while. For instance, I just checked my car's status at 6:22. The last update was at 5:34 due to "vehicle shutdown". I checked again at 6:41, and the result was the same. Now the status was, as you say, spot on because nothing has changed since the car shut down. It hasn't moved. The doors haven't been opened or unlocked. It wasn't plugged into a charger. &c. If something like that had happened, it would have triggered a new status update and that new status would then persist at the server until the next change. So then at 6:42, I remotely unlocked the doors (successfully) and checked the status again. Now the status shows "selective unlocked" with an update time of 6:43.
Here's the difference between polling status and sending a remote service command . . .
When you trigger something like remote unlock service, a sequence like this occurs:
(your device) -> ( ( 0 ) ) -> (BMW server) -> ( ( 0 ) ) -> (car) -> ( ( 0 ) ) -> (BMW server) -> ( ( 0 ) ) -> (your device)
This chain of events has several more opportunities for something to go wrong or to timeout. Why this process (of sending commands) isn't more reliable, we can only speculate. Perhaps the BMW server isn't patient enough re: timeouts. Perhaps it gives up too easily and doesn't retry enough on failure. Perhaps the server and car get stuck in a command/response race with retry delays causing messages back and forth to pass each other in transit and result in unknown/unexpected states on one or other end of the transaction.
But anyway, getting the vehicle status is quicker and more reliable than triggering a remote service, since the status "update" is just a matter of requesting the most recently reported values from the BMW server.