larryllix

I was attempting to do that. Since mst of my lighting programs are based on single variable values it was very easy to move the non-Insteon lighting over. A simple ISY folder containing several variable change detection programs that NRed the values out into polisy's via it's REST interface to modified the cloned variable made that a synch. However when I thought about going further, so many devices were hooked together and dependent on each other I found it may have been simpler to "Tear the bandaide off" than suffering with many more cross-variable interlocks. The grass always looks greener on the other side of the fence and I demonstrated this quite well to myself. Two intense days did 98% of the bandaide technique but I still find the odd thing freaky. I found the odd light flashing on and then off etc...where one program was enabled again and shouldn't have been. Now I comment every program that must be disabled in the If section. ISY didn't have that capability when I started. Thank you UDI for listening to your users!! The WiFi lighting only (over to polisy) technique worked well for about a week or so, and then I just couldn't sit on my hands anymore. All in all, I am glad I made the jump. I did sweat a lot for a few days but that is why I am an ISY user...for the challenges and the solutions,... when I win at each challenge. I found another glitch last night that I need to fix and my dishwasher LD still needs linking into the polisy PLM yet. ISY Portal and Alexa speaking routines were the hardest as each time you delete all ISY Portal pseudo-devices the routines all need to re-attached from zero again. What a PITA! @bmercierWe need a better unused / defunct ISY element cleanup button in ISY Portal. Looks for unused ISY elements and removes them from Alexa. When vocals are changed, we end up with two different names in Alexa and it confuses her. Thanks.

Devices were not successfuly ported and none showed up. Different PLM anyway. Maybe moving PLM with the image may have worked better. Programs are then marked in yellow with Insteon addresses marked in comments. Enable/ disable cannot be trusted and a check box toggle at least one way and save fixes those. Variable values over 255? or maybe 16536 need to be divided by 256x256x256. If negative then add 256 after. I wrote a small ISY program and continually updated the variable names. Calculator would have been faster. NRs did work until edited and saved back as they came in. WoL still doesn't work for any devices. Devices were added one at a time using Delete all existing links. Will attempt clean up later. Not sure what will be left in devices yet. Factory reset or at least old ISY uninstall may be better but all but LD under dishwasher working well now. CAO tags ran as dual kumoapp for a while. Now only polisy. My NRbridge just needed heartbeat variable updated. Sent from my SM-G781W using Tapatalk

@Michel Kohanim I got my polisy/ISY working, then got past the commitment point and had to move everything over (commit). Daunting task took me about two days to clean up some variables (endian reversal) , program enables random, and Scenes demolished. LOL (I used Restore from an ISY backup image) Running 98% now...mostly good. Most items just needed to be refreshed to function. I am running on a USB PLM via polisy USB port. Some outstanding issues I have found: WoL seem to be outstanding and none of the 3 devices I tested work. They do work from my router so devices still receptive and functioning Some OR logic not shown properly in admin console. I have one program that refused to show two ORed conditions in the If section. Other programs show the OR text just fine. When two logic statements are ANDed they showed fine. This is only the admin console text (GUI) , and the ISY logic seems to function just fine anyway. X10 support appears outstanding. I cannot find any method to add any X10 devices in admin console. X10 module not installed, but no hard address method is available either.

Good point. As an assumed newer user he may not be aware of the dual citizenship ISY has now. ...and PLMs are assuming dual lives also. Sent from my SM-G781W using Tapatalk

There is no X10 devices to have a status. There is no method to connect to them.

Switching over to polisy, and using a USB PLM, I found I have lost any X10 features in my polisy. I am not sure if this is software or the USB PLM is incapable of X10 and polisy just reflects that in menu options loss. @Michel KohanimHopefully polisy is just adding X10 support later in the firmware and this is not a hardware deficiency.

Click on the link I provided in my post above and scroll down to the Install section. There you should see two links that will get you the choice we have been posting about, with PLM, and without PLM.

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.