Panda88

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

Looks like the Local API is simple for now. No MQTT so we will need to poll devices for now. . Hopefully the will support in future

You likely need the new local hub device - it is supposed to be in beta stage - there is some discussion on the HA forum and discord

I ordered the new HUB required for local control. Did not receive it yet. My understanding is it is in Beta and there is no API to control it yet

Try to run the update once more. The send me a full log with debug enbled. I do expect it is some missing file - note the installation is handled by PG3 and not the node itself I have some time in a plane thursdy

I have seen the same. I believe is it related to the eIsy i did a reboot /power cy le and IT went away. I am travelling but will check for updates to the mqtt package to see if there could be some fixes there