New UI: Nissan Leaf Charging "203 Unsupported Operation" error: cannot set SoC via UI

[glynhudson]

I love the new UI, I've been using it for the past week or two.

The main issue I've had is that I get a "203 Unsupported Operation" each time I open the charging page and the SoC limit and range limit functions don't work. Previously, they used to work on the old UI, the LEAF integration supports this. If I try to enable a Soc limit then each time I revisit the Charging page the SoC limit is disabled again.

This video show's the error and illustrates the issue:

XRecorder_20250204_01.mp4

Another minor issue with regarding charging is the charging power is shown as a negative number. I understand why this makes sense if positive power is discharge, however I think many users will find the negative power display quite disconcerting! The old app used to display positive charging power.

Another minor issue which is not directly related to the new UI is that the Nissan Leaf (and all other vehicles apart from roadster) does not support varying the charging current. Ideally this option would be hidden, or at lest less prominent to avoid user confusion.

[dexterbg]

Renault Twizy & VW e-Up (with T26 connection) also support varying the charge current, but you're right, the App should know which vehicles support this and adapt the UI accordingly.

[dexterbg]

Just had a look, setting the charge current is also possible with the Bolt EV, the Volt/Ampera, the Smart ED and Zeva based vehicles.

[glynhudson]

Hi, have you been able to replicate the 203 Unsupported Operation error? It's still present in the latest version. I'm unable to adjust the SoC limit via the app, but setting the SoC limit via the web-interface works fine:

[dexterbg]

This isn't a pure App issue. Collecting the parts from the @developerfromjokela pull request discussion:

About the eUP charging config, it would be nice if OVMS3 could handle command 203 for querying the info like twizy does. I've implemented on my own fork this support for Leaf. I can make an exception for eUP to query 204 instead.

The MP API command range 200…255 is reserved for vehicle specific commands, the Twizy allocation is documented in the V2 versions "OVMS-UserGuide-RenaultTwizy.pdf" (around page 72).
But you're right, something similar with generalized semantics would be nice, as the standard commands do not provide this yet. Standard command 16 could be extended for the setter, but a query command is missing. For the standard commands, see: https://docs.openvehicles.com/en/latest/protocol_v2/commands.html

Yup, it would only make sense to create a standard command in future.

It requests command 203 every time user open the charging page. The solution is not optimal, but it's mainly needed for querying charge stop mode, which doesn't come in car data. If you check my repo, I've implemented 203 for eUP. If that could be patched in main repo, I see no issues.

TL;DR: we need to implement a generalized version of the Twizy custom commands 203/204, or add the sufficient charge stop mode to the V2 protocol's "S" message, or best both I guess. That also means making the sufficient charge stop mode a general framework feature now, which also will affect all vehicles currently supporting that.

The App would still need to fall back to the old procedure for OVMS V2 module users, as there are still quite some. So basically the App still needs to switch the query approach based on the vehicle type and firmware version.

[developerfromjokela]

This isn't a pure App issue. Collecting the parts from the @developerfromjokela pull request discussion:

About the eUP charging config, it would be nice if OVMS3 could handle command 203 for querying the info like twizy does. I've implemented on my own fork this support for Leaf. I can make an exception for eUP to query 204 instead.

The MP API command range 200…255 is reserved for vehicle specific commands, the Twizy allocation is documented in the V2 versions "OVMS-UserGuide-RenaultTwizy.pdf" (around page 72).
But you're right, something similar with generalized semantics would be nice, as the standard commands do not provide this yet. Standard command 16 could be extended for the setter, but a query command is missing. For the standard commands, see: https://docs.openvehicles.com/en/latest/protocol_v2/commands.html

Yup, it would only make sense to create a standard command in future.

It requests command 203 every time user open the charging page. The solution is not optimal, but it's mainly needed for querying charge stop mode, which doesn't come in car data. If you check my repo, I've implemented 203 for eUP. If that could be patched in main repo, I see no issues.

TL;DR: we need to implement a generalized version of the Twizy custom commands 203/204, or add the sufficient charge stop mode to the V2 protocol's "S" message, or best both I guess. That also means making the sufficient charge stop mode a general framework feature now, which also will affect all vehicles currently supporting that.

The App would still need to fall back to the old procedure for OVMS V2 module users, as there are still quite some. So basically the App still needs to switch the query approach based on the vehicle type and firmware version.

Standardising that would be beneficial indeed. For OVMS 2 just need to add the exceptions if necessary?

[glynhudson]

The SoC limit is still not working for LEAF via the UI.

A workaround is to use command config set xnl suffsoc 80 to set SoC 80%

[developerfromjokela]

The SoC limit is still not working for LEAF via the UI.

A workaround is to use command config set xnl suffsoc 80 to set SoC 80%

The firmware update necessary for the UI to work is in PR openvehicles/Open-Vehicle-Monitoring-System-3#1188. The UI is functioning correctly, the command is just missing from current release

[glynhudson]

Ah cool, great stuff!

[umbjm1]

I've also had setting the SoC fail with the updated Android app and my 2015 US Leaf S.

The only update showing as available in my web interface is the installed 3.3.003, which seems to be from 2022. How do I get the newest one? It's not clear how to proceed from the link to issue #1188.

I did the web update using the web interface, specifying http://api.openvehicles.com/firmware/ota/v3.1/main/ovms3.bin, which was just updated in December.

A window popped up, showing the downloading and updating. All seemed fine. I rebooted.

The good news is that the app is now able to limit SoC. However, there was no change in the current or available firmware version shown in the web interface. What am I missing?

[dexterbg]

You need to replace "v3.1" by "v3.3", and "main" by "edge" to get the latest build.

[umbjm1]

Thanks!