brendan-w
0100 command late response prevents connecting
I noticed that 0100 command is being sent in elm327.py line 221 in the auto_protocol function.
r0100 = self.__send(b"0100")
I don't exactly how it helps detecting protocol, but when tested in the car, this part of code caused errors. The fact that you have not given any delay(which could be added easily because you defined it in __send as None default), causes the ELM to return "SEARCHING..." for the output. And the result of 0100 get read at ATDPN because of delayed output.(I don't have the debugger output copied, but I confirmed it by examining it in the car.) This causes unexpected behavior which prevented connection in my test. I currently removed that line in auto_protocol, I wonder if adding delay would solve this problem ? And this response delay may cause problems in other parts of the code ? These appeared uncertain to me, so I am adding this as an issue.
FYI: Unfortunately, my time became super limited, and will continue to be for the near future. At the moment, I don't know when I'll get the chance to put actual brainpower into any of my open source projects, but I will try. At the very least, I'm happy respond to questions, but it may be slow-going for a while longer. Not a lack of interest (there's still a ton I want to do to this lib), just a repercussion of a demanding (but cool) job.
But, while I'm here, here's the info for this issue:
Yes, it is necessary. If your setup works without it, it's simply an artifact of having used the adapter on the same car during the last reset cycle. Here's why:
As part of initializing the adapter, we need to know what protocol it will be using to communicate with the car. This influences how we parse responses under the hood. To do that, we put the adapter in auto-protocol mode (ATSP0). But, in order to trigger the auto protocol detection, one must run a command. I chose 0100 because the OBD-II spec guarantees that it will be supported be all cars. After it's sent, the process blocks until the adapter finishes it's protocol scan. This can take a while (on the order of seconds), and it varies from car-to-car. So, under normal circumstances, that self.__send(b"0100") line will only return after the adapter has finished it's scan, and returned a prompt.
But, I'm guessing what's happening is your car is taking longer than expected, and we're reaching PySerial's timeout (currently 10 seconds). This timeout, if reached, will cause the __read() function to return with zero bytes read, and the rest of the code continues. So there's already a "delay" per-se, due to the fact that python-OBD is supposed to block until the adapter returns. If your code is consistently failing at the 10 second mark, then I'd try raising that timeout.
Else, something weirder is happening, and I'd need to see the logs.
Let me know!
I did not know the timeout defined in the port(10 sec) effected the time waited on the response, I thought it was the timeout applied only in the first connection attempt. I manually changed the timeout on that definition, so I must say the issue is caused by me.