
Panda88
Members-
Posts
764 -
Joined
-
Last visited
Everything posted by Panda88
-
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
-
could my TeslaEV Node Server be running down my car's battery?
Panda88 replied to someguy's topic in TeslaEVStream
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)
-
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
-
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
-
X3 TH sensors lose connection with YoLink Node Server after 5-10 minutes
Panda88 replied to dwengrovitz's topic in YoLink
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 -
X3 TH sensors lose connection with YoLink Node Server after 5-10 minutes
Panda88 replied to dwengrovitz's topic in YoLink
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
-
X3 TH sensors lose connection with YoLink Node Server after 5-10 minutes
Panda88 replied to dwengrovitz's topic in YoLink
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
- 1 reply
-
- 1
-