Google Home doesn't know if scenes are on are off. Can this be fixed?

[bruceyeg]

I have a scene called "Home Motion". If I ask Google Home if it is on, GH replies "That mode isn't available for the Home Motion".

 

However, I can tell GH to turn Home Motion on or off and these work. Is there any reason why the Portal doesn't tell GH whether of not a scene is on or off?

 

Another example. I put a KPL6 in the wall switch that controls my bedroom ceiling light. I needed a KPL6 to control a few more things around the bedroom. However, I had to do some rewiring to make this work well. The power for my bedroom light goes to the box in the ceiling and originally the wall switch did not have a neutral wire and had to operate wirelessly without powerline signals. So I changed one wire so the wall switch has hot and neutral wires. Then I put a micro dimmer switch inside the ceiling box. To make this work I setup a scene where the wall switch (called Bedroom) controls the scene, and micro switch in the ceiling (called Bedroom0) is the responder. These work perfectly.

\

However, when I setup GH to control my bedroom lights I had 3 options:

 

1. Make GH control the device Bedroom0 in the ceiling

2. Make GH control the device Bedroom in the wall switch

3 Make GH control the scene.

 

Option 1 has the advantage that GH always knows if the light is on or off, but the wall switch shows the light is off after I've turned it on with GH.

 

Option 2 doesn't turn the light on. The wall switch turns on and off but the scene doesn't.

 

Option 3 works properly. However, GH doesn't know if a scene is on or off. I need to know which lights are on so I cannot use option 3.

 

The best way to program GH would be to use option 3, but then the Portal has to tell GH if a scene is on or off. 

 

Can this be fixed?

 

Thanks, Bruce

[stusviews]

No Insteon manager knows if a scene is on or off, not even the ISY. The Insteon protocol does not have that function, probably because turning the scene On can turn devices ON or OFF. In fact, my movie scene dims some devices and turns others off.

 

You'll need to determine the status of specific device in the scene.

[bruceyeg]

In the Admin Console, I see that under Main Network, the list of devices that are on or off doesn't include any scenes. This supports what you say.

 

However in the Console, all my scenes are listed and I can choose any one of them to see if it is on or off. Doesn't this mean the ISY knows and might be able to tell the Portal to let GH know?

 

If what you say is correct, then it might be possible to make the portal setup a little more complicated. If you tell the portal to turn a scene on or off, maybe you could also specify a second device (besides the scene) that the portal would use to determine if the scene were on or off.

[stusviews]

You can query any device in the scene that you've also added to the portal and Alexa unless turning the scene on turns that specific device off. You don't need to add an extra device. However, you need to ask Alexa tell Izzy to get the status of the device.

[apostolakisl]

In the Admin Console, I see that under Main Network, the list of devices that are on or off doesn't include any scenes. This supports what you say.

 

However in the Console, all my scenes are listed and I can choose any one of them to see if it is on or off. Doesn't this mean the ISY knows and might be able to tell the Portal to let GH know?

 

If what you say is correct, then it might be possible to make the portal setup a little more complicated. If you tell the portal to turn a scene on or off, maybe you could also specify a second device (besides the scene) that the portal would use to determine if the scene were on or off.

 

When you select a scene on the console, it lists the devices in that scene and their status, it does not list a status for the scene.

 

What it means for a scene to be "on" is not exactly clear.  I suppose, it means that every device in the scene is at the exact level that the scene dictates.  But generally, that does not work out how you might want it.  If scene 1 is turned on, and then a single device in that scene is later changed, perhaps only slightly, maybe from 80% to 50%, is the scene now off? 

 

Some of the third apps offer an option to designate a device in a scene as the "flag" for that scene.  If that device matches the scene level, then the scene is "on".  I think that is a reasonable approach, but requires that you manually define the device or devices that meet criteria.  

[bruceyeg]

Some of the third apps offer an option to designate a device in a scene as the "flag" for that scene.  If that device matches the scene level, then the scene is "on".  I think that is a reasonable approach, but requires that you manually define the device or devices that meet criteria.  

 

I like this suggestion. Maybe that could be implemented in the Portal.

 

So far I've learned that (in the case of my bedroom light), the Portal should be able to turn on both the scene and the the mini dimmer device in the ceiling. These are options 1 and 3 at the start of this post. This will allow me to turn the light on and off and the wall switch will match the light because the scene is also being turned on or off. 

 

Now when I ask GH what lights are on the bedroom. It should look at the device Bedroom0 and tell me the correct status of the light.The problem is that it will also tell me about the scene and then I get an error message from GH.

 

These error messages can be annoying. For example,I have a "room" called "configuration" which has 5 scenes. Every time I ask which is on GH says:

 

"Unable to reach 5 things. That mode isn't available for 5 things."

 

I shouldn't have to always listen to these error messages every time I ask what is on. I don't think GH can be configured not to report these error messages. The only solution I can think of is for the Portal to provide answers when I ask what is on.

 

I would like to be able to define a device to act as a flag for the scene and have the Portal respond to GH with an answer rather than error messages.

[larryllix]

Read post #5. It will never be so.

[bruceyeg]

I agree completely with post #5. It makes the point that in the general case you cannot say a scene is on or off. 

 

My concern is not some abstract general case. I would like GH to give me useful information rather than annoying error messages in certain situations where that makes sense.

 

I will explain how some fairly minor changes in how the Portal works will solve my problem. What I'm proposing is optional. If you use scenes and you like hearing the error messages from the Portal my proposal will allow you to continue to receive error messages. However, in certain cases the portal can use a "flag device" and report back that the scene is ON or OFF according to whether the flag device is ON or OFF. 

 

A simple example where this would be useful is my bedroom ceiling light. This involves 2 devices and a scene. These are:

 

BedroomCeilingFixture - a device - Insteon mini-dimmer switch in the light fixture

 

BedroomWallSwitch - Insteon KPL6 on the wall location that used to control the ceiling light

 

BedroomLightScene - scene - controller is BedroomWallSwitch, responders are both of the above devices.

 

Suppose I put the scene into the Portal and call it "bedroom light". Suppose I also put BedroomCeilingFixture into the Portal and call it "bedroom light fixture"

 

Now when I ask GH "what is on in the bedroom" it will tell me whether "bedroom light fixture" is ON or OFF because that is a device, and that is what I want to know. But it will also tell me that it is "unable to reach the bedroom light. That mode isn't available for the bedroom light".

 

My proposal is to enhance the Portal so that it can (optionally) use a flag device. Then I would put the scene in the Portal but not the BedroomCeilingFixture. Instead, I would make the latter the FLAG DEVICE for the scene. When I ask the Portal what is on in the bedroom, it would report back the state of the flag device.

 

The advantages of this approach are:

1. There is only one device the Portal instead of two

2. I don't have to listen to error messages that tell me nothing.

3. I can now use scenes in the Portal. I've been avoiding them because the error messages are so annoying.

 

I've done a lot of programming and have a pretty good idea how the Portal works. The changes needed are minor.

 

When I ask GH what is on in my bedroom, GH converts my request to text and sends it to a Google Home Manager (my terminology) in the cloud. The GHM looks up "bedroom" in a dictionary and decides that this question can be handled by UDI's Portal. I've also told GH the room every device is located in. So the GHM looks up the devices in that room and includes this list of devices in the request it sends to UDI's Portal for the status of these devices. The Portal passes the request to my ISY. The ISY then replies to the Portal, which passes the response it back to the GHM, which sends the answer to my Google Home as text. The latter  converts text back to speech.

 

When the Portal uses a scene, the error message could originate from 3 possible stages in this process:

 

1. GHM might have is its dictionary that the ON/OFF mode is not supported for a scene

2. GHM might pass the scene request to the Portal, which knows that the ON/OFF mode is not supported for a scene.

3  GHM could pass the request through the Portal to the ISY which responds that ON/OFF is not supported.

 

What I propose is that the GHM should pass a status request to the Portal even if it is for a scene. 

 

When the Portal gets a status request for a scene, it should determine the matching FLAG device and query the ISY for the status of that device. The answer will be ON or OFF and that should be returned.

 

On the other hand, if I ask GH to turn on the scene, the Portal should pass that request to the ISY so the scene gets turned on.

 

The use of a FLAG device should be purely optional. Anyone who doesn't like my proposal doesn't need to use any flag devices. I want them to be available for those situations where useful information can be returned by the Portal to my GH.

 

The programming change in the Portal is minor. An extra field has to set aside in a data structure. This field could have a pointer to the flag device if one were specified. 

 

The changes in the Portals web UI to implement this are also quite simple.

 

After you log into the Portal, click Select, and choose Amazon Echo/Google Home, you get a popup window called "Amazon Echo device list" At the top is says

 

Add / Device / Scene / Program / Variable

 

I propose changing this to read

 

Add / Device / Scene / Scene Flag / Program / Variable

 

The only change in the device list would be that some devices would be called "scene flag" (or maybe just "flag")

 

A new popup window would have to be created for adding a scene flag. That window would be similar to the other windows you use for adding things, but with a small change.

 

The "Scene flag" creation window be called "Scene flag mapping" and would require that you NOT use a scene (because a scene flag cannot be a scene).

 

This window would not have the entry box called "Spoken"

 

Instead of a Spoken entry box, there would be a box with a drop-down list of scenes that have already been entered into the Portal. These scenes already have the spoken phrase defined in the portal. The "Scene Flag" device would use the same spoken phrase.

 

On the main popup windows called "Amazon Echo device list", the Scene Flag you added would appear that marked as a "flag" and the spoken would be identical to the matching scene.

 

If you sort this list according to "spoken" and entries with identical spokens would appear together. Thus sorting this way would cause every scene and scene flag to appear together on the device list.

 

My proposed changes to the Portal's UI are minor and the changes in the code in the Portal that direct queries to the flag and turn on/turn off requests to the scene are not difficult.

 

Moreover, those of you who don't like this idea wouldn't need to set up any scene flags in the Portal. Everything would continue to behave as it now does.

 

One big advantage of my proposal is that no changes need to be made to the code in the ISY. Every change is in the Portal. So I am not asking for the ISY to have and ON/OFF state for scenes.

 

I can think of a lot of advantages for scene flags other than my bedroom light.

 

In my house a have a lot of KPL6 and KPL8 devices which I use to control my ISY. The only way you can turn the buttons of these device on or off is by using scenes. The scenes I use of my KPL6 and KPL8 turn matching buttons on and off on a number of KPL6/8. 

 

Thus, I have an "Away Errand" button by each entry to my house. If I turn this button on or off, all the matching buttons go on or off throughout my house.

 

Now with GH, I can say "turn on Away Errands" as I leave to go shopping. 

 

My "Away Errands" scene is in a room called "Configuration". If I ask GH "What is on in Configuration?" I get the response that a large number of things cannot be reached and that mode isn't available for all this things"

 

If I had "scene flags" I could get a lot of useful information when I ask what is on in Configuration.

 

When I press a configuration button on a KPL8, it could run a program, set a variable, or turn on a device. I would like to be able to assign a program, variable or device as the scene flag.

 

I know there are scenes where the ON/OFF could be ambiguous. I wouldn't bother defining a scene flag for those. My main point is that scene flags and be very useful and powerful. They can eliminate a lot of useless error messages.

 

I hope this convinces the people who could implement this.

 

Bruce

[larryllix]

You could create a variable in ISY and a program to detect the level of every device in your scene. If the levels match, within an allowable tolerance, you could use the variable as a flag to say the scene was On.

 

Now you should be able to determine if the scene was on to suit your purposes. If you can fake a scene status using a single device, you should be able to fake a scene status using a variable and that capability already exists.

 

I try to avoid usage of scenes with ISY. I only use scenes where the Insteon traffic quantity would be too slow, or where I need the speed of response. If the Insteon protocol was faster I would only use ISY programs.

[stusviews]

A disadvantage of using programs where a scene would suffice is that programs depend on the ISY to function, scenes do not.

[kck]

This flag idea is very close to what I do in my soft console program.  Since I want to reflect the status of simple scenes like 3-ways on the console it automatically will pick one of the devices in the scene to use as a proxy for the state of the scene and use that when it needs to decide what to display.  That works for 90% of the cases.  For the rest I also allow the explicit designation of a proxy device to represent the scene status in which case that device is used instead of the randomly chosen one.  Works really well.  I can really understand why something similar would be good for this case.  Actually, this function could be done in the ISY itself by allowing scenes to have a proxy defined there.  That would actually be an even better place for it since it would centralize the information in one spot rather than having it spread across different places.  Perhaps in the V5 stuff a node type could be defined that was a responder only and could be instantiated and added to a scene.  That would make scene status look like just another device.  In the long run it might also allow for a more flexible (by the user) definition of what scene "status" might mean in cases a bit more complex that the 3-way like cases.

[bruceyeg]

There is another big disadvantage to using programs. The ISY remembers whether the program is TRUE or FALSE the last time it ran. If TRUE Google  Home will say the program is ON. FALSE is OFF.

 

If you ask GH to turn on a device using a program, GH will always report that the device is ON, unless you run the ELSE block of the same program. Then GH will report the device is OFF.

 

If the device is turned on or off by any other means than this one program, GH will not tell you whether the device is actually on or off. It will report on the program that last time it was run.

 

I gave up on using programs. However, I will use them in the future. The programming in the ISY has to be setup so that one program always runs to control something. That way the program actually does show what is on or off.

 

Regarding scenes. The name "scene" suggests a room with many lights with various levels of brightness. Scenes may have been originally setup with that in mind. I rarely use scenes that way.

 

There are 2 other important ways to use scenes.

 

1. If a wall switch has to control a light but the house was not wired so that the Insteon wall switch has both a hot and neutral wire plus a third wire that goes to the light. In such cases many people use 2-wire Insteon switches, which rely completely on RF. Because my wall switches are in metal boxes and don't receive RF very well, I've rewired my house so those locations where a 2-wire switch would be needed now have a hot and neutral wire inside the switch. That makes it possible for the switch to use Powerline signals and not depend completely on RF. However, to do that I've had to remove the wire that the switch previously used to control the light. Instead I made this wire into the required neutral wire. Now my switch works with Powerline signals, but the only way to control the light is with a scene.

 

When I use a scene this way, the link table in the wall switch and light fixture both have each other's Insteon ID and communicate directly. The ISY isn't involved. When  a wall switch is wired this way the ceiling light responds instantly to the wall switch. A person using the switch would never guess that they were communicating with only Powerlline signals. I guess that it why they named it Insteon. It works fast because the signals between the wall switch and ceiling light only have to travel about 10 feet.

 

Because of the way my house was wired, about 2/3 of all my lights use scenes in this way. Another reason for so many scenes is that everywhere I used to have a 3-way switch (garage, stairs, entry, driveway, ...) I also had to wire it up so all the switches got a hot and neutral wire so they could use Powerline signals, and then the only way to make these work normally is with a scene.

 

In all these cases my "scenes" are not like in a Home Theater setup where various lights are dimmed or brightened. My scenes are usually just ON or OFF. I just need to be able to ask Google Home what lights are on and have it tell me, even though I'm using scenes to control lights.

 

2. The third important way to use scenes is for KeypadLinks. The buttons on these cannot be turned on and off directly like a switch. The only way to control them is with a scene. These buttons can be used to dim and brighten lights, but most of the time for me they are ON or OFF.

 

For example, here are some buttons that are ON or OFF

 

AWAKE - on if I'm awake, off if I'm asleep. Pressing the button in the morning wakes up my house. Turning it off at night shuts everything down.

 

AWAY ERRANDS - on means I've left home. The lights in the exit stay on awhile and then the whole house switch to "Green Lighting Mode" which saves energy. When I come home, I turn this off, and my house reconfigures  itself.

 

AWAY VACATION - same as ERRANDS except that the thermostat is lowered, and cooling is turned off. Also, my house shuts down and wakes up on a schedule.

 

MOTION - when this is on, lights turn on automatically in occupied rooms. Lights in all unoccupied room are set to the default. As I walk around the house the lights adjust automatically. When I turn this off the lights do not ajust to occupancy. However, they do adjust throughout my house to the time of day, according to the light levels set in my Lighting Mode

 

GREEN LIGHTING, COZY LIGHTING, GUEST LIGHTING, BLACKOUT LIGHTING. These are lighting modes that determine the default level of light throughout the 24 hour days. These are setup so that only one lighting mode is on the rest are off. I can turn them on with Google Home.

 

All these controls are in GH in a room that I call Configuration. Because they are all scenes, when I ask GH "What is on in configuration", GH replies "Unable to reach 10 things. That mode isn't available for 10 things."

 

All I want is to have flags so that I can ask GH if my lights and scenes are on and get and answer, not an error message.

Edited July 24, 2017 by bruceyeg

[larryllix]

This flag idea is very close to what I do in my soft console program.  Since I want to reflect the status of simple scenes like 3-ways on the console it automatically will pick one of the devices in the scene to use as a proxy for the state of the scene and use that when it needs to decide what to display.  That works for 90% of the cases.  For the rest I also allow the explicit designation of a proxy device to represent the scene status in which case that device is used instead of the randomly chosen one.  Works really well.  I can really understand why something similar would be good for this case.  Actually, this function could be done in the ISY itself by allowing scenes to have a proxy defined there.  That would actually be an even better place for it since it would centralize the information in one spot rather than having it spread across different places.  Perhaps in the V5 stuff a node type could be defined that was a responder only and could be instantiated and added to a scene.  That would make scene status look like just another device.  In the long run it might also allow for a more flexible (by the user) definition of what scene "status" might mean in cases a bit more complex that the 3-way like cases.

I use several scenes in my gathering room that are always run from programs. These programs control 6 Insteon Switchlincs, five Hue bulbs, 5 MilIght bulbs, and 4 LEDenet RGBWW sLED strips.

 

Each program is triggered by one variabe that can contain one of a dozen numbers that represent whatever lighting combination I last wanted.

 

Anytime I want to determine the last issued lighting level in the room, Ican examine the variable for it's value.

 

There are occasions where I need to "borrow" a lamp or group of lamps for annunciation purposes. Eg. Flash a corner lamp red on and off indicating the garage door is open. Run a sequence of my Hue bulbs in Red across the back wall behind the TV each night to indicate it is midnight as a "get to bed reminder"...etc..

 

After this temporary  "borrow" I need to restore all the devices back to their "pre-borrowed" state(s). It's very easy to restore the same trigger variable value back into the variable.Of course to guarantee it triggers the program bank responsiblefor all the settings, I stuff a -1 value into it, and then replace it with the value found in it before the "borrow" that I saved in a temporary variable.

 

Having a flag available for an Insteon scene would be useless in this case as I have many more systems than just Insteon. I have no Zwave as  I have avoided it so far. Hypothetically a termostat could be included in a scene with a particulat temperature setpoint and/or fan cycle setting. What would constitute the scene being true or not true?

 

In short, if somebody wants to detect a particular and exact  state of a group of devices, write a program in ISY (a very capable logic engine) to convert a range of levels for every device, converting the amalgamated logic into one variable or program flag, true or false. That is what  ISY programmers are capable of....making specific and custom logic needs available. ISY has a very strong set of generalised tools for an HA system, already.

 

If only one device's status is all that is required then that capability is already available too.

Edited July 24, 2017 by larryllix

[apostolakisl]

Really the only way you can judge the status of a scene and not have it be wrong some percent of the time, is to do as suggested above, use programs. 

 

It could be quite tedious depending on how many scenes and how many devices in each scene, but it will work and it can be tailored to your specific idea of what it means for that scene to be on.

 

Basically, you go through all the devices in a scene and say what level each device should be, or you can do a range for each device (basically doubles the lines of code since you need a greater than/less than line.

 

If

device 1 is greater than x

and

device 1 is less than y

and

device 2 is greatar z

and

device 2 is less than a

 

and so on.

The status of the program is thus a flag for the scene.  You leave the "then" and "else" empty.

 

If you don't have overlapping scenes, and you don't ever turn control devices within a scene without using the scene, then you can just pick any device in that scene and use it as a flag.  For many people, that isn't the case.  It sorts of defeats a great deal of the reason we own Insteon and ISY, so we can have all kinds of fancy scenarious.

 

I suppose a nice feature for ISY would be to add an "auto-program".  The "auto-program" would instantly put all the devices in a scene into the "if" section of a program along with the scene deisgnated level for each device. 

Edited July 24, 2017 by apostolakisl

[lilyoyo1]

Even with your flag idea, defining a scene being on would be hard (very well impossible depending on setup). The problem (even with a flag) is that it is possible to have a multitude of different devices in many different scenes (especially in large installs). Just because 1 particular light is on doesn't mean a possible scene itself is on. 

[apostolakisl]

Even with your flag idea, defining a scene being on would be hard (very well impossible depending on setup). The problem (even with a flag) is that it is possible to have a multitude of different devices in many different scenes (especially in large installs). Just because 1 particular light is on doesn't mean a possible scene itself is on. 

I think you need to re-read my post.

[bruceyeg]

Using a program is interesting, but it doesn't solve my problem. My scene is simple. The only devices are the bedroom ceiling light and wall switch. If I want GH to turn this light on properly it has to use the scene. If  GH just turns on the device but not the scene, the wall switch that controls the device is OFF even when the light is on. Using a scene turns on the light and the wall switch. I want the wall switch to be on whenever the light is on.

 

Your suggestion seems to be that I write a program to determine if the light is on. I my case I don't need to. I can include the device in the Portal and just ask GH if the device is on. 

 

There are two possibilities:

 

1. The portal contains the scene and the device

2. The portal contains the scene and the program.

 

In both of these cases I have to use the scene to turn on the light and I get an error message when I query GH because the scene cannot respond to a query. I can still find out if the light is on because GH will tell me if the device is on (case 1) or if the program is true (case 2). In both cases, I get the error message when I ask what is on in the bedroom. My problem is that I get error messages all the time and they are annoying.

 

Considering that about 2/3 of all my lights work this way, it is a real problem for me to be getting so many error messages. A scene flag would solve the problem. 

 

If the scene flag were implemented, you wouldn't have to use it. Whether or not you attach a flag to a scene is up to you.

 

There is one way to get what I want without a scene flag. Suppose I didn't have a scene. Suppose adjusting the wall switch would trigger a program in the ISY which would control the light just as the switch does now. Because the program in the only thing that controls the light, querying the program would always give me the correct answer about whether the light is on. I could have GH operate the program and query the program and all would be well.

 

This still has the problem that I can dim and brighten the light with the switch. A program that passed the dimming and brightening to the light would not be simple.

 

The problem with using a program in the ISY is that it produces a delay. I see this all the time where motion sensors turn on lights. The sensors that are controllers of a scene that turns on a light work very fast. But when a motion sensor has to run a program in the ISY to turn on the light there is a noticeable delay. .

 

In the case of complicated scenes, the flag could also be a program. So you could write a program that checks the state of every device in the IF block, and have nothing in the THEN or ELSE blocks. This program would be triggered whenever any device changed its status and would be TRUE or FALSE according to the criteria in the program.

 

Use such a program as a scene flag would make it possible for you to ask what is on in the room with the scene and not get an error message because the scene cannot respond to a query. Instead, the query would look at your program. You would get back exactly whatever you want, even for your complicated scene.

 

As for the suggestion that this be implemented in the ISY, that couldn't happen very soon. However, the changes to the Portal that I described could be done right away and are not much work.

 

I'm happy with the ISY as it is. My problem is the error messages that I get from GH. Fixing it in the portal would solve my problem.

[kck]

@larryllix: I do use programs in a manner similar to what you sound like you are doing for complex scenes where I want to have a type of "status" for the scene.  Of course, it is a completely arbitrary notion of status for a scene defined to accomplish my purpose.  My point about the proxy or flag idea is that there are some very common scene scenarios like a simple 3 way where that is pretty serious overkill if one simply wants to know if the controlled light is on.  In that case you need to just look at the controlled device which is effectively the state of the scene.  Problem is that you either have to do the arbitrary mapping between device name and scene name which is what it sounds like the Google home solution in place does, or you need to use a program.  Neither are proportionate in complexity to what the user wants to be doing, and for a lot of newer users these are pretty weird constructs to do something as simple as asking what they see as the state of a scene.  For my console purposes I automated that by guessing,which works most of the time and allows me a manual override when needed.  It just seems that the ISY could provide a very small amount of assistance that would make this easier for the most common case and do it in a manner that is philosophically compatible with the v5 notion of virtual devices.  I can live with things as they are but variants of this discussion happen often enough that were I UDI I would seriously consider whether some additional functionality was called for to simplify the simple cases.

[larryllix]

@larryllix: I do use programs in a manner similar to what you sound like you are doing for complex scenes where I want to have a type of "status" for the scene.  Of course, it is a completely arbitrary notion of status for a scene defined to accomplish my purpose.  My point about the proxy or flag idea is that there are some very common scene scenarios like a simple 3 way where that is pretty serious overkill if one simply wants to know if the controlled light is on.  In that case you need to just look at the controlled device which is effectively the state of the scene.  Problem is that you either have to do the arbitrary mapping between device name and scene name which is what it sounds like the Google home solution in place does, or you need to use a program.  Neither are proportionate in complexity to what the user wants to be doing, and for a lot of newer users these are pretty weird constructs to do something as simple as asking what they see as the state of a scene.  For my console purposes I automated that by guessing,which works most of the time and allows me a manual override when needed.  It just seems that the ISY could provide a very small amount of assistance that would make this easier for the most common case and do it in a manner that is philosophically compatible with the v5 notion of virtual devices.  I can live with things as they are but variants of this discussion happen often enough that were I UDI I would seriously consider whether some additional functionality was called for to simplify the simple cases.

Almost every aspect of ISY is never based on any guesses. When a program turns a device on ISY does not assume it to be on, but rather goes by the status reported directly from the device only.  It's a complete feedback system without any guessing.

 

However, scenes may be  a different story. AFAIK scene commands are shoved out the port and devices are assumed to be in the desired state. This can be a mistake at times and lead to bad decision logic causing serious side effects potentially.. Typically UDI leaves any assumptions to the end level programmer/user. There isn't anything in devices, programs or scenes that can't be determined with absolute certainty (always provided comms are perfect)

 

Having said that no assumptions need to be made to get the status of things. For a simple MS / LampLinc only the status of the LampLinc need be examined.  No changes need to be made to any code to get an absolute status in that simple case. Nobody cares what the MS state is. An extremely simple one line program can get that status into a program status. A simple two line program can get the status into a variable.

 

For three way and multi-way lighting logic there is only one status per load, that can ever be looked at, anyway. Switches only put out one shot signals and do not have any status to read.

 

For more complex scenes with multiple devices, a simple program with lines to match each entry in the scene can do the same thing. 

If it is not too complicated to build a multi-component scene, then it shouldn't be too complicated to build a simple program to get the status wanted with the tools that already exist.

 

Virtual devices could alleviate a lot of programming problems for users. I haven't seen any in v5.0.1 to v5.0.10 yet. However virtual devices are only going to do what many ISY programmers are already doing with v4.

Edited July 25, 2017 by larryllix

[lilyoyo1]

I think you need to re-read my post.

And what I said still stands. You would need to be exact or limit your scenes to very basic functions. At that point, just to keep track of 1 detail you lose out on many other things you can accomplish

 

This is especially so in a large install with multiple users. You could have 2 different scenes with the same exact devices that still meet the base requirements of your program. 

[apostolakisl]

 

You could have 2 different scenes with the same exact devices that still meet the base requirements of your program. 

 

That would be a CHOICE you make in writing your program.  Unless your two scenes are EXACTLY the same (which would be pointless), then no, your statement is false, you would always be able to differentiate them (unless you CHOSE not to for whatever reason).

[MWareman]

I have not tried this yet, but for the scenario where you have a KPL and LampLinc in scene, why not assign the spoken to the LampLinc and have the status change of the LampLinc run a program that turns on (or off) the scene so the KPL follows?

 

The KPL would operate the scene, so it works naturally locally.

Google Home can get the status of the device when asked.

The KPL will update when Google Home directly controls the LampLinc.

 

The only issue comes up if the LampLinc is in multiple scenes, but if that is not the case it may work around the issue.

 

 

Sent from my iPad using Tapatalk