Panda88

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)

fully understand

Thanks - no obvious errors in the log - maybe PG3 log shows something. I think you can backup PG3 - then I think you can delete the node - and then try to reinstall from backup - I think that should force a install of the node server If this does not work, backup, delete node, install it in a different slot - delete that and then install back into the original one and then do restore backup - I think that should work

Can you send me a log - Could you try to install on a different node and see if that works - and then go back to install the same node. I did update just before releasing on my personal "real" system and had no issues. If not, maybe ask Michal for help - I think something is stuck is your system

Late, but you can run PG2 and PG3 in parallel

Released 0.8.22 - adds support for SmartRemote and PowerFailureAlarm. 0.7x added support for dimmer and minimal support for IRremoter