Panda88

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

Quick question on the Scene integration Should I make a setting to select a botton to be toogle (meaning it changes state every time it is pressed) - or should I make a switch to be either on or off (It will match the coming on/off FOB - my guess) - It has to do with how ISY handles scenes (you contol them by sending a command (DON/DOF) to the ISY Any preference? I may be able to do both options, but need to think about it

I forgot about scenes - I'll take a look next week - It should be possible to make the both the short press and the long press work sending DON/DOF (toggling) (same for DFON /DFOF), but I need to think about how to initialize it - I have no idea what the state of the device being controlled is when started - so you may need to press twice first time, My initial thought was to send a key press and have the program handle if it is on or off (I have no way to query the state of the fob) Just to be clear - are both short and long press working now?

Is the one you have the one with many keys ? I have only looked at the one with 4 keys - Smart FOB I think they call it - This one has QR code etc and shows up and registers in APP - My guess is you have the old one - It does not sound like it is possible to access that one if the system is not aware of it (I assume it must be D2D linking)