Panda88

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

It looks like my LocalHub does not generate an event when power is not supplied - Yours may be different - you can poll and get th info, but it does not generate an alarm like the powerSensor does

I am looking at this now - do you know what states exist - It seems there is supplying and charging Do you know of others? I believe there are minimum 4 as I get 2 and 3 from API - so 0 and 1 must also exist - likely battery empty and unknown, but I am just guessing I guess there are 2 parameters - DC and battery state

Can you enable debug restart node and send me link My guess is you did not go through the authenticate process (press the authenticate button) Also - did you preform the test to ensure webhook is working

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

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

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?

i have not heard back yet can you send a log

This is what I feared Let me ask UDI if there is a way to add 60 days

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

updated version to 0.0.6 - and added 60 days - let me know if it works I will start looking at the final integration - have a few changes I am working on in the yolink node that I want to complete first (they will port over)

Do you suggest I generate a new version - I thinking touching it does not extend the trial period - maybe I can extend the duration of the trial - but I am not sure how the system reacts to it (after the fact) The more I think about it - I think releasing a version supporting both is possible but at the same time it seems risky to overwrite the existing node for people without local hubs - implementation will be local by default with fall back to cloud only - I hope I can work with Michel/UDI to have people be able to get an upgrade to the new one when moving to local/hybrid version - It does not seem to be possible to do it as an add-on to the existing the way the billing system works

I am trying to find a way to start the node in 2 modes - local and non-local. If I find an acceptable way it will stay as 1 node - otherwise I will likely remain as two separate nodes with the same code for the devices I will start looking at this again as I am back home now

I have this device and it works Looks like I do not log the "unknown" X3 hub. I'll see what I can see from my own system to see if I can deermine if codes are sent (or not sent)

If Yolink were to stop, we would not be able to add new devices etc. It should keep running with what is already there, but adding new devices etc. still rely on the cloud / App

You need to restart the node after enabling the debug level Devices still send data - I just do not process it (as I do not know what to do with it Should be able to see what is reported and then make the needed changes

if you can send a log with power and without power i can tage a look. they do have a dedicated device for this. i do have the pro hub (probably similar to X3 hub) and it may have the same reporting - I'll take a look when I get some time

The plugin ignores the HUBs (besides speaker hub) as they cannot do anything besides being a connection to the cloud

I did some rudimentary test and it worked. I cut the data into the modem when I tested

you should have 4 sub nodes where you define the operations for each press type. i have the same fob and it works Are you trying to use a scene to control this ? I still believe it should work, but I have not tried it I have used programs mostly with this one Send me a debug log (enable debug and press the different keys are few times)