Panda88

can you test 1.4.26 a little longer and if ok ill release the version - yes it was a typo

does the 1.4.29 have the issue you mentioned before. how do i create it for testibg?

It makes little sense that other leak sensors work and one does not - maybe give it a try a little later - sometimes there are issues on the server side

I'll keep it in mind next time I change something

OK - The issue is ST is used to represent if connected - not on/off for this device I guess I can look at changing it but it may cause issues for others

I use UOM=25 to support unknow value

I did a pre-release for you if you are interested ? As I understand there no easy way to revert back - yolinkTest in the non-production store - if it works I can release to the real node

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