WiCAN-OBD at home and on the road

[rbauman70]

After purchasing my new-to-me 2024 Kona Electric, I wanted to integrate it into my smart home setup. I had a couple of goals in mind:

1. Get the vehicle's state-of-charge into Home Assistant and EVCC so I could optimize charging with my solar panels,
2. Get live vehicle data for use with A Better Route Planner (ABRP) during road trips, and
3. Monitor the car's 12V battery which is an Achilles Heel on some Hyundai EV's, maybe mine.

It looked like the WiCAN-OBD was a good solution for 1). Although I have Bluelink for a cloud-based connection to the Kona free for a year, I try to minimize my cloud-based dependencies. I didn't need the extensive features and protocols of the WiCAN-PRO and I thought the WiCAN-OBD supported ABRP as well (it doesn't). Turns out the ABRP compatibility issue was a feature for updating the web site with data, not providing live data via Bluetooth Low Energy (BLE) when using the ABRP app in the car. It's also only in WiCAN-PRO version firmware for now.

I was able to get the WiCAN-OBD connected to Home Assistant via Wifi easily with Jay Oswald's very nice WiCAN Home Assistant integration. This requires "AP+Station" mode in the WiCAN.

With BLE enabled in the WiCAN, the ABRP app couldn't find the WiCAN dongle while attempting to link to live data. The nRF Connect app showed a very minimal BLE advertisement from the WiCAN. I had to get more information from the WiCAN, so I setup the ESP-IDF development environment, cloned the main WiCAN-fw branch and built the WiCAN firmware with logging enabled. After comparing ble.c with the version on the wican-pro branch, I decided to use the wican-pro's version since its BLE advertisement was much more extensive. I only had to disable a few references in ble.c (cmdline, tx power control) to compile the newer version. Now the ABRP app was able to find the WiCAN dongle during its BLE link scan. ABRP would connect but fail looking for an ELM327 AT command response.

While logging the ABRP requests in the elm327.c module, I noticed that the ABRP was sending standard PID requests (01h 00h) without a carriage return terminator that the elm327 code was expecting. Adding the following to elm327.c at the beginning of elm327_process_cmd allowed ABRP to connect to the WiCAN successfully.

#ifdef ABRP_BACKPORT
    /* ABRP does not append a CR to PID requests for standard PID's (00h to 09h). Append one here. */
    if ( cmd_len > 0 && cmd_buffer[0] <= 0x09 )
    {
        buf[len++] = '\r';
    }
#endif

This assumes that all ABRP commands are atomic, but I didn't see any evidence otherwise.

Setting the WiCAN to use BLE requires changing the mode to "AP" from "AP+Station" and enabling BLE. It's done through the WiCAN web interface which means I'd have to bring up a browser each time I was leaving or returning home. Instead, I implemented a toggle switch on GPIO1 for the two modes--home and away. GPIO1 is one of the I/O pins brought out to the 2x5 header on the WiCAN board. I implemented a routine in config_server.c modeled after other set_config routines that sets the objects in the config file for the desired mode and forces a reboot.

void config_server_set_home_config( home_mode_t mode )
{
    switch ( mode )
    {
        case HOME_MODE:

            if(strcmp(device_config.wifi_mode, "APStation") == 0)
            {
                ESP_LOGI(TAG, "Already in home mode.");
                return;
            }
            break;

        case AWAY_MODE:

            if(strcmp(device_config.wifi_mode, "AP") == 0)
            {
                ESP_LOGI(TAG, "Already in away mode.");
                return;
            }
            break;

        default:
            ESP_LOGE(TAG, "Unhandled mode: %d", mode);
            return;
    }

    cJSON * root;
	root = cJSON_Parse(device_config_file);

    switch( mode ) {

        case HOME_MODE:
            cJSON_SetValuestring(cJSON_GetObjectItem(root,"wifi_mode"), "APStation");

            cJSON_SetValuestring(cJSON_GetObjectItem(root,"protocol"), "auto_pid");

            cJSON_SetValuestring(cJSON_GetObjectItem(root,"ble_status"), "disable");

            cJSON_SetValuestring(cJSON_GetObjectItem(root,"mqtt_en"), "enable");
            break;

        case AWAY_MODE:
            cJSON_SetValuestring(cJSON_GetObjectItem(root,"wifi_mode"), "AP");

            cJSON_SetValuestring(cJSON_GetObjectItem(root,"protocol"), "elm327");

            cJSON_SetValuestring(cJSON_GetObjectItem(root,"ble_status"), "enable");

            break;

    }

    const char *resp_str = cJSON_Print(root);
	ESP_LOGI(TAG, "resp_str:%s", resp_str);
	FILE* f = fopen(FS_MOUNT_POINT"/config.json", "w");
	if (f != NULL)
	{
		fprintf(f, resp_str);
		fclose(f);
	}
	xTimerStart( xrestartTimer, 0 );
	free((void *)resp_str);
    cJSON_Delete(root);
}

Now I only have to toggle the switch on the dongle when leaving or arriving.

I 3D-printed a small case to hold the WiCAN PCB and switch.

Sometimes if I don't switch out of home mode and return home, the WiCAN doesn't reconnect to my home Wifi, but by in large the implementation is working well. Many thanks to the MeatPi folks for putting what is obviously a huge effort into developing the WiCAN hardware and firmware. Keep up the good work!

For 3) I decided to use a BM2 battery monitor. I have an ESP32 in the garage that periodically queries the BM2 and posts an alert if the voltage drops too low.