kaplansa

I take it 3.2.4 is the latest (as of this post)? Thanks for explaining it. The only thing that seems affected by the bug is the My Notifications section of the UD Mobile app. Suggest that while you're fixing the naming conflict, you might fix the UD Mobile app so that "cancel" returns to the main screen. It's minor. Thanks for explaining it to me. Best of luck. Cheers.

I recently performed a firmware update using UD Mobile to update my eISY (and PG3) to IoX 5.7.0 and PG3x 3.2.5. IoX successfully upgraded to 5.7.0, but according to the PG3 dashboard, it's still at 3.2.4. To make matters worse, when I click "My Notifications" (which is beta) in the UD Mobile app (on my iPhone 14 running iOS 16.6.1), I get an error message in UD Mobile (screen shot attached). The next screen asks you if you want to reboot. If you say "yes", it will reboot. If you say "Cancel", you'll go right back to the same "Upgrade Status" error screen. It's an infinite loop within the app from here. You have to swipe and close the app, never to return to the My Notifications screen or go through this again. So I've got two problems now - how to force PG3 to update to 3.2.5, and this infinite loop problem using My Notifications in the app. Thanks!

Hue node server works well, but every other day it needs to be restarted in order for ISY (on Polisy) to continue working with it. Any ideas? What other info can I provide to help? Thanks!

Thanks! And wouldntcha know it but Michel helped me in the end so it might not matter. Seems my problem may have been simply a matter of timing because I was working while UDI was going through sever upgrades on their end. Keep ya posted but for now everything looks better.... timing is everything I suppose...

Interestingly, my situation is nearly identical to that post. I also purchased my Polisy during the OG pre-order and let it sit and probably messed it up similarly although not exactly. Similar end result. The key to that solution though is having the img.bz image (that I don’t have). I’m comfortable with BalenaEtcher and I’ve already got all the necessary cables. At the risk of going trigger happy once more, any chance of getting that image file so I can take a stab at it at least? OG ISY and UDI SuperFan

Lol. You are correct. I meant IoP… But technically, isn’t IoP an IoT? Hah. Michel is obviously amazing and he’s called me “trigger happy” more than once from attempting my own hot fixes while waiting for his reply. Maybe that should be my new nickname. I do get the sense however that I screwed up the underlying operating system somehow and it’s nothing a good re-image wouldn’t solve but I should probably take your advice and wait… Yours in the IoT! — Trigger Happy OG ISY and UDI SuperFan

It's possible I may have FUBAR'd my Polisy, maybe by rebooting it before an update completed, not sure. I'm getting strange errors when IoT starts up, for instance, that suggest to me the OS is corrupt or possibly incomplete. I've even gone into SSH and deleted and re-installed ISY on Polisy just to be certain these errors aren't something that reinstalling ISY wouldn't fix. More examples of where my Polisy isn't working right, when I do a package update from the ISY Admin Console, I get 5 beeps, sometimes 6, but never 4. Similarly, if I click "restart IoT" from the IoT Admin Console, IoT never comes back online (can't see it in ISY Launcher), yet ISY Launcher suspiciously sees something because of the way it hangs like it's waiting for something (not normal behavior when everything works fine). In this scenario, only pulling the actual plug from the device will restart the device. In fact, the only way to restart IoT without having to pull the plug is by clicking the "Reboot" button in IoT. I have a ticket open with Michel who's been amazing to work with, but knowing that he has a million other responsibilities that don't include just me, what I'd like to do is re-flash my Polisy if such a method exists. For instance, on the ISY994i you could insert a fresh SD card. What method exists on Polisy to literally factory reset it with a proper OS that I promise not to accidentally screw up this time? Thanks!

Here's a screen shot of what I see in my ISY994i with WLED configured on my Polisy Server. I've got the WLED polyglot configured (there's only one configuration parameter - ipaddress_of_wled). I don't understand how Polisy works I guess. I've factory reset the Polisy a number of times too to clear it up, re-added my ISY and the this node server. I've removed and re-added the node server to ISY. I'm not sure what I'm doing anymore. Help? ISY SCREEN POLISY DASHBOARD WLED CONFIGURATION (INSIDE POLISY)

I can understand that. Nice call. Unfortunately, I'm not running any AV on these Macs (shhh, don't tell anyone). Although that gives me more to think about anyhow and makes sense. Anyone else had similar problems on Mac that you found out the culprit if not AV?

Strangely about 80% of the time when I fire up the ISY994i Admin Console, the two automatic writes buttons ("automatic writes to devices" and "automatic writes to battery powered devices) are missing. This is a problem because when those buttons are missing (and their corresponding File menu items are missing too, btw) the Admin Console doesn't work - it can't write any updates to devices, sometimes crashes (spinning beach ball), generally unpredictable and bad. When I fire up the Admin Console and see these buttons are missing, I close the Console and literally just fire it up again, and down, and up, and down, until it decides to start with those buttons displayed. Once they're displayed, things are generally okay. I've tried cycling power, rebooting, and I can't seem to find a pattern when or why this happens. Makes the entire system flaky and unpredictable. I've recently upgraded to 4.0.5 to see if this behavior changes and it doesn't. I'm also running on a Mac (latest OS) and this behavior is consistent across three different computers. Clearing Java cache doesn't seem to help either. Anyone else seen this behavior? Help.

Awesome code, Larry! In case anyone's wondering who's reading this, if you have two garage doors, the only changes that I see need to be made are: 1) Add both garage door sensors as responders to the same scene that your KPL is a responder also. 2) Create two (2) GARAGE DOOR CLOSE programs (I call mine "Garage Door Close - Left", "Garage Door Close - Right"). Each program looks identical to yours, except that each checks the status of only its sensor (program "right" checks the right garage door sensor, program "left" checks the left garage door sensor) 3) GARAGE DOOR BUTTON run both GARAGE DOOR CLOSE programs (left and right) in Then section 4) GARAGE DOOR QUERY program queries both the left and right garage door sensors and relays 5) GARAGE DOOR SET INDICATOR checks the status of both the left and right garage door sensors in the If section using an Or statement (i.e. "status 'Garage Door Sensor - Left' is On or status 'Garage Door Sensor - Right' is On") 6) If you're like me and used the green wires on the garage door opener kit, then your garage door at rest is "on" when closed. Since we're just using programs to set the KPL indicator, I see no problems reversing the sensor status logic in Larry's programs - e.g. "status 'garage door - left' is Off" works just fine. Only make sure that GARAGE DOOR SET INDICATOR program knows to set the garage door indicator scene to On when the garage door sensors are actually Off (either garage door is actually open). Otherwise, no problems that I'm aware after an hour of testing. Question though, Larry. You said, I don't understand the point here of this scene - it's not the same as the Indicator scene you suggested, which seems to work fine on its own. Why create this second scene with the KPLs as responders here too? Again, AWESOME work! You really made my day by making this so simple. Cheers Seth

Hello! I feel as though I have plenty of Access Points and Dual Band devices for my home to handle a mere 6 RF devices - 2-thermostat modules, 2-triggerlinc sensors, 2-motion sensors, yet my devices get spotty reception. I started with 2 Access Points and RF devices worked great until I started adding about 10 more Insteon devices (non dual-band - dimmer switches, that sort of thing). Then they stopped responding in my ISY-99i Pro. Trying to rule out RF interference I bought two 2-dual band lamplinc modules and places them literally within grabbing distance of my thermostats. Thermostats work now. But when I place either the lamplinc or an Access point directly underneath a motion sensor, the motion sensor acts as if the RF bridge isn't even there. So three questions: 1) Is there a way to tell if an Access Point is working in the ISY? What should I look for in the event viewer or otherwise to tell simply if an Access Point is sending/receiving any signal from the circuit or RF? 2) Is there a tool that you can use to check if any particular device (fridge, TV) is giving off or absorbing too much RF signal causing interference? I haven't added anything to my home along those lines since everything was working fine and I do most of my testing at night when nothing's on, no one's watching TV or doing laundry. 3) Could it be that I really need an Access Point or dual-band device at at outlet next to every RF Insteon device if I can't solve the RF interference (assumed) problem? Any other thoughts to getting my motion sensors back online in my ISY? Thanks for the advice folks!

Hey Lee. So this has been an exciting turn of events. On a whim I decided to pry a triggerlinc off my pantry door in the kitchen and bring it into my study where the dual band PLM and ISY are located, and guess what - everything relating to the triggerlinc works fine. I've since been walking around the house with the triggerlinc in-hand trying to figure out my RF signal pattern and the only place it consistently works is in the study right next to the PLM. So perhaps this has nothing to do with the firmware after all (I'm sure you guessed that a while ago), but I have two fairly new Access Points (just a couple of months old) and is it possible that both of them have stopped working? It seems the only good RF signal I get is in my study, and after about 15' it starts getting wonky. The triggerlinc starts blinking erratically when I get nearer to the kitchen, indicating that the device has lost its RF communication. That might explain the other RF devices too since they're not any closer to the PLM and nearer to Access Points that apparently no longer do anything. So... is there a way to check that the Access Point is repeating the RF signal of a device? Consider I have two (phase coupling on outlets of different sides of the fuse box) and neither seem to be repeating from my non-scientific observations. Appreciate any more advice - what to buy, what to return, maybe another dual-band device, at a loss. Cheers Seth

I've also done a PLM restore to see what happens. Nada. My PLM is connected, btw, since I know you're going to ask "13.23.E5 v92 / Connected" and there's an Access Point right nearby the TriggerLinc in case anyone's wondering. And BTW, when I said "all" my RF devices stopped working, I meant all of them - just realized that ISY doesn't see either of my thermostats any longer with this firmware either! There's a red exclamation point next to both of them. Not good Cheers. -- Seth

New battery was the first thing I tried Here's the log. All I'm doing is putting the triggerlinc into linking mode and trying to add it to the ISY using the manual Add Insteon Devices option... Sun 12/05/2010 11:15:58 PM : ---- Initializing the linked devices ---- Sun 12/05/2010 11:15:58 PM : ---- All Linked Devices are now initialized ---- Sun 12/05/2010 11:15:58 PM : ---- Add remaining devices ---- Sun 12/05/2010 11:15:58 PM : [ 13 E1 AC 1] Removing all links Sun 12/05/2010 11:15:58 PM : [13 E1 AC 1 ] Querying engine version Sun 12/05/2010 11:15:58 PM : [iNST-ACK ] 02 62 13.E1.AC 0F 0D 00 06 (00) Sun 12/05/2010 11:16:07 PM : [iNST-ACK ] 02 62 13.E1.AC 0F 0D 00 06 (00) Sun 12/05/2010 11:16:16 PM : [iNST-ACK ] 02 62 13.E1.AC 0F 0D 00 06 (00) Sun 12/05/2010 11:16:20 PM : [13 E1 AC 1 ] Failed getting engine version. Reverting to i1. Sun 12/05/2010 11:16:20 PM : [13 E1 AC 1 ] Using engine version i2 Sun 12/05/2010 11:16:20 PM : [iNST-ACK ] 02 62 13.E1.AC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06 (00) Sun 12/05/2010 11:16:29 PM : [iNST-ACK ] 02 62 13.E1.AC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06 (00) Sun 12/05/2010 11:16:38 PM : [iNST-ACK ] 02 62 13.E1.AC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06 (00) Sun 12/05/2010 11:16:42 PM : [ 13 E1 AC 1] ** Not added ** Remove Device Links failed Sun 12/05/2010 11:16:42 PM : ---- All Remaining Device Added ----

Yes, I always put it in linking mode first. I got a different error this time after this order of operations... Removing triggerlinc 1. Right-click "delete" for the triggerlinc in ISY 2. Put the triggerlinc into linking mode 3. Click "ok" on the ISY dialog. 4. ISY status bar does it's thing - triggerlinc gone. Adding triggerlinc back 5. In ISY "Link Management" --> Add Insteon Device 6. Choose Triggerlinc, fill out the the fields. 7. Put Triggerlinc into linking mode 8. Click "ok", "remove all links" 9. Dialog does its thing, displays the following error: Failed writing the highwater mark [-200000/-1] Node not added - failed removing links (13 E1 AC 1) [-200000/-9] If I try adding back the triggerlinc again, but in step 8 choose to keep existing links instead, I get the following error: Node not added - failed reading links (13 E1 AC 1) [-200000/-8] I should note that in every case, whenever the ISY attempts to write to the triggerlinc, during the writing process, there's an error underneath the status bar that says "failed getting engine version. Reverting to i1." I've since even tried factory resetting a triggerlinc and no differences. Do these errors provide any more useful information? Never had this much trouble before... Thanks guys!

@LeeG Any idea about the triggerlincs? What's [-200000/-15] mean? It's all a little disconcerting only because I've upgraded the ISY firmware a dozen times before and everything's worked fine (about 20 devices), but this particular upgrade made my RF devices stop controlling their scenes, as you pointed out with the motion sensor. Appreciate the help!! Cheers

All of my RF devices have stopped working (triggerlinc and motion sensor). Example - After the ISY update to this firmware, I tried removing a triggerlinc from a scene and got the error "Failed writing device link" with an error in red "[-200000/-51]". I tried removing the triggerlinc from the scene in the first place because I noticed it just all of a sudden stopped controlling the scene. Triggerlincs don't display current state in ISY either (blank). What does that error in brackets mean? My two motion sensors that control switchlinc dimmer scenes no longer control those scenes either. I've noticed that the red LED in the motion sensor, when tripped, flashes red several times as if telling me there's an error (which clearly there is, somewhere). In the ISY, motion sensors don't display current state, except for the low battery sensor, which is "off" for both my motion sensors. Thoughts? (for the record, alerts to my google account and controlling else seems fine.)

That's funny. Exact same thing for me too. All my notifications stopped a couple of days ago when I installed 2.8.6 and upon "testing" I got that same password error everyone else got. And this morning I opened my garage and I got a notification out of the blue. I'm scared to touch anything for fear that I'll stop getting them again, and like you, waiting for 2.8.7 which I hope will be out any day now. Michel and crew are probably just busy working the holidays, my guess

You think you're gonna have 2.8.7 out this week? Just asking because I use SMTP alerts for security and I'm obviously running blind with the SMTP problem in 2.8.6. I could downgrade if you think that's a better idea (to which version?) rather than holding out for 2.8.7 in the next couple of days. Thoughts? Cheers

Just bought two brand new 6 button KPL dimmers (v.36) and had to manually add them to the ISY (Link Management --> New Insteon Device). ISY couldn't find them automatically, which I thought strange. Nevertheless, they're added and seem to control scenes just fine. However, both KPLs (all KPL buttons) have those green 1011 arrows next to them. I've tried "write updates to device", I've even tried restoring, removing, re-adding, re-writing, you name it. Can't make those arrows go away. What am I doing wrong? Running ISY-99i v2.8.4.

Good idea. I tried. Unplugging and walking away to come back and plug in a couple of minutes later didn't change anything. Guess - when I flipped back to the green wire, IOLinc works fine again! So here are my observations: 1) IOLinc using green wire works fine for a couple of days. Sensor state is automatically sent to the ISY as they're supposed to. 2) Some trigger event possible throws the IOLinc into confusion mode. Sensor state is no longer automatically sent from the IOLinc. You have to manually query the IOLinc to get the correct sensor state. 3) Flipping from green to red wire sends the IOLinc back into "normal" working mode. Everything works fine. 4) Some trigger event possible throws the IOLinc into confusion mode again. Requires manual query to get state. 5) Perhaps because I'm using red at this point, state is reversed from what it should be when manually queried. 6) Flipped back to green wire. IOLinc works fine, but I need to uncheck "trigger reverse" in ISY to get the proper state reading. See how long this lasts until I need to flip back to the red wire to "reset" the ISY. Odd, isn't it? Thoughts?

It gets weirder. Not only is the sensor signal not automatically updating, but it's coming in reversed when queried. So here's what I know. When the IOLinc goes kaput, two things happen. 1) Stops automatically sending sensor status 2) Sensor status when queried may be reversed (off/open should on/closed, vice versa)

It happened again. IOLinc worked fine for exactly two days. Now they no longer send their status until manually queried so they're useless as far as creating programs around them in the ISY.I have this feeling that if I swap back to the green wire things might temporarily work again. Keep in mind that when I bought these IOLincs, I used the green wire, and they worked fine for a couple of days until this problem surfaced. I then replaced on IOLinc with a brand new one to rule that out, didn't fix. Then I flipped the wiring from green to red and everything worked for two days. Now it doesn't work any longer and I'm thinking about switching back to the green wire. I'm wondering if there's something wrong with the IOLincs that their internal sensors shut down after some trigger event and are 'reset' when I change wires? I'm also wondering why I feel like I'm one of the only people to experience this. I've gone through three IOLincs at this point all with the same issue. I have a fourth brand new one in a box, but I'm probably wasting my time installing that one. Any more pointers? Anyone? Pulling my hair out...

Here's what I'm thinking - four programs. Program Garage Door Closed If Status 'Garage Door-Inside Sensor is On Or Status 'Garage Door-Outside Sensor is On Then Run Program 'Garage Door Open' (Else Path) Program Garage Door Open If Status 'Garage Door-Inside Sensor is Off Or Status 'Garage Door-Outside Sensor is Off Then - No Conditions - Program Garage Execution If - No Conditions - Then Send Notification to 'Me' Set Scene 'Kitchen Lighting' On Run Program 'Garage Execution" (Else Path) Program Garage Door Trigger If Program 'Garage Door Open' is True And (Status 'Garage Door-Inside' is Off Or Status 'Garage Door-Outside' is Off ) Then Run Program 'Garage Door Execution' (Then Path) Obviously I'm still figuring this stuff out. My logic is that if the garage doors are open, the Open Program will be true. The only way to make the Open Program = False would be to actually close the doors (The Garage Closed program). The the Trigger program simply checks to see if the doors are open and haven't been closed. If that's the case, the don't run the trigger program - we only want the trigger to run if we know that the doors have been closed before they've been opened. If that makes sense We'll see how it goes... heh