larryllix

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.

That is turning the device on to 50% or 10%. The OP wants the levels preset so that paddle operation actvates those levels. ..."So, tap the switch during the day and it comes full on. Tap it at night and it only comes on a little bit"

Scenes are popular with some users. You can adjust them before hand and then any source of controlling that scene will turn on the light to the same level. Scenes are not operated by the local paddle on the switch. The On Levels you want to adjust are similar to a scene with an On level and Ramp speed, like a preset the local paddle will operate.

On Level and Ramp Rate have been in every version since V3 when I came into the ISY world. Some of the settings are a bit obscure at first.

Ensuite Lights Level.adjust - [ID 012F][Parent 00FA] If From Sunrise To 10:00:00PM (same day) Then Set 'Master Bedroom / Ensuite Lights' On Level 100% Set 'Master Bedroom / Ensuite Lights' Ramp Rate 0.5 seconds Else Set 'Master Bedroom / Ensuite Lights' On Level 20% Set 'Master Bedroom / Ensuite Lights' Ramp Rate 4.5 seconds Here is another I use for mood bathing. Use a long tp down to get the lowest lighting the bulbs can do. Ensuite Lights Dim.adjust - [ID 0130][Parent 0017] If 'Master Bedroom / Ensuite Lights' is switched Fade Down Then Set 'Master Bedroom / Ensuite Lights' On 8% Else - No Actions - (To add one, press 'Action') Finally, here is two that adjust the blazing LED at nights. You will need to do it by time. I am using a tally from10 MS units dark reports. Set SwitchLinc LEDs Bright - [ID 0027][Parent 0036] If $sHouse.darkCount < $cDARK.THRESHOLD Then Wait 5 seconds Set 'Gathering Room / PotLight over Table' 20% (Backlight Level) Wait 5 seconds Set 'Dining Room / Dining Table' 23% (Backlight Level) Wait 5 seconds Set 'Gathering Room / PotLights over Chairs' 25% (Backlight Level) Wait 5 seconds Set 'Kitchen / Kitchen Bar PotLights' 15% (Backlight Level) Wait 5 seconds Set 'Gathering Room / PotLight over Desk' 15% (Backlight Level) Wait 5 seconds Set 'Foyer / Front Porch Lights' 15% (Backlight Level) Wait 5 seconds Set 'Foyer / Side Deck Lights' 15% (Backlight Level) Wait 5 seconds Set 'Mudroom / MudRm Potlights' On 12 / Off 2 (Backlight Level) Wait 5 seconds Set 'Master Bedroom / Ensuite Lights' 25% (Backlight Level) Else - No Actions - (To add one, press 'Action') Set SwitchLinc LEDs Dim - [ID 0007][Parent 0036] If $sHouse.darkCount > $cDARK.THRESHOLD Then Wait 5 seconds Set 'Gathering Room / PotLight over Table' 5% (Backlight Level) Wait 5 seconds Set 'Dining Room / Dining Table' 8% (Backlight Level) Wait 5 seconds Set 'Gathering Room / PotLights over Chairs' 11% (Backlight Level) Wait 5 seconds Set 'Kitchen / Kitchen Bar PotLights' 5% (Backlight Level) Wait 5 seconds Set 'Gathering Room / PotLight over Desk' 5% (Backlight Level) Wait 5 seconds Set 'Foyer / Front Porch Lights' 5% (Backlight Level) Wait 5 seconds Set 'Foyer / Side Deck Lights' 5% (Backlight Level) Wait 5 seconds Set 'Mudroom / MudRm Potlights' On 7 / Off 2 (Backlight Level) Wait 5 seconds Set 'Master Bedroom / Ensuite Lights' 5% (Backlight Level) Else - No Actions - (To add one, press 'Action')

IIRC I ran into the same thing with my an the Copy Scene Attributes solved my problems also. I never did figure out what it did, or what is is supposed to do. Good on ya' Mate! BTW: The devices under the scene listing, in the device tree, do NOT operate the scene values. The scene values are adjusted inside the scene page. This is a very common mistake for newbies. I don't know why they are still shown in multiple copies of the device page, in every scene, to confuse ISY users.

I don't use my KPL like a selector switch but when I read through that description I just walked away after an hour or so. I couldn't figure out WTF it was supposed to do either, so I can see not using it. Terminology is very cultural/area dependent and what is perfectly clear to one person is totally fuzzy to another. THis is a common problem as code monkeys are not usually good doc writers.

If those heartbeat detction programs are in place and haven't reported a failure then your HDSes are functioning as well as you trusted them when you crafted the programs. I think you had a power blink.

Possibly a power blink with ISY reboot and no door sensors have since reported any status change? Check the last time the program has operated in the summary, or there must be another way to ascertain when ISY last booted up. Do the HDS have a heartbeat? Heartbeat program?