Closed Mike7Chu closed 2 years ago
Yeah, makes sense. If you want to PR something that's fine - should be easy enough.
As a workaround, there's no reason you need to let the constructor handle activation. My original intention was for more complicated situations like this you'd set activation_type = None, and then call request_activation() manually with any customization or preconditions already satisfied (for instance, if you need to toggle the physical activation line using some other API).
If you want the library to take care of it automatically (like for auto-reconnect), probably just add a constructor argument called something like
activation_type_vm_specific=None
Store it on the object, and pass it into request_activation wherever we do now (reconnect and constructor).
Thanks for your reply. I'll try to change activation_type. :)
I tried to connect to a vehicle as DoIP interface with this library. And It didn't work Rotine Activation at below code.
The issue show "ConnectionRefusedError: Activation Request failed with code 0". It means the header is wrong. The root cause is vm_specific=None. In ISO-13400-2, vm-specific is optional. But some vehicle have the specific, It need to vm_specific data. So I want to change vm_specific=ecu_vm_specific.