HABit

Attempting to create a Schedule/Program with schedule, an error pop up presents when attempting to save the time.

What a shame! I was just looking at the (soon to be) KS220m dimmer/occupancy for my (eventual) new house. OK, scratch that contender. I think as my Insteon dimmer switches die/get flaky, etc. I’ll rip out the guts except for the paddle switch and replace with Shellies.

If you wanted a quick switch/dimmer: get a US-style paddle switch, from a vendor (quality micro switches), put a Shelly dimmer or switch in it (they are very small devices) and there you have it - Insteon replacement which natively supports WiFi with REST and MQTT. Perhaps a PGx controller soon (as soon as I get access to an ISY and my Polisy again). That’s good for DIY or for yourselves, but in production need UL (Shelly already has UL approval so just a sub-section approval due to re-packaging). I keep trying to convince Allterico to package their dimmer this way, but they only see a small demand in Europe as it is (dimming) just catching on there (their main market). Besides dealing with the Bulgarians is a 10x latency factor - certainly monotonic folks.

@pyrorobert Sometimes the the ram card in the ISY can go bad and cause weird behavior. You can easily replace it (slot in ISY) and get a larger ram at the same time. Sorry, not near any manual now to tell you largest size you can use, but look in the ISY manual for details about replacing and size constraints. Good luck.

Hi @DAlter01, I apologize for the late reply. I have a crazy schedule and just saw your post. I think I see what you are doing. The bottom line is: Did it work for you? If the solution works, then that’s almost the whole battle. There are some things you can do to enhance operation, but then again if what you have works, why bother? You could use a timer program and load a state variable with a value you get from memory (another var) so you can adjust the On-time by things like time-of-day, or whatever. Users can then also easily adjust the On-time by the great UD Mobile program (change the value in the var). The great thing about the ISY is you can do things in different ways. I had an occasion to look at a system I coded about 5 or so years ago and I know that I’d write the programs differently today. So as you use the ISY, you find easier/more efficient ways to do the same task. It’s all good - you get better over time. As for your documentation, I use the old-fashioned flow chart or pseudo language IF-THEN-ELSE format, then convert to ISY’s single if statement format, knowing that when implemented the program will be multiple programs in ISY language. I read it OK the way you described your programs, but gave you the benefit of doubt that it worked. That you have ANY documentation for your system, is a plus. I always try to write an operator manual so I know how I want the system to work. Then you can work toward making the entire system work that way. Plus, (as personally experienced), it’s great to have a manual if you plan to sell the automation system with the house. You WILL get your money out, plus. Good job. I wish you a very good experience with the ISY and on this forum. I’m sure others here will read what you wrote and have done, and gain inspiration from it.

If you want sophisticated pool automation, then use Hayward products and the OmniLogic as the controller. I have Hayward but had no way to integrate it with the ISY. I now have a contract to integrate the OmniLogic into an ISY. The project is long-term (8 months out or so), and not sure I will make a Polyglot or just use a version of that which talks to my interface. If I make a PG NS then I hope to offer it on the store. I’m so busy that I don’t know much about PG3, so have to learn that interface first. For the house I’m building I had to evaluate a Jandy, Pentair and Hayward-Omnilogic controllers for usefulness as a controller and how integratible it was. The Omni was the clear winner (except you have to fight to get the API). When I started I thought the Pentair was a better product line. I agree with posters above that the Autellis is a great way to go, but cannot find any of them these days so had to make other choices.

Hi @Dalter01, Sorry for my tardiness, the meeting ran long. I just looked at all of the systems I have. I no-longer utilize any timer in those systems for the MSII - I cannot post any code. I am in the progress of building a new house, so the ISY which may have contained the Timer In the ISY, turning-off the DON response from the MSII, is not available, and none of the systems I have access to utilize that type of technique to circumvent the time-out/retrigger phenomena of the MSII. Recently, I have either used the MSII as-is, or attempted to use a different solution for load-timing which does not include Insteon devices.

Hi @Dalter01, first you understand what LarryLiix is saying (summarizing: The MSII was designed to be a stand-alone unit, so the base operation is to allow it to be linked as a Controller, set it’s internal timing for a period of time, allow it to do its internal retriggering and let it control the load via Insteon without ISY interference). I use an MSII in that mode for two instances, just changing the On-Level via a Scene in the ISY when it needs to be dimmed or brightened (On-Level). If you are going to use an ISY timer then be aware that the MSII does not send a retriggering DON command when itself is retriggered and sends ONLY the final DOFF command at the end. The one success I had (instead of just using the MSII out of the box with no intervention), was to set the MSII time-out to a long period, or to set the link to something other than the bathroom load, using that DON to initially trigger the Timer (with the attendant ISY delay to turn-on of the load). Assuming that for rapidity, you use the load as the initial trigger to run the Timer program, I set a single integer variable as the Time-out value, setting a Timer state var in a Program to the amount of time I want to initially trigger the load. The MSII is set to a short time-out value so it will send additional retriggering signals, but only after it sends a DOFF, then a DON (which is not a retrigger, but a detect again). In the Program I immediately set the Scene controlling the Load to IGNORE the MSII, using the ISY Timer to turn-off the load. When the sufficiently long ISY timer expires, the Program first Dim’s the load, to warn any occupant that the load will be turned-off, and then turns it off. I use any additional DON’s as the retrigger for the ISY internal timer. I use every DON from the MSII to trigger (or retrigger) the internal ISY Timer, but ignore any DOFF’s. The internal ISY Timer is the component that turns-off, via a Program, the load, not the MSII. I’m not near my ISY at the moment to give a snippet of code, and have a meeting scheduled right now, so cannot go to the ISY for several hours, but will post the code for this after the initial comments. Again, it is easier for me to use the timer within the MSII to turn the load both On and Off, forgetting about the ISY, other than to vary the amount of brightness of the load depending upon the time of day.

To understand what is happening: Since the micro-C in the KPL's is under-powered, LED lighting connected to their loads will tend to flicker. Dimmer light settings, amplify the effect/make it more noticeable. Better (more expensive?) LED bulbs can help, but in my experience will not eliminate this problem entirely. The problem originates in the fact that the KPL's need to scan the keypad buttons, which adds enough overhead that when Insteon signals are received by the devices, the dimming circuit (program) is interrupted until the address/command decoding is completed. LED's react to voltage variations quickly (incandescents don't), causing the varying intensity of the bulbs (flicker). As Bumbershoot points out, this topic has been previously discussed on the Forum.

I saw the video UD sent out, and was impressed by the crispness of the operations demonstrated in the video, (no doubt attributable to utilizing native coding). Unfortunately, not a Droid owner, but looking forward to IOS. Would be happy to help test. Congrats on this development. Having written console apps for the ISY I understand what a PITA grappling with NS underlying functionality can be. Really good move by UD recruiting you to develop.

@Derek Atkins Franky, the easiest way to separate out sending a DON and controlling the flood light load, would be to just use two 2443’s (On/Off Module): One to send the DON connected to the PIR load our (via yellow wire), and another 2443 to control the load. If you want to hack through this and attempt to use only a single 2443, then you can connect both load and 3-way switch wire (as you have now), but put the 2443 into Momentary Up/Down mode. This is supposed to be used when you have a double-throw momentary switch, where up: AC-L to yellow turns on the load (MO SW Up); Down: AC-L to purple turns the load off (MO SW Down). This effectively makes your PIR send a DON, AND will turn the load On only, never Off. Now by doing that you now need to use a program/timer in the ISY to turn the light off after a timed interval, by sensing the 2443 DON event and timing off after your selected time period. First, start by creating a Scene where a switch - say a Keypad Linc button, is one of the controllers, and the 2443 is the second controller (there will be no responders in the Scene because the 2443 is both a controller and responder). With this you now have the ability to see if the load is on because the KPL button will indicate when the light load is activated. Next you need to construct a Program - a couple actually, lets see: You need a timed-off operation that works like this: When the 2443 sends a DON, the Program’s If statement will say: Program (1) IF <outside flood> Switched On In the Then part you are going to set a State variable to whatever period of time you want to have the flood light stay on and then automatically turn off. Timer Program (2): This Program will trigger if the state variable is > 0, or Not 0 (however you want to do it), then count the state variable to zero after waiting one minute. IF <outside flood timer ST> NOT 0 THEN Wait 1 Minute <outside flood timer ST> -= 1 You can turn the flood load off in the ELSE part of the Program, or (my preference), use another Program (3) to detect the state variable is zero and turn off the flood load. Now we are back to where we started because when the PIR turns on and Program (1) triggers it causes Program (2) timer to turn the load off again. So next add some gating to BOTH the On Program (1) and Program (3) that detects the DON and turns off the load. Program (1) Modification: IF <outside flood> Switched On AND Status <KPL Btn Floods> IS Off This prevents the timer (Program 2) from starting if the outside flood is manually turned on Program (3) Modification: IF <outside flood timer ST> IS 0 AND Status <KPL Btn Floods> IS Off THEN [turn off outside flood light load].... You can play with the Programs to achieve exactly the results you want if you need additional controls on the lights. You may also consider using another variable to keep track of the KPL <outside Flood> button status, using it in the Program. Things you can add are: Load the On-Time for the light timer Program (2) from another variable so you can change the amount of automatic on-time depending upon the time or circumstance (home/away, etc.). I found the best way to understand the Insteon and especially ISY environment is to play/experiment to see exactly what happens.

@Derek Atkins If you are using a micro-module relay/switch as the load controller, it also has two small gauge wires that can be employed in a 3-way switch scheme. I used one of these micro-modules in that config years ago, with a cheap flood light + PIR fixture. I wired the PIR to one of the module's wires (IIRC yellow wire), but removed it from the light load (important). So the idea is that when something triggers the PIR in the floods, it acts like a switch (load to yellow wire), that causes the micro-module load to activate, while you get a bonus of an ON (DON) insteon command to the ISY to use as a Program trigger. Be sure to take a look at the manual because (again IIRC) I believe there are several modes that may exist in the module. (Sorry no where near the manual so am being vague here). Not knowing anything about your PIR/Flood device, be sure to verify that the PIR is acting like a switch to the lamp (generally an inexpensive PIR/luminosity component is employed in these light fixtures which acts like a simple load switch - but please verify this).

FWIW: I have had network latency problems with Orbi's. I have a backhaul system setup with the Orbi's and got them to overcome Wifi weak areas in the house. The latency wrecks havoc on the Web Socket subscription - you get disconnects for Admin Console and Polyglot/Node Servers. Be sure the Orbi firmware is updated, especially for the satellites.

The electrolytics are notoriously bad in these devices, however from your log my thinking/guess is a signal decoding issue (this includes RF and power line signals). The decoder decoupling circuitry is as bad as the power supply caps. My devices typically start to fail in the decoder section (missed turn-On/Off commands, flaky operation, other devices fail due to no repeating, etc.). If power supply (such as it is) is failing, it could be injecting noise into the decoder which, since it is Gaussian/random noise, will undoubtedly cause false "decodes" of commands. Equally likely is that the decoupling cap in the discriminator circuit has started to leak causing false signals to be detected (same mechanism of noise). After 5 - 10 years, I think you can expect failures in Insteon (and no doubt many other HA) devices.

All traditional dimmer circuits use a phase triggered TRIAC (or other similar AC switch). In the old rotary dial type dimmers, the dial is a potentiometer that controls the rate of charge in an RC circuit that builds up according to the resistance set by the pot. When the voltage on the trigger of the TRIAC is sufficient it fires and the AC voltage is supplied to the load for the duration of the AC phase. At AC zero-crossing, the TRIAC turns off again, and the process starts over. Even though the AC waveform is sinusoidal, it is still a pulse, albeit with rounded corners. The Insteon uses a tiny micro computer to simulate the RC (integrator) circuit by firing the TRIAC a count of increments (0-255) from the AC zero crossing. With incandescent bulbs, the mechanism for generating light is thermionic - the filament heats up until the outer valence electrons breach their orbit and voila photons are emitted (let their be light). The great thing about these types of bulbs is that cheap dimmers worked really well due to the time lag to heat or cool the filament (think no flickering if the voltage varies on the line or due to an over-taxed micro, which does not turn on exactly when it should). LEDs emit light/photons, when the voltage is sufficient to initiate excitation, but unfortunately for dimmers, turn off just as rapidly. To create dimmable LED bulbs, the manufacturers must simulate the resistive load of an incandescent bulb using a resistor and a capacitor. This generates a proportional voltage that is used to drive a voltage controlled oscillator (the thing that makes the PWM). Cost being everything, initial dimmable LED bulbs worked OK for "static" dimmers, but for the Insteon dimmer, subject to doing other things besides turning on the TRIAC at the correct pulse count, you see flickering when, for example, an Insteon command is being received and it tries to decode the address, etc. I do not use LED bulbs in prominent locations (such as the hanging lights over my Kitchen bar), since the flickering is greatly evident. Other places such as the living room, the flickering is there, but other lights help distract you from sensing this effect, plus could be staring at the TV, etc. With the Phillips Warm Glow, the product engineers actually looked at this problem (no doubt since they are into HA, it is a topic of which they are aware), and have done a great job minimizing it. We just need to invent slow LEDs to eliminate this problem.

If the LED bulbs are dimmable, they will have a "driver" circuit to convert a dimmer output PWM (e.g. Insteon dimmer switch, etc.), to a proportional voltage and then to the bulb's own PWM. LED's are quantum devices and either emit photons/light, or are off. Pulse Width Modulation has been used since the advent of "dimmable" LED bulbs to trick the eye into thinking that the light emission is dimmer. Since LED's switch On/Off in nanoseconds, when an Insteon Dimmer Switch is busy decoding power line or RF commands, even if the command is not addressed to a particular device, the internal microcomputer chip does not service the PWM function as diligently, and thus you see flicker in concert with power line or RF Insteon commands. The Phillips Warm Glow bulbs incorporate an integrator (think capacitor type delay, but digitally implemented), which effectively diminishes LED bulb flickering. While I have gone out of my way to avoid the $$$ Hue bulbs, Phillips has actually done a great job designing their products.

Not static addresses but "reserved" in DHCP. Try looking under Advanced Settings in your router (or some similar sounding name for DHCP lease reservations (again whatever your router admin console calls it). That function basically associates a MAC address to an IP in the DHCP map so on boot/lease renewal, the same IP address is issued to the device. Spinning/busy icon - Have you tried rebooting the router?

@baabm What you are seeing is the DHCP lease renewal. With a quick look, it seems that your router is releasing all of the DHCP leases every 30 minutes. Go to your router admin console, login and find the DHCP lease renewal setting (Usually in advanced settings). Adjust it so that the leases expire at a longer time interval. Many ISP provided Modem/routers don’t handle many devices even though the address space seems to be there. Every time the router DHCP leases expire, all of your devices (especially WiFi, immediately try to obtain another DHCP lease. This can cause some delays, and with some routers, devices don’t get a lease renewal for a noticeable period of time. Another thing to do is go into DHCP settings and set lease reservations for all of your devices. This helps to speed up lease renewal and you will always know the IP address of your devices.

When I download zipped files on my Mac using Safari, the zipped file is placed into the Downloads folder and is not unzipped. If however, you click on the zip file (which will look like a folder), then it is automatically unzipped and the contents are available in Finder, under the zip file name. Caveat: I am running the latest version of OSX, and I believe the auto unzipping occurred in an older version of the O/S or Safari, according to Preferences settings.

LOL I think I hear the Stones "Dealer" playing in the background. I think I actually experienced a sensation of euphoria after getting an RPi and installing the first NS. No more typing endless NR's and manipulating variables to try to get some control over something or other (plus I'd typically do it too quickly and end up troubleshooting the NR, etc.). And then being able to put nodes into Scenes... Yeah, yeah, here comes that feeling again!

You may want to check out Olibra’s Bond Bridge (hub) https://www.bondhome.io/products/bond-bridge/ The hub can “learn” from RF controllers, if a device is not already in their database. I have had some RF controlled devices that weren’t listed as being controlled by the Bond hub and was successfully able to get them to work. Olibra is a great company and is more than willing to help you get a device working. Might be worth a shot asking about your Venux devices on the Forum. If it seems like it will work, you will then use the excellent Node Server on an RPi/Polisy to control with the ISY.

A way to make this happen is to allow plug-ins in the new Polisy/ISY, much the same as Node servers have vastly improved the number and kind of available devices the ISY can coordinate/control. Even if UDI became the new Apple of automation control, it may still be difficult for them to match the ingenuity and rapidity of a driven 3rd-party developer, who just wants some functionality in the Admin Console. (No slight to the excellent developers at UDI. Having run a hardware/software company I found that for every product, or version of product, development soon becomes the minority portion of the task, with support, documentation, sales, overhead, admin, consuming the rest). In addition, plug-ins would allow for various presentations or functionality, even if there was duplication of purpose, but variations on implementation.

Larry, you make a good point about the retriggerable nature of the MSII. As long as the MSII keeps detecting motion within its timeout period, it will reset its counter/timer for re-arming. This effectively suppresses initiating any additional On messages being issued. Typically I try to set the re-arm (time out) time as short as possible And only have the MSII sent On commands, using an ISY program/timer to provide a light (or device) turn-off. If additional On commands are received from the MSII, the ISY timer value is reset, so the on-time is extended. However, as you point out, the problem with that is if the MSII is internally retriggered by motion, the subsequent On commands never come to reset the ISY timer. Fortunately, after having studied the problem, typically the opposite action occurs, which is people are doing some stationary thing and no detection occurs by the MSII. This is as bad since then the lights/etc. will turn off. Then it becomes a game of adjusting the timeout value of the MSII to optimize the detection in a particular zone. I can’t comment on corporate cultures or motives, but I can offer an experienced guess (having run development programs in my dim, dark past), regarding why the MSII has this unfortunate characteristic. I believe it was a failure on the part of the Project Manager/Team/ Leader/whomever to recognize who the core customers of Insteon are. They determined (or were told to do this), that what customers desired was a Popeil-like motion switch that would turn a light on, keep it on for as long as motion was detected, and then shut off. Great, but unfortunately serious integrators are then challenged with utilizing the MSII in a more sophisticated HA implementation. If they had given control over whether the MSII automatically retriggered, or just timed out and sent additional On commands, then this problem would be reduced. Unfortunately I have participated in development projects where Marketing is breathing down the Engineering team’s necks, told to do things that we did not want to do, and then later taken heat for it working that way, after product release. If you are using the MSII in the context of how it was designed then it is a great device for stand alone operation. I have one in the laundry room. The ISY knows it’s Responder is on/off, but the MSII’s main function is just to turn on the lights (Using a Scene), and keep them on as long as someone is present (longer timeout and retriggerable time periods = excellent performance). However, note the absence of any ISY interaction.

I have an Insteon Hub I got a while back when the MSII’s were first released, just so I could use it to setup the MSII’s. After I initially updated the ISY to v5.x and tried to re-link the MSII’s as the 2844, many failed and then stopped working. I used the Hub to attempt resetting the MSII’s to operable states (unfortunately did not work). Ultimately I determined (with hints from the many sojourner’s here on the Forum), I needed to do factory resets on the MSII’s, sometimes several times, to be able to link to the ISY. I think there is much unknown about the MSII, what the Hub does when it “installs” one into the Hub, etc. I have also come to suspect that some of these things are hacks to “fix” the design flaws in the MSII’s. My experience is that the MSII’s work pretty well for motion detection. I have seen problems with sensitivity issues (ie MSII turning on after delay even though targets in close/direct proximity to the MSII). The MSII’s that have this issue don’t seem to be redeemable even with multiple factory resets and repeated re-links to ISY (the ISY has nothing to do with the issue other than it is enrolling the device). I have become convinced that Insteon used a PIR processing chip (tiny micro) with multiple sensors, and have actually found a couple of candidates that might have been used in the design. These chips perform certain processing tasks such as digital integration for ambient light, PIR temperature compensation, etc. but have to be understood before hacking out a solution using same. The result is I believe, what we have now. Unfortunately, if implemented properly, the MSII could have been a really great addition to the Insteon device line. So perhaps Insteon will give us the “Glorious Shining Moment” we are all hoping for, and re-establish itself as a viable HA device vendor. Time will tell (but not too much time...).

On my sample program above, if you notice values that are are inconsistent, you may want to inset a wait n seconds (1 or more), after the Query MSII command, to allow the MSII to respond and the ISY to update its Node values for the MSII, before saving to vars. @kclenden Thanks for your input. I really have wanted to get an ambient light detection node in some of the areas where I have the MSII’s installed, but have found that the actual values “wander” around inconsistently, so Luminance has been so far, unusable for me. Typically, I use ambient light levels to determine when it’s appropriate to augment lighting in an area. So when the Luminance value falls below some threshold, the HA system either initiates, or allows (from motion, etc), area lighting. After reading Michel’s trials with the MSII, and declaration that its operation was haphazard (not motion, only peripheral sensors), I determined that I would have to qualify all readings from the MSII to see if useable. I think next I’ll try some sort of smoothing of data values, rejecting outlier data within some period. Would you mind telling what version your sensors are? I have found varying quality of the MSII’s with some requiring repeated factory resets before they become functional. Perhaps that’s what is being observed with these little troublemakers. @larryllix Thanks for that link. Oddly, I’ve never had that failure with the MSII’s yet. I have seen it with one of my older MS1’s. Looking at the error log I see an entry with 0’s running off the edge of the log (assuming here the device has gone into “insane” mode and is repeatedly transmitting garbage). Unfortunately, it has reliable Dark detection, so have been reluctant to replace it.