Panda88

Can you PM me a log file with debug enabled and I'll take a look Are you sure there are no empty spaces in the UUID / secret? Hub should be fine - but you need to configure the cloud portion - local only works on 1606 There should be install instructions in the more detail portion

I released the yolinkLocal to the production store If you are an existing user (of TSTYolinkLocal) and want to keep the setup, it seems you need to backup your system, delete the TSTYolinkLocal, install the new YolinkLocal in the same slot and restore the system. There is likely a bug in PG3 that prevents an upgrade when the node changes name - the nodeID is the same - only the name changed

Thanks - It seems there is a bug in PG3x handling name changes If it works, I'll release to production store and get going on releasing next version with improved error (offline) handling

Just to be clear - you have a license but it cannot upgrade? Can you make a backup remove the TST and install the new in the same slot and restore - does that work?

Added a new node to control Netro(home) irrigation controllers and moisture sensors Netro_watering Offers basic control as well as access to the data provided for the controller Do not poll too often as there is a limit for 2000 API calls/day per device - default is probing every 20 min

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