Yolink Local API

[Panda88]

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 

[sjenkins]

@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  

[Panda88]

This is what I feared

Let me ask UDI if there is a way to add 60 days

[TJF1960]

@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

[Panda88]

i have not heard back yet 

can you send a log

[Panda88]

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?

[TJF1960]

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

[sjenkins]

The concept is already proven to me -- I'm on board

[Panda88]

waiting to hear back from UDI if there are issues with the proposed approach

[Panda88]

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 

 

[sjenkins]

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.

 

[Panda88]

 

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

[someguy]

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. 

[Panda88]

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

[sjenkins]

@Panda88,

fyi the version in beta store has reverted from 0.0.7 to 0.0.6

[Panda88]

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 

[sjenkins]

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.

 

[Panda88]

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 

 

[sjenkins]

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.