Panda88

can you ask UDI about this. it may be a define somewhere i am missing but i do not know how to fix

Does the AC change state - I am not very knowlegdable on UDM - but is AC works I need someone else to give a hint as to what to do on UDM

It is difficult to know when connection is down - there is likely an indication on API return but I have not found it yet Yolink is looking to add hubs to local network. - did not work last time I tried - o doubt the speakerhub will work in local mode but i cannot say for sure. I think the tts is in the cloud

You have to create a new set there

Creating a new home should generate a new UUID etc. There is a list of them - one for each home

The local is a few revisions behind - I did not update it when people could not get hub I should be able to use the same code base for both, but initialization is a little tricky as I do not know if system is local or not when the node starts (so it would require to different programs/code to start the node) - beyond that it is common code - this is how it is now - but in two different branches currently (that is why it is behind) - I was planning to let the user specify if local is needed (through the config) but I have not gotten around to look at it yet (config is the most complex part due to the multi-threading of PG3) It may be possible to keep it as one - and it should be a goal, but not sure when I can make it

Tim Maybe you can try to make 2 homes - that should allow 2 sets of credentials and allow operation of existing node - you need to move your test device to the new "home" - I think the new home needs the local hub for testing I do not know enough about PG3 to answer the ID related issues

Correct - I have not found a way to identify the connection type yet - I have a request in but no reply yet The old hub can be used to extend range of network (but the devices attached will not be local (yet - they are working on this) - I have some devices in a pump house that the local hub does not reach reliably (I have an ethernet conenction there), so I hope they will get this working

I so not think there is a need for curl. It is separate from the node. You just need to move you devices to the local hub - do it one by one initially. If you have more than 1 hub (for range reasons)!the local hub must be able to see the device you move

correct - I do not recall if I had to push anything on the hub - I only use ethernet I found some info on home-assistant forum initially that helps me get going

response = requests.post(self.local_URL+'/open/yolink/token', data={ "grant_type": "client_credentials", "client_id" : self.local_client_id , "client_secret":self.local_client_secret }, timeout= 5) if response.ok: temp = response.json() logging.debug('Local yoAccess Token : {}'.format(temp))

It should but i have checked it recently. Tesla may be changing the local access requirement. I am ravelling so i cannot check until i return as you needed to do a physical switch when starting - see the notes

i was referring to a change i am planning - not there yet ill check what changed in v22 biy the only thing i can remember is commenting out a debug statement that was causing an issue ill see if i can debug while travelling

It appears for the log that it goes back to the original message (0) after trying node 2 and later node 3 - Is that not the case? If it is the case, it may be a bug on yolink side Anyway - I am thinking why not include the message as part of the pay function directly (no need to select message first) - would that work? - then there is no reason to cache the previous message text then - I could add the other parameters as well - It is possible to do this now with the later versions of pg3x

I'll take a look to see if I can find something - I did not change any code relating to this, but there must be a bug. I have no way to test as I am travelling Can you send a full debug log - the issue may occur earlier than what you included - ideally as a log zip file

click on the localHub and get the needed info under general and integrations

I was expecting that - I had to create a new node to get it on the non-production store

YolinkTest is for different purposes. ill remove it later as changes have propagated to the production node

Try now - it shows on my other eISY now (It always shows on the one used to release)

there was a mistake in the release - try 1,4,22

Try to install 1.4.22 - I had a mistake of not enabling all devices (used during test)

I added a new TSTyolinkLocal - hopefully this one makes it through

I am not sure what happened - I pushed it - it showed up and was later removed - It happens often to me - not sure why I have not tried to replay the original node - It will have a different node id, but nodes should have the same names and addresses - it may work and it may not

what do you mean by nodes? there should be one node per speakerhub registered. the setting is to select different messages to be played on different conditions you may need to restart once more as the node updated and it will not remember the setting from the previous version if just set (i believe)

there is a config parameter NBR_TTS you can use to specify the number of messages that can be defined. I think the code allows you to set a higher number - and you should then run the node, stop it and start it again - that should increase the number of messages that can be defined It may not work, but let me know if it does not and send a log file with debug enabled