Repository navigation
Zoe fixes 2 - #2
Conversation
The Zoe profile reported no range. The EVC answers PID 223451 on 7E4/7EC with the range the car shows, in km, as a 16-bit value in the last two bytes of the reply. This is the PID CanZE reads for the range of Zoe Phase 2 cars (field 654.42), and it sits on the same ECU as the state of charge, so it is one more request on the existing addressing. The new range_km field uses the same byte_index -2 form as battery_level_wh. It reaches aa-proxy-rs through raw_topic; aa-proxy-rs ignores it on /battery. A car that does not answer the PID logs a failed request and the daemon goes on with the next source. Evidence: read from a 2016 Zoe R240, 223451 returned range_km 30 at 24.28 % state of charge and 4990 Wh, which is about 16.6 kWh/100 km. The replay test serves that reply (62 34 51 00 1E) in the Zoe read cycle. Broadcast frame 654, where Phase 1 CanZE reads the range, returned no frames on that car, so it is not used. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
Thanks! The tests pass locally. Two things before merging:
The repository now runs CI on pull requests, so please rebase onto |
Some adapters print a bare '>' right after ATMA and still start monitoring. The scan took it for the end of monitoring and returned after about 40 ms with no frames, so the external temperature was never read. A prompt that arrives before any frame is now ignored; a frame after it shows the ELM is monitoring, so the stop CR is still sent. A prompt after frames still ends the scan, and silence ends it through the idle timeout. In that case the ELM may still be monitoring, so the stop CR is sent; the prompt is not taken for an idle adapter. The scan logs why it ended, how long it took, how many stray prompts and which CAN-IDs it saw, and warns when a stop_when frame never arrived. Each field read from a broadcast frame is logged at debug level like the UDS ones; the raw lines are logged at trace level. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Some values are four bytes long, such as the Zoe trip distance. A field with length 4 is now decoded, unsigned or signed, and scaled in f64, since an f32 cannot hold such a raw value exactly. Validation accepts length 1 to 4 for uds_pid sources; broadcast frames stay at 1 to 2. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
poll_uds_pid sent a source's pre_request before the PID, but poll_uds_pid_multiframe ignored it, so a multiframe source could not open a diagnostic session first. It now sends it after ATH0, with errors ignored as in the single-frame path. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Add three values the original canze-rs read, with the PIDs and scaling checked against a real car log: - trip_km (2233DE, four bytes, x0.0001), sent to /odometer with odometer_km - trip_energy_kwh (2233DD, three bytes, x0.001) - battery_module_1_temp_celsius (2104 on the battery ECU 79B/7BB, byte 4 minus 40, after 10C0; this is the temperature of module 1) The last two go out through raw_topic. The Zoe replay test covers all three with the values from the log. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
both addressed |
No description provided.