jtara92101

Thanks, Javi, I will explore the front aux connector. But I'd imagine it just has a mechanical switch that is activated when the plug is pressed in. I found out how to make a drink. You have to ask Tender. Still getting used to the idea of asking different services. For food recipes, though you don't ask through a service. I actually like that each service has a different voice, unlike Alexa. I don't like that they (at least Tender) will bug you until you dismiss them. Tender wanted to offer more cocktail recipes. (I used "thank you, Tender, goodbye!" There is a history list of all interactions and you can play back your voice. I guess this is in the interest of full transparency so that you know just what the device has recorded. I'd like to think that once you erase the list, it is truly erased. OMG I asked "Hey, Google, can I change your trigger word?" It gave me instructions for changing ALEXAs trigger word on Echo! Google needs to get themselves moved higher in the search results!

What if you are playing a record on your quad system at the time? And now you want to turn on the lights in the kitchen, because you want to make Jiffy Pop? So, you say "OK, Google! Turn on the kitchen lights! And, oh, what is the weather going to be like tomorrow?" Google answers, through your preamp (or some thingie in front of it) and you hear the weather recited on you quad system, and your Steely Dan record is automatically muted or attenuated for the duration of the answer. Once you hear the weather, the record is un-muted, and you return to your Big Black Cow. That - or the functional equivalent - is what i mean by "cut-through". A specific source (a home assistant appliance, in this case) can "cut through" whatever is now playing, without having to actually switch sources. Like an integrated navigation system in a car would override any other audio source for the duration of an announcement. So... it would be handy if home AV receivers would have an audio input (or inputs) that can "cut through" in the manner described above, as it would be very handy for "home assistant" type devices.

So, my neighbor gave me a Google Home device. His dad gave it to him for Christmas, but he's too paranoid to hook it up. Just unboxed and set-up, so no real experience yet. I have to say, am impressed with a few things: 1. It's actually un-tacky and even attractive, and fairly unobtrusive. 2. Amazing sound quality for a little box. Impressive bass and impressive stereo separation. 3. The voice mic is plenty sensitive and voice recognition seems very accurate. (Better than Siri on iOS, which drives me batty!) I have the device in my living room, and it can "hear" me "loud and clear" from my adjoining office. One thing that is immediately obvious, though - and this goes for all such devices - I would like to have the sound be routed to my home AV receiver. Only problem is, home AV receivers are going to have to catch-up now, though. While I could use a ChromeCast Audio device to connect, there is a feature lacking (I think - have to dig through my thick Denon manual...). They need to start adding a "cut-through" input that will override regardless of current source. Sure, I could perhaps set something up to switch sources back and forth, but that's just too clunky and not fast enough. (Maybe newer receivers have this? I have a several-years-old AVR3311). Of course, anything (in the future, I suppose) that will have ChromeCast Audio built-in would I presume have a cut-through feature. This is going to be "interesting", as I am an iOS/macOS household otherwise. There are some deficiencies. It doesn't know how to make an Old Fashioned. Fortunately, I have that committed to memory. It sure as heck isn't going to know how to make an Aviation. (It doesn't.) It does, however know how to make Osso Buco, and helpfully drops the written recipe in the Google Home app. It seems to have an anti-alcohol bias, which is something I would more expect of iOS.

It might make sense to use a beacon that supports the multiple competing standards: - iBeacon (Apple) - Eddystone (Google) - AltBeacon (Radius Networks) And in any case, it would make sense to support multiple standards, if at all practical. AltBeacon is fully open-source with no licensing needed to build hardware or deploy software that uses the standard. Whether it gains any traction is another matter. The Radius Networks hardware products support all 3, and many products support both iBeacon and Eddystone. Radius does have a compact USB dongle like the BleuStation 100 (as well as other form factors), at similar (I think a bit high) pricing. But you can buy them in onesies without a hassle. A quick search of Amazon finds a number of iBeacon/Eddystone USB dongles at lower prices. I'd imagine a search of Alibaba would find them even more significantly less expensive, at varying levels of quality.

The Bleustation's seem pricey, and currently only available in 10-packs? Anyone know what the different is between series 100 and 200, other than size? Their website isn't very helpful. OK, I found a Starter Kit with 3 beacons. No pricing, though. I gather they are going for the retail market. Doesn't seem to me a good match for home automation, at least with their current marketing.

https://en.wikipedia.org/wiki/Solar_storm_of_1859 Luckily, we haven't had anything to match the Carrington Event since. (Well, we have, but fortunately aimed away from Earth). I think it would be devastating to modern-day electronics.

"control" is a transient EVENT, not a STATE. "control" has no "memory". Your second program will turn the light on when the keypad is operated to unlock, so long as it is between sunset and sunrise (next day). If I understand you correctly, you want the light to come on from sunset to sunrise, provided that the gate was last opened by the keypad. You will have to maintain some variable. Set it true when the door is switched unlocked by keypad. Set it false, when ??? (What did you have in mind?)

Do you have an RF remote? If so, is it one of the old Multi-Elmac remotes (or compatible?) And, if so, are you in an area with military installations? It's been a while since I've seen reports on the local news (San Diego) about "garage doors opening spontaneously all over town". I suppose because newer remotes are of a type that's not susceptible to the (alleged) interference that causes them to open spontaneously. I find the theory a stretch, as you'd need to have pulses that just happen to correspond to your code, and with the right timing. But it's on the record. http://www.sandiegouniontribune.com/sdut-remotes-for-garage-doors-car-locks-on-the-fritz-2010apr03-story.html http://www.sandiegouniontribune.com/sdut-navy-radio-might-be-crippling-conn-garage-doors-2012jul23-story.html http://www.sddt.com/News/article.cfm?SourceCode=200412061a#.WJKU4UUrK-Y USUALLY it has been limited to non-operating remotes. But there also have been reports over the years of spontaneous openings.

I suppose the reason you haven't seen this discussed much that that few of us have any interest in this type of configuration. Most would put KPL or SL in all of the switch boxes, and then either run the light off of one KPL or SL, or else use the micro module, and create a "virtual" 3-way circuit. I have considered using micro dimmers in my bathroom, because it would enable me to use a "vintage"-style pushbutton switch by using the seldom-used sense input. So far, I have only deployed one micro-dimmer, in a closet. I replaced a glass-globe light with pull cord with a flat LED light. Since there were only hot and neutral in the box (and no protective ground!) I used a micro-dimmer, and put a battery-powered micro-switch on the wall outside of the closet.

So, install a microswitch behind the fridge. When the fridge tips back, it will close the switch, sending a signal that she has parked! OK, seriously - gated parking garages in condos, commercial buildings, etc. usually/always (code, safety, stuff like that...) have a coil of wire buried in the concrete that will detect a car passing over it, and open the door to allow a vehicle to exit. (In my building, we keep a weight plate near each door to place over the coil for the garbage ma.... er, waste removal technician, for moves, etc.) Maybe you don't want to hack away at your concrete. But I'd imagine you can do something with a coil under some sort of mat, etc. In lieu of a commercial system, there is this: http://hackaday.com/2014/04/04/building-an-inductive-loop-vehicle-detector/ Note the above (in comments sections) also discusses surplus detectors that can be picked up very cheaply. It won't solve the refrigerator problem, but at least it will provide a reliable presence detection. Actually, maybe it could solve the refrigerator problem. Would need two inductive loops. Would need some experimentation with placement of the forward loop, and might be difficult to make it work reliability with multiple vehicles. (Different sized hunks of metal over the loop...) You could flash a light, sound a buzzer, etc. just like in the automatic car wash. Another approach - there are loads of non-contact gadgets available that will solve the refrigerator problem - high-tech (or low-tech) alternatives to the tennis ball on the string. Just find one that has a relay output. On the other-other hand, I don't know that it's a good idea to ENCOURAGE pulling up all the way until the alarm sounds. Unless you have the OPPOSITE problem (door closing on trunk.) So perhaps best to separate the concerns of presence and position. For a complete solution, you could use 3 sensors, of whatever type (inductive, optical, whatever).

That's not how ISY programs work. They do not "execute over and over". They are asynchronous. Programs only run when the state of any of the variables that the IF examines change. (Or when they are manually run or triggered by another program.) They are perfectly efficient for monitoring state changes.

It will act like any other IF invocation - it will evaluate the condition, and run either the THEN or ELSE depending on the result. But I would suggest you don't activate a scene OR run a program. Just set a variable. Then you can write a program or programs that make use of the variable.

If you are opening a door, I'd think you have the OPPOSITE problem. You WANT a limited distance. I'd think you wouldn't want to open the garage door while blocks away. Does your garage door take an extraordinary amount of time to open?

An iPhone 4S (as well as certain iPad/iPad Mini models and iPod Touch 5G or later) or later can be used as an iBeacon. Really only meant as a convenience for developer testing. https://blog.passkit.com/configure-iphone-ibeacon-transmitter/ There are a few App Store apps available to do this, as well as sample code if you want to build yourself. Here's one. I haven't vetted it. https://itunes.apple.com/us/app/locate-beacon/id738709014?mt=8 https://itunes.apple.com/us/app/ezbeacon/id842580782?mt=8

Put an iBeacon in the car? Ideally, wired-in in some manner so that it transmits when parked, and not when driving. (No good reason, except it seems silly to drive around bleeping "i'm here" to the world. But then again, that goes when at work, the mall parking lot, etc. etc. etc.) Or some kind of long-range RFID tag? Random web page I found: http://www.phaseivengr.com/wireless-technologies/wireless-technologies-overview/about-wireless-rfid-sensors/about-ultra-long-range-uhf-rfid-sensors/ Apparently "ultra long range" is 20+ feet, is that good enough? Been a LONG time since I've messed with this stuff. We used "long range" passive RFID when I worked at the (now closed) San Onofre Nuclear Generating Station. "long range" back then meaning a couple of feet, so that workers could just walk through a portal without having to scan a card, use a fob, etc. (FWIW was not for access control but as one aspect of exposure monitoring - they still had to show a bade to a guard!) I think there were portals in various places within the Red Zone to monitor when workers entered/left certain areas so that their time in the area could be tracked.

arp-scan can take an IP address, a subnet range, or a domain name. I assume the above refers to devices with local domain names phone and phone2.

Oh. The LED is supposed to be green? Doh! I just looked at mine. It wasn't lit. Unplugged it and plugged it back in. Now green. I guess this is a sign that it is failing/failed.

Andy, as I understand it, rEST isn't limited to direct access to the ISY - it is available through the portal. But now I see the purpose of the IFTTT inbound API - it allows use of a token rather than user ID/password. And the token has limited scope to performing one action only. User ID/password would be protected inside of SSL (though there is a small potential security issue with this) but I wouldn't want to provide user ID/password to a third-party service. It might be OK in a trusted app, but I see the "IFTTT".

As Andy has pointed-out, the IFTTT section isn't necessarily just for IFTTT. The "inbound" part of it can be (mis)used by ANY service app or service. I'm a bit confused, though, why this is thought necessary for Locative integration. Why not just use the rEST API?

You certainly can set-up a KPL to trigger different programs from each button to provide different lengths time. I prefer a more "automatic" approach that I have used in the past. (I moved and no longer have bathroom fans - one has a window, the other has an always-on vent with central fan several floors up.) My previous system was much praised by my interior designer. She commented that she loved the idea that the fan just turned on with the lights, as it avoids the embarrassment that using the fan implies a certain usage mode of the room... So, my setup was: - fan on when any light in bathroom goes on - fan off when all bathroom lights are off, after a timeout - there were "shower hours", during which the fan use was extended - the bathroom fans were also part of a "whole house random ventilation schedule" (e.g. fans and HVAC blower) - as the fan was on a SL relay, you could still manually turn the fan off - I later added a moisture sensor on an IoLinc, (just screw setpoint on sensor) so if there was excess moisture, the fan would continue to run in any case (placement is tricky, my initial placement underneath a "floating" vanity was unsuccessful.) - the hope was people would just go for the big top button on the KPL, which set a scene with vanity, shower, and track lights at "dramatic" levels. Other buttons were for shower, shave (or you could call it "makeup"), cleaning levels. You might want to do other variations on this, for example set fan timer based on length of occupancy. Really, the fan should come on with any occupancy of the room. The primary purpose is to remove excess moisture from this small room, and one would expect at least the sink faucet to be used upon any occupancy. If you search the forum, you will find descriptions (and programs) for MANY elaborate bathroom timer schemes. It seems to be a favorite of tinkerers!

From direct observation, it is my understanding that the IFTTT Maker Channel is NOT real-time. Am I wrong about that? Has it changed? If Maker Channel is not real time, it would matter not if RemoteLync IFTTT channel is real-time or not. Maker Channel delay is ONE of the reasons I abandoned using Nest's excellent home/away detection to set a variable on my ISY. (The other reason is that Nest doesn't do home/away detection if the thermostat is set OFF.) Maybe it is just because Maker Channel recipe for Nest has to poll Nest service, whereas RemoteLync notifies IFTTT directly?

Browser makers are progressively restricting the use of Java within the browser. They've done this because running Java applets found on random websites is just plain unsafe. They've progressed from "opt-out" to "opt-in" to "nuh-uh". Chrome, for example, is at "nuh-uh": https://java.com/en/download/faq/chrome.xml Java isn't and never was a "browser" technology. Java applets run on your desktop system, outside of your browser. But in the early days, browser makers made it easy for Java plugins to automatically download applets when you visit a web page and then display the output within the browser window, using a plugin. Those days are gone for some browsers, and on the way out for others.

But your home might be a pile of cinders by the time IFTTT notifies the ISY, as IFTTT only runs triggers every 15 minutes, and so the average response time is 7 1/2 minutes. Bumbershoot's solution will work if you have HARD-WIRED alarms that use a traveller wire. These use two wires to power the unit with AC (also have battery backup) and a third, "traveller" wire that is used to signal the other alarms to sound if one goes off. First Alerts that support RF signaling are available in both wired and battery-only configurations. So, Bumbershoot replaced ONE of his Kidde's with First Alert. I assume that with that setup, you will not get a correct indication of the location of an alarm. e.g. if you put the ONE First Alert in the kitchen, an alarm anywhere is going to indicate "kitchen". The First Alerts that support smoke bridge do not use your "house wiring" to connect to the smoke bridge. It is RF, and it is proprietary. And I wouldn't want to "hack" it in any case, or any safety system. (on edge of seat awaiting Teken's response...)

Spec sheet on the relays: http://rabbitmax.com/files/SONGLE-SRD-05VDC-SL-C.pdf Mechanical relays will always be rated "each". It is just opening and closing a mechanical contact. Any voltage UP TO 120V. (Actually, says 250AC/110DC) Note that the ampere rating is derated at lower voltages. 7A@28V. No specs are provided below 28V. (The Form C versions get derated, and that is the version on this board. Form-C is break-before-make.)

Some hope: http://stackoverflow.com/questions/33409530/amazon-echo-push-a-message-to-the-device Only a rumor... I leave it as an exercise to the reader to find the denials of the rumor. http://www.digitaltrends.com/home/amazon-alexa-push-notifications-fall-voice-activated/ Live demo of a work-around: And forum thread explaining it: https://forums.developer.amazon.com/questions/40799/workaround-for-push-notifications.html