Query and Resume

[sfhutchi]

I know that there is a function to query certain devices (or all devices), but can these be saved?

 

For example, if I have something trip a certain scene like an 'all on' for security purposes (say a motion sensor trip)... can I change the settings of these devices but then return them to their original settings when the program was first triggered?

 

For example:

 

Query Device A

Query Device B

Query Device C

Run Program Security Lights

Wait 10 Minutes

Resume Device A

Resume Device B

Resume Device C

[Michel Kohanim]

Hi sfhutchi,

 

Interesting but why would you want to change the settings? If you do an All On (My Lighting->On), then all devices will turn on, ISY is updated with their status, and when you turn them off, ISY is updated yet again with the correct status.

 

Would you be kind enough to elaborate a bit?

With kind regards,

Michel

 

I know that there is a function to query certain devices (or all devices), but can these be saved?

 

For example, if I have something trip a certain scene like an 'all on' for security purposes (say a motion sensor trip)... can I change the settings of these devices but then return them to their original settings when the program was first triggered?

 

For example:

 

Query Device A

Query Device B

Query Device C

Run Program Security Lights

Wait 10 Minutes

Resume Device A

Resume Device B

Resume Device C

[MikeB]

I think he wants a scenario where, say, his security system alarm goes off for some reason.

 

When it does, the ISY-26 would turn on all lights in the home. Once the alarm is de-activated, he wants the lights to turn back to their previous states (not all off).

[Michel Kohanim]

MikeB,

 

Aha! That makes sense but a little difficult to implement mostly due to limited resources on the box.

 

We shall investigate since I think this would be a great feature.

 

Thanks and with kind regards,

Michel

 

I think he wants a scenario where, say, his security system alarm goes off for some reason.

 

When it does, the ISY-26 would turn on all lights in the home. Once the alarm is de-activated, he wants the lights to turn back to their previous states (not all off).

[Mark Sanctuary]

You could have a command that snapshots the current state of any scene device list; in this case My Network. Then run the security scene. Finally use a Restore state command and all is back to the way it was. This would be a very cool feature.

 

Save Snapshot 'My Lighting'
Run Program 'Security Scene'
Restore Snapshot 'My Lighting'

[Sub-Routine]

I was going to roll my own for this situation.

 

I already created programs using Fast On. Any of our outdoor light switches and several inside switches will start a program that will quickly turn on all my indoor and outdoor lights used in my normal lighting scenes (evening, midnight, dawn, daytime.) It will also trigger a few key lights to fast on as well, and of course a fast on back to the scene initiator switch because more than likely this switch would be dimmed in any of my scenes. All the lights in these scenes are common area lights; outside doors, the sidewalk and driveway, hallways, foyer.

 

I've got that going so far.

 

After an allocated delay I will simply call the scene normally used during the current day and time. Wait with a wait random time added, 10 minutes + random 10 minutes perhaps. This could be unique to each switch.

 

I haven't messed with that yet, but I don't believe it will be very difficult.

 

I am rather sure that I would want to sometimes be able to override the normal scene resume...

 

Rand

[sfhutchi]

I think he wants a scenario where, say, his security system alarm goes off for some reason.

 

When it does, the ISY-26 would turn on all lights in the home. Once the alarm is de-activated, he wants the lights to turn back to their previous states (not all off).

 

Exactly. I realize that it would require some resources to do it, but maybe something like this could be implemented in a limited fashion.

I realize that there are some ways to implement some programs to return to some level... but in each of these cases you have to 'assume' what the settings were.

[Sub-Routine]

Irealize that there are some ways to implement some programs to return to some level... but in each of these cases you have to 'assume' what the settings were.

 

If regular schedules are on I know what the settings are. As I stated, these are all common area lights. I don't think it will hurt anyone to return the common lights to known values for the day/time. If it does they can use another controller to modify the devices they are using.

 

If unexpected guests arrive I might want to change the schedule. If it's just someone coming home the wait command should be perfect.

 

Rand

[sfhutchi]

My thought is that the 'reality' of a household is that the wife, the kids, and the guests use switches and dimmers as they see fit. If I have a triggered event, I would like things to go back 'as they were'.

 

My general theme on any of the automation that I am doing is to make it as unobtrusive as possible.

 

I think that you solution is good, but there will likely be those scenarios where someone changes one of the settings and then you return to your programmed scene. Eventually after enough annoyance, you will adjust your scene to match the new 'preference'.

[Mark Sanctuary]

You know the resources might be small if it was implemented with only trying to return device levels as there where before. The scene provided in the "Save Snapshot" would be the device list to key off of and you could create an indexable lookup list. Then the scene device list could be gotten again in "Restore Snapshot" used again to go thru the list to return levels.

 

Save Snapshot

 

Retreave the Scene device list:
Light1:Light2:Light3:Switch1:Light4:Light5:Light6

Store level data in same order as scene list so indexing would match:
30:30:60:ON:OFF:100:0

Restore Snapshot

 

Retreave the Scene device list again for indexing the data list:
Light1:Light2:Light3:Switch1:Light4:Light5:Light6

Look up the data by index with the scene list:
30:30:60:ON:OFF:100:0

This is a high level concept so I am guessing there is some low level stuff I am not accounting for. I think the only stored data would be the levels.

 

If wanted it could be done with a normal hash table too then the indexing would be automatic but would use a bit more memory to store the names in the array too.

[sfhutchi]

I like it Mark. This is probably something for a future version as I know that these guys are interested in releasing 2.5... but I hope that it becomes feasible to do this at some point.

 

It is amazing as I look back though at the major functionality improvement that we have seen with the ISY. It went from a nice standalone scene editor with basic scheduling and triggers to a full-blown complex programmable home automation appliance for Insteon and X10. This all in such an incredibly short time.

 

I can't wait to see the future innovation out of these guys!

[Michel Kohanim]

sfhutchi, Mike B, Rand, and Mark:

 

Thank you so very much for the feedback and the brainstorming. I must admit that on this point I am more in tune with Rand. This said, however, I do understand that switches/lights would never stay at their preset levels especially if you have kids.

 

The technical difficulty is not about coding; it's about managing the resources while being the least obtrusive.

 

Let me elucidate:

Let's assume you have 40 devices and a trigger that turns on a scene with 20 of your devices. Let's assume that these devices each were at different levels prior to the trigger. Now, let's say you want to store the state of each and every device. This means that ISY has to send 20 commands to 20 devices which should take approximately 15 to 20 seconds if you have a flawless INSTEON network. If you don't, then add 4 seconds for each "misbehaving device".

 

Now, during these 20-25 seconds:

a. All the schedules are delayed 20-25 seconds (have to wait for the queue to finish)

b. Any communications from Admin Console to INSTEON will be queued and thus delayed 20-25 seconds (you won't even be able to do it since the System will be busy!)

 

So, the more devices you have, the more the delay, the more the likelihood of communications errors, etc. If you add more of these triggers, then there's nothing to prevent this scenario to completely hog the network/ISY resources and stop all other activities. And, this is precisely why group commands/scenes are so wonderful: they only take one operation.

 

Similar ideas which are less obtrusive could be:

1. Capture and apply the current state of the devices within scenes. So, for instance, your kids adjust the levels for your dining room scene to a level that makes the most sense. You simply go to the controller for that scene and apply the current state of each device to that controller

2. Some type of pattern recognition based on ISY's log entries

 

With kind regards,

Michel

[Mark Sanctuary]

I started to realize I was not taking in to account the idea of sending non group commands for all the levels. This is going to take a bit more thought.

[sceaton]

I started to realize I was not taking in to account the idea of sending non group commands for all the levels. This is going to take a bit more thought.

 

I see this as more of an issue than Michel's comments ... I thought the ISY kept tabs on the network and updates it's record of what state each device is in based on network traffic. Hrm. Although ... I guess if the ISY hears "Device A Brighten" it doesn't know just how bright "brighten" is without querying it afterwards.

 

Okay, so capturing an accurate "snapshot" (quickly!) IS a problem.

 

Then, when you want to "restore" the settings to the snapshot levels, the devices are not in a scene or group (as you were saying, Mark), so they would have to be changed one-at-a-time, which isn't very classy.

 

Not to be a pessimist, but this (cool feature) has some pretty big hurdles.

[Michel Kohanim]

sceaton,

 

Just for clarification purposes:

 

I see this as more of an issue than Michel's comments ... I thought the ISY kept tabs on the network and updates it's record of what state each device is in based on network traffic. Hrm. Although ... I guess if the ISY hears "Device A Brighten" it doesn't know just how bright "brighten" is without querying it afterwards.

 

Not entirely true. ISY calulates/predicts what the value should be regardless of what you do and from where (the physical device itself or ISY) including brighten/dim. Infact, you can test this scneario and you'll note that ISY is usually within +/- 5% accuracy of the actual state. Therefore, ISY does keep tab of the state of devices without having to query them after each command.

 

If you want 100% accuracy, then you can activate the Query schedule which currently runs at 3:00 AM (or whatever time you might have readjusted it to).

 

With kind regards,

[sceaton]

+/- 5% is impressive!

 

Cool, so I guess the biggest thing, which there really isn't a workaround for, is having to restore each device individually when restoring to the snapshot.

[Mark Sanctuary]

I guess the best way is go try to figure out what scenes where on and turn those back on. That would be much less Insteon traffic unless there is many scenes on then it would take several scene requests.

 

I wonder if there is a way to look at this by subtracting the security scene. I am trying to think outside of the box, the hard part is the Insteon protocol has us boxed in on this idea.

 

This is getting more difficult as I think about it. Geese.

[Mark Sanctuary]

Insteon does not have a live scene command. It has to activate scenes that are already loaded in each device. I think the device is always listening for its scene to be called, and if it hears it on the network it activates that scene.

[Michel Kohanim]

sceaton,

 

Precisely ... that's the major obstacle.

 

Mark,

 

I agree with your suggestion (turning back on the scenes) which is equal to what Rand was suggesting.

 

With kind regards,

 

+/- 5% is impressive!

 

Cool, so I guess the biggest thing, which there really isn't a workaround for, is having to restore each device individually when restoring to the snapshot.

[Sub-Routine]

Eventually after enough annoyance, you will adjust your scene to match the new 'preference'.

 

That is a good idea, though it should not be considered an annoyance. The ISY makes it very easy to change scenes or create new scenes.

 

As I said, I am calling only lights unlikely to be changed by users. I am not including any room lights in the quick on scene or the fast on devices.

 

B forbid I ever again put timers on the Kitchen or Dining room. That trial lasted for about three days and four nights many years ago. She is happy with the ControLinc Living room, but, like I, am still figuring out a KPL for the Family room. I bought a RemoteLinc and it's still a tossup. The timers are effective 90% of the time.

 

Rand

[sfhutchi]

Eventually after enough annoyance, you will adjust your scene to match the new 'preference'.

 

That is a good idea, though it should not be considered an annoyance. The ISY makes it very easy to change scenes or create new scenes.

 

Yes... I don't mean that creating a new scene is an annoyance, I meant that if the system allowed you to take actions for specified activities and then return to whatever state they were in... this (in my mind) is less of an annoyance then it always returning to what I (the scene programmer) thinks that it should be at that time. I want my programs to be able to react to the changing environment.

 

For example,

 

Right now I have some hall lights come on at a very dim level at some time in the evening. This works fine, but many times people are turning them up... or off. No problem... that is what switches are for.

 

My next step is to add some motion sensors to these areas so that I know when people are in this area. Based off their presence, I will want to go to a higher brightness level for a period of time and then return to wherever it was previously set. This is less obtrusive (and more adaptable to the standard home environment) than returning to the scene that was originally scheduled at that time.

 

Possibly there are ways to get closer to where it was by creating multiple programs with one looking for a light off, and one looking for a light on and then at least trying to match it a bit closer there. I'll have to experiment a bit with it... but it certainly would be nice to be able to return to the 'level' in progress.

[Michel Kohanim]

Rand,

 

I agree with you 100%.

 

sfhutchi,

 

I do agree with your premise as well as the fact that something should be done about it. Again, the problem is not the coding; the problem is how to avoid delays/network traffic/unexplained behaviors when ISY is trying to set all those devices back to their previous state. Any ideas?

 

Thanks and with kind regards,

Michel

[sfhutchi]

My current thought is to at least try this with a very limited implementation. For example, allow the ability to save and resume just 1 or 2 devices to start. Maybe this is something for a parallel Beta (or Alpha) activity??

[Michel Kohanim]

sfhutchi,

 

Let's see what we can do ... no promises but I do think this is a valuable feature.

 

With kind regards,

Michel

My current thought is to at least try this with a very limited implementation. For example, allow the ability to save and resume just 1 or 2 devices to start. Maybe this is something for a parallel Beta (or Alpha) activity??

[sfhutchi]

... no promises but I do think this is a valuable feature.

 

I understand. I guess that it is a good sign that we have already been talking about new features... meaning that we are very comfortable with the current functionality.