Panda88

It may take a little time to propagate If you want to test the mobile App - I would reinstall in new slot If just using AC - I would just upgrade - it should work - it is difficult for me to test as I do not have an EV to test

Released a new beta 0.1.33 - give it a try - I think it is close Data will remain when EV is asleep or offline (time since last update and state is updated) Fixed some bugs Will try 2 times for commands if first fails (seems to be issue with old cars) There may be an issue with Mobile App - some results shows numbers than text - may be fixed but cannot test it easily - may need to install in new node address

It was a bug in reporting - control updated the state automatically - It is only when something else controls the outlet this happens (i.e. someone presses the local button)

Found a bug - try 1.2.5 just released

@someguy Can you send me a debug log file on the honk horn command that takes 2 tries - I can hopefully fix it to only need 1

It is similar - the car will push the data to the server (either at Tesla or at UD) and the ISY will query the server - It is what is happening now, but there are limits on number of calls to retrieve data (to limit bandwidth at Tesla) - the external server would not have these limitation Currently the poll for more data is API call limited, so fewer updates will happen I think commands count would still be limited, but I do not know for sure. Tesla offers a prototype server to install, but I have not looked at it

Currently - short poll updates data if car is on-line, long poll tried to wake the car and then fetch data, so users can play with these numbers. Tesla does offer an option to have an external server running to collect data and users would then poll this - data would automatically upload from the car once online. However, this will require the UI team to implement and maintain this server - probably depends on number of requests for this - it should be the most energy efficient solution as data only uploads when car is on line Naturally one would be able to wake the car to get it to push data - I assume this is silimar to the tesla approach. Another benefit is there would be no limits on API calls

@someguy Do the commands work in your setup - I think you have an older car that does not support virtual keys. Please let me know as I expected to have to have special code for this case, but maybe Tesla handles this on their side How would you expect the automation to work when car is offline - I assume there will be no triggers as data does not change. Time since last update should show how old the data is, but I still do not see the use of old data in context of automation Again, I am open to change the behavior if people request it

It is default operation at this point when car is offline (not asleep). I could change it to show last data but in my mind that is not useful either. I would wake the car if it shows offline I am open to change it asi am not sure how the border is being used

Is the car online?

i'll try to find where it is in the documentation - Can you send me a log file when you say try to honk horm - maybe it will say something about how to identify if car can support virtual key or not and what to do in that case

Gary From log 2024-10-19 22:32:22.008 Command udi_interface ERROR TeslaOauth:_callApi: Call POST https://my.isy.io/api/tesla/api/1/vehicles/5YJSA1E53PF518311/command/honk_horn failed: 500 Server Error: Internal Server Error for url: https://my.isy.io/api/tesla/api/1/vehicles/5YJSA1E53PF518311/command/honk_horn 2024-10-19 22:32:22.008 Command udi_interface DEBUG TeslaEVOauth:teslaEV_HonkHorn: teslaEV_HonkHorn unknown - {"response":null,"error":"vehicle rejected request: your public key has not been paired with the vehicle","error_description":""} Looks like the virtual key registration did not work - did you try to open site https://tesla.com/_ak/my.isy.io on your mobile device

Hopefully this help on basic operation. We can look at commands next

Did you register the Virtual key. No commands can be sent without if you have a recent car

I do not understand how you can add the token - it should not be needed anymore. You should just click the authenticate button when it shows (on top of node) and you will be taken to a login site at Tesla. It is possible your car is so old that the virtual key is not supported (there is a limit). My guess is I can send commends directly without the need for 2nd layer of encryption but I do not know We can give it a try once you have the basic node working (be able to see data from car) PM me a log file and maybe I can figure something out

i think you can use the alarm to trigger your function - i.e. have Yolink report an alarm if power > 2KWh and then trigger on that . I wonder if there is a bug in the ISY on how to compare numbers - maybe I need to make it report W and not kW.

Did you try to use yolink power limit to see if it triggers. I would guess that to trigger faster. My guess is yolink just treats power as data so it follows the update sad chedule for the device. Note if you start polling to fast they will throttle the access I think using the alarm in yolink is the way to go I do not understand why it would not trigger but it could be resultatet to unit conversion in isy

Can you send me the log as a file - you can pm me

There is a beta version in the non-commercial node store to try udiTeslaEV2 I believe the controls work now, but have not been able to test (as I do not have an EV). I requires PG3x Please let me know of issues and incluce a log file for debugging purposes To enable commands a electronic key needs to be installed on the car Got to https://tesla.com/_ak/my.isy.io on you mobile device - this should open the tesla moble app and you can then apprive the installation of the key (I have not personally tried this so I do not know what it will look like)

I have not tried the specific use but it should work - the plug reports power and you could even use the Yolink alarm for power to create triggers in case the power reading does not work There is room for a normal plug in the second outlet if needed

Still working on it - we have a server now by Universal devices that helps send the commands - it is not stable yet, but it is making some progress - we can send a command some times

I tried my water sensor and over night it went offline - as expected - It may work now - there is no difference between sensors as they call the same functions (assuming the YoLink API acts the same)

If it happens again save the log. It should be possible to debug - it is always a guess when the API is not fully documented. I can try to pull a battery in one of my sensors to see if I can see a change

Can you send me the log file - you can message it to me Did you make sure there is no space at the end of the UAID and Secret Key Just to be cleat - the node shown is the PG3 node (to show it state) - it is not the HUB = there is no node for the hub as it offers no functionality - there are no Yolink devices imported

I got a little more info - they use special channels in the APP (not available to the API) From support: I'd like to clarify the difference in detection speeds between the app and the API. Direct Device-App Communication The app communicates directly with the cloud platform in real time via optimized channels, allowing it to receive data almost instantly when a LoRa device transmits a signal. This is further enhanced by the use of push notifications, which are highly efficient in delivering updates immediately. API Request and Response Overhead On the other hand, API interactions rely on a request-response mechanism, which can introduce minor delays. This includes the time needed to: Establish an HTTP connection. Send the request. Wait for the server to process and respond. Handle authentication and authorization processes. These steps can cause slight lag. API Rate Limits and Throttling In addition, our API is subject to rate limits to ensure fair usage across all users. Specifically: A single UAC is limited to 100 API calls within a 5-minute sliding window. A single target device can receive no more than 6 API calls per minute, with a minimum interval of 200 milliseconds between calls. These restrictions help manage overall performance but may cause delays in scenarios requiring frequent updates. I hope this explanation clarifies the differences. If you have any further questions, feel free to reach out. Best regards, Thomas | YoLink Customer Support