Panda88

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

0.8.20 released - supports SmartRemoter - Assume it is same for the securityFOB Let me know if functionality is sufficient - I made a combined key press and also separate keypress (so there is no difference between long and short press)

Just released 0.8.20 - Includes support for SmartRemoter (FOB) and PowerFailureAlarm - and hopefully added alittle more text explaining how to install

There are actually 2 descriptions, but I'll see if I can improve it in next release - working to add power failure alaram and smart remote

Can someone send a PG3 log - I just installed (fresh install on eISY after upgrade to 5.5.5) and have no issues (node had been installed before but was deleted before upgrade to 5.5.5). Have you tried to download the log - not just looking at it in the console/browser - In my case there was a log but it did not display in the console/browser.

Did you try to power cycle polisy/eisy - It ay help in case node does not shut down completely

I am not on 5.5.5 yet - I am out this weekend, so it will have to wait until Monday - need to have enough time to investigate what is going on

I went ahead and ordered one - we will see what I find

I see a smartRemoter API. I assume that is the remote. I can buy one next time I buy devices and then try to integrate - unfortunately I just bought some so it may be a little while - I'll add it to the list

Strange - it is doing exactly what it is supposed to do - It says is does not see any changes in node-defs - (which is true) - 0.7.5 corrects a few spelling errors -that is all I am not sure - it is possible the SW is too smart and does not upgrade because it does not see a change. The changes actually end up on the ISY I just received the power-fault detection device and will add this soon - I believe that release will force an update for sure as I will be adding a new node type

Can you send the PG3 log as well - everything seems fine besides speakerhub not connecting - I verified code on github is 0.7.5. I assume you have a version from the production store (you should have otherwise it would not notify on a new version)