bjs169

Thanks for everything. Will definitely be taking a close like at my programs over the holiday break.

This is all great. I have had similar ideas about refreshes to ensure the button is in the right state, but it seems so kludgy. I guess you are saying it is just a necessary evil based on the limitations of the ecosystem. I can accept that. Curious, the status checks at the start of the .off and .on programs, are those status checks coming from a query to the device or coming from an internal state representation in ISY? I had assumed from a device query, but since you are saying these conditions are to prevent ISY traffic I am now wondering if was wrong and status comes from ISY. Finally, just curious what is the +# nomenclature in "Garage Entryway+#"? And, yes, I am old enough that I did once own a 300 baud modem.

Thanks, the paragraph was really helpful. You are right that I break everything out due to long being observant of the DRY principle. I'll see if I can rethink my approach and try to combine programs instead of aiming for reuse. How would you approach incorporating physical device feedback into the installation? Say someone turns on the breakfast dimmer from the physical device. This will turn on button B on my KPL because of a scene. But also want to ensure G and H are in the right state in this situation. Is that an appropriate time to use my existing "state machine" programs?

My approach previously had been to try and treat these buttons like a state machine, but I think I see what you are saying. Do you have an example you could provide?

Adding the 15 minute wait worked. Sunset - [ID 0016][Parent 0021] If Time is Sunset - 30 minutes Then Set 'Scenes / Device Scenes / Front Outside' On Set 'Devices / Master Bedroom / Master Bedroom KP Dimmer / A: Master Bedroom Outlet' Backlight On 1 / Off 0 Wait 15 minutes Run Program 'Downstairs Some On' (Then Path) Else - No Actions - (To add one, press 'Action') I will try shortening it today.

This helped. So, next question is did it help due to the delay being longer or did it help because the "downstairs on" was executed twice. I'll eliminate the second sunset program and add a 15 minute wait to the original sunset program to see if it still works with the longer delay, but not the second execution.

Sorry. I apologize if my comment sounded sarcastic. It wasn't intended that way. I appreciate all your help. I was just clarifying that the status gets changed in a variety of situations and not just the one use case. Sorry again. You have been very helpful so far.

Hey MrBill, thanks for taking so much time with me. I really appreciate it. I am not asking you to do my homework, but the install is more complex than that as you probably could imagine. Many scenes, programs, and, of course, manual button presses can cause the devices tied to A-F to change status. I want G&H to be responsive to all those events and not just the events raised by a single program (e.g. sunset). That is why I have tried to abstract the state of G&H into their own program so no matter how state on A-F devices changes I *should* end up with G&H in the right state, but it has been a challenge for sure. One change I made to try today is created a second sunset program that kicks off at Sunset - 15 minutes and will put the "downstairs on" program in there to see if the longer delay helps. This sort of imitates what I have been doing manually which is wait for the current sunset program to run, go and take a look and see the state is incorrect, and then run the downstairs on program from the ISY UI to "fix" the status. It's an odd one.

Unfortunately, the changes suggested by you and Techman in this thread did not help today. Sunset program ran, all my devices turned on as expected, but no status to trigger the "status change" program (HandleKitchenKPStatusChangeA). I then manually run the "downstairs lights" program (Downstairs Some On) and the status change program does trigger. Very weird. Maybe I need to redesign the way the KPL all on / all off work, but very odd that it is only this one KPL and only when triggered by a schedule. Maybe someone has some ideas. Instead of talking about how I have it programmed, maybe I will talk about what I want to achieve, and someone can suggest an approach. 1) I want the G button to turn off every device / scene tied to the A-F buttons when the G button is pressed. And when everything tied to A-F is off then I want the G button to be lit. If any device / scene tied to the A-F buttons is on then the G button should be not lit. 2) I want the H button to turn on every device / scene tied to the A-F buttons when the H button is pressed. And when any devices tied to A-F is on then I want the H button to be lit. If all devices / scenes tied to the A-F buttons are off then the H button should not be lit. Status pseudo-code: IF (A OFF AND B OFF AND C OFF AND D OFF AND E OFF AND F OFF) THEN G = ON AND H = OFF IF (A ON OR B ON OR C ON OR D ON OR E ON OR F ON) THEN G = OFF AND H = ON

I've implemented the change you suggested in the sunset program. That's not something I have tried before. We shall see how it goes. All of my 8 button KPLs use the G button as an "all off" and the H button as an "all on" shortcut to turn off / on everything controlled by that KPL. They also act as status indicators. If a single device controlled by the KPL is on then the H button will be on and the G button will be off to indicate something is on. When everything the KPL controls is off then t G button will be on and the H button will be off to indicate nothing is on. I have had quite a bit of difficulty in getting this to work reliably and this approach does seem to work on my other KPLs. But certainly open to suggestions if this "all on / off" is something others have done before.

I appreciate your help and will try your suggestion about using THEN, so don't want to argue with you, but what you say about an empty IF is not accurate. You had me second guessing myself, so I just verified by running an empty IF and the THEN ran fine. And, recall from my OP, the instructions in the THEN have been executing. Just one of them has an issue with status, but the control does actually work. The empty IF executing the THEN makes sense to me from a Boolean logic perspective. But go ahead and try yourself. None-the-less, I have already taken your advice and updated the program to run the THEN just to see if that helps. Thanks again!

Thanks for the quick response. 1) I will try running the THEN, but was under the impression that running an empty IF is the same as running a THEN. But I am open to trying anything. Will see how that works out tomorrow. 2) My variables are state variables. Here is how I use it: HandleKitchenKPStatusChangeB - [ID 0066][Parent 0005] If $kitchenKPLStatus is 0 Then Set 'Scenes / Program Related_Scenes / KPL All Off On / prs_KPL_All_Kitchen_Off' On Else - No Actions - (To add one, press 'Action') HandleKitchenKPStatusChangeC - [ID 0067][Parent 0005] If $kitchenKPLStatus is 1 Then Set 'Scenes / Program Related_Scenes / KPL All Off On / prs_KPL_All_Kitchen_On' On Else - No Actions - (To add one, press 'Action') 3) I already tried the wait approach (3 seconds, not 2) thinking maybe there was just too much traffic at once on the network. It didn't help, so I reverted that change. The other thing I was thinking is I could just add a query command to the program to query the state of one of the devices (Kitchen Sink / Kitchen Island), but that seems like a hack. I'd rather solve the real problem if it can be solved. Thanks again!

I have an issue that has been plaguing me for some time. Status changes are detected from a device when I trigger a program manually, but when that same program is triggered on a schedule status changes are not detected. I have a sunset program that turns on a scene, sets the backlight level of a keypad, and runs a "downstairs lights" program. No issue with the scene or the backlight level. The "downstairs lights" program runs and sets a device to 60%, turns on a few scenes, and calls a networking resource. Everything executes fine and everything that is supposed to turn on does turn on. However, one of the scenes has an issue related to status. It turns on four devices. Two of those devices are monitored by "status change" program for any status changes in those devices. This "status change" program never triggers under these conditions. HOWEVER! If I run the "downstairs lights" program manually from ISY interface then the "status change" program DOES get triggered. Sunset - [ID 0016][Parent 0021] If Time is Sunset - 30 minutes Then Run Program 'Downstairs Some On' (If) Set 'Scenes / Device Scenes / Front Outside' On Set 'Devices / Master Bedroom / Master Bedroom KP Dimmer / A: Master Bedroom Outlet' Backlight On 1 / Off 0 Else - No Actions - (To add one, press 'Action') Downstairs Some On - [ID 0035][Parent 0020][Not Enabled] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Set 'Devices / Living Room / Living Room Lamp Dimmer' On 60% Set 'Scenes / Special Scenes / KitchenIslandAndSink' On Set 'Scenes / Device Scenes / Office Brian' On Set 'Scenes / Device Scenes / Office Lori' On Resource 'Hue Morracan Lamp On' Else - No Actions - (To add one, press 'Action') KitchenIsandAndSink scene: HandleKitchenKPStatusChangeA - [ID 000E][Parent 0005] If 'Devices / Kitchen / Kitchen KP Dimmer / A: Kitchen LV' Status is Off And 'Devices / Kitchen / Breakfast Dimmer' Status is Off And 'Devices / Kitchen / Kitchen Island Switch' Status is Off And 'Devices / Kitchen / Kitchen Sink Switch' Status is Off Then $kitchenKPLStatus = 0 Else $kitchenKPLStatus = 1 I have to be missing something, right? Either that or I am having bad luck and I experience interference only when the sunset program runs and never when I run it manually? Seems unlikely, so I assume that I just don't understand something about how ISY programs execute in different situation (i.e. scheduled vs. manual). Any thoughts? Thanks!

@Javi, do you guys collaborate with the MobiLinc guys to resolve issues? Has there been any communication with them about the possibility that something with the MobiLinc portal is causing issues?

@Javi, not sure if you have access to the sales@universal-devices.com address, but all of my long communication via email has been there. Most recent email was sent by your team on 11/1/2021 at 10:40AM CDT. It was sent to the same email address that should be associated with my portal account that I am posting under now. I have had the UDI mobile app configured using option #2 since I upgraded to the first supported ISY version. Prior to 11/1 the app was often not responsive showing the same network symptoms that as anything else trying to interact with the ISY over Ethernet. The suggestion in the last email I had from your team was: I did this step and I reenabled MobiLinc portal after several days. I acknowledge that after this step things are better but there are still intermittent issues with anything network related including the MobiLinc app, Alexa (via MobiLinc obviously), the UD Mobile App, and any outbound connections from the ISY to Network Resources. I just rebooted the ISY. I have not been doing that on a regular basis like Dennis has been since I have just been living with the degraded functionality. I will see if that makes anything better and will keep an eye out for any errors that show up in the UD Mobile App. Like I said the issue is intermittent. As of right now, after the reboot things seem okay. I have a CS background and though I know that the ISY is a real time OS which is different than the preemptive multitasking systems I am used to, the way I would describe the behavior is that the ISY appears to me to be in a spinlock or thread blocking situation when this is happening. I theorize that the MobiLinc portal is probably at root cause, leaving sockets open, but that the ISY TCP/IP stack is not dealing with this well. I could be totally wrong, but that is what it feels like to me based on my experience. Attached is my most recent error log just collected now after reboot and trying some network stuff. ISY Error Log.v5.3.4__Wed 2021.12.01 07.12.52 PM.txt