dmazan

Exactly.

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.

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?

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.

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).

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.

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.

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.

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.

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.

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.

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.

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?

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.

Just what I need. I guess the name makes sense, although it's a little obtuse. And not mentioned at all in the manual.

Figured out that you have to remove the device from a folder to delete it. That's odd. Unfortunately, since I added the device checking "Add Devices Found In Links And Keep Existing Links" ISY does know about the links and happily adds them back on restore. But now that I can delete the device I can simply re-add it checking "Remove Existing Links".

How do I delete a device? What I really want to do is only write the ISY-specific links to the device, ignoring any old, probably dead links. I could have done that when I added the device, if I had picked that option. But now that I added the device, keeping existing links, how do I get rid of the non-ISY links? If I could delete the device, I could re-add it and select "remove old links". But I can't seem to delete a device once it's there.

I have some devices that have old links, usually from devices that have been swapped out after failing. Is there a way to edit out those bad links (short of a factory reset and restore)? Related, it would be nice if "Show Device Links Table" would attempt to look up the names of the target devices, rather than just showing the address.

I've got just under 100 devices. I'd love to be able to print out at least the names and addresses of each device. Even better if I could also get the list of scenes and included controllers and responders.

Yes, actually it does. You just can't enter it as a bookmark--iOS changes the # to %23. But if you enter it into the browser address bar and then save it as a bookmark, that works.

That would be great. Remember that access without a password would be restricted to source IP addresses on the local network(s) (preferred to be entered as a parameter list as there may be multiple local LAN subnets or remote LAN subnets via VPN, as opposed to allowing access based only on the Universal Device's LAN configuration). Although it is technically feasible to spoof a LAN IP, no self-respecting firewall is going to pass a packet on it's WAN port that claims to be from it's LAN port. Granted, there might be a compromised inside host but (a) that's not on you and ( nobody is doing that to to gain control of my lighting.

I understand. Something just strikes me as wrong about adding a piece of hardware and spending time configuring some software because a piece of commercial equipment is missing a pretty basic feature. (Okay maybe it's not basic but Homeseer and several other HA products I've looked at as replacement do.) The ISY is the most competent system I've worked with in terms of interfacing with the devices--much better than Homeseer. I just wish it was better at interfacing with the humans. I may try MisterHouse on that RasperryPi.

Thanks for the ideas. I currently have multiple locations with multiple Windows boxes running HomeSeer. The idea with the ISY is to reduce complexity and the number of potential failure points. Writing my own interface to replace one that I paid money for isn't in the cards. Hopefully the ISY will become a fully usable production out of the box.

Attempting to hide the logo on an iOS device using #main_panel=false doesn't work. It ends up being URL-encoded into %23 which fails.

Are there any plans for a modern, browser-based administrative interface? Certainly any of the available front-end frameworks would provide an interface as or more responsive than the Java version and would work across all browsers and versions.