Soko, you can currently define up to four poll state times, but you don't need to, if you don't use them (compiler fills remaining with zero). The poll state to use is under vehicle control, as you already saw. Poll state numbers do not have fixed framework semantics (the comment in my example is just an example). Btw, you also don't need to restrict your polling to just one list, you can use PollSetPidList() to switch lists as well -- see OvmsVehicleRenaultTwizy::ObdRequest() for an example of how to use this to implement a single manual poll for a command. Regards, Michael Am 26.07.20 um 09:22 schrieb Soko:
Hello,
Thanks heaps. There is now way I could have figured this out by myself. I will give your values a try asap.
You did only 3 entries for the polltime though... As far as I could see there are 4 which correspond to the possible parameter values for PollSetState(...);
Looking at the other vehicles I haven't seen any automatism the PollState is set by the framework. One vehicle uses 0-3 for (off, on, moving, charging). So I have to change the Poll-State manually in my vehicle implementation, correct? In different words: When I only call PollSetState(0); (for early stage testing) the polling uses only the first polltime-value. Doesn't matter if the car os off/on/...?
thx again
Soko
On 25.07.2020 20:45, Michael Balzer wrote:
Soko,
0x22028C isn't a PID, it's an OBD2 command (0x22 = poll extended ID) + the actual register address 0x028C to be polled.
And 0x7E5 isn't a header, it's probably the address of the OBD2 device you're polling (txmoduleid) OBD2 is a subset of ISO-TP, in ISO-TP devices can be addressed at any ID and respond at any ID. The OBD2 base protocol defines a broadcast address at 0x7DF, and assigned device addresses in the range 0x7E0 - 0x7E7. Replies shall be sent at the device address + 8, so the reply for a poll to 0x7E5 would normally be coming from 0x7ED (rxmoduleid).
That are the basic principles of the OBD2 protocol, see https://en.wikipedia.org/wiki/OBD-II_PIDs#CAN_(11-bit)_bus_format .
So your poll could for example be defined as:
const OvmsVehicle::poll_pid_t vwup_poll[] = { // Note: poller ticker cycles at 3600 seconds = max period // { txid, rxid, type, pid, { period_off, period_drive, period_charge } } { 0x7E5, 0x7ED, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x028C, { 0, 10, 60 } }, { 0, 0, 0, 0, { 0, 0, 0 } } };
See vehicle.h for OBD2 commands (poll types) currently supported. See the other vehicles for examples of complex poll definitions.
Regards, Michael
Am 25.07.20 um 20:09 schrieb Soko:
Heya,
Another thing I can't figure out at the moment. I have to poll the VWeUp and I figured out (hopefully) how to do that. But I have no clue how to translate the "usual" ELM327 Header+PID to one entry for the OvmsVehicle::poll_pid_t
The only value I've understood is the polltime. On my OBD2 interfaces I use a PID of 0x22028C for SoC. But PID is here only 16 bit! Where do I put the header 7E5? What is txmoduleid and rxmoduleid?
I can't believe that I'm the first one with this issue ;) Couldn't find any doc though :(
So I'm very thankful for any pointing in the correct direction/doc/example.
thanks
Soko
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26