Panda88

Thanks I'll contact UDI and see if there is a solution

Just removed the TST from the name in the non-production store - getting ready to move to main store - Can someone check if it allows update/upgrade of the TST version - This is a super version of the yolink server supporting both cloud and local operation (but also more complicated to setup) I hope to have 1.6.x working soon - better retry mechanism but I wanted to get all of this done before releasing 1.6.x (to keep variables to a minimum) I also have the new shufoff valves on my list to do - I did purchase them and hope it should be simple Also ordered the new ON/OFF Fob - want to see if it is truly ON OFF only or is it the same as the 2 key FOB limited in the App

Did you ever find out what the issue was?

Nothing obvious in install.log :-(

Can you send me the install log - I cannot see how it can still get the new version On the other had, I am happy the 1.6.0 works - I am seeing the same and plan to release soon - but wanted to upgrade to 6.0 to make sure it works there as well - I have not had the time for the upgrade yet

There is still a bug in the release - it is supposed to be 1.5.16 1.6.0 is very close to release - includes improved retry but it is not officially released I guess I need to understand my release tool better - I am not releasing from main (allowing me to test main before releasing) I installed 1.5.16 back to the release but 1.6.x is coming soon -= will likely switch to 6.0 before doing that release but need to finish something else first

It is MQTT related - may be 6.0 related - I'll try to figure out if something changed in 6.0 I have seen this before and sometimes a reboot/power cycle fixes it

There was a bug in speakerhub - did not update the ST - 1.5.16 should fix it

I'll take a look to see if there is a bug - the hub is a special case that needs special handling - especially the speaker hubs

Found a problem with my installer - try again now

Can you try to reinstall - I have a release bug for a 1/2 hour today I have not updated to 6.0 yet, so I have not tested

Connection state can be suspended in case you generate too much traffic - It is still connected so state on-line - just suspended - The reason it takes so long to start up with a lot of devices is I am trying not to generate too much traffic (PG3x is multi-threaded so it basically starts all at the same time causing connection to be suspended) - It can still happen as I cannot 100% figure out how YoLink counts the time - but it does recover eventually - once up and running there is usually no issues It is also partly from the need to move ST to be the actionable parameter - in some cases ST was on-line before - so I had to create a field to use in programs that previously relied on this ST field I agree it is a little confusing, but I had to make this choice to make it somewhat backwards compatible and support UDImoble

You can see the connection status on the local node - It local - Local is added to the status In general local connection has priority over cloud (if you select hybrid mode) - meaning local connection is used if device is connected to the local network - note even if on local network the hub reports status back to cloud. I think commands from app will go through the HUB but not 100% sure

you need the local one. It is currently called TSTyolinkLocal in the beta store. i plan to move it to production store after a little feedback. both nodes will share a large portion of the code base

i just released another local hun node in the beta store. i handles both local and cloud with all the devices (all devices share code now) - i would not run 2 nodes in parallel. what is your reason for doing this? the local also communicates with cloud (when internet is available).

OK - I made a new release in the beta store - combined code into the normal yolink node, making this a "super" node supporting both local, hybrid and cloud only. Given this all devices are now at the same version as the yolink server If it works well I'll move it to the production store and remove TST from the name (should not matter if you purchased the beta version - my understanding ). Next step will be to see if I can improve the retry mechanism

I just released a new local version that uses the yolink 1.5.14 code base (common code based for devices) Let me know how it works - if ok, I'll make a full release and move to the production store (and remove TST from the name) I see this as a super version of the normal node server Next task is to improve the retry mechanism - then add a few more devices I bought

seems there is a bug in the config file for normal hub (i did not test that as I use a different hub) i'll release a fix shortly - hopefully that is the only one

Hi I just released a new version of the YoLink server 1.5.13. Added support for HUB (battery powered hubs can now be used to test if powered by AC or internal battery) - Need to poll this as it does not seem like message is generated on change Updated IRremoter to have subnodes for each code - supports learning codes now. NOTE - By request I changed behavior of ST and added a GV30 variable to all nodes - GV30 is the existing ST (mostly if node is online) - Changed ST to show the most relevant parameter of the node - this is to support udiMobile status icons (they trigger of ST parameter) - I hope that it is not too big a problem as some code may need to be updated if programs tests for online status Few other bug fixes I hope this covers the requests I have had over the last few months Next is support for new LeakStop devices as well as a more robust retry handling when devices are off-line Will also work on bringing the YoLinkLocal Beta (support for local hub) into a production form

Can you send me a log. I am out this weekend

Fixed version - thanks I agree and could likely merge the two - I just fear confusion with non-local users (having option to enter credentials that they cannot get etc.) if it was to become 1 combined node Making the local a super node is not too big an issue - but it still requires double testing (and even more so when supporting both connection types) - but as you say long term it could take over the existing one. I guess I'll aim for the combo node from the start

it is the version shown or the one installed? There is no difference between to two besides the version number I have started to work on the local version - I am wondering if it is better to make the local node only handle devices attached locally to the hub (the non-local can be handled by the existing node) It seems like a cleaner cut in my mind vs the current node Let me know what you think

Yes - there is a localHub that is not widely promoted (yet?), but you can buy it if you contact them I would start with the simple Hub (much lower cost) initially if you are just testing - service is reliable if you internet is reliable. Once you have something critical that must work without internet access you can look at localHub - my guess is price for the localHub will also be lower by then. It is fairly easy to move devices to local later

A new version of the node is now available 0.2.10 supporting the call limit - 3 wakes and 10 commands every 24 hours. Note, there is no need to wake the car to check data - data will automatically update once car is online and something changes. Car only needs to be wakened, if one wants to issue a command (assuming car is asleep). There is no dedicated wake command anymore - the commands will wake the car if asleep. Tesla started charging for these calls (data and more importantly for commands and wakes). It is universal device paying for these calls, so the node is a subscription node to cover the cost generated by the node - cost is estimated based on typical data use.

Great to hear - there was an indication of overflow (too many calls) - I will look into that later, but focusing on bringing normal Yolink up to the state I want before merging the local into the code base - allowing both node type to be synched for devices