Hi,
Thanks for your kind words 
As I don’t have the HomeyPro23 it’s hard for me to understand your request.
If you know about an App that has done something like you request, I can probably contact the developer and get some help implementing it.
Cheers 
Rune
I think there must be some answers here. Sorry, I’m trying to help you as best I can, but I’m not a developer and I’m having trouble knowing what to look for.
same here. Or we are doing something wrong?
Hi @Roy_PEDRINIS,
I’ve looked through the SDK and I can’t find anything else to add. Are you not getting any data on the “Energy Screen” or don’t you have the screen, what are you missing that you feel needs to be added ?
Cheers,
Rune
The schematic diagram is missing vehicle detection and the addition of a dedicated beacon for electric vehicles.
I think this information will be useful:
Thank you so much 
EV chargers
EV chargers are devices that can be used at home to charge EVs. When creating a driver for an EV charger, apply the device class evcharger and set the evCharger property in the energy object of the driver. EV chargers should have the measure_power capability. This represents the real-time power consumption of the EV charger in Watts. This value can be positive and negative.
Positive when the EV charger is charging the connected EV.
Negative when the EV charger supports bi-directional charging and is currently discharging the connected EV.
To accurately reflect the charging state of the EV charger add the evcharger_charging_state capability. This allows the user to easily see the state of the EV charger and act on state changes like “EV is plugged in”.
Finally, to allow for easy control of the EV charger add the evcharger_charging capability. This capability acts like the on/off switch with regards to charging, and automatically generates useful Flow cards like “Start charging” and “Is charging”.
To enable Homey to distinguish between the charged and discharged energy of the EV charger, the driver should define the meterPowerImportedCapability and meterPowerExportedCapability energy properties, as shown below.
Imported energy refers to the energy charged by the EV charger.
Exported energy refers to the energy discharged by the EV charger.
These properties should be assigned to the corresponding capabilities of your device responsible for measuring charged and discharged energy. If your device does not support discharging just omit the meterPowerExportedCapability property.
/drivers/<driver_id>/driver.compose.json
Copy
{
"name": { "en": "My Driver" },
"images": {
"small": "/drivers/my_driver/assets/images/small.png",
"large": "/drivers/my_driver/assets/images/large.png"
},
"class": "evcharger",
"capabilities": [
"measure_power",
"evcharger_charging",
"evcharger_charging_state",
"meter_power.charged",
"meter_power.discharged"
],
"capabilitiesOptions": {
"meter_power.charged": {
"title": { "en": "Charged Energy" }
},
"meter_power.discharged": {
"title": { "en": "Discharged Energy" }
}
},
"energy": {
"evCharger": true,
"meterPowerImportedCapability": "meter_power.charged",
"meterPowerExportedCapability": "meter_power.discharged"
}
}
The evCharger property and the evcharger_charging and evcharger_charging_state capabilities are available as of v12.4.5.
EVs
EVs are battery electric cars. These cars can be charged by an EV charger. When creating a driver for an EV, apply the device class car and set the electricCar property in the energy object of the driver.
EVs should have the measure_battery capability which represents the current state of charge of the battery. Additionally, the ev_charging_state capability should be added when the EV can report its current charging state (plugged in/out, charging, discharging).
/drivers/<driver_id>/driver.compose.json
Copy
"name": { "en": "My Driver" },
"images": {
"small": "/drivers/my_driver/assets/images/small.png",
"large": "/drivers/my_driver/assets/images/large.png"
},
"class": "car",
"capabilities": ["measure_battery", "ev_charging_state"],
"energy": {
"electricCar": true
}
}
The electricCar energy property and ev_charging_state capability are available as of Homey v12.4.5.
Hi
Could be that the changes you are looking for is coming with the newly released v12.4.5. As soon as it gets installed on my homey I can add the bits that comes with the version.
Cheers
Rune
Hello, ok, perfect, thank you very much. In any case, my homey has just been updated this night, so I think it should soon be the same for you. Thank you and I await your response.
Hi,
I’ve published a test version v1.11.0-test that supports the latest changes from Homey v12.4.5.
Please let me know if the changes work and I hope are the changes you are hoping for.
Cheers,
Rune
Hi,
New patched v1.11.1-test is out.
Added better support for the new state evcharger_charging_state.plugged_in_paused.
Cheers
Rune
Perfect, thank you very much. I just downloaded it. I’ll get back to you by the end of this week. Thank you in any case for your follow-up and involvement.
I just tested it and everything works perfectly. Thank you very much for your work, your responsiveness and your listening skills
Hi,
v1.11.1 is now live.
Thank you all for helping out verifying the changes 
Cheers
Rune
Today the data for isConnected is incorrect (tested using the “AND-card” “Is connected”, and calling the card from HomeyScript). It says that the TWC Gen3 isn’t connected to the car. Also, when examining the device, it states that the contactor is open since 8 hours, which I interpret that it isn’t connected.
However, it is connected and the Tesla app shows it’s connected. I went out to the car and disconnected the charge, and then re-connected it. No change.
Does anyone have any idea what I’m doing wrong?
Hi,
Could be timeouts from the TWC that are causing your issues.
There are servere times I’ve experienced timeouts from the APIs:
When this happens you can check with a browser if this is the case by going to http://IP/api/1/vitals
There is a setting under in the app «Update frequency» I’ve experienced that when it’s about 60sec or more everything seems to run smoothly.
Cheers
Rune
I think I’m the one doing something wrong here. Easy to blame the system for timeouts, but I’m not sure that’s the problem… my code is:
async function isCarConnectedToCharger(){
isConnected = await Homey.flow.runFlowCardCondition({
id: "homey:device:9d433210-d15d-480a-99b6-849a6a648fa1:is_connected",
args: {}
})
.catch(err => {
log('error:', err);
})
.then(res => {
log("res:" + res.result);
return res.result;
});
log("isConnected:" + isConnected);
return isConnected;
}
It logs:
res:false
isConnected:false
And when calling the api for vitals, I get:
{"contactor_closed":false,"vehicle_connected":true,"session_s":36605,"grid_v":233.3,"grid_hz":49.978,"vehicle_current_a":0.5,"currentA_a":0.0,"currentB_a":0.4,"currentC_a":0.5,"currentN_a":0.8,"voltageA_v":0.0,"voltageB_v":0.0,"voltageC_v":3.3,"relay_coil_v":11.9,"pcba_temp_c":23.6,"handle_temp_c":17.7,"mcu_temp_c":33.1,"uptime_s":775215,"input_thermopile_uv":-418,"prox_v":0.0,"pilot_high_v":8.7,"pilot_low_v":-11.6,"session_energy_wh":0.000,"config_status":5,"evse_state":4,"current_alerts":[],"evse_not_ready_reasons":[1]}
which says vehicle_connected:true
What am I doing wrong?
Consulting ChatGPT, it suggests that I use the vitals API directly. But it feels wrong - when you’ve made a good and easy Homey app, I should take advantage of it and use that instead!
async function isTeslaPhysicallyConnected() {
try {
let response = await fetch('http://10.17.29.22/api/1/vitals');
let data = await response.json();
log("phys_connected:" + data.vehicle_connected);
return data.vehicle_connected;
} catch (err) {
log('Error fetching vitals:', err);
return false;
}
}
Hi,
When calling isConnected the app uses cached data, normally the cache is 60seconds. I can do a change to the app where the isConnected and isCharging does a direct call to the TWC, to see if that helps your issue.
Cheers
Rune
Sure, we could try that. If the error is in the caching.
Hi,
I’ve published v1.12.0-test where I’ve updated the isConnected method to return the vehicle connection status directly.
Cheers
Rune
