mwester

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.

Nope, factory-resetting the unit has no effect on anything else in the Insteon network; only that device itself will be erased. Now, other devices may still have links referencing that reset unit, and certain software or functions may not work the way they should because the PLM erased it's links - but even that's quite fixable. Just don't plug it into ISY B to test it - that could be bad.

Yep, exactly. Seems really odd, but that's actually pretty common when dealing with z-wave and network resources, or basically with any devices that are not Insteon-based. With a pure Insteon-based implementation, the scene and the button behavior usually "just work" because of the way one usually constructs scenes; when I added z-wave I ended up creating a bucket-load of scenes that exist for no other purpose than to control the LEDs on my keypads. Naming conventions are useful to keep those scenes separate from any Insteon scenes that have controllers driving them.

Add button d as a responder to a scene. Then, in your programs that do the hue work, just set that scene to "on" or "off" in order to cause that LED on the keypad to illuminate or not.

Nope, you're right -- the 2413S does not supply power (unlike the 2412S, which did).

Well, you're on the right general sort of direction, in the sense that there is an alternate way to gain access to the ISY -- but it isn't through the PLM. Your ISY should have a micro-B USB port on it -- plug a usb cable in, and plug the other end into your computer. Now, what you do once you get that done I can't tell you.. I've been meaning to try it, but the problem is that the ISY just keeps working so I've never had any incentive to do so. But I think there are other threads here on this forum where users have done that and recovered the ISY, so perhaps a search would help. Otherwise, someone will be along (perhaps even the UDI folks) and offer some assistance rather soon, I expect.

but only in white...

I do love those buttons - very, very nice. I'm going to hold off on an engraver, though. The fundamental problem that I see, at least for me, is not the engraver -- it's that the person using it needs to have some skill and artistic ability to create a nice, clear, clean, meaningful icon for the button face in the first place! And since style is not my strong point (heck, I consider it a good day when I successfully match my socks!), I'll have to wait until we get some sort of "button graphic library" created. Again, nice job on the buttons, Marcin!

I agree with you, EddieRock - up to a point. I guess my concern with opening that up in general is the potential for abuse - it would make Alexa just intolerable if a random skill that I've enabled suddenly made Alexa shout political slogans during the dinner hour in order to push the agenda of the developer... I think Amazon needs to figure out a mechanism, somewhat "android-app-like", where I approve the features such as the ability for something to make Alexa speak. The fundamental difference is that right now, a skill does not actually get access to anything from my Echo until the skill is addressed by me invoking the skill FROM MY ECHO (emphasis). What you're asking for troubles me because it opens up a means for some other thing, be it connected home, or some third-party skill that I (or my kids) have enabled, to cause the Echo to initiate something WITHOUT the echo itself being involved. From a security point-of-view, that means the attack-surface of the Echo has just dramatically increased. So, I'm willing to wait to see what Amazon does. And, if they do the wrong thing, I'm also willing to put my echo and tap up for sale on eBay.

Congrats to the creator of this. However, I think I can do pretty much the same with an angle bracket from the hardware store, a bit of black paint, and a black wire tie... for less than 2 dollars! (and it wouldn't even look to much different!)