larryllix

He is a poster from years back using a similar name. He may not be here much longer though.

Some programs are based on being enabled and disabled by other programs and double enabling them or double disabling them will not work with a complex arbitration program(s). Including a conditional line inside each program for $sVacation or $sOccupied, makes each program clear which factors influence the program instead of hidden parameters, and forgotten programs that most people forget to maintain every time they add a new program to do something. I have been down this rabbit hole many times before and trying to be lazy while programming will almost always bite you in the bum, sooner or later. Make it obvious and clear or you will pay.

I use folder conditions also for some functions that do not get operated frequently. Some of the problems with folder conditions is that programs can get killed in the middle of an operation and leave devices, and/or variables in unknown states. Another problem with this technique is some programs may be dependent on multiple conditions and that can really confuse the logic outcome. Another problem is testing a program in a disabled folder. There was never any indication the folder is disabled when testing the program but they just do not run and you may start tearing your programs apart in desperation to repair a program or two. I created two variables called $sVacation and $sOccupied. I have programs that run only while the house is not occupied and also I am not on vacation. These are completely different functions. My HRV ventilation system does not run while on vacation but does run while not home. While on vacation my humidifier doesn't run but does while just away. While on vacation I send house alarms via both email and text message. While I am home I only have Alexa speakers announce the alarms. My $sOccupied is operated and controlled by about 13 MS units and my KPL security keypad. Mostly timers based on movement in the house just retriggers a programmable timer to a location dependent time delay. Areas close to doors count down from shorter times than internal zones where TV watching lowers the movements detected. My $sVacation variable is operated by my ecobee thermostat which is very reliable with schedules and can be set up years in advance with schedule. It is the boss. I tried it the other way but the stat is remote controllable and very reliable. Outside lights come on for later times dependent on not being on vacation but not being home. Programs just look like this (out of house but not on vacation) If $sVacation is $cFALSE <------------ permanently defined variables AND $sOccupied is $cFALSE <------------ permanently defined variable AND Whatever light is switched On Then do something Else ----

This has happenned a few times in my Tag lifetimes now. When it happens I usually attempt to view the kumoapp webpage, and then my kumoapp code. If either is not running properly, or will not serve the code to me, I know the CAO Tag server is down. In this case, waiting for the server is usually the only course of action.

Good to hear constant micro updates. I haven't made the jump yet as it means rebuilding a PLM so I can trust it and I have had so many compound LAN and modem problems that I was avoiding adding any complexity to my system before trusting other components. Sent from my SM-G781W using Tapatalk

Thanks. That is good news and much different than what we have heard in the past from these clowns. Sent from my SM-G781W using Tapatalk

I had an instance a few weeks ago where the app hung. After rebooting the tag manager and restarting my kumoapps I just gave up and left it alone. A few hours later it came back by itself. I figured that was all just the servers but the power cycle may have set the stage for things to resume, also. The tag manager can seem to take half an hour to get back up to speed at times. Sent from my SM-G781W using Tapatalk

We went through some of this with Insteon nay sayers also. However, with Insteon, many 500' away via powerline connections have been posted as successful. Insteon RF is not robust enough to achieve more than a few dozen feet of distance in a hop. With Zwave, from what I read here, people have a hard time to get it to connect further away than the next room, so I am not sure where a hacker could even make a connection without sitting on your front porch. Multi-residence buildings, and commercial constructs may be a problem in that area. If this is a low level security in the protocol, the 700 series boards may have made that difference.

Interesting! I have no Zwave equipment yet but looking from the outside so far. What is this security used for? - Security of protocol and signal integrity? - Security against outside hacking into the signal/devices? What would ISY do with the security if a bad/hacked packet arrived?

ISY takes a Zwave interface instead of the Insteon PLM. It was a plug-inside board but not sure if another dongle has become the latest interface or not. Zwave may do better with shared wiring panels. Zwave is all RF comms. You may have to just try it, using enough devices as repeaters. Get advice from experienced people here for which devices support all the latest. Zwave has been through some cheap devices in the past. Will you also have some WiFi/Router for yourself? That could present some RGBCW bulbs that you can buy cheaply now for less than $10 each.

You could have problems with signal reliability depending on how large your store is and how the wiring is done. Do you have a subpanel / breaker box for only your store?

I found it best to keep the commands simple so that everything is Alexa....turn on/off xxx lamp/light/lights The verb and adverb are always spoken first. It works best. However I just found one thing that appears to be blocked from going to ISY. "Prime" anything. The devices are always Red Lights, or Red Bedroom lights for two different rooms. Alexa knows the difference between lights and just light and lamp. Occasionally it will ask which one, and a longer distance away from the speaker always works better. When I command her, usually the Alexa Dot at the other end of the house responds.

I wonder how Nokia can get all the ICs they need but Smartlabs can't.

Just imagine of Insteon devices re-transmitted X10 signals and amplified them? Now we know why they didn't try that one.

You likely need to find threads on the ISY Portal and @bmercier the creator of ISY Portal.

Portal? ISY Portal is a cloud based bridging software and can only talk Internet/IP. Perhaps you meant a PolyGlot Node Server (NS)? but then it is only IP also and would require a ZWave bridge. That may be found in your pol/ISY.

The M13 sounds familiar from my PLM code memoirs. IIRC X10 was supposed to transmit the code and then retransmit the code in reverse bits. I always thought it must have never been decoded though as so many random things could trigger X10 devices. I wrote a VB program to decode X10 signals and used it to debug one of the Smartenit? bridge stye devices, decades later. That is where I found it to produce really stupid things and returned it as a manufacturing defect. IIRC the user could never see the reverse transmission as it didn't get out of the X10 bridge devices to the serial ports. hmmmm...been a long time now. I never got past some of the special X10 sequences and it would confuse my software, right out of sync. I would love to do the same for a PLM with Insteon and watch from a third PoV.

I have 5 LDs running for a few years and have never seen that before. Is it the Wet, Dry or Alive heartbeat signal? How are you detecting these "false alarms"? How old is your PLM?

I had some odd X10 signals "perceived" in my ISY994 / PLM. Apparently certain house/unit code signals are very easily interpreted from powerline noise. IIRC X10 signals are supposed to have some security used but apparently the proofing is ignored.

I always use a long timeout for manual overrides anyway but you could eliminate it from the program samples. I find when lights are automatic people tend to never turn them off.

Also, you may want to note: You are disabling the IF section of a program with no IF lines in the section. There is nothing to disable.

Notice how @oberkc's program contains three conditions? Sunset, Sunrise and XXX Switched On. His time frame now acts as a filter, while your time frame also acts as trigger at sunset causing the Then section to run. The difference is having a switched/on condition which only be true when the program is triggered for evaluation by that switched/on device named. Therefore, when the time frame triggers at Sunset as True the logic being ANDed with the device switched/on line causes the whole IF section to evaluate to false. With you program From Sunset to Sunrise the sunset will always run True and turn the 'motion test' on and sunrise will always run Else and turn 'motion test' off.

I don't recommend using a condition to disable a folder. Programs inside stop dead and may leave things off or On, in an undesired state. I find a lot more programming is needed to correct all the unknown states of things. Also programs inside a disabled folder cannot be tested. I do use a few to switch my security zones on and off though but they are all quick action temporary usage programs. Create a state variable called $sHouse.vacation (and one called $sHouse.occupied) I use my ecobee thermostats to control this variable. Ecobee stats have future schedule built into them and are very reliable. I have tried other methods and the stats work the best. YMMV. In the If section of programs that need it add the line IF whatever trigger AND $sHouse.vacation is $cTrue <------ $cTrue is an Integer variable permanently set to 1 as a constant Then ...... Else -- Note: $sHouse.vacation and $sHouse.occupied service two completely different needs in my programs. $sHouse.occupied is $cFalse doesn't fake occupied lighting, TV lights, and still cycles my HRV system for fresh air because I will be home in a few hours.

Most devices support comparison to a device parameter. Maybe this is a feature in ISY Pro??? I have run Pro for years so I am not sure. However, if not....and I know this sounds like it is getting complicated but it gives easy future options to Make your devices easily replaceable...say average two devices humidities? Detect a failed unit and replace with another in ISY software? Make your programs easy to test? This is how I would do it. YMMV Create a state variable called $sHouse.humidity Create a folder called "Sync devices" Create a program under that folder called Sync.humidity Enable run at startup for this program (Summary tab) Program Sync.humidty [enabled] If device.humidity >= 0 <----- trigger on any change Then Wait 2 seconds <------ avoid CPU clashes with other programs = background task set $sHouse.humidity = device.humidity <---- keep ram copy of it set $sHouse.humidityy init to device.humidity <---- power up knowing last humidity reading Else --- Now use that state variable for your de/humidifier control programs. You can test you programs by twiddling the state variable Just ask if you want more or have problems!!

A few things. Each program contains a second Wait 10 seconds. Since there are no following lines the Waits do not function for anything in the programs. The only triggers you have for each program is the humidity reading changes from your sensor. Each time the humidity changes reading the program may run again or reset the currently running program. In this case it will not cause a problem. Here is what I would do using two variables $Humidity.max, $Humidity.min Humidifier Program [Run at Startup Enabled] If humidity <= $Humidity.min <----- Integer variable. You can change while running without the program stopping AND dehumidifier is Off <------ insurance against both running simultaneously Then Repeat while humidity <= $Humidity.min <---- same integer variable=always common set humidifier ON Wait 20 minutes <--------run time set humdifier Off Wait 10 minutes <----------- Off time if desired Repeat 1 times Else set humidifier Off <-------------- may get interrupted while on, insurance Do the same thing for the dehumidifier, changing the cross locking to the humidifier status.