oberkc

I think were I to desire to do what you described, the best approach I can think (until isy v5) would be a combination of mobilinc and programs. Create a program for each interested condition (dinner guests, weekend away, overnight guests, etc....). Each program would be completely blank (if triggered entirely from the phone) If Nothing Then Nothing Else Nothing Once established, these programs are visible from mobilinc. Using mobilinc "run then" or "run else" clauses for any of these, you would be setting the programs as TRUE or FALSE. This program status could then be used as conditions for other programs and react accordingly. It is an approach only a mother could love, but it would be functional.

Or, even simpler, forgo the program and variable. The folder condition could be as simple as If status kpl button is on Then Enable programs in this folder to run This is how I do it. Unfortunately, this does not solve the virtual button problem. I use a combination of tasker and mobilinc to create buttons on one of my android home screens, but I have yet to find a way for that virtual button to change (light/dark) as an indication of current status. I understand tasker widget icons are static images. Perhaps I am missing something.

I should have been more clear. When I suggested apps and computers talking to insteon, I was thinking broader than a dedicated app or software. I was thinking more universal integration, where all apps can trigger insteon events, not just one or two apps, or vice versa. For example, my mail and calendar apps could trigger an insteon scene. Or the ISY could send a text message from hangouts. Or the ISY could trigger the remote control app to turn on the tv or music. With regards to the original request, it seems an ultimate goal would be for the ISY to integrate with whatever calendar application one uses, allowing one to define a given day as a work, holiday, vacation, weekend, party, and have the ISY react in a coordinated fashion without having to recreate the calendar in the ISY. But, for now, I think annual and monthly days in theISY would be a great start.

If I had to identify the one shortcoming with ISY organic programming capabilities, it would probably be in this area. I have always wanted the ability to be more generic in specifying times and dates, such as If april first of any year If holiday, If on vacation Integration with a shared calendar such as outlook or google or ical or whatever would be wonderful. I understand this is "on the list" of improvements, by not as high a priority as I would prefer. Someday, I may take the time to do what you are about to do, but not now. I agree that this has broader implications than a simple trash notification. Perhaps, too, that a smart home is not a single device that does everything, but a well-integrated ecosystme where your phone, apps, computer, calendars, hvac, all can talk to each other and trigger events.

Good. I am glad you found that wiki article. This is one of those cases where I have decided that the the payoff is too low for the amount of work required. My approach would simply be If Thursday Send notification In the notification, I would simply include a reminder to self to wait an extra day if there was a holiday this week.

There is no reason that I can think of to avoid using the else path of a program. So long that one understands program triggers and evaluation logic, they are a powerful tool that would be silly to ignore. I suspect most of the reason you see empty else statements is based on need rather than some inherent flaw. Coneceptually, I see nothing wrong with your "not a holiday" program. Yes power failure could be a practical concern. Another might be how you intend for the ISY to know whether it is, or is not, a holiday. That is more complicated than it sounds. If you desire to be somewhat tolerant of power failures, I would simply break this into two programs If not a holiday And thursday Then Send notification Else nothing If a holiday And friday Then send notification Else nothing But, your bigger problem, I suspect, is programming the ISY to know what days or weeks are holidays.

Perhaps accessing the admin console from a browser would avoid the problems. My use of the dashboard has been limited to device and scene control. I have never experienced your problems using the browser method.

Not necessarily. I would try control. Hopefully, the fix is this simple. (I note your test program uses control.)

Perfect!

WRT thewabit program, the other boundary problem that could (conceivably) arise is is sunrise occurs during the wait period. If so, the lights would remain on indefinitely.

I have not taken the time to fully understand you different variables and devices. One thing, however, jumps out at me. The program condition: " Status 'Gate Outside Safety Loop Sens' is On" Why are you using STATUS rather than CONTROL?

Aha! Now I see. I think I would simply avoid any looping or waiting, and add a second program like miked suggested. A couple of other thoughts....what if the door was already closed when you leave the geofenced area? Are you not concerned that this will open the door? Have you considered configuring your relay into momentary mode and relying on this (rather than a program wait statement) to pulse your relay?

Sorry. I misunderstood. The only thing I see that runs "just after midnight" is 7n your second program, and it does nothing that I can see. What program do you expect torun after midnight that "adjusts the lights down further"?

First problem...you are not checking the sensor status....you are turning the relay on, then off. Second problem...relays will not transmit status. Third problem...there is no need to query any insteon device for status. Most insteon devices transmit any change in status. If the sensor were to change state, it would transmit this change. Any other insteon device that cares, including the ISY, would know of this change and react accordingly. Correction to my original post...it is miked's approach that I like. Sorry.

I briefly mentioned the need for a scene in my original response. Create a new scene. Include in this scene the keypad button, as responder, nothing else. In the program, include a statement to turn off the new scene.

The program suggested by themlruts is how I would do it. " I just don't understand how I can loop and continue to query the sensor until closed." Why do you believe there is any need to loop anything. When the sensor changes, it will tell the ISY. I also don't understand you purpose in the one second cycle of your relay. Is the relay connected to anything?

What makes you think the 9pm program did not run? Is it disabled? If you check program status after 9 and before midnight, does it show TRUE? What evidence is there that the 11pm program did not run? Are you basing this upon the fact that the backlight levels remain unchanged?

The brute-force method would simply be to add a statement at the end of your program to turn off the kpl button. If this button is a secondary button, you may need to create a new scene, containing only that button, and turn the scene off by program. An alternative, depending on your needs, is to create a scene with the ROG keypad controller and chandelier as responder, and modify the program: If CONTROL 'ROG Other.... Then Set moms bedroom kpl on Wait 5 minutes Set new scene off Else Nothing

Also, not all plms are dual band. Is yours? Are you plugging the hub into the same outlet as the plm?

That is quite interesting. Most of the time, with my dedicated tablets that never leave the house, I dont percieve any latency beyond about a second. Perhaps mobilinc on these units dont go through an "initial refresh"? Keep us informed what you come up with. What I would like, but have not yet figured out, is a widget that changes (dark and light, perhaps), depending on state of an insteon device or scene. In other words, I would like a widget that simulates a keypadlinc.

Because of my problems revealed when I upgraded to android 5.0 (thread created in the mobilinc forum), I have suddenly become keenly aware of sluggishness when connected via https connections. In my case, I dont use my phone much around the house, and use other tablets connected solely via local http connection, which is quite fast. With the phone (both cellular and wifi data) and mobilinc, I have yet to Establish a good understanding of how mobilinc transitions from cellular (https) data and wifi (http) data, but I can say that tablets are alway on http connections, and they are fast. Cell phones, when on https connection, have a response lag that can be near 30 seconds in my case. I also believe that if I am home, the phone on wifi, and I continue to see those delays,that mobilinc has not made the transition to http non-secure connection. My point...if you are seeing delays when on wifi, consider the possibility that you are still on https secure connection and have not transitioned to http as your settings suggest should have happened.

Mwareman, Thinking a little further about my approach and your comments, I believe you are correct about one problem with my approach. Unfortunately, I use these toggle widgets sparingly, and in situations where they are the only mechanism that can control the scene. To avoid hav7ng the toggle widget get out of sync, I might choose instead to pick one de ice in a scene as an indicator for the scene state. Then I would use the indicator device as a condition in a program. If Status Indicator device is off then Turn scene on Else turn scene off

The program I posted i disabled to avoid having it otherwise react to changes in status. The only way it can activate is if called by mobilinc. I hav never noticed any problems with mobilinc sync operations. Your proposed approach to the fan problem is near exactly how I would approach it. Like the first, I would expect these would need disabled.

I do toggle tasks with tasker widgets, if that is what you seek. First, i create program (disabled) such as: If This program is false Then Turn light on Else Turn light off I then create a tasker widget, through the mobilinc plug-in, that executes the program if path.

In some cases, I have become a fan of the harmony hub. This would require no line of site between remote and ISY, so long as one of your hub blasters is pointed at the ISY. Alternatively, I see no reason it could not be used to transmit IR commands to the ISY through an IRLinc. It has been a while since I programmed the IRLinc, but I recall that it could learn pretty much any IR command and execute a program from that command as a trigger. I think the IRLinc directly supports scenes, as well.