MrBill

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.)

The topic can be googled as well. I was actually looking for the news story that I've linked before. I once got a series of messages 7 or 8 months later. Fortuitously they had time stamps included so i knew they had been stuck somewhere. A 3rd party contractor that handles gateways had shut down a server with messages still in queue, after the server was repaired and put back in service months and months later the queue was sent. The shutdown occurred on Valentines day... the news media had a good time reporting on the creepy messages people got... instances of valentines day text from boyfriends that had moved on, and/or even a dead spouse sending valentines wishes. Found one article. there were many more. funny stories like that aside... there are 100's of threads in this forum where people "discover" than they aren't receiving text messages or that they are late... and post to wonder why.... text message notifications are not reliable.

Definitely an SMS and MMS text gateways. SMS will reformat messages and break long messages into messages shorter than 160 characters. MMS does none of that and allows up to 1024 characters in a single message. MMS also allows pictures, but doesn't require one to be sent. Your solution is exactly what I was getting at without knowing your carrier. Be aware tho... you'll likely miss messages or have delayed messages from time to time. I'd always include a time stamp in your message ${sys.date} ${sys.time12} so that you can see how old the message is when it is received. The reason for the problem is that many spammers abuse the SMS/MMS gateways, lost and delayed messages are simply collateral damage as 3rd party contractors that manage the gateways deal with the spam.

@dex I agree with @larryllix that you may never make sense out of MSII data, I also wasn't aware that MSII doesn't send heartbeat-- but I don't own any MSII's either. Most Insteon wireless devices tho do send heartbeat and have a heartbeat node, there are simple programs to monitor heartbeats and report when they have stopped.

@geobark Looks like your sending to a SMS gateway which might be altering the message. Is that the case? if so which carrier? with ATT use @mms.att.net instead of @txt.att.net with version send your message to @vzwpix.com instead of vtext.com. bottom line: if you're using a gateway to send messages via text you'll soon be complaining of missing or delayed messages. Text gateways are not viable. Instead discover Pushover as suggested by @asbril. It can be used via the Notification nodesever, or you can create Network Resources directly and skip the node server. Yet another excellent solution is to download an email client such as SparkMail on your phone. Create a separate email address to use with that and turn notifications on. (I.e the only thing you will use SparkMail for is to receive notifications from your ISY. Use your existing email client that probably doesn't notify for email for everything else.

Which model ISY? That won't be compatible with a 994. With Polisy, it's not a supported device but if it's USB you might get it to work to some degree, or you probably won't.