Current values in controls

[PedroKTFC]

I've learnt today that it's possible for controls to include the sensors they are controlling to give their actual state. So, for example, the climate switch can use the climate sensor to tell the climate current state. Thus, in the device info page, it will show the current state in the controls section and only give you the option to change it to its opposite state (so if it's on, you can only switch it off). The actual on/off actions will still be available. Similarly, the charge current and charge limits could use their current values.

When you change a value/state, the value/state will change accordingly. There is a delay to this change as the car is polled and the new value/state determined. For a short while it might look like the change hasn't worked.

Personally I think this is definitely better despite the short delay. But before I make this change, I want to canvas people's opinion. There shouldn't be any backward incompatibility issues other than the display looking slightly different.

[lukej0]

I would totally love this

[funnyfrish]

İ would love this when the state and control are in the same entity. Great work

[pvmil]

I like it, it simplified the UX, it will cause a breaking change but certainly willing to make the change.
You ready own the development, big steps made over the last weeks, thanks

[PedroKTFC]

I don't think it will be a breaking change as the switches will always have their control actions. The sensors will also always be present. The UI for the binary devices will look a little different but that should be all.

[top-gun]

100% for it. :)

[PedroKTFC]

Based on what seems to be unanimous feedback, I've updated dev so the controls that have corresponding sensors use them for their current values. These are:

• climate
• charge port door
• charge limit

No other control has a corresponding sensor at the moment. I'll slowly add more sensors and add them to their controls.

You'll see that with the binary controls, if you click to change the state, the control echoes what you did but very quickly after reverts to the old state. That's because the app has to send the request to the car, wait for its response and then update the sensor. So shortly after reverting to the old state the control flips to the state you requested (assuming it all works of course). It would be good if I can find a way to delay the feedback to mask this.

Oh, and I've also added a control to vent and close the windows. I use this a lot to cool the car down before I get in the car.

I'm going to pause here to get some feedback in case there are any issues. If all goes well, I'll promote to main in a day or so.

[top-gun]

Based on what seems to be unanimous feedback, I've updated dev so the controls that have corresponding sensors use them for their current values. These are:

• climate
• charge port door
• charge limit

No other control has a corresponding sensor at the moment. I'll slowly add more sensors and add them to their controls.

You'll see that with the binary controls, if you click to change the state, the control echoes what you did but very quickly after reverts to the old state. That's because the app has to send the request to the car, wait for its response and then update the sensor. So shortly after reverting to the old state the control flips to the state you requested (assuming it all works of course). It would be good if I can find a way to delay the feedback to mask this.

Oh, and I've also added a control to vent and close the windows. I use this a lot to cool the car down before I get in the car.

I'm going to pause here to get some feedback in case there are any issues. If all goes well, I'll promote to main in a day or so.

Seems to work for me. It compiled just fine, after waking the car data arrives and the switches initialize with good data.

The related sensors are readable like before so I don‘t expect this to break any automation.

[PedroKTFC]

I'm puzzled why your controls aren't like mine unless you're picking up a slightly older cache:

[top-gun]

I'm puzzled why your controls aren't like mine unless you're picking up a slightly older cache:

Hm. I recompiled, this time I forced everything to the latest git commit. It‘s obvious that „boot“ is missing. Even restarted the server os, no change.

Was there some addition to the yaml that I missed?

[PedroKTFC]

You're clearly picking up an old version of client.yml despite all the @s. I've tried in my other system (which doesn't connect to the car so I can't fully test it) and also found it hard to get the right version. In the end, I had to use the full SHA for the version I wanted:
client: github://PedroKTFC/esphome-tesla-ble/packages/client.yml@a267d6710d01869c5a3bfe27bc36440f7c5181fc
while #dev worked for everything else (hopefully #dev will be working fully soon). Note I no longer have the dashboard_import: lines in my yaml.

The caching by github is extremely frustrating!

[top-gun]

You're clearly picking up an old version of client.yml despite all the @s. I've tried in my other system (which doesn't connect to the car so I can't fully test it) and also found it hard to get the right version. In the end, I had to use the full SHA for the version I wanted: client: github://PedroKTFC/esphome-tesla-ble/packages/client.yml@a267d6710d01869c5a3bfe27bc36440f7c5181fc while #dev worked for everything else (hopefully #dev will be working fully soon). Note I no longer have the dashboard_import: lines in my yaml.

The caching by github is extremely frustrating!

Using the SHA hashcode definitely helped!

I'm in the office so I can't get data, but via VPN I was able to recompile and see that I have new entities - "boot" is prominent because it's at the top and finally it's there. Hallelujah!

If that didn't help, my next step would have been to create yet another 1:1 branch in my own repo and point all references to that repo. Usually, that will fix things, but it's not a solution that scales out to everybody.