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.