larryllix

Is there a convenient way to port device bridges (Portal Table) over to polisy from ISY? I see I can have two ISYs and pay two licenses but the thought of rebuilding every portal device bridge causes me some grief. Can the two ISY UUIDs for ISY & polisy be swapped so that the existing bridging table switches over to the newer polisy? This seems like a daunting task here. I am not sure I am ready to take the whole thing in one whack and yet I am not sure there is any "half-way" without full commitment. I have no programs in place yet although many yellowed out ones from the polisy restore I did of an ISY backup image. Anybody else done this? Ideas?

They do hide them in the boxes sometimes and who keeps digging after you strike gold? Glad you didn't toss the box. That means users should be able to transfer firmware and PLM to polisy, get it running, and then trade for a USB PLM if desired.

IIRC my PLMs came with a 9 pin D connector to RJ45 cable. I will have to look in my junk box. Been years now.

IIRC no Zwave dongles have been tested with polisy, as no support for Zwave has been released yet, according to UDI's 's last polisy announcement.

Some manufacturers can upgrade their firmware and there is nothing you can do about it. That would be unfortunate. People should have a choice of staying where they are or upgrading to new features. A really unfortunate example of this is Android phones and iPads. When they want you to but new hardware they just force obsolescence on our device and the things you paid for quit working so you have to buy new hardware.

No. If a manufacturer changes something that removes capabilities then it is the fault of the device mfg. If the NS dev releases a new NS version to support the changes then it would be a fresh NS sale, at the dev's discression. I think that would be fair. If the dev has no interest or disappears then the users are SOL at the hands If the device mfg. Again, the NS dev could offer sympathy prices for previous owners. Sent from my SM-G781W using Tapatalk

I prefer the pay once and done format. Small bugs fixes should be included in that once 'n done payment. v1.05 --> v1.09 However, when a new feature(s) is/are added, and a major revision digit would be increased, a new sale should be completed. v1.05 --> v2.01 Some discount for previous version owners could be incorporated but may get too complicated as devs would need to keeptrack of purchase history etc. I don't like and avoid subscriptions with a passion and want the money done and know what I got for that money. If I don't pay my subscription, I don't want my system to stop working. IMHO, my purchased software product should continue to function at it's purchased capabilities. Cloud services may be considered differently to compensate for server maintenance costs.

Get a polisy with zwave or add a zwave board to your ISY and start building a new side system as needed. ...or start getting some WiFi items and use NSes or NRs to control and input things. I doubt we will see the Insteon basic building blocks disappear for five more years once the accountant wakes up. Sent from my SM-G781W using Tapatalk

As for @MrBillabove re: kitchen lighting. Totally agree again. People want to vary their lighting colours with all this analogue style lighting levels and concepts, which is mostly a waste of time after getting some experience with it. eg: At the beginning of the coloured RGB lighting I was, like many others, really concerned about mixing white and RGB colours in the same bulbs. After having this capability I have found when you want colours, you want them rich and deep, no pastels that are hard to even detect. When you want white for a work surface you want a daylight white (5000K to 6500K). When you want lighting for evening relaxing and TV watching you want a warmer white (2500K to 3000K). Those needs never really vary very much. Same for white levels, you only really need 100%, maybe 40%, about 10-20%, and maybe 1-5% depending on the bulbs. Insteon scenes can do that quite well. Make the presets (in your scenes) and then pick a scene to turn on. However, I have a Gathering room where my kitchen, dining room, TV area, and hobby area are all in one big room. I don't vary colours on my kitchen counters and bar, but I do dim them down a lot, to fade them into the background (5000K) late at nights while TV watching. With the newer RGBCW bulbs they have two sets of white LEDs inside so you can mix and match white temperatures and I am just learning to use that colour fade for late evenings. It has got people to bed earlier than we formerly did, so it is working. ISY is my friend and it will be yours also!! Very capable little box.

First I don't use many Insteon Scenes. Insteon Scenes are presets to speed up group changes to devices and give no feedback to ISY. The resultant levels are assumed by ISY. I do use some Insteon Scenes but much of my lighting is now WiFi RGBWW/CW bulbs and strips. Yes, it takes a bank of programs and I keep them in ISY folders. I don't vary levels much as I have found only the levels of 100%, 40%, 20%, 10%, and 2% are useful level differences. Of course Insteon SwitchLinc dimmers cannot do under about 12% with LED devices. WiFi bulbs and strips can do 1% quite nicely. In a folder of program handlers I would typically have GathRm.fullOn, GathRm.dim, GathRm.TV, GathRm.reading, GathRm.xmas, GathRm.Easter, GathRm.Halloween, GathRm.Canada, GathRm.IndependanceDay, GathRm.blue, GathRm.red, GathRm.sunset, GathRm.automatic, etc, etc, depending on the room I have the lighting in. Each program in each folder looks likes this: If $sGathRm.mode is $cMODE.DIM <--- $c denotes an Integer var permanently set to a value as a constant for clarity in programming Then set chairPots 40% set sidePots 60% set TVwallPots 20% Else --- Also you always need a program for off If $sGathRm.mode is $cMODE.OFF Then set chairPots Off .... etc Else ----- Once that is done now a trigger program would look like this If SwitchLinc is switch On Then $sGathRm.mode = $cMODE.FULLON Wait 4 hours $GathRm.mode = $cMODE.OFF Else ----- Now you can save the current settings in a save variable while you "borrow" a light to flash or temporary setting and restore the whole set up by just returning that value to the control variable. I am transmitting these variable over to my polisy and letting it handle all my WiFi stuff now, while the Insteon things are being handled by my ISY because it has the PLM until later developments in polisy.

I would attempt to measure resistance from both leads to the ground lead. ThenI would dry it out in the sunshine or use a slow heat source (furnace vent?) and then attempt to measure the resistance again. If you are not an electrical guy with a good ohmmeter, then hook it up and test again...maybe install a plug and plug it into a GFCI circuit receptacle. Make sure it is well dried inside...maybe a day or two. Make sure it is grounded well and avoid touching the frame until proven good. If that doesn't work, I would attempt to dip the whole thing in a good (over 80% pure) isopropyl alcohol or other dry cleaner and then dry it out. Test again. If you can disassemble it to do this, even better. The rinse may get rid of any dust that is giving the moisture a conductive medium to cling to.

Maybe I launched a complicated sounding technique on you too soon but basically... For lights If StateVar = 1 (True) <------ Then turns on an Insteon Scene, some WiFi lights, some Zwave lights etc. Else turns off same as Then For transfer of control to polisy, I clone critical variables (used in techniques above) if they change. polisy has all duplicate programs for now, based on variable values ISY event--> changes a state variable-->ISY program detects value change and NR transmits value to clone ISY variable in polisy-->polisy program detects value change and polisy controls lights instead of ISY.

I totally agree with the concept put forth by @MrBillabove. I believe ISY has the most power of any device and allow ISY controll all groupings. My ISY is not allowed to control any device directly. By allowing ISY total control over everything it is easy to insert some local lockout, or conditional logic, based on other factors that Alexa will never know about. ISY knows how to combine logic. As a side note: I mostly control programs in my ISY labelled XXX Lamp.select. Now I can use ...Alexa...turn on/off XXX Lamp.select My ISY can now decide if it wants to allow it, delay it, operate multiple devices, operate WiFi devices etc.. etc.. The syntax is the same for all devices...so far. Even A/V volumes with ...Alexa...turn on louder ...Alexa turn on softer My bank of select programs, mostly operates a state variable and another bank of programs does all the dirty work depending on the value injected into that state variable. This makes independence for later modifications very easy. Multiple programs can operate that grouping of 10-30 lights with one variable save. Now that I am partially moved over to polisy and running two logic systems it has been a blessing as it is easy to transmit a single variable to the slave polisy and have it do all the dirty work for dozens of WiFi bulbs. ISY has all the Insteon stuff and inputs yet while the polisy has all the Ethernet stuff, as a half way point.

I would not share devices between two PLMs. Only because it is easy to get confused and make a mess that gets difficult to straighten out. Currently I am running an ISY and a polisy and although I have dumped all my code over I have disabled all my program folders and only enabled certain non-Insteon functions ie: Ethernet based inputs and system things like time clocks from ISY's internal system functions. I have recently written some NRs and syncing programs that write value updates into my polisy variables eg: $sHouse.vacation,and $sHouse.occupied. I will slowly be adding more as I can depend on the polisy firmware for al my functions. Then most of the code is written into the old ISY and can be detached easily. Each step of the way must be thought out very carefully as you can make a mess that can be hard to straighten out. Best of luck. Try to keep it to devices separate from essential functions. Otherwise you will have multiple links to each PLM that need to be cleaned up later and every Restore you do will erase the other PLM's links which will be quite hard to fix.

Likely the links in the wetvac OnOff module have been corrupted. Try a restore of the device a retest. If no success, try a factory reset of the device and the Restore, retest. Have you reset the LD? They are only good for one shot before human reset. Also have you checked the circuits inside? The they may have been exposed to water. Is your heartbeat detection program working properly?

Is the device on the same powerline phase (120V leg) as the PLM is? Do you have any bridging between your powerline phases? Have you factory reset the device before attempting to link it with your PLM? What ISY firmware version are you running and what UI are you running?

I went through this morning and corrected all my endians from my cross load (ISY backup= polisy Restore) If the number is positive subtract 256 x 256 x 256 If the number is negative subtract 256 x 256 x 256 then add 256 to get the proper result. This got my hundreds of $constant (Integer) variable values back and working. I wrote a small ISY program to do that but I had to to change the variable names for each manual run of the conversion program. @Michel KohanimPlease give us "indexed variables"!! . One polisy program run could have fixed all Endian transfer problems in one foul swoop, right inside my polisy. Got my CAO Tags KumoApps double reporting to both ISY and polisy, along with many self triggered slave ISY programs calculating more convenient values like dewpoints from them.

This sounds like your PLM may be shot. You may want to get a new one on order, and if the existing one comes back, you will have a spare. If not you will be up and running with a bad one you can consider repairing. In the meantime, you could factory reset your PLM, and then do a PLM Restore in the admin console.

https://www.amazon.ca/gp/product/B07XNXZCGY/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 https://www.amazon.com/Tamicy-Pieces-Ferrite-Suppressor-Diameter/dp/B08BPHCXR3/ref=sr_1_3?dchild=1&keywords=Clip-on+Ferrite+Ring+Core&qid=1635098472&qsid=138-2737271-5070552&sr=8-3&sres=B07ZQZQ5BQ%2CB07CWCSNW9%2CB08BPHCXR3%2CB088LNB2DT%2CB08T67QRJC%2CB08H88PZLS%2CB095H36PXK%2CB08BPGGN3T%2CB085FRZ9JY%2CB07V7DGZ5V%2CB01E6PLXZ0%2CB072559VZ4%2CB07YJYQT6N%2CB08B4QNV8C%2CB07YKD5XHW%2CB07Y7ZB5DY

Thanks for that. What I was really hoping for was information on direct comms between Zwave devices...mostly MSes and Switches/Dimmers. If there is such a thing. I have only a dozen Zwave devices I have fallen into that I have never hooked up to a spare ISY with a series 300 board in it. 700 dongle is waiting to get plugged into my polisy once I can move over without having to go back. Insteon devices are very clumsy to move around with their absolute enrollment via physical buttons. For now I will continue to use the Insteon items I own for lighting (with MSes) mostly, and slowly start to move over to WiFi and Zwave for other items. Insteon has been acting creepy and...well you know, so I don't want to ride the wave into the predictable abyss coming. I have about 40 WiFi devices already and other than needing a router with lots of NAT space (always hidden from public knowledge), and needing some custom bridge software to "group" lights into "scenes", WiFi works more reliably, and faster, than other protocols. Now that the 802.11ax is becoming popular I would hope some of these WiFi devices would adopt it for better arbitration of devices in APs.

I would also be interested in the how and what for Zwave scenes. I understand Zwave devices have some type off scene connection between devices or common grouping method. As @grossmdwas asking. How have people's experience, especially with the last method mentioned by @asbril, worked out? Is it fast enough etc..?

KPL general backlighting can be set via ISY program lines. Individual KPL button backlighting can only be set On and Off via Insteon Scenes created to set each button's backlighting. Bit of a shortsightedness by Insteon but... Create a scene for each button and then have your programs call the scenes as required.

Thanks. I realised the conflict after I did it. Just pulled in a backup from my ISY into my polisy after starting over and realising this would take me a month. Makes a mess of the variable values but they are all installed by name, NR installed, programs installed = no PLM so lot of patching to do when that happens. Will still take a week or so of patching but not the month I was looking at before. If the full and proper backup and restore happens, all my ISY elements should line up and fall into place later. Went through and installed conditions in almost every folder so I can enable them one at a time later. If $cTrue is not $cTrue System clocks and calendar seem to be working into variables. Now waiting for my USB Zwave to be drivered up by UDI. I bought the SiLab dongle. I guess I could install one of my spare serial PLMs or better yet, my USB PLM. I almost forgot about that one. Things are clicking away now. BTW: Makes you wonder about all these shipping delay excuses. DigiKey.com shipped my SiLab Zwave dongle late Tues from MN/ND. Night about 10:30 PM. It went to Memphis, then to Mississauga (by Toronto) and was delivered to me Thursday about 12:30 noonish (about 20 hours) for $8, cheapest shipping. Unheard of before in my 70 years. Usually those things take about 7 to 15 days. Go pandemic!

Did the trick! Thank you very much!!!! Now to tinker How long before we have USB Zwave sticks in beta to play with? ( iknow...push..push)

Just started setting up my polisy/ISY. Tried to change the port address to 80 to avoid the https flagging constantly and now ISY Launcher cann't find it. When the address is ADDED to the launcher it cannot find it. I figured I created a conflict with my polyglot so I stopped my polyglot service but to no avail. How do I modify some setup file to set my polISY back to the 8080 port or 8443 port?