larryllix

Colour of the light is not CRI. AFAIK CRI can only be applied to white light. My cheapie bulbs are stated at >80 CRI but the MiLight bulbs I used previously were way over 90 CRI judging by the quality of light. They far exceeded any white LED or CFL bulb I have ever experienced. Note: RGBCW bulbs do not use the RGB LEDs to produce white. Note the LEDs are lablled for function beside each unit.

I have over 35 WiFi RGBWW/CW bulbs. While they do present some challenges for home LANs, I do not depend on any cloud service for them. I have managed to avoid the Tuya items and the protocol is very complex and too difficult to hack for me. Instead, I use all MagicHome bulbs and RGBWW/CW strips. I have written bridge software to make them act as scenes without delays between bulb activations (popcorn effect). This is all controlled by ISY NRs and I can cause local bulb effects for warnings and alarms. MagicHome RGBCW protocol bulbs have just come back on the market everywhere for less than $10 each for 9 Watt units. 7Watt units are even cheaper.

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.

ISY already supports http(s). It retries already. However. things can get permanently messed up by boxes half prepped and answering requests. Like my ISY994 using an IP address of 0.0.0.0. Why would it retry when it already had an IP address? Many people use expensive power bar, power up sequencers already to ensure proper boot order. Sent from my SM-G781W using Tapatalk

That's what we need for ISY. A delay on bootup timer box. This could allow other things like polyisy or PLM to get fully up to speed first after power failures. Sent from my SM-G781W using Tapatalk

Here is what I use for my bridging software. I run it every few minutes from cron. Should be able to just substitute your bridge run software into the command line. #!/bin/sh -e #If python3 is not running then start NRbridge.py #Install times to retest hourly using crontab -e if ! pgrep -f "NRbridge.py" > /dev/null then python3 /home/pi/NRbridge/NRbridge.py & fi exit 0

That would have been what I would have expected as ISY994 will not ever likely be higher than version 5. Perhaps that is not what is intended but the way I expect it to go. It would eliminate a lot of confusion, while using the same name for the firmware inside the devices.

If you have a problem with anything from SH, you will have to pay the shipping to return it also. Not much of a warranty, if they supply a DoA item.

Turn the scene Off. Are you trying to edit your scene or use it? Why would you edit a scene, changing every device's level?

Note: I have always found you can click on any program. The clicked-on program does not determine starting position for the search.

LOL! Most of us have been caught on those previous ideas we forgot about from years back. Shows the automation engine works well though. Glad you found it!!

Is there anything shared between the polisy and old ISY? like variables or some way to cross data and/or controls? If not, can cross NRs be used to manipulate variables for lighting commands or what not, yet? Sent from my SM-G781W using Tapatalk

IMHO the search engine fell down somewhat when the topic cards came into play. Most don't use them and I forget they are even there. I tried to use them at first but now can't be bothered. I have many posts I can remember doing but when I want to reference them, most I cannot find.

Long click the set button and put MS II into linking mode, as is necessary for all Insteon battery based devices. They save battery life this way, by not monitoring 24x7. Write your changes and then click again twice or just wait for about 5 minutes to return to normal operation.