Panda88

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

The issues is we are currently using state - so it will not trigger unless there is a state change - The node does not know the state of the device you are controlling so it appears there is no change in state. Moving to control (DON/DOF) should solve this issue

Quick question on functionality - Should I default the sending commands behavior. I have something working now, but need to know if I shoudl default it to a state, or don't do anything until configured. There are 6 options for either a long press or a short press 0 : Send DOF (normal off commands to scene) 1: Send DON (normal on ) 2: Send DFOF (fast OFF - equivalent to fast double click) 3: Send DFON (fast ON) 4 : Each key press toggles between DON and DOF 5: each keypress toggles between DFON and DFOF Separate functionality can be assigned to LONG press and short press Should I default to one of these values (if yes - what) - or simply do nothing until the commands are selected

I do not own a X3 device. It is likely sending a command I do not know how to handle and this may cause the offline event - Maybe it is too aggressive to show the device off-line, but it is a situation the code does not know that is happening. If you can enable debug and send a log when it happens I can take a look

Hi I released a new version to address changes to the API - it add an estimated backup time remaining int eh status node There will likely be a follow on release to enable rate information etc - new information available in the API - Still need to figure out how to handle time in logic in the IoP

Hi I released a new version to address changes to the API - it add an estimated backup time remaining int eh status node There will likely be a follow on release to enable rate information etc - new information available in the API - Still need to figure out how to handle time in logic in the IoP

There are already 8 functions - there is a short press and long press for each key Toggle would mainly work in a scene, but could naturally also be used in programs (but you can do the same with a variable)

OK - thought a little more about it I will have to change the smartRemoter to have - sub nodes for each key - I can keep the existing node but will need to have a sub node for each key - otherwise I cannot determine which of the keys you link to a scene Hope this is acceptable