Panda88 Posted August 27 Posted August 27 It will not be easy as they code for the devices will be shared - I am looking at adding a field to hold the current ST and then move ST to the active item - it will take a while 2 Quote
sjenkins Posted August 30 Posted August 30 @Panda88 looks like the TSTYolinkLocal is now dead in the water. The "subscription" is out of date & it has shut down. Won't restart or re-install or update. Not sure what is required to give it a jolt, but would appreciate more time on it until the production version makes is out of your shop Quote
Panda88 Posted August 30 Posted August 30 This is what I feared Let me ask UDI if there is a way to add 60 days 1 Quote
TJF1960 Posted August 30 Posted August 30 @Panda88, I too have lost access due to expiration date. I know you are working on it. I also wanted to report that while PG3 shows the plugin as disconnected, the devices seem to show as being connected. And some show Cloud, 1 or two show Local. Please see screenshots -Tim Quote
Panda88 Posted August 31 Posted August 31 Seems there is no way to reset the license What would you recommend - Maybe the easiest version is to offer an option to buy in the beta store - and I can then propagate it to main store once ready Will that work? Quote
TJF1960 Posted August 31 Posted August 31 Speaking for myself only, that works for me. You have put a lot of time and effort into it not to collect a fee. Thank you! -Tim 1 Quote
Panda88 Posted August 31 Posted August 31 waiting to hear back from UDI if there are issues with the proposed approach Quote
Panda88 Posted September 3 Posted September 3 They confirmed I can make the node have purchase price and once fully released if paid it will provide access to the full release node - I'll make a payment option for the beta for now Probably keep it the same as the cloud version 3 Quote
sjenkins Posted September 6 Posted September 6 Payday so I was able to drop the $15 All installed and booted nicely ; we are back in business....locally !!! btw: : over labour day weekend one of my yo-link leak sensors went off and found a leak in my RO water system. The dealer had "never" seen that failure mode (the plastic weld on the filter failed). Yo-Link saves the day & my supply of ice for the boat on the long weekend!! Thanks again @Panda88 for taking this plugin to the next level. 1 Quote
Panda88 Posted September 6 Posted September 6 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 1 1 Quote
someguy Posted September 10 Posted September 10 I’m looking into using yolink. If I want to use it with local API, what do I need to do? Is there a certain hub I should buy? Thank you. Quote
Panda88 Posted September 10 Posted September 10 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 Quote
sjenkins Posted September 11 Posted September 11 @Panda88, fyi the version in beta store has reverted from 0.0.7 to 0.0.6 Quote
Panda88 Posted September 11 Posted September 11 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 Quote
sjenkins Posted September 11 Posted September 11 5 hours ago, Panda88 said: it is the version shown or the one installed? 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) The one installed is 0.0.7, the one I got a message on and is in the store is 0.0.6. Assumed there was no difference, just wanted to let you know as it has happened to me before ; just causes noise with the users. I am good either way on do the non-local devices sit on the local plugin. Con is it means another plugin, Pro as you say is keeping it clean ( keeps it very obvious which ones you added to the local hub). Saying that, my additional speaker hub is sitting on the local plugin right now & seems happy enough. Do'ing it this way would allow me to utilise it with one plugin. I don't know what the plumbing is, but doesn't it give you a path to "one plugin to rule them all" if the local eventually swallows the functionality of the non-local hub? or does the communications go the other way? Good to support either way. I have debated this question with my Hunter-Douglas plugin, there are Generation 2 & 3 with very different update paths. I kept them as one, but nearly split them in my last rewrite. There are almost no blended 2/3 environments. In this case you will have many with at least a speaker hub which has some use but won't be on the local. More rambling than help, but maybe some things to discuss. Quote
Panda88 Posted September 11 Posted September 11 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 1 Quote
sjenkins Posted September 11 Posted September 11 I guess two ways to countermeasure the confusion for users 1. Make the local plugin handle both, the regular plugin handle remote only. Will likely have your more advanced users in the local plugin. Could use this as your slow merge plan. Cons: managing two plugins & as you state the testing involved. 2. Lots of warnings in the instructions and the labels on the configuration items to steer the remote users from entering anything in the fields. Again assumption is your local hub users are your more advanced. May, or not, be a good assumption. Pick your poison. 2 Quote
Panda88 Posted September 24 Posted September 24 (edited) 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 Edited September 24 by Panda88 2 Quote
TJF1960 Posted Monday at 06:23 PM Posted Monday at 06:23 PM Hey @Panda88, the new beta has been working great for about 24hrs. I noticed snappier response time over the previous version I had installed. I have not had any of the issues I had before. I really like the "Initializing" driver state in the Yolink Setup node, very handy since it takes about 20 minutes after restart to receive all the data from all of my devices (47 Yolink devices, many are temp sensors) and switch to Initialized. A couple of questions. I have trouble remembering the difference beween Connection State and Node Server State or maybe now its Online State. Is Connection state the devices are talking to TSTYolink node server and Online is TSTYolink is talking to IoX? Thanks for making this all happen! -Tim Quote
Panda88 Posted Monday at 06:31 PM Posted Monday at 06:31 PM (edited) 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 Edited Monday at 06:35 PM by Panda88 Quote
sjenkins Posted Monday at 08:17 PM Posted Monday at 08:17 PM @Panda88 just did the update to ISY 6.0 ; most started up ok but Yolink local will not show connected , nor update any of the devices. I sparked up the regular remote Yolink I keep in another PG3 slot, it started up just fine, showed connected, and started populating devices. I looked at the plugin logs and got nothing. the main logs looked like they sparked just fine, no errors. I did a re-install (which the upgrade does as well). No joy. Any others having issues after upgrade? Quote
Panda88 Posted Monday at 08:53 PM Posted Monday at 08:53 PM 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 Quote
sjenkins Posted Monday at 08:56 PM Posted Monday at 08:56 PM @Panda88 2 minutes ago, Panda88 said: 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 great minds.... just did an install in a clean slot, no joy, sorry. Get what you need done -- we will be fine, I just wanted you to know or me to know it was my system. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.