larryllix

Those are the internal Eisy hardware clock updating the software copy of the time every 30 seconds. With no packet information included in each line, they cannot be from any devices. Insteon devices are not polled regularly and are 99% push technology. No action = no traffic.

What about the people that just purchased an ISY994 three years ago?

After you put the MS into linking mode you should be able to Query it for a few minutes before it times out. This was done to protect battery drain from constant queries.

$cTRUE is an Integer variable assigned a value to indicate what True is in my system. To permanently assign a value to any variable you put the value in the left column of the variable and each time the system boots up the value get copied into the value of the variable. You never change it then it is permanently assigned. It can be any value you would like and usually assigned 1 or some non zero value. All programs that use it will understand, no matter what value you use. It is for convenience and clarity of program understanding mostly. '$' is the prefix all variables get assigned by the ISY system 'c' is the prefix I have assigned to indicate is is a constant, I never change it 'TRUE' is the name I have assigned to the variable indicating it's usage. . . . .The caps also indicate it is a constant value, and a common method used in many programming languages, to indicate it is a constant value. Many programming languages have values like this permanently defined in the language. $sVacation is 1 <--would have been equivalent, in my case, but less clear what it's purpose is, to other readers.

You need to include a quote or a ping (like this) @Michel Kohanim to get his attention back. He is a busy man and doesn't read every post for entertainment purposes.

For now...and likely forever, ( Zwave, Matter, Insteon collapsing, xxx, YY, polyglot, polisy, eISY, and IoX launcher, have always dominated the progress over new features and small operational bugs, for the last 4-5 years) change the line to a comment and enter the same line's text into it. When you restore it you already have the placeholder and don't have to click it up a dozen times to get it into the right place again.

Zigbee is a basic level protocol and almost every brand uses a different high level protocol. You would need specific driver that understands Hue's protocol and likely a different driver for every brand of device.

This is the method I use but the MS II has a problem with the send OFF enabled. If you set the MS timeout shorter than the program Wait time, the MS OFF signal will interfere with the program timeout. If you set the MS timeout longer than the program Wait time, the MS will not reset to send another ON signal in time to reset the program WAIT time. The MS must have the OFF signal disabled and the timeout must be less than half the program Wait time to properly extend the program ON/True timer. If the MS ever times out internally, and it keeps seeing motion, it will never send another ON signal. The MS II needs a second internal timer, not use the same timer for both ON and OFF delays.

Exactly, but only when the time slicing executive can get a break. This is done during any Wait, or Repeat loop, in the ISY code. Those lines are a voluntary "let somebody else have a time slice" construct.

When I was in this process I set up a bank of state variables that were cloned in my polisy. I created a program triggered by any variable that changed and sent them allover to my polisy. With variable control over banks of lights in my home, it was so easy to setup and each program could be ported over to the new device without any interruption of any lighting controls or scenes. I was going to do the reciprocal to send any changes back to my ISY at which point I decided to commit and retire my ISY instead. It was a lot of fun synchronising the two boxes but it was time to walk away.

Then as per @oberkcpost above. The MS II has some design bugs in it. If you have the MS and lights linked directly, then you will want the timeout on the MS quite short (say 30 seconds?) and no Off signals sent from it (On only). This tries to avoid the Off lockout for the same length of time. As long as the MS II keeps seeing motion and never times out while in the OFF state, it will never reset to send another ON signal. Hopefully the new Insteon manufacturer can see the light on this one and fix this before producing them again. Without at least one working sensor, Insteon is not home automation anymore. It is only remote control and timers, like Alexa or GH boxes, but without a voice input or output.

Looks good to me but you can right click on the program name in the tree and select copy to clipboard. Then paste it into your post. Much easier to read with a HD screen. Do you have any of these devices linked to your PLM via Insteon links? If your MS times out it could turn the devices off in error. Is you MS set to fast time cycles? It could be continuously re-triggering your program to start over.

Yes, There has always seemed to be a fear of writing too many programs with the usage of variable/flags. As an old coder it is hard for some to get over the concept of so many programs. At first is seems like you are complicating program things but after using them, it makes programming a larger system much simpler. I remember many negative arguments against variable usage. Even with my Alexa voice control (on/off only) I use this path style: Alexa vocal-->program-->variable-->program(s)-->device(s) All levels of lighting are based on a value in a variable and then a triggered program controls banks of lights, depending on the last value in that variable. Another side benefit is the ease of saving the levels of 15 bulbs into a single variable so that a flashing bulbs warning can be used temporarily, and then restored after, by using only one line of ISY code.

Definitely. I have programs that are 40 to 60 lines long and when I debug I have to delete a line to test and then rebuild it before moving the new line back up 45 clicks to save. Then there are the bad replacement errors that can creep in. One way is to copy the program and disable the original program. Then delete bypass lines to test. Once done, delete the test program and re-enable the original program. Sent from my SM-G781W using Tapatalk

I will strongly second the usage of a variable flag. I run most of my lighting and most of my system on variable flags. While it may seem like you are doubling the code and the program bulk, think about it down the road when you want to add another sensor into your vacation trigger logic. The new program only had to set the variable to True or 1 to control the works. Then there is the other half of the formula...think about adding another function...say turn off your ventilation while you're on vacation...just trigger a program by the same variable. ...simple as that. Away and want to the status of your complex system? just inspect the variable. Once set up it really does centralize your functions and make things simpler in the end. Sent from my SM-G781W using Tapatalk

The second 12:01 AM would be the next day and requires the option to be selected or it won't work with a 0 seconds selection. EDIT: Oops, I missed your date change so the technique I stated does not apply to your example.

...and just to add to that with a common gottcha, if a time frame goes over the end of the day (midnight) don't forget to check "NEXT DAY" OOOOPS! my bad My comments above do not apply to this case of a multiple day time frame length.

programs must be entered into ISY by using the admin console program editor. There is a special tab to edit programs in the Admin Console. Program elements are accessed via pulldown menus so that you cannot make a typo error. When done editing a line, Update must be clicked for each line. When done the program must be Saved on the left menu. All programs can be backed up and then the same file may be Restored back into ISY. No separate text editor can be used.

How long have you operated an ISY994? or any ISY for that matter? You haven't ever asked for help here before with that name.

My MagicHome bulbs and LEDenet RGBW strips all work with ISY994 but you require NRs in ISY and a RPi or other box to make my NRbridge software translate to the devices.

I could never figure out how to create decent scenes inside a NS so I never tried. I continue to use my own software controlled by a few NRs. It works very well so I see no need to use a NS and have never tried the latest one. As I posted before with NRbridge I can control any combination of MH devices as a group from inside any ISY program. A slight popcorn effect can be detected upon WiFi congestion problems and when operating more than about 6 to 8 bulbs in a dynamic group. Multiple groups require 1 second or more between NR commands due to variable substitution problems that have never been resolved in ISY firmware. It would take some techie capabilities but I can give you a copy of it if you want to try it for yourself. Take a few hours to install it. Sent from my SM-G781W using Tapatalk

Yes, I had some discussion with @bpwwer regarding converting my software into a NS but I don't believe it can be done decently in a NS as Insteon scenes are. However I can operate devices sequentially so quickly that they appear to be operating simultaneously, especially with a slight ramping the bulbs can provide. The ISY firmware system doesn't like to operate things without long time gaps between operations as the NRs still have timing problems built in, when using variable substitution.

I have software to group MagicHome devices into groups controllable and creatable on the fly within ISY programs. It is not incorporated into a NS though, and requires NRs to send the commands to the NRbridge software so not easily implemented unless you are fairly technical in that respect. My NRbridge currently resides inside my polISY along with my ISY firmware. It requires the user to set up four NRs with multiple variables and then set up RGBevel, WWlevel, CWlevel, and a list of up to ten bulbs you want set to those variable parameters before initiating one of the NRs to SET levels, ON, OFF, or EFFECTS in that list of bulbs. A pythin program module also requires the IP addresses of all your devices and they need to be locked down inside your router DHCP reservation table. These devices do not actually support scene style operation but can be WiFi controlled so fast the human eye cannot detect the sequential operation well. There is no status feedback and thus no query of statuses inside ISY at this time. I keep track of last sent "scene" values inside ISY and use those to detect current levels and colours. MagicHome bulbs support some nice effects including red, green, blue flashing that can take the load off of ISY programs. I use green to notify of hallway motion outside and red to indicate Midnight as a bedtime reminder. The white strobing is very bright.

Keep in mind when you enable/disable folders, programs inside can get stopped dead in the middle of them and not finish their jobs. This could leave a device or program "in process". The folder enable can make things easy but comes with some dangers. Usually this is not a problem. I tend to avoid using this technique due to it being so obscure and programs cannot be tested while inside a disabled folder. There is no indication of programs refusing to run manually so it can be very annoying. The other method I try to use is to use a single variable say $sVacation that is used inside my vacation programs/routines like this..... If whatever trigger AND $sVacation is $cTRUE (permanently set to 1 and marked with a constant prefix) Then ----

You may have missed his main query (Can we still say that?) . All variables get prefixed with an "$" by the system. It differentiates them from other elements such as programs and scene names.