Web interface doesn't seem to reflect the state of themes

[dmazan]

It looks like both the on and off icons always appear for a scene in the web interface.  As a result, you can't tell if the scene is on or off.  That's particularly and issue with the scene is just a n-way switch configuration.  What I would like to do is hide (by setting the names to start with ~) all of the individual devices comprising an n-way switch and just display the scene.  That way, turning it on or off from the web interface will always keep all of the switches in sync.  But, if I hide the component devices there is no way to tell if the load device is off or on.

 

I realize that a scene isn't really ever off or on.  But it would be very useful if a scene, in the web interface, is displayed as "off" if all of it's component devices are at on level = 0 and "on" otherwise.

[Michel Kohanim]

Hi dmazan,

 

We have had so very many discussions about status of scenes! In ISY, scenes do not have statuses simply because a scene is a collection of controllers/responders and each controller, may have a different set of on level/ramp rates for each responder. As such, it's very difficult to figure out status of a scene.

 

 

With kind regards,

Michel

[dmazan]

Any thoughts on how to avoid a web interface user from turning on/off one device of an virtual n-way set while still being able to see the state of the load device?

[dmazan]

One answer would be that if a device is a scene controller and that device's state is changed by the web interface, place the scene in the same state as the change to the device.  That is, treat web input to the device the same as physical input.

[Michel Kohanim]

Hi dmazan,

 

What if you have multiple controllers? Which one would you use as the status?

 

With kind regards,

Michel

[dmazan]

In that scenario, you wouldn't need a scene status.  Since any of the controllers, when activated from the web interface, would do whatever that controller would do if physically activated, you would not end up turning on, for example, one switch of a virtual n-way circuit and not actually turning on the load.  So you wouldn't need to hide the individual devices and you wouldn't need a scene status.  The thing I am trying to avoid is exposing the individual devices in a way that would let the various devices of a n-way circuit get out of sync.

[Michel Kohanim]

Hi dmazan,

 

Just to be clear, what you are suggesting is to assign a scene status IF AND ONLY IF the scene itself was activated through ISY? And, if so, how about Dim/Brighten and Start/Stop fade up/down?

 

With kind regards,

Michel

[dmazan]

No.  The issue I am trying to work around is that if I have a n-way circuit, say a load device and two other unloaded switches, and I expose just the load device via the web interface, turning it on via the web interface would turn on the device but leave the other two switches in the off state (with their leds showing off).

 

My first attempt at dealing with the problem was to hide the load device and the switches and just expose the scene.  But then the web user can't tell if the load device is on or off.  I understand the difficulty in representing whether the scene is on or off.

 

Accepting it is hard to decide if a scene is on or off, an alternative would be: when a device is activated via the web interface, if it is a scene controller, activate the scene as well.  That would prevent the devices from getting out of sync. 

[Michel Kohanim]

Hi dmazan,

 

Thank you. The main issue is that if you activate a device from the interface (not the device itself), the scene is NOT activated (this is an INSTEON feature whereby you cannot act as a proxy to the switch). If we were to do this, it would be even more difficult since the logic would now have to look for web activation (ST) vs. physical device activation (DON/DOF).

 

With kind regards,

Michel

[dmazan]

How about just a simple option on the scene: "In the web interface, treat each controller for this scene as an alias for the scene itself".  No issues with acting like the switch, just an administrative option to have on or off for any controller device instead act like the on or off button for the scene.

[Michel Kohanim]

Hi dmazan,

 

That's a good option. Alas, what you are suggesting will NOT work if you turn on/off the controller (in the scene) from an ISY client (i.e. web) then NONE of the responder will respond simply because in INSTEON you cannot act by proxy. In short, the status of the scene will not be what it should really be.

 

With kind regards,

Michel

[dmazan]

I didn't make my point well.  My suggestion is that there be an option to treat controllers in a scene each as an alias for the scene itself.  So activating a controller of a scene with this option selected from the web interface would not activate the controller at all; it would act just like activating the scene from the web interface.

[Michel Kohanim]

Hi dmazan,

 

Thanks for the clarification. I do understand what you are recommending but I do not understand how this would help the situation. i.e. let's say someone turns on/off one of the controllers from an ISY client. Let's say that this device updates the status of the scene. Based on this situation, now, the scene shows on while none of the members are actually on.

 

I think a better approach would be to assign a status (only on/off) to a scene when a scene is activated from an ISY client.

 

With kind regards,

Michel

[dmazan]

Ah, that's the point.  I accept that it is difficult to impossible to reflect the status of a theme in a meaningful way.  With this option, I don't need the scene to show a status.  I can just expose all of the devices from the n-way scene as individual devices with their status.  If somebody turns one on form the web interface, it acts like they have turned on the scene from the web interface.  So the individual devices reflect properly whatever the scene does.

 

Basically it solves the only problem which is exposing the individual devices and having only one turned on.

[G W]

I've been following these discussions for as long as I have owned an ISY. I've debated both sides and I've tried to find a method that will give an accurate status.

 

It just can't be done to satisfy everyone under ever circumstance. However, if you could assign a status of ON or OFF to show that the scene was told to turn On/Fast On or Off/Fast Off and only those four actions could set the status, that might satisfy most users.

 

There is still the situation where a scene can be On or Off but a member of the scene is chanced to a different state afterwards.

 

At least this will give the last full state of the scene and an indication of its state.

 

 

 

Best regards,

Gary Funk

[dmazan]

Yes, that would solve my issue as well.  But my suggestion doesn't actually impact the handling of scenes at all.  It just gives you the option of assigning any or all devices to act like an alias for their scene when controlled from the web interface.  The issue is sort of unique to that special kind of scene used only to simulate an n-way switch circuit.  You could even just have that be a checkbox option on the scene: "scene simulates an n-way switch circuit" which would then enable the device-as-alias-for-the-scene-when-controlled-from-the-web-interface interface behavior.

[Michel Kohanim]

Hi dmazan,

 

I am so so so sorry. I still do not understand. Would you please let me know:

1. What should happen when ISY scene is activated from the web interface?

2. What should happen when the scene alias (controller) is activated from the web interface?

3. What should happen when the scene alias (controller) is physically activated?

4. In all cases above, what would be the status of the scene AND other members in the scene?

 

 

With kind regards,

Michel

[dmazan]

1. Same as now; no change.  The scene is activated but the web interface doesn't show its status.

2. Same as if the scene is activated from the web interface.  The scene is activated but the web interface doesn't show its status.

3. Same as now; no change.  The scene is activated as determined by the controller's link configuration.

4. Same as now; no change.  The web interface doesn't show the scene status.  It does show the individual status of the devices, however they happen to be recorded in the ISY.

 

The only change I am suggesting is the option to make an individual controller, when operated form the web interface, act as an alias for a scene.  That could be done as an option on a device (make this device a web interface alias for scene x) or on the scene (make all devices in this scene web interface aliases for the scene).

[G W]

 

 

The only change I am suggesting is the option to make an individual controller, when operated form the web interface, act as an alias for a scene. That could be done as an option on a device (make this device a web interface alias for scene x) or on the scene (make all devices in this scene web interface aliases for the scene).

If I understand this correctly, the "web interface" as you call it, is using REST commands to control the ISY.

 

If a device is turned on through the ISY are you wanting it to show that any scene the device belongs to is turned on?

 

Best regards,

Gary Funk

[dmazan]

No.  No change at all to the behavior of the scene.  The ONLY thing I am suggesting is being able to declare a device, for the purposes of the web interface (meaning the current udajax web interface), when operated either on or off, to act as an alias for the scene.  No change to the way scenes or their statuses are handled, no change to the way devices or their statuses are handled.

[G W]

You're repeating the same thing over and over. If we don't understand it the first time, repeating the same is not going help.

 

Best regards,

Gary Funk

[dmazan]

I am fine with the way status is handled for scenes.  I understand it is difficult to determine the actual status.  I am fine with the way individual device status is handled.  My only issue is when I have a scene, specifically created to simulate a n-way switch circuit, which typically has one or more load devices and one or more devices that do not control loads directly, all of which are typically controllers.  

 

If I only expose the scene through the web interface, turning it on, off or setting the dim level properly changes all of the devices.  But if I expose any of the individual devices through the web interface, which is desirable because it shows the correct status, turning it on, off or setting the dim level only impacts that one device.  As a result, the light in the hall might be on, but the switch on around the corner indicates it is off.

 

My proposed solution is to be able to configure any device as an alias, for the purpose of web control input only, of a scene.  Or, alternately, be able to configure that all devices in a scene act as aliases of the scene.  That's it.  No other changes.

 

Is that clearer?

[stusviews]

If you control a device, then only that device will respond. None of that specific device's links, neither controllers nor responders will be affected at all. If that were not the case, then you could easily create an infinite loop. If you want all the devices in a scene to respond, then you must control the scene, not any one of the devices in a scene. That also allows a device to respond differently to different controllers.

[G W]

Yes, and that is not going to work because a device can be in more than one scene. So can it know which scene to set the status on?

 

Also, you keep saying "web interface" like its the controlling object. What if it's changed through the Android application?

 

Best regards,

Gary Funk

[dmazan]

This is only for scenes that simulate n-way switch circuits.  By definition, none of the devices is ever in more than one scene.  Think of it as a checkbox: either in the scene configuration: "device acts as an alias for this scene" or, maybe simpler, in the device configuration "device acts as an alias for scene" with the scene specified in a dropdown.

 

Actually, since is doesn't change any behaviors on the back-end, it could even be done in the udajax script, although odd to have the configuration in two places.