mwester

Except that novels tend to be more readable, and a lot shorter! SSL is more like "Finnegans Wake", IMO.

I can't tell you what anyone else would expect - but my 'stat also has "AUTO" mode, and what I expect (and what it does) is that when in AUTO it maintains the temperature within a pair of setpoints, turning on the heat or A/C as appropriate to do so. I think the key here is the setpoints -- WHICH one are you asking Alexa to change when you tell it you want the temp to be set to 75 -- are you adjusting the LOWER setpoint upwards (which would turn on the heat!) or adjusting the UPPER setpoint upwards? Methinks that the vocabulary for Alexa is going to have to be adjusted so as to make that clear - and Alexa needs to refuse to act unless the intent is, in fact, completely unambiguous and clear. But that's just an opinion -- and as a matter of principle, I don't let my HA adjust my thermostats, because the amount of damage possible if something goes wrong with that is just way out of proportion to the benefit, at least at this latitude in the winter.

(Re: Original Topic) I wonder if there's a developer or debug feature that can be enabled to let one listen to exactly what it is that the Echo is hearing from its microphone array? That might offer some insight into the original problem described here (and might make the cardboard/foam workarounds described here less of a trial-and-error thing to set up) -- it might be worth an email to Amazon's echo support folks to find out (and while you're at it, perhaps they already know of this problem?)

Yes, one has to be selective to ensure one gets the feature -- but the cost isn't necessarily higher than Insteon. And when faced with a 3-way switch setup, the z-wave solution for that is far cheaper (although it must be noted that z-wave doesn't have such a solution for 4-way switches!).

Use both. Just remember that crossing between the two (z-wave and Insteon) requires the ISY to do the work to bridge the two, so there will always be a delay of some sort. Right now that delay is just too long for lighting (guests will actually start flipping the switch back and forth a few times before the ISY finally schedules the program and executes the command to turn on the light - not acceptable). I use z-wave for all sensors and the main garage door, and for second floor lighting. Insteon is used for first-floor lighting where the Keypadlincs play a huge part in the spousal-acceptance-factor. I also use Insteon in the out-buildings (shop and shed) because it's a tad too far for z-wave and I don't feel like putting a z-wave repeater on my yard light pole. Both have their place - and both have their frustrations. But to be honest about it, I've had ten times more trouble with signal issues on my Insteon stuff than I've had with the z-wave. Once someone comes up with a proper z-wave replacement for the keypadlinc, I'll be looking at re-doing my first floor with z-wave as well -- and getting rid of numerous filterlincs clogging up outlets all over the place!

No, this is not normal behavior -- this usually indicates communication problems between the ISY's PLM and the device in question. The REST API call cannot cause this -- HOW the "On" or "off" event is triggered is immaterial to the on-the-electrical-wire signal. However, if you really only ever see this with the REST calls, it could indicate that perhaps your REST call is doing something different from what you're doing when you turn that device on or off from the Admin console -- for example, perhaps you're addressing the device from the Admin console, but turning on or off a *scene*, and perhaps that scene references some non-existent device, thus triggering the error. Or perhaps (and this is a stretch) your computer from which you generate the rest call is creating electrical noise on the powerline, and its just a coincidence that the program you're running creates exactly right sort of load on the computer to create the right sort of noise so that interference is generated when you issue the REST call... (I said it was a stretch! You're better off investigating a common ordinary generic interference issue instead!)

There's a power supply in the fan itself -- the big advantage (at least the big one for me) of a DC fan motor is that it's completely quiet at low speeds - no audible hum at all. I understand they're also more energy efficient, but I confess that given how little it actually runs I can't see that being a feature that justifies the extra cost). Mine too has the proprietary RF remote, which just sucks because everything else in this room is automated. The only remaining solution that I'm planning to try, as soon as I find a low-cost used remote for that fan on eBay, is to solder a few wires to the remote and connect them to the relay on an IOLinc. I can accept one speed on/off, so that'll work for me.

Let's step back just a bit. Repeat your test sequence - this time watch the device status in the ISY Admin console. Does the console status update when you manually turn off the device? If not, then you have a communication problem if the device is Insteon, or a zwave device with "instant status".

There's the problem - I can't know that. The application is to add a "heart beat" to Polyglot, so that one can be assured that the connection between the Polyglot node server and the ISY is functional -- I have no idea what specific sensors or devices might be handled by that specific instance of the Polyglot service so I don't know how critical it might be. Thanks for the comments on battery life - for some reason I'd never connected the loooong 24-hr heartbeat interval with battery life, but it's obvious now! Since this wouldn't be battery powered, that would imply a much shorter heartbeat. How often is too often, though? (Note: this is ONLY between Polyglot and the ISY -- this won't add a heartbeat to sensors served by Polyglot if the end device doesn't have a heartbeat to begin with! So this is just to ensure that your Raspberry Pi, for example, hasn't crashed overnight...)

What I mean by fixed is that I determine when I build the device what the heartbeat interval is - and you can't change it, no way, no how. Variable is if you, as a user, have a control or setting to change the interval at which the heartbeat is sent - so if you want a heartbeat once per 24 hours, you can set that, or if you want it once every 8 seconds, you can set it to that... I'm going to take your question as a vote for "fixed".

Assume I'm implementing the heartbeat feature for a device to be managed by an ISY. How exactly should that heartbeat function? 1) I'm leaning toward a fixed heartbeat time period. The argument against a user-adjustable period is that it renders sharing of programs to monitor the heartbeat more difficult, invites confusion when different instances of the device in question end up with different heartbeat times, and it adds yet another step when performing a complete reset of a device (one has to update the heartbeat). Feel free to try to convince me why you need it to be adjustable. 2) Right now, I've implemented the heartbeat as a periodic sending of the DON command (i.e. the device was just switched on). The device will ALWAYS respond OFF when queried, and will never send the DOF command. 2a) Is this consistent with other devices that have heartbeats? 2b) Would it be better to send a DON, wait a few seconds, then send a DOF instead? 2c) Would it be better to implement something completely other than an On or Off? 2c1) perhaps an actual HEARTBEAT command? 2c2) perhaps an actual HEARTBEAT command with an incrementing value? Feedback requested.

Ah, so that's the REAL question -- how can one cause a program to run on the ISY from a phone? What phone? (Android or iPhone?)

??? Perhaps you can clarify what you mean by "Virtual Control"? I'd solve this by simply coding your program thusly: Turn on alert device wait 5 seconds Turn off alert device Close garage door

Exactly what is turned on first, and what fails to turn on? For a while (I've since redesigned my solution), I had a large pump on an applianceLinc, with a syncrolinc and an IOLinc -- I noticed that when my program turned on the applianceLinc, the pump would start, but the messages from the syncrolinc would be lost, and messages sent to the IOLinc would be missed unless I added a several-second delay. The problem is that the pump's startup either sucked down the voltage on the line or injected too much noise on the line, and until the pump motor's internal startup circuitry switched to normal mode, there were no Insteon messages that were making it through. Perhaps whatever you're starting when you switch on the first half of the outletlinc is causing the same sort of temporary startup noise that prevents the second message from being seen by the outletlinc.

Hold on a second here. I wonder if there are some assumptions being made incorrectly -- based on the original post, I suspect everyone is understanding that your keypads are not working, but assuming that all the other devices ARE working with the ISY. This last post makes it seem as if it's not just your keypads that aren't working but 40+ switches that are ALSO not working -- but are there other devices that ARE working with the ISY? I guess I'm now wondering if there's a much simpler explanation at hand -- if your ISY can't talk to ANY of 40+ devices, then it's pretty unlikely that 40+ devices all failed simultaneously. The simpler explanation would be that your PLM (the box through which the ISY talks to all the devices) has failed. Perhaps you can give a broader picture of exactly what is NOT working, and what IS working in your network - that would be really helpful right about now!

http://forum.universal-devices.com/topic/10516-random-all-on-event A 41-page thread (and not the only thread on the topic at all!) devoted to one such issue/concern with reliability. I have NO critical systems that can be impacted by such an event -- the one system that demands control by the ISY has been set up so that the normal (safe) state is with the IOLinc in the "on" position (I needed an external relay to do this, but that's a small price to pay for peace of mind). My garage door is controlled via z-wave now, which (if you read the forum) may have connectivity issues for some homes, but at least it doesn't suffer from the Insteon issues.

Upgrade to the latest 4.x version (make sure firmware and console version match) - you'll find that you'll be able to change the font size so you can read it on those ultra-high-res displays. And if you search other threads here, you'll note that UDI have stated that they're doing no further development on the Java IDE -- they too know that a Java-based IDE is not the way to go!

The results observed by 502ss are not an isolated case -- I too used burn time back when I was monitoring an ancient oil-burning furnace. I didn't set out to monitor oil levels -- my goal was simply to ensure that the furnace was working when I wasn't there at the old farmhouse, so I was monitoring the thermostat 24VAC line to detect when it was calling for heat, and monitor the temperature adjacent to the boiler to ensure it actually fired up. As a side effect of the monitoring, I discovered that it was dead simple to compute run-time, and from that I tried to estimate fuel level left in the tank - and to my surprise, the estimates were amazingly close. I did that for two years, and never once was off by more than 10 gallons from the gauge.

Z-Wave works well -- and unlike the zigbee, the ISY z-wave module DOES support home automation devices.

I think the statement on the bottom of that blue object in the background is significant: CAUTION! From the components visible on the circuit board, I would not recommend connecting any part of that circuit to an IOLinc, or even exending any circuit inside that device to the outside via a wire of any sort. Particularly if you, as you state several times, are not completely sure about what you're doing. The risk is that you will inadvertently bring the live house power (at 120 Volts) out of the device on that wire. Sure, you're measuring only 3 Volts across the speaker -- but that might very well be 117 Volts on one terminal and 120 Volts on the other -- the difference is 3 volts. You might even be able to get it to work with an IOLinc without any sparks or smoke -- but if you have that sort of voltage on one of the wires going to the IOLinc from that device, and your cat or dog happens to touch it, or chew it, well, that would be bad. Or if something sparks, and the spark falls onto your wooden floor, or your wooden baseboard, or your flammable carpet or rug... And even if you measure carefully to ground -- well, reversing the plug on the device might change everything. Don't do it.

Gah! I'm suprised it lasted that long! An air conditioner - that's about the worst possible load you can put on a relay; I can't think of any worse household appliance. The startup current is simply off-the-scale with those compressor motors. That 11.5 A rating -- that's "running". The starting current for that sucker is probably 20+ amps, but even worse, if the A/C unit is "on" when the tiny itty-bitty little relay in the outletlinc turns "off", there's going to be a massive arc inside that little relay. They make special relays for A/C units -- google "definite purpose contactor" to get an idea of what they look like (there's NO way that'll fit inside an outlet); the little relays in your outletlinc aren't in that league by any means. So, nothing wrong with the outletlinc, just the wrong application for it.

It's a edge view of a pcb -- I'm not sure what I'm supposed to be seeing there?

I do. I won't be renewing it, though...

Not here. The amazon drones can only take it so far, when they run out of power, they drop the package and it travels the rest of the way to my door by barge, horse-and-buggy, and the last little bit by foot. Even FedEx "Priority One Overnight Guaranteed by 10AM" took two days. On the other hand, USPS regularly gets me my eBay purchases in two days and sometimes less... go figure.

Not necessarily... When I lived in one of the Chicago suburbs (conduit required by code), I had to pull some extra conductors through various parts of the house, and in order to ensure that I didn't confuse myself I chose colors that weren't already used anywhere in the house -- orange, yellow, and light blue. Because I had to wire the basement for a rec room and a workshop later on, I saved money by buying 500' spools of the orange and yellow -- the point being that the basement got wired with white, orange, and yellow wiring, all completely legit, per code (it was inspected and passed), and not at all "control cable". Also, using the conduit as ground was completely acceptable in Chicago and surrounding counties. I did pull one run to my home office for the computer equipment with a ground wire and it's own outlet -- if I recall correctly, one uses a specially marked and colored outlet to signify such a dedicated run. Regarding the original post, I think code demands a switch at each entrance to an attached garage. So removing the switch by that door, unless the door is permanently sealed and completely inoperable (not just "unused, it has to be sealed in some way), it may be a code violation to remove that switch. Just sayin.