tjkintz

Every router is different and so are levels of expertise so I can't give a good generic answer. My environment is probably unique for the people following this thread but for what it is worth, I have a Mikrotik router. Mikrotik also provides a windows program called winbox to facilitate configuration, among other things. Within winbox, I can see all the connections from the firewall settings. I can then filter those connections to just those from the Polisy. I always keep that filter in place and try to remember to look at the connections. Regarding my hunch that the hub is not the issue, if you have notifications set appropriately in the YoLink app, you will get a notification if the hub is offline. If you aren't getting those notifications, then the hub connection isn't the issue.

The issue likely has nothing to do with the hub or how it is connected. The issue is likely that the NS needs a connection to the YoLink server running on an Amazon hosted server, which is what Panda88 is referring to. The NS keeps the connection alive but cannot currently detect when it is lost. Restarting the NS reestablishes that connection. Anything that would break the connection, like a router reboot, ISP down, power failure, etc. is likely the source of the problem. Every morning I look at my router to see if the connection is still there and if not, restart the NS. It is a TCP connection to port :8003.

If you are somewhat knowledgeable about networking, look for something getting restarted, such as a router, cable modem, access point, etc. I trace my problem to a 30-minute TCP connection timeout setting in my router which caused YoLink to stop working after 30 minutes because it could no longer talk to the YoLink cloud server. Working with Panda88, he changed the NS to renew the connection every 10 seconds which solved my problem except for the case when something truly breaks the connection, like my ISP going down or a power failure taking down a piece of the network infrastructure. Panda88 is now trying to figure out how to detect a lost connection, rather than simply renewing it, so he can reestablish the connection.

I've been working with Panda88 and running 4.4 for a few days, and 4.3 before that. I'll let Panda88 elaborate on what was changed but I think the problem of "it works and then it doesn't" should in general be solved. There is still a related issue to be solved but Panda88 is aware of it and working on it.

Re: logging into Polisy to get MQTT log files, I can see the Polyglot log and it has MQTT entries along with a lot of other stuff. I can also log into Polisy via ssh but don't know what to do once I am there. Is one of those things what you were referring to? If ssh, please advise how to get the log files once I am logged in. I could write something to edit the Polyglot log file to keep important stuff, if I knew what was important.

"Exact kind of action I see on my motion sensor." Oh great, I just ordered 3.☹️ The NS didn't continue working for even an hour. It never detected an open or close and sending toggle commands from IoP again does nothing. The NS log shows nothing for the open and close times whereas the YoLink app history shows them. @Panda88, let me know if there is anything I can do to help debug.

I am running the latest versions of Polisy and YoLink NS. Of the YoLink devices I have, it is the garage door controllers and sensors I really care about. In fact, that was the sole reason I bought a Polisy. At least twice, maybe more without realizing it, everything in IoP looks fine re: YoLink. I can query and toggle the doors; however, nothing actually happens. The door doesn't move and of course the state doesn't change. I can raise the door via the YoLink app or door button, but the IoP state does not change. My program that toggles the door based on other criteria runs but doesn't raise the door. The most recent occurrence was this morning. I restarted the NS from Polyglot and then I could successfully toggle the door from IoP and the sensor would reflect the proper state. Restarting the NS seemed to remove and then add the YoLink devices. However, the programs I have written to run when the door state changes, are not running. The if-clauses look like they are pointing to the right devices. I increased the NS logging level to debug and may get better data re: what is happening but, in the meantime, are there any clues or suggestions to isolate and eliminate the problem?

With IoP, the log entries say, "System Unknown". I do not recall this with ISY 944i. Is there a way to assign a system name?

:8080/WEB/index.htm did it, thanks.

Not sure if this is related the latest release since I just moved to IoP and that is the only release I have experience with. Everything I see in ISY System Configuration and Help|About gives me my URL as the ISY local address:8080 but nothing responds at that port. :80 brings up Polyglot v2 and :3000 brings up Polyglot v3. Should there be a web server at :8080? Help|About does say Internet access is disable for some reason. UD Mobile successfully test my local connection at :8080 but the browser does not get a response.

The syntax in the subroutine is strange to me too, such as "In", the delay and the use of the variable. It obviously is right but I have never seen it. Awaiting that explanation, you can arguably simplify the program by a creating a program folder, specifying the conditions when the programs in the folder can run and putting the program(s) in that folder. That is how I only have my sensor controlled programs run from sunset to sunrise. That way each program does not have to do the time check.

Maybe off topic, my MS II that controls a scene causes log entries when there is an ON or OFF control. My MS II that controls a program does not generate any log entries when their is an ON control. I can figure out motion was sensed by seeing log entries for the lights in the bathroom scene being turned on or off but an explicit entry in the log for an ON (or OFF if that is how the sensor is configured) control would sure make life easier and make for consistent behavior.

Larryllix refreshed my memory. Using a dimmer switch as an example, there are multiple control signals; ON, OFF, DIM, etc. For the program IF switch is switched ON then <do something> Else <do something else> the ELSE clause will never execute because the program will only run when there is an ON control (that was all that was tested for) and that is handle by the THEN clause. For my MS II, configured for only ON, there is only one possible control; ON. $master_bath_night_light_status is an integer variable, not a state variable, so changes in its value will not cause the program to run. The program only runs when there is an ON control and then I can test the integer variable. Therefore I was able to simplify the program to what is above.

It was intentional but maybe not necessary. More than a year ago, and therefore I can't find them anymore, I was part of some threads relating to IF/THEN/ELSE tests. I think larryllix was part of those threads. I have a background in programming and in pseudo code, I expected something like the following to work: IF light_status is 1 THEN <do something> ELSE <do something else> I thought it was an ISY bug in that the ELSE clause would never execute if the light_status was not 1. It was explained to me that the IF clause needs to capture all the things necessary to drive the logic. So, in pseudo code again, I would need something like: If light_status is 1 or light_status is not 1 AND light_status is 1 THEN <do something> ELSE <do something else> I think the explanation had something to do with state machines. In fact, it proved to be true so I am now in the habit of putting in what seems to be unnecessary things so the ELSE clause executes. I do not know if this changed with V5 of the ISY software and it still bothers me that I have to do this but better to be safe. Does anybody know if the ISY V5 software still requires this and/or can give the explanation why it does/did?

Above are my settings and program. This is not the first iteration of the settings or program but it is what it evolved to when I discovered I was getting multiple ON triggers, and therefore multiple email notices, before the 30 second timeout. I used to have ON/OFF set and just ignored the OFF. I wanted maximum sensitivity and took a chance the higher the sensitivity number, the greater the sensitivity. I still don't know if that is true. I have the hardware jumper set to limit the range because I don't want the lights to turn on when I get out of bed. The program is in a folder with a condition that it only runs from sunset to sunrise. I didn't want to rely on the sensor figuring out if it is night or day. There is a separate program to monitor the status of the night light scene. If any of the lights are on then the status is 1, else the status is 0.

I have 2 MS II's, one controlling a scene and one triggers a program. The one controlling the scene works more or less as expected. The purpose of the program is to turn on a bathroom light scene when my wife steps out of bed at night and leave those lights on until she returns to bed. It is normally a bathroom trip but could be an insomnia trip lasting much longer. The program sends an email message for each on and off signal. I have discovered that the MS II sends multiple ON signals while it is sensing motion. This is true before the timeout set in the options expires. The email messages are a few seconds apart and stop once the motion is no longer being sensed. This is true when the MS II is set to send ON only or both ON and OFF. I programmatically turn on the scene at the first ON and ignore all the extra ON signals for 30 seconds. After the 30 seconds, I assume the next ON was caused by her return to the bed so I ignore all extraneous signals for another 10 seconds and then turn off the lights. I had expected the MS II to send one ON and no others until the timeout option setting expired but that isn't how it works.

Yes, I know paddles and keys don't have status. However pressing a key does change status to some value. The point is if the program tests for control switched on and the user holds the key down longer than a tap, the status will change to something other than 255 (on). In that case the test for control switched on will be false. In fact the program will not even run because it was testing for a control switch On but it turned out to be a control switch fade up and that wasn't being tested for. As posted earlier, I want a mini-remote key to be a true toggle. I don't care what they press or how long they hold it and I don't care what the value of status is other than 0 or not 0. That is why for my purposes I don't test control, I test status as follows: If status is not off then set some switch on else set that switch off Yes, as posted elsewhere multiple times I completely understand what you are saying in your example; when testing control do A can never happen but do B can. That is why my needs are met so much simpler by testing status and not control.

Yes, I can turn things on or off by testing control for on or off but that doesn't address all the other possibilities. What isn't obvious is that On sets the key status to be 255 and Off sets the key status to be 0. If the user holds the key down longer than a simple click (which my wife and others habitually do), the status will be set to something between 0 and 255. A program that tests the key for On or Off will simply not run in that situation because it wasn't an On or Off key press; it was some sort of dim/brighten key press. If the program won't run then it doesn't matter what logic is in the program. Conceptually, testing Not Off would cover any status > 0 but the program: If control switched Not Off Then do A Else do B Will run if, and only if, the Off key is pressed; all other key presses are ignored. Therefore only the Else clause can ever run. I understand something has to happen for a program to run; my issue is with testing Control. If I test status Not Off, my program will run for any key that changes the status to any value. I also want to view the key as a pure toggle; if the light is on then a key press will turn it off and if the light is off then a key press will turn it on. This is regardless of what kind of press it was. That is why I normally write the program as: If key status is not off then turn the lights on else turn the lights off This works well unless ISY and the remote get their status out of synch. In that case a key press might be lost. This has actually happened once for unknown reasons. It is also a little confusing in that the color of the LED is likely to be meaningless, especially if the light is controlled by other things. So a red LED could result in the lights turning on and a green could result in the lights turning off.

Edit. I have learned a few things from this thread, https://forum.universal-devices.com/topic/23461-do-something-if-device-is-on-for-x-minutes/ although I don't like what I learned. When testing control, the program will not run unless the key or paddle press is one of the things explicitly tested for. If the program won't even run then it doesn't matter what logic is in the program.In my example of testing control to be switched On, the only thing that will even make the program run is a button or paddle click On. Any other action will simply be ignored. So a mini-remote key that is an Off will not even get the programming running because I tested for On and didn't test for Off. The Not On test will never be true therefore the Else clause will never be executed.

Continuing this thread....... The whole toggle thing is problematic. For some reason, maybe because the keypad had been turned off, the first key press did not trigger a status test in my program. Subsequent ones did. Given that one of the keys is supposed to trigger a program to turn off all the devices in a scene, the missing first key press is a real problem when the devices in the scene are not visible. Did they really turn off? In my case they didn't. This really seems like a bug. I then changed the status test of Off or not Off to be a control test of On or not On (it could have been Off or not Off too). Logically this should cover all possible cases; not On implies one of the other 8 control possibilities, Unfortunately the "not" condition never gets detected, just the test for On. Again, this seems like a bug. Is there a way to submit these to the developers for investigation or do I just hope they read the forum?

I do this a lot and suggest a refinement of what larryllix posted. The problem with testing Control is that there are too many possibilities for a key press; On, Off, Dim, Brighten, etc. I found it better to test Status for Off or Not Off. That way, any key press will run the program and that test will be True in all cases. Here is my recommended pseudo code: If ....Status ButtonX is Off Or status ButtonX is Not Off Then Enable program Toggte ....run program (if) Toggle Disable programTogtle Else ....--- Program Toggle (DISABLED) If ....Load is Off Then ....Set Load On Else ....Set Load Off

I think I answered my own question. Testing if the status of a button is off or not off will run the then clause.

I want the mini-remote to be configured as an 8-button toggle. With this configuration is there an easy way to detect when a particular mini-remote button is pressed? I just want to know if a it was pressed; I don't care if it was On, Off, Fast On or anything else. I can test for all the control possibilities but I don't consider that easy. I tried testing for Status Responding but that didn't work. I tried testing for Control is switched on or Control is not switched on as shown in the test program below, but ISY only executes the Else clause. It really seems that the test program should work since the program only runs because the key was pressed and logically it has to be either an On or a not On. Example program: All non-MB devices off - [iD 0003][Parent 0001] If Control 'Master Suite / MBR Devices / Remotes / R2G - All MB lights off' is not switched On Then Set 'Office Devices / S2, ceiling floods' Off Else Set 'Office Devices / S2, ceiling floods' On