jtara92101

This is getting ridiculous!

I dunno about the mini switch (even though I have one!) but the regular 6-button (now called "5 button"...) and 8-button switches can be field-converted between the two configurations. You need the trim kit and you need to do a special reset procedure.

Not so fast the the defenestration of the XML. XML compresses quite nicely. And the connection from mobile vendor backend to UDI backend should be compressed. As a developer, I prefer using JSON, as it is much easier to consume. But it's just as bloated as XML, and also as easily-compressed. XML is more open to compatibly-modifying data structures in the future (and with good design practices) without forcing the need to update existing software. JSON is more limited in the data structures it can represent, but works for most needs. I wouldn't recommend a pure binary connection, as it would be very difficult to deal with schema changes over time. There is a spec for "binary JSON". http://bsonspec.org/ I do this for a living - write mobile apps that talk to APIs. I've worked with a couple of the U.S. National Laboratories on apps that front-end services that analyze energy efficiency of buildings. some quite complex data. One lab choose XML, another choose JSON. The XML one took a mess of code. The JSON one was easy-peasy. The work of "Lab X" has been taken over by "Lab Y", FWIW. The JSON one. Currently, I write mobile software for dispatching service technicians. JSON APIs. Easy-peasy. Either way - XML, JSON, or something else... KISS. It is common to offer EITHER XML or JSON, as well. But of course makes the web service code more complicated. While *I* prefer JSON, UDI no doubt has their reasons for XML. They've adopted it extensively, it fits with the way they've been doing things. Either way, efficiency really isn't much of an issue, due to their compressibility, and has to be balanced with upgradability.

Exactly! Again unsure of Android, but at least on iOS, apps do NOT have to stay running to receive push alerts. The push alert opens the app, which need not show UI when it receives the alert. (App decides what to do.) Assume Android is similar. This also leave it up to each mobile software vendor to implement the actual mobile-platform push alerts. And, so, it is the mobile software vendor (not UDI) who will get in trouble if they abuse the intended use of the push service. (Yesterday's brew-ha-ha with the Dash documentation viewer - Apple revoked developer status of the developer alleging some sort of ratings abuse) makes me glad that I have no published apps in the app stores - at least not under my own or company name. I develop apps for internal use by multi-national corporations. I cannot afford to jeopardize my developer account by having something stupid happen like a perceived abuse of app store...)

BTW, while going off-topic. I have two nice Trine solenoid-operated latches that go in your door-frame that I have no use for. I've been meaning to put them up on eBay. PM me if interested in purchase or trade - would be interested in current-generation dual-band Insteon SL or KPLs if you've got extras! These WILL keep the door locked (closed). They are to be used with deadbolt-only. They can be changed to fail-open or fail-closed. They are each slightly different design.

Au contraire! One in the wild, in the hallway outside my condo. (See photos.) On either side of stairwell to isolate the stairwell. Used for it's intended purpose, for fire protection. They are used on fire doors that are left open for convenience. If the alarm is activated, or - quite by design - upon loss of power - the electromagnet will release and the door will close. Without this device, would need a closed door with a "this door to remain closed at all times" sign. I made a little video, but too big to upload, even in 480P. It takes quite a tug to close the door. Children might have difficulty. Looked at the specs on the product linked above, was surprised actually how little juice it takes, so you can't really object too much based on wasted power. (.05A at 24V = 1.25W). This seems smashing an ant with a sledgehammer for OP's problem. Would have to install a closer that will stand daily use (note the ones in my building to not get daily use!), purchase the electro-magnet, install an electrical box in a strange place, install big ugly magnet thingie on the door, make sure the electrical box is mounted firmly enough to withstand the big ugly magnet thingie banging against it (daily!) when the door is opened. ---- Speaking of fire protection, did you use a fire-rated door on that room you built inside your garage? Is the original door from the mudroom (original garage entry door) fire-rated? Per current code? Is the wall you built fire-rated? That's a garage. With a car. Loaded with gasoline. I'm a bit sensitive to the subject, as I've had fires next door twice in my life - both thankfully of fairly minor consequence. In a 28th floor high-rise in Detroit, there was a grease fire in the kitchen right next door. Nasty water came under the wall. And, more recently, in the place from which I recently moved, neighbor left a wet rag over a can lamp on floor with incandescent bulb. Thankfully, only smoldered. Fire department responded and I wasn't home, so fire department broke into my condo to insure nobody was inside. HOA irresponsibly did not call their on-call guard service, and I came home to an unsecured door and not knowing what had happened. First thought was break-in, but there was iPad on the kitchen counter... Did not smell any smoke. When I was a kid, as well, house two doors down burned to the ground. Current residence was declared "completely fire-proof" when it was built in 1927. Wisely, those chimneys xxxx staircases are today protected with fire doors, and the building sprinklered. 1985 code (when my previous residence was built) only required fire-rated doors on every other unit, and even then I think only because units are in pairs with facing doors. Developers almost always do the minimum needed by code, so every other door was a metal fire-rated door (neighbor had the metal door, I didn't). State Farm (neighbor's insurance) cheerfully paid for installation and finish (quite an expensive finish, I might add - bright red HollandLac, lovingly applied coat after coat after coat in landlord's contractor's garage...) of a new, 2-hour rated wood door. A 2-hour fire-rated wood door will run $400 minimum, and you won't find it in stock at Home Depot. (It was ordered from Lowe's - Home Depot didn't even know what we were talking about!) We worry a lot about home security here, but don't often see anything about fire protection.

Alternative solutions might involve: - A short piece of wire, or - A small magnet, or - A manual for the alarm system Short and to the point!

It seems to me your use case is very similar to the current email notifications. Would it be sufficient if the user could add a notification to a program? Others seem to be seeing this more broadly, and - I fear - not really within the intended usage of push notification services. Since an individual CANNOT originate push messages (that is, other than using a Apple/Google-provided or third party app) and in any case push messages have to be put in the push network(s) from an always-connected server, it would seem appropriate for the Portal to do the job. It would round-out the current email and text notifications. So, if a user has a portal subscription, they should be able to add something in email/notifications to create a recipient that is reached via push notification. Alas, I see a fly in the ointment. Push notifications - at least for Apple, Google may be different - only go to a specific app. For Apple at least, UDI can't send notifications that can be consumed by your app. (Not YOUR app, as it is Android...) They can only send notifications to their own app, which they don't have. It could be done in a round-about way, if UDI had an app on mobile devices. The UDI app would receive notifications, and then could notify any apps listening on a device using a Custom URL Scheme (iOS) or an Intent (Android). Again, this is all with Apple infrastructure, which is what I am familiar with. Maybe James can comment on the differences with Android push services.

Define "stopped using"? You mean permanently? Or just that the phone is turned off, etc? You are SUPPOSED to continue to send push messages even when your phone is off. It's practically the whole point of it. The backend service will queue them for when the user's device(s) is/are online. Still not clear to me just what events are intended to be sent. These push message services aren't meant for any kind of bulk transfer, and should be aggregated, even for the same user. And unless the data is very short, it should just be a notification that tells some app that it ought to go somewhere (outside of the messaging infrastructure) to fetch it. "you're up next to sing Karaoke" -> cool "the Karaoke singing queue changed" -> cool, go get the Karaoke singing queue from somewhere "the Karaoke singing queue changed, Bob is up next, then Fran, Sarah, Frank.... -> uncool '100 new songs were added to the Karaoke library" -> cool, go get them from somewhere. uncool - followed by 100 song titles. 10 notifications to same user in 1 second's time - uncool, aggregate! Understand these are generalizations, based on how Apple APNS works - and sure the intent of the Google push services are similar.

No, APNS does not have an Android lib. It is exclusively for sending push notifications to Apple devices. And you do not SEND messages to APNS from Apple devices - they must be sent from a server that makes a permanent connection to APNS. There is no "lib" required, as the support for receiving push notifications FROM APNS is built-in to every Apple OS. Only mentioned it because I'd imagine Google has similar rules, for similar reasons.

I dunno about Google, but Apple APNS REQUIRES that a provider MUST make a connection to their service from a single server. They want the messages aggregated on a single connection. There is simply no provision for individuals to send APNS messages. (Other than through Apple or third-party apps, and all will employ a back-end service that connects to APNS.) Yes, an individual can fiddle it, if they get a developer agreement and set-up a server to talk to APNS. https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW9/ Thus, it would be inappropriate to the ISY to send APNS messages, and wouldn't be permitted by Apple. But if UDI would like to add APNS capability to the Portal, that is something that could be done.

A suggesting that UDI host button designs has come up here several times. Might I suggest a GitHub project or projects instead? It's not just for open-source software! Enlightened people use GitHub for any sort of open-source projects - electronic hardware designs, mechanical designs (3D print), novels, whatever... As far as somebody printing commercially with a licensed icon set - read the licenses carefully, and I think you will find many that are suitable. You might not find that the author anticipated such a novel use, and so in that case you can contact the author and see if something can be worked out. Keep in mind that in most cases, the author has anticipated that users will deploy the icons on websites or in apps or on printed pages used by hundreds, thousands, millions, billions of people. It's unlikely they will want to extract large license fees for printing their icons on buttons. They make their money selling the icon sets to thousands of software developers - 10 bucks, 10 bucks, 10 bucks, 10 bucks, 10 bucks! I use these licensed icon and font sets (icon fonts) extensively in my work of developing mobile apps. And has been pointed out, you can find plenty of free ones anyway. Now, try to license a letter font from a commercial font foundry for a novel use (or, really, ANYTHING other than use for printing flyers or whatnot or for use on a website) at a reasonable price. THAT is not going to happen! I have tried. I tried to license the font used by Bloomberg Businessweek. (It's not their own bespoken font) The foundry wants close to $1000 PER TYPEFACE to use in an app. https://fontsinuse.com/uses/10/bloomberg-businessweek I wound up using Input Sans instead of Neue Haas Grotesk. I was going for "highly readable", which Neue Hass Grotesk is, but Input Sans is even more readable, though a completely different look. Input is meant as a "programmer's font", but as it comes in a proportional version (as well as fixed-width, which is more suitable for use in an editor used for coding) there are many other uses for it! (I use it in an unpublished app for browsing Karaoke songs, where you will have drunk people trying to read a screen in the dark...) There is my daily peave, and at the same time a suggestion for a great font to use on engraved keys! http://input.fontbureau.com/ http://input.fontbureau.com/info/ For key tops, you will want to use it in a fairly heavy weight.

It recurred. Open Failed for [/CONF/46/PRP] I think this is a bug, but hopefully a benign one. I sometimes accidentally right mouse click. I think it must set some flag in another file saying "there are notes for this node". But I haven't made/saved any notes. So, it goes to open the file, and there is no file. Or is it just trying to open the file when I right-click, and because I have not previously saved notes, it gets the error message. Either way, I'd call it a bug to log it - or at least log it with this wording.

Got this today on MacOS Sierra. Was setting a lampLinc OFF from the console. May or may not be related. But why would a socket be opened just when setting a device off?

No difficulty. I just installed it. I noticed that message in the event viewer. It seems to me that the ISY is complaining it could not open a file in the ISY's filesystem. I doubt that the OutletLinc is a relevant detail. It's just what I was doing when I got the message in the Event Viewer.

That's why I looked the other way and hummed a tune. It is apparently a linear power supply.

I finally installed the OutletLinc Dimmer today. As I expected, it is able to dim the dongle driving the LED tea lights (as was the LampLinc I had there previously). I had to fiddle with the power supply dongle a bit - the position of the dimmer key magnet is touchy! I had to look the other way and hum a tune as I read "LAMPS ONLY". (But these are lamps...) Insteon could be a bit more innovative with their products. I would like to see a "low-voltage linc" product. Either as a dongle or as a in-box device, give us a DC power supply that will supply some small current able to run stuff like this and control the voltage and perhaps current limit. Programming voltage range would be good. The 0-10V "ballast" is a step in that direction, though I infer it is actually an older device that they'd intended for fluorescent ballasts which in a commercial setting accept a 0-10V signal to set brightness. I've got one waiting for installation of kitchen counter LED strip with a driver that accepts a 0-10V control signal. But this probably wouldn't supply enough current for a number of LED tea lights, as it's intended use is just a reference voltage and would only need to supply a very small current. And of course not in the right form factor. We have a precedent in USB outlets that supply line voltage and 5V for USB charging. So, UL should permit this to be built-in to an outlet. As well, Insteon should move into making drivers for LED strip lighting with built-in Insteon control. Right now, you have accept "non-architectural" dimming with a "dimmable" LED strip driver run off of an Insteon dimmer, or else do as I am doing and get a 0-10V-controllable driver and the Insteon ballast dimmer. And forget about RGB, RGBW, RGBWW, WW, you need a Rasberry Pi (or some always-on computer), a driver, a power supply, a WiFi dongle, and a flying saucer. Optional installation by LGM. This space is WIDE OPEN for Insteon and they are seemingly doing nothing.

I installed a new OutletLinc Dimmer today. Was curious as to what Insteon engine was being used, as it is at the other end of house from PLM and have had issues with some locations only accessible via hops through I1 or I2 (not I2C) devices. Unclear to me how to interpret the Event Viewer results (I did NOT get the message about reverting to I1), but I noticed a curious and seemingly unrelated entry in the Event Viewer: [FileOpen] Open failed for [Conf/47.PRP] ® Does this mean there is some flash memory failure in my ISY994 or a corrupted file? I repeated Query Insteon Engine, and did not get the error message again, so could be completely unrelated.

I have some Commercial Electric screw-in eyeball conversions for 4" and 6" cans. They have phosphor on the face of the central "bulb" part, and have a very significant afterglow when turned off, similar to the Philips A19 phosphor buibs. I've been assuming this is purely the response time of the phosphor. I'd think that all high-CRI buibs will have to use phosphor, and so would naturally filter steps. It may be, though, that that afterglow is too weak to really act to filter steps. I noticed your lamps are CRI 82, not particularly high, but also not awful. But high enough that I'd imagine they need to use phosphor. Did you set the ramp rate of your scene that controls the lamp(s)? The scene will have default ramp rate unless you change it. The ramp rate you set on the controlling Switchlinc will affect the ramp rate of it's (I presume, non-existent) load. To avoid cognitive dissonance, set the ramp rates the same for the SwitchLinc and for the scene, so that the LEDs on the SwitchLinc will follow the dimming of the scene.

Oh, oh, oh.... That hot tungsten filament will take a while to heat up/cool down, and will smooth the steps! So, a really good LED bulb might try to smooth the transitions when brightness is changed, using essentially (either an analog or digital) filter. And to do it right, they will have to determine the ramp rate and adapt.

I doubt the brand of LED (or driver - I presume these lights have a built-in driver) is going to make a difference in terms of "stepped dimming". If it takes a 0-10V analog input, I think it's unlikely it will have a ADC (if it even uses an ADC, brightness control may well be analog) with fewer steps than the 2475DA2. The Insteon 2475DA2 specs say it has 32 steps. It goes from 0-10 volts in steps of 0.3125 volts. Looking at 2447D, regular Insteon SwitchLinc dimmer, the spec says it has 32 steps "locally", but "increments of 1% with software". Seems a bit strange that 2475D would only have 32 steps, since it has no "local" means of control. (No physical switch.) Has anybody ever noticed that SwitchLincs are more smoothly controlled "with software" (whatever that means!) than they are using local control from the switch paddle? The tear-sheet for the lamp isn't very specific. Just says "0-10V dimming". https://www.1000bulbs.com/pdf/lithonia-2gtl2-lp835-brochure.pdf http://www.acuitybrandslighting.com/library/LL/documents/specsheets/LED%20TROFFERS.pdf Can you clarify just what you mean by that? I presume that, like any Insteon dimmer, you can program the ramp rate? No? maybe the default ramp is different?

I wonder if one reason for the push for TR sockets is that they couldn't get dongle makers to build their dongles upside-down? (So that outlets can be installed properly, with the ground pin UP. A dropped object then is likely to hit the ground pin first. But what about the neutral? It would be on the right then. I wonder if due to the spin of the earth... is there one of the remaining pins neutral/hot statistically more likely to be hit? If so, what about Australia? Mine are ground-pin-down now - I bought the ground-pin-up hook, line and sinker in old place, and... too many dongles I give in! Besides, ground-pin-down is more aesthetic. Either is permitted by code, at least in San Diego.) Anyway, it does help prevent accidents with half-plugged-in plugs. You still might have power with a plug a bit out of the socket. And then the occasional plug-that-was-made-with-too-short-prongs...

ALL of the outlets in the entire place were complete garbage, including 3 with open grounds and 1 with broken strap. The ones with the open grounds and broken strap were removed and capped at move-in. They are all being or have been replaced with commercial-grade TR outlets. The one for the tree sculpture is awaiting the OutletLinc dimmer, which will arrive whenever SmartHome's tin can phone lights-up with a call from American Express (still trying to get my lost shipment replaced, and SH needs confirmation that I removed the dispute.) The cover was off to vacuum out the inch of lint and to paint. I wasn't gonna stick the painted-on cover back on after fresh paint! Unrelated to electrical (unless The Three Stooges are doing the work...) had ALL of the angle stops replaced today, as they were a disaster-waiting-to-happen as well. (I LOVE that 3 Stooges episode where they get everything mixed up, and water shoots out of the stove burner, chandelier, and - the coupe de' gras - they turn on the TV and it shows a picture of Niagara Falls with predictable results.) And that's exactly why the one high on the wall behind the refrigerator and the one for the microwave got TRs as well, even though they are not required by code in those locations. I want to protect the BIG children as well! And of course under-sink. Not sure if that's required by code, but curious children do crawl under sinks. Any place where you might be fiddling with tools in a tight space needs TR. So, by inference, The Internet can kill you, because it is a series of tubes.

I don't know if this will work for you, but you could convert them to wired, as I have done. See attached photos. I have a metal "tree sculpture" that I commissioned. The artist made a few of them before mine, but only used battery-operated candles (which can be changed-out to real candles, if you want to live dangerously.) I got the idea to wire the LED candles, and he incorporated the wires. He's built several more now with the wires. Drill a hole in the base, push a wire through, and solder to the battery contacts. I used thermostat wire, as the stiffness was helpful for routing the wires through the sculpture and having them stay in place on their own without having to be tied-down much. I used connectors for each candle, so that they still can be swapped-out for real candles. I used a power dongle with switchable voltage from 1.5 to 12 volts that can be used to vary the brightness. But now I have them on a LampLinc and am able to dim them. I keep the switchable voltage at 9V to avoid burnout (though I have had no trouble with 12V, I just don't need it that bright...). I am awaiting shipment of an outletlinc to tidy-up the installation, whenever SmartHome realizes that American Express has removed the dispute over their lost package and has already notified them... (I am losing patience, though, and about to put it back on, along with a BBB complaint...) CAUTION: The lamplinc works great with THIS PARTICULAR POWER SUPPLY. It is apparently a linear supply, because it does dim nicely on the lamplinc, and to "architectural" levels. (That is, I can dim to very low levels.) It may just be that many/most of the switchable-voltage supplies like this will work. Otherwise, play it safe and use some on/off module! We've already had a discussion about this here, and I am sure others will chime-in with their own cautions. WFM but YMMV!

I don't know why a failing device would cause the firmware in the ISY to write when you ask it to read! Maybe there is a quantum link. A wormhole from the failing device that makes the ISY firmware act differently than it was programmed.