Panda88

You should be able to use directly in a scene as long as you configure the function of the keys - I did not 100% follow your approach from before - but I did not spend a lot of time on it as I was working on fixing the issues in the remote code

The FOB keys are reset to defaultupon install (from versions before the latest) - so if you changed anything you need to reconfig in the AC - The new release is supposed to remember the settings upon restart I need the log from the node - ideally with debug enabled

This is how I envision the use . The toggle function (long press) is used directly in a scene - as a controller - It will send DON followed by DOF on next click and so on The ON (DOF) (short press) will be sent to a program as control waiting for ON (switched on) - that way ON will be sent each time the switch is pressed. I do not believe that I did change anything on the status but let me know if something changed. I do not think I touched this part of the code, and it seems to be working in my tests (but I did not test excessively on this one as I do not believe I changed anything)

Can you send a log - did you reconfig the triggers?

Uploaded version 0.8.88 - should fix toggle and ghost triggering for remote

Did you select control vs status when programming ?

It seems to be the same issue I mentioned before - the short poll is actually executing the DOF

Do you have a node server log of this - ideally with debug enabled I wonder if the issue is with the switch also sending a command - I thought I had eliminated this but there may still be a bug. I'll check in parallel after I finish my changes to the remote - The current code has an issue with the polling causing the last command to be executed again - so if something else changes the controlled devices' state, it will execute

Do yoo just need the temperature or do you need the rest of the control as well? Getting the temperature is simple - making a control look that works is a lot more complex

I believe some users have found the correct settings - I think the long poll cannot be too small otherwise the node server keeps the car alive. I do not own a car myself, so it is a little difficult to investigate this - I have some code that is not released yet to check if the car is going to sleep - but I am not 100% if it works. I think other users can chime in - or look is some of the other threads for the best long poll and short poll settings. If you pull data yourself regularly (in a program) the car will not go to sleep for sure - I would only pull when needed (not just to keep data updated for now reason besides showing the data) - thus the large long poll requirement (long poll updates the data)

Added sensor temperature reporting for 0.8.50. Let me know if it works.

Sure - but I believe the issues will be similar

After a quick look, I only see the temperature being sent when you query the device (getState). Not on alerts or updates. It also shows -1 in the log I found. I am not 100% sure, but my experience with battery operated devices a getState to the device gets a cached value (from last update from cloud) - not current. It simply burns too much power constantly querying it. I can take a look at providing access to this, but be aware of the above - It is possible the temperature is updated upon alerts (and can be retrieved afterwards), but we cannot force an update besides the normal report cycle (hours) when no motion occurs I need to compare indor and outdoorl Motion sensors to be 100% sure of how it operates (it is not documented in the API documentation), but my guess is they would report the same. Git or here is fine as long as I am mentioned (so I get a message)

I think if you do not start the AC - you can just delete in PG3 and reinstall in same slot - unless you move stuff around after installing, it should show up as it was before - It has worked for me this way

currently there is no local API - only cloud there is supposed to be a new hub coming that will allow some level of local access but it is not released yet i should say cloud access has been reliable

The main issue - as I see it - is the node does not know the state of the scene - so it you turn on the device from the remote, the state will be on - if someone else turns the device off, and you press the remote, I am not sure the state changes (not triggering the program) - but sending a control for sure will trigger the program - I may not be 100 correct here, but it is my understanding

I think it is an issue for Bob - The node server does not handle the new version (besides providing info that a new version is available)

You should see 4 sub-nodes for the remote after the update. You can select one of those as the device and use control (rather than status) - that should execute whenever the key is pressed (you select in the node setting if it is DON/DOF etc.) - that will effectively ensure the press is executed - even if the state does not change. I do not think you need to use the first statement in the if statement - I think the new sub-nodes ensures this I cannot think of why the problem you are describing happens - if you can get a debug log of when it happens I can take a look to see if I can figure out why it happend.

in programs you can use control vs status - Control executes when key is pressed - status only executes if status changes

the update issues is out of my control - Bob is likely the guy to ask - thre have been a few issues but it is improving

Latest release (0.8.41) has a possible fix for the X3 - I cannot test as I do not have a device - The X3 sends data in a different way If there are issues, please enable debug log and send log

Released new version that supports DON/DOF/DFOF/DFON - effectively enabled control in programs. Allows configuration of each key - Should create 4 sub- nodes 1 for each key pressed.

I can try to reach out to yolink to see if they can offer advice - there may be a more correct way of doing it - of keep track of number of call per min etc?

This is likely different - "code": "000201", means API from yolink is not responding - it may be a timing issue - there is a limit of how many commands that can be sent in 30 sec (if I remember correct) - maybe I need to delay this - I do have observed some of the devices reply "code": "000201" once in a while - but I never found the root cause - maybe I need to dig for this - it is devices that offer control where this happens

Getting DON/DOF should solve this issue - I need to implement the defaulting (well test it - it is there already) - I will be on vacation next week, so not sure when I get to do the test and release it