Panda88

Just a quick update on the local support for YoLink using hub YS1606 It is working well so far - I have a device that appears offline with the new hub (IRremoter) - it works if I move it to cloud (the node allows both ways of operation)- but get off-line replies once in a while even in that scenario It appears to be transparent if operating local or via cloud from the node perspective. I could release a beta version if there is interest, but it seems the hub is not fully released yet Let me know if there is interest in a beta

The new streaming node server for Tesla EVs have been released as a 90 day trial to the main (production) store The node uses streaming services, so the EV only sends data to the node when the data changes. Given this there is no need to poll data, and as a result there is less battery drain on the EV. Short-poll (5min default) sends a heartbeat and updates the EVs connection status (online, asleep, offline etc). Long-poll (2 hours default) check and updates tokens required to maintain the connection. A few more data fields have been added, and sentry mode control is now supported. It is expected that existing nodes will need to move to this node/model, as this is the preferred use model by Tesla. If more data is desired, check the list of available data at Available Data | Tesla Fleet API and request it to be added

I did post a new version to fix it

I think you are correct that something is wrong - It is a raw number from the API - it may be reporting in BAR and not PSI- so you actually need to multiply the number by 14.5 I believe - I'll fix it

I think this is a question for UDI - They are in charge of the payment system. Yes - we are testing how reliable the new approach is - data is running through UDI servers - I think we are getting close, so there should be an official release soon The new node has some real benefits - i.e. it will use less battery of the car, as it only updates data when there is a need. There are also a few more info fields and support for sentry mode.

I have been playing a little with the local control - it seems to work well at the basic level. Hybrid works well with some device having local control and others still on cloud (but I see no reason to have could devices as functionality is the same for local devices (naturally you need to register the devices on-line (cloud) and then move them to local later). APP shows a little delay when controlling local devices, but ISY control works well - naturally local control without cloud access will most likely not work with APP I still have to try to go completely off-line, but it should work - the issue is more how the system recovers after an internet outrage I need to understand how the solution works with multiple hubs (one local and rest traditional) on the same network (LAN). I have asked yolink, but did not hear back yet I probably need to separate the code into a new nodeserver but time will show

The new hub is ys1606 - the ys1605 only supports cellular - it was supposed to include local support, but as far as I know the plans changed - the 1606 also supports cellular BTW

They just provided me a beta of their local MQTT solution. It kind of eliminates the need for local vs cloud - it is using local if the device is registered locally (and send info back from hub to internet if connected) and uses cloud if not registered locally so there is really no need to select a mode.

How do you guys envision the local integration - For now the functionality is limited and requires polling of devices. It is a hybrid model where a device can be controlled both local and via cloud - with more functionality in the cluld control My thinking is using cloud if connected, and if the device goes off-line fall back to use local. One could also go local first and only use cloud for advanced features - Once they get MQTT working on the local hub local could go first with advanced features using cloud Let me know what approach is preferred

A new TeslaEVstream node server has been added to the beta (non-production) store for testing It uses the new tesla official streaming interface allowing data to update when data changes on the EV - NO NEED TO POLL DATA. This node will replace the existing udiTeslaEV2 node going forward. If more or different data is desired take a look at https://developer.tesla.com/docs/fleet-api/fleet-telemetry/available-data to see what data is available (long list) and let me know. I can try to add it during this beta release Short Poll generates a hear beat Long Poll updates the state of the car (Online, Offline , asleep etc). It also checks if tokens need to be updated None of the Poll gets data from the EV - the EV streams data as they change (max rate is set to 60 sec for most settings). To use the node server, one must install an electronic key on the car On your mobile device open https://tesla.com/_ak/my.isy.io. It should open the tesla app where you can approve the key-install - Older EVs may not support the virtual key. Note, currently only supports NA EVs Additionally, one must open external access on the eISY/Polisy. got to https://my.isy.io/index.htm and log in Select PG3->Remote Connections on the eISY/Polisy Make sure that Remote Connection is ACTIVE To validate if the connection works, there is a TEST button/command on the main page on the node (result shown in the last field in the main page).

On the polling issue - If you are automating maybe poll once a day and then perform an update as first step in your program used for your automation. I assume you are making decision in programs, so when these program execute you can update the data before making the decision. I assume it is a few times a day keeping the data calls to a minimum. Naturally, if you look at the AC and want data updated polling would be needed

We are working on a streaming option where data is only updated when data changes so polling becomes less of an issue.

I was told in the fall the local Hub would be different from the cellular one (Hub3) - They likely need more horse power for the local integration - apparently the CPU is different in the local hub than what is in its documentation

I received mine. It is still beta but you get it cheaper

It does.take a long time to restart the node. It is caused by deliberate delays needed to ensure the api is not overloaded by calls to the yolink server. There is a limit of calls per minute Once restarted everything is back to normal. This is done to handle systems with many devices The upgrade issue is related to the FW and not the yolink node. The node relies on the FW to perform the upgrade