larryllix

Two programs using a State variable. State variables can cause programs to trigger when they change value. First program to sync your state variable with one of the device values. If weather temperature < 99999 Then $sVariable = weather temperature Else ----- Second program compares the two values If furnace temperature > $sVariable Then do whatever you want here Else ------

I would advise to upgrade sooner than later. It isn't that bad for 99% of the people. Most, if not all, failed conversions, are marked with yellow icons for the programs devices that the auto process couldn't figure out. Inside the programs are explanations, usually with clues about what the original was. Scenes can sometimes drop devices or settings, but I think that has been improved. If all goes to hell in a handbasket you can always load your previous version back in, and restore your backup. On average, the process takes about 10-15 minutes, plus the time to do a new and fresh V5 backup. There are also ways to save your programs into a readable text file. Forgot the syntax, now.

@Michel Kohanim @gviliunasV5.1.0 did not fix the Insteon Scene update battery write problem for Insteon. V5.1.0 scene updates still attempts to write to battery devices. This becomes a big problem as the logic doesn't work. If "Battery Device Writes" is disabled, the system saves up the updates inside ISY, as designed. Now, if the Battery Writes option is ever enabled, by accident, or mistake, all the cached writes are attempted to be written to the battery devices, and can never be cleared from ISY. Rebooting ISY does NOT make ISY forget the cached writes and cannot be cleared with any normal means. hmmmm. I didn't try a power cycle yet but I just finished making the rounds to manually put about 6 MS 1s into linking mode, then disabled the option again. maybe later, if it happens again. if programs are written to update battery devices, ISY attempts to not clog up the Insteon comm channel by spacing out writes with time gaps...good ploy. However, by the time ISY gets to most devices the "Linking Window" time has expired and more battery device updates become cached. This process eventually bogs ISY Insteon comm channels down, with owing updates and retries until ISY processing almost stops. The busy box never goes away in admin console. if the delayed "Battery Write" option is enabled, manually writing updates to battery devices, from the admin console, are also blocked. This results in the user having to enable the "Battery Writes" option to accomplish the clear the cached updates and then all other owed updates get dumped on Insteon battery devices again, bogging the Insteon system again. Please hurry with the bug fix!!! Thanks!!

It seems v5.1.0 has introduced another problem with this item. Adding another MS 1 I found trouble manually updating the device, even in linking mode. Remembering I have the Battery Write option disabled, I re-enabled it so I could manually write the options back to the MS. What a mistake. Now I have about 5 MSes with green 1011s beside them and lots of constant busy boxes in admin console. I haven't experimented to see if UDI fixed this problem with v5.1.0, but I thought I had all my owing battery device writes cleared out before I disabled the delayed "Battery Write" option, a few days ago. If I cannot find a workaround for this bug, I will be going back to v5.0.15 before this seeming botched attempt at making it work better was created. I use Insteon Scene adjustments each evening and morning to adjust the 100W equivalent bulbs in bedrooms to an acceptable level and this may indicate the write to battery devices upon scene updates, may not have been fixed in V5.1.0. More testing needed here. This stuff grinds my ISY to a snail's pace as I have about 12 MSes that really exemplify the problem. **SIGH**

Nice! I am glad I am not 1010 anymore! * 10102

You may be right, but MIchel had advised me it would be fixed shortly. I also wondered that it was intended to just have the "Battery Writes" turned off and leave it in as it seems to work OK and give the user manual control over the process. The open linking window time technique doesn't appear to work at all because the "Battery Write" disable also locks out the program auto-update technique out also. The time gap between updating a scene via ISY and an MS seeing motion can really cripple my ISY every day and sometimes for weeks in a seldom attended room. Manual updates for a battery operated MS seems to be the only logic that is ever going to work anyway. In the past many of the ISY fixes were never listed in the updates posted.

I have moved my MS IIs away from direct light applications now so my drive to find a resolution has left the building, for now. I think UDI fixed the write battery devices with scene link updates in v5.1.0. I know it was on the table as a bug but I haven't tested it in v5.1.0 for the above reason. Yes, I don't like all these cheap work-arounds because I, like IIRC you are, prefer more structured programming approaches that I wouldn't get tossed out of school for.

I am still formulating another method using the MS II devices but haven't worked on it yet. We should be able to have the direct link with a light device to allow a fast on time with motion. Then ISY can detect the NS On signal and interfere with the MS --> Lamp scene link. I haven't tried it yet but this was introduced with one of the V5 beta releases. The delay inside the MS II would have to be very short as they present other problems in that they will not reset for the same time delay without motion either. Yuk. Design flaw IMHO. After the desired time the scene would have to be modified by ISY again. Hopefully, this wouldn't wear the eprom in the lamp device (guessing about 2-3 years?) out but it could be the cost of doing business like this.

With Insteon, I have turned off Battery Writes and disabled my folder Battery Device AutoUpdating. You can do the right click|write updates manually, when you need them. The automatic Use my open time window method was causing my ISY to hang and bog down until the next even caused it to correct itself. OTOH, ISY scene modifiers were attempting to write to battery devices in v5.0.16C. I assume that was fixed in V5.1.0 so this problem may not exist now.

I only use the MS1s as I have no Zwave. The Insteon scene is the only MS ==> Lamp that I have heard of that responds with a fast enough speed for room entry lights. I have three MS2s. I use many WiFi devices also but not for MSes. I have found and purchased many extra MS1s to replace any MSes that burn out. I have used some LioN 9v batteries that have burned out some MSes now with their 11.6v output. Not doing that again. The MS II is useful for non-immediate light requirements, security, and occupancy (home/away) detection, and I have now moved my 3 x MS IIs to those usage styles. I don't use any other fields in the MS IIs, as I find them mostly nonsense and unreliable, so far. Any other protocol of MS will have to go through ISY and will never be as fast as the Insteon/Insteon scene interface.

I have done that many times without problems. Likely save the power supply by soft-starting the power supply. I wouldn't try it with motor loads though. The dimmer circuitry never achieves 100% waveform.

I watched level 1 for about 15 minutes and the only major thing I see if my WC8 board variable stuffing a state variable, time integer MMDDhhmmss every 20 seconds along with one or two other weather variables when they change more than X counts. The odd stat update comes in and ecobee NS updates every 3 minutes. Nothing revealing but I will look for level 3 items next time I am in that area of town.

Installed and running. ISY seemed a little busy for about half an hour with continuous "Busy" box? Didn't find any strange issues, programs or devices that were weird. Backed up and all looks good.

Another Automation Anonymous candidate!

We have gone insane from too much home automation. SkyNet has already started.

He could just run the pump off of the latching relay contact or... ... get an ISY994 box and do it all in ISY programs.

The other thing that comes to mind is to put in a latching relay with each float activating Latch and Reset. Then run one I/OLink off the contact. You can get many voltage rating on P&B? KUPxxxxx relays for decent prices. I was a protection and control tech for 35 years and wired control panels for 5 years before that. I still remember some relay solutions from back then.

That is what I was thinking of, so it looks like you are on the right trail. If the floats had a mechanical hysteresis that overlapped the other float...could work but OTOH the float never never reset to be triggered again. Actually if you could introduce mechanical hysteresis you could do it with only one float. I have seen this done with a long shaft, several locking rings and a floating, sliding ring in between the two limit rings. The second float could be used in a wider allowance for extreme limits/emergency/failure levels detector. I have seen sump pumps with this style of float system where you can adjust either stop on the same float "stick" for the float pontoon to push.

My test Alexa vocal program control to test variable/pseudoMS to vocal output (ISY Portal in&out) works fine. No snags here. Thanks!

The basic part should be easy. create a scene with the upper limit/float as the controller. Set the pump receptacle as a device 'on' create a scene with the lower limit/float as the controller. Set the pump receptacle as a device 'off' There you have all the non-ISY control you will get create an ISY program to monitor the upper float and set a fail-safe timer to turn off the pump create and ISY program to monitor the lower float and the upper float and set a fail-safe timer to query both IO/Lincs. create more ISY programs to overview/monitor things, as required and thought of, to attempt to make the system safer than just the two floats. Monitor IOLinc failure, Insteon comms missed, etc etc... Your cabinet is not metal so you should have no problems with RF standing waves inside the "resonator can" fro dual-band Insteon devices, should any be added or needed later. (new dual-band i/oLinc comes out in 2029)

I would unplug the pumps and leave the i/OLincs powered up for the winter. You wouldn't want a frozen pump to be powered up by some HA error. The minor electronics heat will keep the Rh down inside the case by raising the temperature inside the units, lowering the Rh.

With scenes you cannot have any conditional logic. They are not as dependent on ISY, for sure, but when the power is off the pumps don't work anyway. Scenes can be modified, on the fly to create conditional logic, but that still is dependent on ISY then and scenes can make your logic obscure and hard to troubleshoot, or understand, a few years later when you need to update something. That many operations per day, something will give up the ghost as contacts do not like breaking motor load circuits that much. Your ISY programming is obviously smoothing things out there. If exact levels are important your ISY program timers could be tweaked somewhat, I would think. 1-2 cycles per day could be a good compromise.

@bmercierLooks like I may have found some answers. Whatever kicked my Alexa Routines off, removes the device triggers and also disables each routine. After re-attaching each device again, I didn't notice the "disable/enable switch" was disabled. Well, I did notice it but while in the disable position, it appears to be labelled a disable switch that was Off, so I was reading it backwards. grrrrr.... It was also possible my finger was slipping on each save when clicking the back arrow and disabling each Routine, also Then, I could not duplicate the multiple speaker selection using Announcements. It turns out the Alexa app routine does not support multiple speakers directly, but the IFTT interface included does, via it's messaging option. I created a dummy Routine with an instructive name at the top of the list, because I have been caught on this before, but didn't remember it from a few years ago. I tried to contact Amazon support a few times, but the online chat contact would never answer, and I could never get an answer from the support phone number, either. Despite submitting my email address, I never received a response from that either. I will be watching for the satisfaction survey, I am sure will come later.

Sounds like @Jimbo had to make a choice of F or C to be transported, and then convert it in the NS which powers up more slowly. May need to include a "heartbeat valid" flag into every program making usage.

That seems odd. The KumoApp injections never switch out of C to F.