Panda88

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