larryllix

The light requires a switch. Install a SwitchLinc, instead of mechanical switch, to control it, wherever you mount the switchbox. HCS

My apologies! I went to v5.0.x as soon as it came out over a year ago, and I would have (and did) swear those options were there in V4 and earlier. Sorry I wasted your time with a solution that wasn't going to work for you.

He is operating the dimmer from the built in paddle in the SwitchLinc and the two devices cannot be divorced. Scenes are not going to do it very well, without bright flashes with the light going on full brightness first and then a program delay to activate a scene to dim the light. In the middle of the night that is unforgivable. on the eyes. Thinking back there is a better way that I have used for this. Set the local level to say..20% (for night usage) and create a program that overrides, and beats, the 20% with a fast On during the day time The level can be set in the admin console with the device's webpage page. If ...SwitchLinc is switched On ...And ...from 7:00 AM ...to 11:00 PM (same day) Then ...set SwitchLinc 'Fast On' Else ...--

With a good backup file, you could try v5.0.7 for the least problems. few admin console errors on bootup and a few devices not showing status. All Insteon programs work properly AFAIC. If you have too many trouble you could reinstall 4.5.4? and use the Restore to resume where you started from. May take an hour or so. I have no Zwave and it would be a bigger concern to do this, from reading others reports. I have never had a system hang, or an undesired (that wasn't my fault) operation from even the worst of the v5.0.x alpha versions, yet. Totally stable, just not complete or without useless errors popping up.

No? Thanks. But they should all have the local level as a basic setting. @OP. What version are you running?

At first glance your idea should work. Post your programs here so people can look for quirks that are easy to overlook. You may need to quote his post to get his attention.

Here you go! It's hiding. Maybe you have to scroll more on the pulldown.

and I answered you that you do in every version since v3 that I have been using ISY. Post #8. Maybe you missed it.This was the very first thing that Insteon devices did. have a local, settable light level and ramp speed. You can even set it at the switch paddle if you read the manuals. Look harder. It's there. I need to get on another computer to give you a screen shot

I finally tore the 1/8" jack off the iR sender cable since the unit is garbage anyway. (shiiping to return cost more than the warrantied 2411T) The iR LEDs were wired backwards. I patched another 1/8" jack together with the supplied cable and plugged it in. Voila! Red LED flashing when sending codes. SH QC is a joke and a lie. This unit would have never got out the door if they performed any testing on this unit at all. Now to make v5.0.7 actually link with it. The instructions in the admin console screen box make no sense and don not work. Linking worked a few times but very intermittently. occasionally another linking box pops up and I have had one success with one code but cannot mange to get it to connect again for more programming. The latest device version they shipped me, and I waited three weeks before they shipped from the Labour Day sale is V1.A, 1444, That's right... 44th week of 2014. Thanks Smart Home for wasting my money and always delivering the latest firmware and product release. Jerks! I have been determined to stick with one system. Insteon but ZWave is starting to look much better to me, every SH day.

If you are setting the local On levels by a time frame program this program is not necessary. Just tap on the top of the switch and the light should go on to the set level by your other local levels setting program. See post #4 top program. Then No scenes are required and usually not used for one light. No other programs are required unless you want to time the light off automatically or something else from it. Your program will be competing against the paddle direct wired to the dimmer.

Women have higher priority interrupts and the process usually focuses on them. They shop for that feature in a coprocessor.

Unless it's his wife requesting it.

It works but yuk. I can't recommend v5.0.7 to a newer user but...

Yes, but the quest lies with SH, probably. I watched SCADA systems protocols grow over the years. The one I worked on started with reporting by exception when asked on a regular basis, and a master All data Poll on a periodic timed basis and/or after a bootup. This idea is very similar to the Insteon protocol idea. Device only report when something changes but the master (ISY) can do a all device query when needed to get back in sync. Years later that protocol evolved so that everytime the remote terminal was polled, any changes to devices were report, the same but each response (even if no change reported) one addition piece of data was added to the response in a Round Robin fashion. After enough polls for changes, everything was updated and always up to date with no massive flood of data coming back. ISY could do this where devices are not battery operated. Let's say ISY detects there are no impending operations and all programs are sleeping (not running or in a Wait line). Now ISY could query one device and update it's database. Next time the next device in the list could be queried. This could be on 5 minute, or setting, basis. The Query All would still be required after power up as ISY knows nothing yet. The Query All at 3:00 AM would become redundant. Several times per day all device statuses would be updated and devices not reporting failing in their reporting may get corrected. Device failures could be detected earlier. Comm problems could be detected before devices are needed.

Welcome to the forums! NO automatic font sizing, only manual. Font sizing should really be the jobs of any decent OS making the system hardware independent. Trouble is the font size is an out of date syste based on printer dots and vide card dots and not the actual size seen by the user. Windows has attempted to correct some of this by implementing scaling factors on the fonts but has let the user base down, apparently. Apple, Andoid and ancient Linux knock offs, have done worse. This should not be up to the application to determine the size of your monitor but I guess a few more gigabytes of code spread and duplicated through every application known to mankind is OK in this wasteful era.

I have to admit. I looked the word up in as many language dictionaries (Spanish slang?..nope), as I could find, and couldn't think of a better way to bot tle it.

The tag manager can stuff ISY variables on your LAN with any port forwarding. But... The Tag manager only operates by cloud permission, or running KumoApp code on the cloud servers, and then telling the Tag manager to send it. Not quite completely clear of cloud dependence but no open port to the outside. Tag -->Tag Manager--> Router --> Cloud server (kumoApp) --->Router--> Tag manager --> ISY

Interesting! I would like to see what you did. Can you link to it or give more clues. See my post above. I didn't think any analogue change triggered data could be done without cloud, just level triggered reports. (high/low) Editting after reviewing the KumoApps code. (thanks MWareman) Thanks. EDIT: Wait. I am totally wrong on that one. I checked my KumoApp code and I am using a LAN based access into the ISY. So the KumoApp code is running on the cloud and sending the actions to the Tag Manager as a portal into your LAN. Then the Tag manager send it via your LAN to the local devices (ISY). No port forwarding required!

Sorry...confusion there. No port forwarding is required to use the Tag manager to work with the tags. Port forwarding is required to allow the KumoAppa code to stuff variables into ISY through the native router firewall. This is incorrect! The KumoApp code talks through it's own portal to the Tag manager that stuffs ISY variables, via your LAN. No prot forwarding required. (Thanks MWareman) I believe the simple threshold notifications come from inside the Tag manager (but still require cloud "approval") and the KumoApp analogue values come from the cloud server (proven by the port forwarding requirement) to the Tag manager and sesent to your ISY on your LAN. @Paul. do you have some Tags?

It's been hard with so many conflicting statements out there to determine exactly where all the storage and smarts are done from. I only know when you unplug your Internet connection on the ISP side of the router, the tags stop working into ISY on the LAN. CAO claims this is because they do many calculations to linearise the temperature sensor and other sensors. Sounds like mostly BS, to me.

I just did a test and the windows keyboard shortcuts appear to work OK in the admin console for win 7. I always use the original key shortcuts though. <shift><del> and <shift><insert>. Touch screen based machine don't like to support key shortcuts, unfortunately, so you have to do some finger contortions, and physiotherapy later, for your crabApple fingers.

AFAIK it stuffs the variables from the cloud service. So yes a port forward has to be done in your router. Many of us have this working for the last year or two. I have four tags. Scott has a bunch as well as MWareman would wrote the original code found in one of the threads about this. They work very well and easy to implement with many different ways to get notifications. Scott has the Tag manager accessing his honeywell thermostats that they added a hook in it, for.

The IP address needs to be static. This can be done in ISY but a better idea is to let your router mangae it. In your router, look for a DHCP reservation table twhere you assign a permanent/same IP address to be issued everytime it gets asked by a crtain MAC address. Then you router knows what it is and never issues the same IP to anybody else, causing a conflict.

I don't think the admin console ever allowed pasting on a windows OS. Maybe in the URL I may have used it. I use the copy NR function, and then modify, to expedite things similar.

Yes The CAO Tags use a Tag Manager module that has to check in with the cloud service to work though. They provide a cloud website called KumoApp where you can write or copy code to stuff your ISY variables with temp, humidity, angleX,Y,Z, Battery voltage, motion, loss of signal, Illumination for some newer ones. These report by exceptions typically to keep traffic down. This is done via the ISY Rest interface. Very accurate and the Pro models can keep data for months without contact and then update like they were never gone. They also report by many methods like email, push notifications, text messages, and vocals through their app on your mobile device.