jgreco

My recollection is that the ISY994i was released around 2013. SSL has undergone some radical changes in the last five years, with the deprecation of older crypto, driven by the harsh realities of bugs and flaws in older crypto, and the realization by browser developers that they could either be complicit in allowing poor security, or take a leadership role. For the most part, they've stepped up and have been killing off insecure protocols, rogue certificate authorities, and solving other issues. Whether or not we'd prefer for this to be the case, those of us working in the industry are dealing with the prospect of 4096 bit certificates in the near future, or in some cases, actively deploying them now. Many small embedded controllers that are fine for non-SSL duties, or were merely slow with 1024-or-less-bit certificates become virtually unusable with the substantially higher crypto load demanded by 2048 bit certificates, and, yes, I can tell you that the ISY is pretty darn slow. Measuring only the speed of connections, I get a minimum 4.6 seconds to connect with a 2048 bit certificate, and an average of 5.9 seconds. This has nothing to do with the speed of the client, and is strictly a test of the ISY platform's crypto capabilities. We do network infrastructure engineering here and have seen this across all sorts of embedded processors, including network switches, UPS gear, and all sorts of other gear with marginal CPU's that were believed to be fine for the task when they were designed. By way of comparison, placing an HAProxy based load balancer in front to decode 4096 bit HTTPS and proxy it to the ISY as pure HTTP results in 0.05 second connect times, using a simple 256MB single CPU VM on a hypervisor. This also speeds up the interactions with the ISY, although not by as much as I'd prefer. It is completely possible to solve the problem this way for the long term. This method provides a fast SSL layer that is virtually indistinguishable from HTTP performance. However, it does require having some other device present to act as a proxy. I've used a virtual machine here as it is conveniently and cheaply available, but one could do the same trick with a Raspberry Pi (newer == better). It is an unhappy answer in that there's a second thing to worry about and manage, but it answers the question of whether or not there's a way to do HTTPS quickly.

OK. I will take your word for that. Should I dare suggest that is not the insteon definition of a scene being on and run the risk of being called silly again? I'm sorry. I wasn't aware that you weren't following the full conversation; I see now I had been talking to kingwr when I said "I'm talking lighting-functionality scenes." The choice of technology to implement lighting is just a way to get stuff done. If you want to define "scene" as being an Insteon thing, what happens when one of your lights is controlled by a legacy X10 device? It can't be part of the scene because of a technicality - that it doesn't support a more modern signal protocol? I'm not interested in Insteon's definition of a scene, which someone else pointed out is called a group anyways, not a scene. What I'm interested in is useful lighting and controls. I want to click buttons and have lights do specific things. I want the LED's on the KPL's to do meaningful things. etc. One of the most useful things our home automation system adds to our Insteon network is the correct reporting of the state of scenes, because that's something that Insteon generally lacks. If all my lights are off, I want the ALL OFF LED to light. If anyone turns a light on, via any means, I want the ALL OFF LED to go out. If that one light is again turned off, I again want the ALL OFF LED lit. Likewise, when other scenes go into state, it's very handy to have those LED's light and extinguish as appropriate. It's easy and intuitive for people to use. The Insteon plumbing behind the scenes is irrelevant, as we can integrate X10 or other supported devices as well, and it still works the same way. From my point of view, when the lights are set in the right state, scene's on. That turns out to be very useful for driving KPL LED's, web reporting, API control, etc.

Suppose one has a scene with a controller keypad button and two responder dimmer switches. Suppose the "on" levels for each responder is set at 50%. Suppose, then that each individual dimmer was manually set to 50%. The keypad controller would not be on. Is the scene on? That is all that it means. Fair enough. Answer: Scene's on. Insteon's not sufficiently sophisticated to deal on its own with representing the situation since Insteon is essentially a system with no centralized controller; I kind of expect a device like the ISY needs to address the logic check needed to turn on the keypad LED. That, incidentally, is the trivialized version of my initial inquiry ... which was whether or not the ISY *actually* handled this sort of thing without someone needing to manually code up the logic to tally the state of a scene. Having to send out the proper Insteon event to update LED's is fine, but I don't really want to have to string together several dozen individual status checks in order to implement large scene state checking. The automation controller already knows Insteon group memberships and ought to be able to derive whether or not the devices are in state with a simple traversal of the device list. That's silly. A scene cannot be defined three different ways; what you are describing would be three separate scenes. Even the language you use to describe the situation indicates that it's not the same scene. You had to say "Each scene" - making it clear that this is really more than one. You can certainly have multiple scenes controlling the same set of lights. Speaking as a longtime software designer who has been highly successful in simplifying systems so that they can then be scaled massively, I'm fairly comfortable in theorizing that people can get bogged down in trying to deal with everything possible when it would be better to focus on some manageable and reasonable point that isn't a quagmire, and then running with that. If your model of a scene doesn't work in practice because it's too complicated, throw out the model and substitute a simpler one. I've presented a simple definition for a scene that's very functional, and not just hypothetical, since PowerHome uses it and it works fine here. It may not mesh with some of your preconceived notions of what a "scene" ought to be, but the fact is that my "scene" definition is useful in what it can do, and can be trivially coded, while your notions of a scene "get complicated pretty quickly" and I certainly understand why you'd see implementing code for it as a headache. It's something to think about, in any case. From my perspective, it's a tragedy because I really wanted to do something practical like an ISY, but I don't want to be manually managing large if/and/and/and/and/and/and/and/[...]/then code structures, because experience teaches that along that path lies madness (and errors).

Sadly, all our devices belong to multiple scenes, at a minimum ALL-ON and ALL-OFF. I bought into home automation to get away from overly simplistic lighting control restrictions. We have some lights that are members of maybe half a dozen scenes. Insteon is fantastic since it provides more capabilities than any of the old hardwire or low-voltage control systems did, and it's reprogrammable without rewiring. Thing is, we bought KPL's because there are key points throughout the house where it's nice to be able to call for certain scenes, only a few of which can reasonably be implemented as an x-way Insteon Group. Most of our KPL's have a few regionally-appropriate scenes, such as the one at the bottom of the basement stairs which has "basement walk", "basement off", "laundry", "workshop". "basement walk" will bring up a set of lights at a set dim level to allow people to walk around without running into doors and walls, which really needs to be a scene due to the number of affected devices. "laundry" and "workshop" can be a simple Insteon link because they're hitting single targets, but "basement off" has to hit maybe a dozen targets. Having the status lights are really neat because sometimes family members don't hear each other; it's not unusual for someone to come on down and work on laundry, and the status light there is a great reminder not to hit basement off. So both the ability to set scenes and to see what's going on are nice.

Okay, so you are hung up on the term, implementation and technology Fundamentally, I don't see "scene" as an artifact from X10, because the term far predates X10 scenes and has a general meaning that fits what we're discussing. We can call them a "group" too but then there's confusion as to whether we're talking specifically about an Insteon Group or just a collection of lights. So to keep things clear, I'm not talking X10 scenes, or Insteon Groups. I'm talking lighting-functionality scenes. You raise an interesting edge case, and I can see cases where it'd be problematic. The problem is that it's extremely handy to be able to set your lights to some known state. Insteon Groups address that, but for completeness within the Insteon protocol they also allow a Group Off signal to be sent. Makes sense for hopefully obvious reasons, but of course this inserts a third possible state because instead of "ON/ANY-OTHER-STATE" you have "ON/OFF/ANY-OTHER-STATE". Computer programmers would typically look at the first case and say "well that's obviously 1 or 0". But we look at the second case there and kind of pull our hair because the ambiguous state cannot be articulated in a useful fashion. For a home automation system, though, it's really difficult to support ambiguous states that cannot be articulated in some useful fashion. Maybe you COULD have "OFF/SOME/ON" or something like that but the usefulness of the middle state is highly questionable. So PowerHome doesn't do that. It simply defines a scene as ON when the lights in that group are in the defined states, and OFF otherwise. Now I've tried to be very clear about the underlying thinking so that it's clear that the ambiguous state is both a problem and not very useful. I *think* we agree on that at some level. So here's the solution to the problem you are asking about: you can use two scenes, one to match scene on, and one to match scene off. This works, at the expense of adding a scene, but gives you your tri-state answer: you get an indication when all lights are in the defined scene mode (SCENEON == ON), an indication when all lights in the scene are off (SCENEOFF == ON) and when things are in the ambiguous state (SCENEON == OFF && SCENEOFF == OFF). Now, here, we actually do use two scenes, one for ALL ON and one for ALL OFF; this works great to provide some very useful functionality in our system. You can feel free to deny that it's logical to want scenes to have state, but I think what PowerHome does is reasonably sensible *and* it provides some very useful capabilities for reporting the status of lights. So far I haven't found any reason to test for the ambiguous state in our setup, so from my point of view being able to identify when a group of devices is in a defined state is very useful, and hand-wringing about what it means when they're not in that state is not useful.

I'm really trying to figure out what that means. Why would it depend on that?

I'm fine with the scene being "false" if a member device isn't in the exact state. Practical experience with a working system tells me that this isn't really a problem. I don't see why having a device in dozens of scenes makes it impractical. The algorithm isn't particularly complex; when a device's status changes, you traverse each scene it is a member of and update the status of the scene if needed. The value in knowing the status of a scene CAN be in knowing that lights are off, but we use it both ways. When the wife calls and says she's going to be working late, it's convenient to be able to override the scheduled events and set outside night arrival lighting, but she also sometimes comes home early when she's supposed to work late, and the LED's a reminder. We make reasonably frequent use of enough scenes that I cannot agree that it's just convenient knowing a scene is off. I certainly agree that knowing a group of lights is off is convenient; we have an ALL OFF scene that goes on when all (interior) lights are off. But this requires no special code... PowerHome's scene code just notices that all member devices are in the proper states and the scene's state transitions to on. There's an event that pushes an Insteon update out to the KPL, but that's it. We can add more Insteon devices to the network, and as long as they're members of the right scenes, all configured KPL buttons will both control and report the scene just fine with no additional twiddling of code. See, and that's what I want to avoid, I don't want to be adding devices and then forgetting that I need to modify this program and that program for each scene and possible thing that might happen throughout the automation system. The ISY appears to be extremely useful in implementing some higher level logic that Insteon is incapable of on its own, but this sort of logic is the kind of thing that I would want in an automation system ... abstraction with a mind towards allowing developers to focus on function rather than micromanaging devices.

In PowerHome: If the devices aren't set to the state defined by the scene, then the scene is off. I mean, it's really that straightforward, you run through the member devices, check their status, if all of them are in defined status, scene's on, you're all done. That might be tough to get your head around the first few times you do something silly in programming things like the local on-level to some similar-but-not-the-same value (50 vs 60%). Been there, done that. But really, my question in return would be: For your setup, if someone had set the local on-level to 50% for each of those dimmers, and then manually single-tapped each one on, so that both are in fact at 50%, is the scene on or off? Or do we call it two switches that happen to be set to the same level as a defined scene, but since it wasn't tripped electronically, we're unwilling to call it a scene? I'm even fine with that last one, if that's the way it is, but I'm not sure that such an option is beneficial. I hope that these questions at least give you guys a little something to think about. As for the rest, I'm quite disappointed to find that I'm going to have to find a way to put up with PowerHome (or maybe MisterHouse has gotten up to speed). I think the ISY is a fantastic little gadget regardless but I'm not prepared to lose significant functionality, and I'm not sure I have the time to spend figuring out how to use the ISY as an Insteon gateway to some code running on a server somewhere that can implement the functionality I seek. Thanks for your responses and I'll be happy to continue this thread (if anyone's interested in debating how many scenes can dance on the head of a pin!)

Yes, thanks, that's helpful in that it clarifies that there's no coherent scene concept. I already have an operational Insteon network and am not going to be able to rip open walls to install additional KPL's to address what I would call a very unfortunate deficiency in an otherwise awesome gadget; I had really been hoping to come up with a reason to buy one. Our current system helpfully updates the status LED's based on the actual status of remote lights. This works even for things like local load sensing on a LampLinc; if I turn on a lamp on a nightstand by flicking its switch off and on in the middle of the night, PowerHome catches that and our "ALL OFF" scene LED extinguishes. At the same time, we can actually use the KPL buttons to send scene commands too. It's fairly intuitive. We like it a lot. It's great to be able to know that no one's in the basement because a KPL LED indicates that all basement lights are off. I had, however, wanted to eradicate the need to run a Windows box. I don't think I need to explain that to anyone here.

I guess I'm curious as to why you think that. Fundamentally, a scene ought to describe a given state of a set of lights in your lighting system, correct? Like "all lights on", "all lights off", "nighttime", "watch movies", "outside lights/driveway for late night arrival", etc. For example, "all lights on" is when all the lights are "on". You have a group of devices, let's say "all", and they're in a defined state. Insteon provides a way for this to happen with a group message. So you probably agree that if the Insteon group message is sent, then the "all lights on" scene is on, right? 1) What if the signal comes from an IR controller to the ISY? The ISY then proxies the scene request to the Insteon network. Is that still activating the scene? If so, then we can dismiss the concept of a scene as being an exclusively Insteon thing; something else can trigger a scene. 2) What if the member devices include an X10 device that doesn't support scenes (not even sure the ISY handles X10, but pretend it does and follow along for the sake of debate)? So an IR signal comes in to trigger a scene and the ISY sends out an Insteon scene command and an X10 "on" command to our device. Is this still a scene? I see it as being so, because a scene is about the results, not about the technical details needed to make it happen. 3) What if someone then turns off one of the Insteon devices? I think we're in agreement that this no longer results in the scene being on. Because if it doesn't, then the question becomes at what point is the scene no longer on? One light off? Two? All? etc. 4) Someone having turned off the device, then what if someone then turns it back on? This is the ultimate question. All the lights are on. Is the "all lights on" scene active? All the lights are on. I say the scene is active. You're saying no, I believe. Why? Because a device was manually set? So you're saying that it requires an electronic command to set up a scene? What's the benefit of that? It does make logical sense to track scene status, but you have to have a consistent vision of how to make use of this. For example, we have an "all lights off" scene, which is all lights off, oddly enough. Now here's the cool bit. Besides just being able to hit ALL OFF when we leave the house, which is the obvious goal of the scene, we can ALSO see when lights are on - because PowerHome's scene status is propagated out to our KPL LED. So when a kid gets up at night and has turned on their room light, we can see on the master bedroom KPL that a light somewhere in the house is on (because ALL OFF is *not* lit). This is just one trivial example. The definition of "scene" should be very simple and straightforward: when all member devices are in the target state, then the scene is active.

I have no objection to using a combination of scenes and programs. What I'm looking for is some higher-level capabilities in the device. What I *don't* want is for every time I purchase a LampLinc or SwitchLinc to have to go and be modifying every bit of logic associated with any member scenes; for example, I don't want to have to have a bit of logic that says IF (KPL1 == ON && KPL2 == ON && SWL == ON && ALL_ON_SCENE == OFF) THEN ALL_ON_SCENE=ON, SEND_INSTEON(KPL_ALL_ON_LED, ON) Because if I have to go about it like that, then when I add a LampLinc, I have to modify that to be IF (KPL1 == ON && KPL2 == ON && SWL == ON && LAMPLINC == ON && ALL_ON_SCENE == OFF) THEN ALL_ON_SCENE=ON, SEND_INSTEON(KPL_ALL_ON_LED, ON) But I have to do that for *each* scene that a device might be a member of, and probably for on AND off states, etc. This might not be so bad for a few devices, but gets ridiculous quickly with dozens of devices and a dozen scenes. It also gets complex for things like dimmed states, etc. With PowerHome, now, it does something clever, and this gets to the heart of what I was asking about. PowerHome knows the Insteon network and its settings. That *includes* the scene settings. Let's say your all-lights-on scene is currently on. PowerHome knows that. Now you get an Insteon event that indicates SwitchLinc has been turned off. PowerHome updates SwitchLinc's status in its database of course. However, it also notes that all-lights-on is no longer active, since not all the devices are in the required state, and updates its internal database to note that. THAT update can be monitored for with a PowerHome event, and then we push out an LED status update turning off the all-on LED. If we get another Insteon event indicating that SL has been turned off, PH will note that all-lights-on scene is once again active, since all the devices are in the required state again. Once again we trap that with an event and can push out an LED status update turning on the all-on LED. The important bit here is that PowerHome is aware of the change in the scene's status WITHOUT any user-generated code; it knows based on the Insteon configuration that if it were to send an ALL-ON, that KPL1, KPL2, and SwitchLinc are set to ON. But the inverse is also true: it also knows that the ALL-ON scene is on if KPL1, KPL2, and SL are locally switched on. Further, if any of those devices are locally turned off, it knows that the ALL-ON scene is now off, because the devices are no longer in the required state. This logic is MUCH simpler: ON INSTEON_UPDATE { IF (ALL_LIGHTS_ON == ON && ALL_LIGHTS_ON_LED == OFF) SEND_INSTEON(ALL_LIGHTS_ON_LED, ON) IF (ALL_LIGHTS_ON == OFF && ALL_LIGHTS_ON_LED == ON) SEND_INSTEON(ALL_LIGHTS_ON_LED, OFF) } And it has the advantage of not needing to be updated every time a new device is added into a scene; PowerHome already knows what devices are part of a scene and just takes care of that itself. I still find even that a bit ugly, but it's manageable. It's also a completely reasonable expectation for a home automation controller to have a modest amount of intelligence to allow designers to focus on designing overall strategies rather than having to micromanage each device. It isn't clear to me that the ISY is actually capable of tracking scene states automatically in this manner.

I'm toying with the idea of ditching a troublesome PowerHome setup for something else. The ISY is a natural candidate. In fairness, the problems with PH have less to do with PH than the underlying Microsoft and database stuff; PH itself is pretty competent. My big hot button item is scene status on KeypadLincs. I want each KPL to accurately display the status of the real world scenes it controls. This is in turn driven by Insteon scene commands, of course, but is a bit tricky because Insteon isn't oriented towards "the bigger picture" - that's where an automation controller comes in. Let's say you have two KPL's and a SwitchLinc. Three scenes, "all on", "all off", "nightlight" (the SL at 30% and KPL's off). You hit all off. Insteon "all off" scene fires, Insteon "KPL LED all-on off" scene fires, Insteon "KPL LED all-off on" fires. Everything's fine. I see how to do all that with the ISY too. You hit all on. Inverse happens. Also easy. But now you press off on the SwitchLinc. I want the KPL all-on LED to extinguish. This requires something in the network to be aware that a member of the real world scene is now not compliant. Further, if you then press on on the SwitchLinc, the KPL all-on LED should come back on, since all three devices are once again on. If you then press load off on the KPL's and set the SwitchLinc at 30%, the "nightlight" scene button should light up. Now in theory you can sit there with a large IF/AND/AND/THEN structure that has to be grown each time a device is added; that's ugly and unmanageable. Trying to do this for a dozen scenes would be awful. PowerHome actually updates its internal group status to reflect things in the manner I describe above, and then it's just a matter of triggering when that status changes and pushing changes out to the KPL LED scenes. I have the required Insteon scene magic working great under PowerHome for manipulating the KPL's and Insteon device scenes... but I cannot really tell what the ISY's capabilities are for acting as the needed intelligence. Is the ISY up to such a task?