larryllix

Oh Gawd! Caught with my pants down there!!! Thank you!!!. Now to glue some hair back on!!

Pick your version depending on whether your system has a PLM or not

OK. New problem. @Michel Kohanim Trying to connect to my first Insteon module (tried a few now). I have tried a USB PLM (new), a serial port PLM (used), power cycled both PLM and polisy many times (in PC order) and when I attempt to link my first Insteon plug-in module, ll I ever get is this error and then my polisy/ISY goes into a continuous busy box "initialising system" . When it finishes 100%, it starts again and never stops. I have noticed that it has stored variables for system time and dates, and also updated variables via REST input from my ISY running NRs. I haven't seen any "with PLM" "without PLM" firmware versions for v5.1.1 polisy. UPDATE: About | PLM info/status shows "/not connected" regardless of PLM style. Any ideas or clues?

Thanks MrBill, but I can do all that, and have (see OP) , but it doesn't port the spoken device table over to the new UUID connection. I see a download to .csv feature, but I see no way to pull hundreds of devices back (in the table or .csv file) into the new UUID, avoiding the rebuilding of the whole table one spoken definition at a time.

Not at all thanks. Let me repeat: Is there a convenient way to port device bridges (Portal Table) over to polisy from ISY?

As a more specific question: What happens when I take mu ISY PLM, all configured and connect it to my polisy? Is there more to do with re-linking or will polisy just assume the PLM like nothing has happenned and continue on? It seems that my Insteon devices and ISY Portal must go together, full switch or nothing.

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