MrBill

Also it should be noted that ANY Insteon traffic during a link count will throw the link count off. People seems to give the command "DO A LINK COUNT" without mentioning this. This means No switch flips, no motion and no battery device heartbeats can occur during the link count. If any traffic occurs the pointer will move to whatever that address is in the order and the link count can be very high or very low as a result. If any battery devices exist in the system, you almost need to do multiple link counts until the same number occurs twice or you determine there is a hardware fault. The advice to "Do a link count" is not valid without understanding how link counts work and why they might be invalid.

That depends. There are two versions of the leak sensor (I'm lucky enough to have some of each) One version clears itself as soon as it's dry or picked up. The other version stays "wet" until the contacts are out of water AND you have pressed the button once.

You should be able to uncheck the box "Migrate ISY Portal License" and everything else should migrate fine. I haven't done it yet tho.....

Create a integer variable and use several programs, such as: Program MotionSense If Motion is switched on And $iMotionCount < 5 then $iMotionCount += 1 Run Program MotionLightExpireMotion (if) Run Program MotionLightOn else (none) Program MotionLightON If $iMotionCount = 5 then turn light on else (none) Program MotionLightExpireMotion If $iMotionCount > 0 then wait 10 seconds $iMotionCount -= 1 Run Program MotionLightExpireMotion else Turn Light Off Disclaimer: I don't have an ELK M1 and don't know how often motions can retrigger. The wait and motion count above also may need adjustment based on that answer and personal preference. When I started writing this example I assumed it would use a State variable rather than an integer variable, but the solution is much more complicated using a state variable. Since the 2nd and 3rd programs only have an integer variable in the If statement they will never run unless called by another program. The first program is triggered on motion and only continues to accumulate the value if the motion value is less that 5. Since the second and third program won't run on their own, it runs them. The second program has one job only when the motion count gets to 5 it turns the light on. the third program expires motion and anytime the value reaches 0 turns the light off (it may not be on but this minor inefficiency shouldn't cause problems, a fourth program could be used to turn off the light when the variable returns to 0 but it would need to be run from the else that currently turns the light off.)

there are users that are paying twice. I'll be in the same boat if I choose to migrate. I'm paying both ISY and Polisy portal licenses. The second sentence of OP's original post establishes that he is also paying for both:

I think you have to email support. Apparently they must not have it linked anywhere. I also use BalenaEtcher for other things and would have no problem if the process was just outlined somewhere and a link to the file.

There appears to be a method as described in this post. However the BalenaEtcher method has never been disclosed in the forum or the wiki. The wiki says: If you are a geek, you can reflash your SSD yourself. Please submit a ticket

Proceed directly from 4.9 to 5.3.4. Be sure to make a backup before upgrading from 4.9 (File > Backup ISY). If you don't have Z-wave or any "adjust scene" it shouldn't be much of effort to upgrade to v5.3.4

did you restart polyglot? Beyond that you need to tell us more: We don't know if you're using Polyglot 2 or Polyglot 3, you tagged on to a thread in IoP, but are you actually using a 994 or is this really ISY on Polisy? Or are you perhaps using Polyglot Cloud? If so, PGC has been offline since February, if that's the case it actually stopped posting about 7 months ago.

4.8 to 4.9 is an easy upgrade. There should be a button in the admin console, it will probably take you all of 5 minutes for that upgrade. You're correct going from 4.9 to 5.3.4 is more complicated. First question to ask, is do you have the Z-wave Option? If yes, the second question is whether it's 300 series or 500 series, and my guess is that if you're on version 4.x that it's a 300 series. To find out from the admin console, to to Z-wave at the top, then Z-wave version. 4.55.00 is 300 series, 6.81.00 is 500 series. If 300, don't upgrade to 5.3.4... instead the furthest you can upgrade is v5.0.16C The Second question to ask is do the Programs in your ISY use "Adjust scene"? If so each of those programs will need a manual repair after upgrade. Third question is do you have programs that are intentionally "disabled", if so make note of those programs because they will become enabled during the upgrade and will need to be manually disabled again. (Reminder: sometimes disabled programs exist because they aren't entirely disabled, they do run when another program runs them. Disabled really just means the IF statement won't automatically detect conditions.) Last, the undocumented best practice is to make a text copy of your programs before upgrading. This is very easy to do and will take less than 1 minute. In the Admin Console navigate to the Programs tab then click the top level folder in the tree (usually it's named "My Programs" but might be different). Once "My Programs" is highlighted right click it.. on the context menu at the bottom choose "Copy Folder to Clipboard". Now open Notepad (windows built in program) and Paste the clipboard (click in the window and press Ctrl-V), then File > Save As and give it a name with a .txt extension. This will come in handy if a program doesn't update correctly (see "Second Question" above), you can use this file to see how it was before the upgrade. Finally after you upgrade to 5.0.16C or 5.3.4 the first stop in the Admin Console should be Help > About to make certain that the Firmware and UI version numbers match exactly. If they don't deal with that before proceeding. The second stop in the Admin Console after upgrade should be the Programs tab > Summary sub-tab. Look for the color YELLOW on that page. If you see any, that program didn't convert correctly and needs manually attention. All in all upgrades from 4.x to 5.x go much better today than they once did. Just follow the detailed upgrade instructions, plus the points I added above and you should be good. Good luck.

yes

Yes. Please refer to the wiki: https://wiki.universal-devices.com/index.php?title=Polisy:User_Guide#Polisy_OS_Versions_Below_13 Looks like you need to contact UDI support.

Wait is interrupted when the state of the IF changes. Use this constuct: Program 1 if dogdoor is switched on then run program 2 (then) Program 2 if (none) then disable program 1 turn on light wait 5 minutes turn off light enable program 1

you can be selective about migration. but if you actually have completely separate portal accounts and not multiple ISY's on a single account you may need to move the ISY and Polisy under the same portal account to be able to use the migration tool.

I dyed it purple for halloween!

Once the state of the IF changes, execution is interrupted at the next break (wait and possibly repeat). There are many possible constructs to avoid the issue. I'll write an imaginary abstract example with probably little real world value to illustrate: Program FanCycle.on If Temp > 80.0 then Run Program FanCycle.loop (then) else (blank) Program FanCycle.loop If (blank) then Disable Program FanCycle.on Enable Program FanCycle.off Repeat every 10 minutes Turn on Fan wait 5 minutes Turn off Fan else (blank) Program FanCycle.off If Temp < 75.0 then Stop Program FanCycle.loop Turn Fan off enable Program FanCycle.on disable Program FanCycle.off *// Note: since this program is disabling itself this MUST BE last. //* Program FanCycle.startup (Run at Startup) If (blank) then Turn Fan off Enable Program FanCycle.on Disable Program FanCycle.off else (blank) Program FanCycle.on watches for the temp to exceed 80, when it does it runs Program FanCycle.loop which immediately disables Program 1 and enables Program 3. Program 2 then cycles a Fan on and off for 5 of every 10 minutes. Program FanCycle.off get us out of the loop when the temp drops below 75 Program FanCycle.loop insures that the devices and programs are returned to known states when the ISY is rebooted. If the power to the ISY (or the house) was interrupted while the loop was running, if we didn't have program 4 when power was restored the fan might be on or off (insteon returns to it's last state) and Program FanCycle.on would be disabled which would mean the loop would never begin again. If we don't write these programs as segments like this, the problem is that as the temperature bounces around unanticipated things happen... for example consider this: Program FanCycle If Temp > 80.0 then Repeat every 10 minutes Turn on Fan wait 5 minutes Turn off Fan else Turn Off Fan here are some of the unintended things that happen: If the temp is rising, the loop will first execute at 80.1 or above, if the next temp change is 80.5 the current Then block will stop running, and a new Identical Then block will start running with timers reset. if the temp is wavering around 80 like 80.1, 79.9, 80.5, 79.0, etc the fan will stop and start everytime the temp updates if the temp is falling and had dropped below 80 this program will create ALOT of unneeded insteon traffic, because each time the temperature update the ISY will send the command to the switch to Turn Off. In conclusion: ISY program is a different beast. While you might be able to use some constructs from other languages/styles one must also consider what's happening under the hood (example: it doesn't make sense to turn the fan off everytime the temp changes by .1 degree all WINTER long.

Does the computer you are using to access the admin console have access to the internet? If so try "Admin Console (Cloud)" The difference is where the admin console is downloaded from, Launcher gets a fresh copy every time it is started via Finder. The cloud version will generally be faster when a 994i is in play. The reason is the Java requires a secure connection to d/l the admin console... 994's don't have much processing power and take awhile to encrypt the file have the keys have been negotiated. Another suggestion is you may have a firewall issue, try disabling in firewalls. @DJonas another question: is this Mac or Windows? If Mac you may wish to just download admin.jnlp from your ISY and place it on the desktop. Just remember you need to delete that and clear your java cache when you update ISY firmware. http://ip.of.the.isy/admin.jnlp save the file on the desktop. You must replace ip.of.the.isy with the actual local network ip numbers that you are seeing in the finder window.

Doesn't look like he's getting logged in. Note the Main tab is still blank, no tree yet. @dpierre I'd clear the Java cache as per @Geddy and also delete the .state files as described here.

The real question is why are you rebooting your router every other day? That seems like treating the symptoms not the disease.

I've about reached the conclusion that when i move my insteon over to Polisy that I need to do it manually, factory reseting every device and start fresh. there's about 3 devices (2 are fanlincs) that I won't factory reset but just clear old links as I re-add because they are hard to get to. I just wish there was a faster way to add my ~380 programs, but I suppose I'm smarter about programming now too so starting from scratch may not be all bad.

do you have an extra keypad or can you pull one out. Wire it when a plug in pigtail and cap the red wire. Plug it in in the same place as the PLM.

I successfully upgraded to 3.1.7 (which is different than 3.1.6 that I thought I was upgrading to) I have to comment tho, that following the second instruction to restart PG3: restart Polyglot 3 leads to some confusion. When selecting "Restart Polyglot 3" I was presented with this utterly confusing dialog box pops up: I didn't install any scripts. but i didn't seem to need to manually do that because it did restart. Sounds like this dialog box is out of date and needs to be reworded.

@wrj0 try hard refreshing your browser... Ctrl-F5 or Ctrl and click refresh.

I just jumped on testing this. I've been debating moving to Polisy, however I wouldn't be able to if button press events such as this don't work. Here's what I did. Acquired an 8-button keypad from my spares stock and wired it with a temp cord and plugged in. Factory reset the 8-button keypad, then added it to the Polisy test system and it's PLM (2413U). opened Event Viewer then tested communication by turning Button A on and off from Admin Console, then Turned button A on and off by pressing the button. Everything worked as expected. Opened "Button Toggle Mode" then set Button H to "Non-toggle Off". Pressing button H now causes a single DOF to appear in the event view (as expected). Added an INT variable called Button H Count, then created the following test program: Pressed Button H several times... each press adds one DOF to the event viewer, and correctly increments the Int variable. So everything is working correctly as expected, now the question is why @dex's ISY can't hear the DOF's. Insteon Noise?

Messages like that i send via more than one route to my phone. Example: the email notification that is sent to text is actually also sent to the email address using the spark email client, and it's sent via pushover. for multiple email receipts use a group like this: Also I don't send a message like "the furnace failed" just once. I send it every hour until I've stopped it or the problem is resolved. Also you mentioned UD mobile, I haven't played with its push notifications yet but it now has the capability of sending Push notifications. (It's a recent addition to UD Mobile.)