MrBill

I assume MD is motion detector? If so, its a battery device and in V5 there is a nasty bug covered in several threads (the two most recent):

I do agree with others, if the issue is a tripping circuit breaker (from load, ARC Fault, or even random nuisance GFCI trips) the root cause should be determined and corrected instead. The single EXCEPTION (that I can think of while typing this) being a GFCI Tripping from lightning which both OP and I appear to have (his is a GFCI breaker, mine is a GFCI outlet). Lightning is not generally a problem until the amount of wire after the GFCI is long, or the lightning is very close. It's a problem with a root cause that can't be fixed. That's something I've been wondering for awhile and you just nudged me to figure it out. I knew that the ISY Inventory Node Server reports 286 Insteon Nodes. That number is inflates the device count tho. I have a lot of 6, and 8 button controllers, not to mention wireless devices with multiple nodes. So to count devices i used Generate Topology and then cut and pasted the nodes table into Excel, then extracted the device number column and only truncated it to the left 8 characters, leaving a column of AA.BB.CC Insteon device addresses, then used the Excel remove duplicates function. The result I have 114 unique Insteon addresses. Next I'm going to workout how many of each type of device are present.

weird, when i used Responding = False the THEN block executes on failure. Edit to add: perhaps it requires 2 programs ( Responding = False and Responding = True) to monitor both states (3 total programs)

heh, I actually had 15 seconds in that program when I was testing, I typed over it manually as I was posting the program. Specifically tho, I would imagine on larger Insteon systems the problem would come at the 3am factory query all. Query all already takes 10-12 minutes which I'm more painfully aware of during and ISY restart, I'd try to avoid a being too frequent with a loop that produces insteon traffic.

I installed a new switch one day a few months back (actually expanding a location from 3 to 4 gang) I had the worst time setting backlight values equally due to this bug, I finally realized I needed to either restart the admin console 4 times or the better workaround is I created a one time use program to set all 4 backlights, ran the then block once and then deleted the program. While that's a simple workaround, I wonder why this version 5.x bug has never been addressed?

@gviliunas What happens if you reverse the logic? 'Test LampLinc " Responding is False. I was only testing in one direction yesterday. I have a GFCI that trips occasionally due to lightning, in my final program pair I query only once per day at 4PM and the GFCI was purposely tripped. After I reset the GFCI, I manually turned the queried switch on and back off, specifically to update the ISY's status.

If you configure your own SMTP server in Configuration > Emails/Notifications > Setting/Groups then you can send to <10digitnumber>@mms.att.net and the messages will arrive from your email address, they are also not broken up into short messages which arrive out of order. (as of last time i checked 4.5 years ago the messages using UDI's default SMTP server would not arrive). I created a Comcast mailbox for my ISY to use exclusively. I also send most messages to the inbox of that same account. You can likely do the same thing with whoever your provider is, I'll include a redacted screen shot to perhaps make it easier, port number may however vary by provider, most use 587 or 465 (and almost none use 25 anymore) but there could be variations.

That's how the 8-scene mini remotes work, it's a hardware limitation. Being a wireless device the mini-remote has no idea what the state of the scene actually is. If you watch the little LED indicator on the top of the button you can tell which way it's activating. We actually changed ours to 4 scene controllers with an on and off button for each of the 4 scenes. Then for some of the pairs instead of it actually being a scene on/off I used programs. For your hot water, is the bathroom light an Insteon switch? If so, you could just use a program from there to turn your scene on, skipping the 8-button remote entirely.

This actually does work, and I'm going to use it to find out when a GFCI trips, it already has downstream permanent Insteon after the GFCI. I was however confused about the second query program and created it to run the If of the program in your example, that's not correct. here's what worked for me: AAA test no query loop - [ID 00EA][Parent 0001][Run At Startup] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat Every 15 minutes Set 'Christmas-Front#' Query Else - No Actions - (To add one, press 'Action') ------------------------------------------------------------------------------- AAA test no query - [ID 00E9][Parent 0001] If 'Christmas-Front#' Responding is False Then Resource 'zzz-push test' Else - No Actions - (To add one, press 'Action') Of course since the query generates Insteon traffic so you don't want to run it too often. In reality for my application I only need it to run once in the late afternoon. So as I go make this permanent I'll probably just set the query for one specific time per day.

thanks!! that's interesting, I see why the close node could be useful in some cases. I just use the open node in my simple closet switch installations tho. the hardware (at least the US hardware) has changed tho.

There was a time in the late 90's and early 00's that I sent alot of stuff back, as i recall it was never a hassle, but we were a 'smarthomepro.com' dealer then a bought a shit of of X10 from them. I know we probably returned stuff that technically didn't qualify for return but they never complained (we bought alot of units back then tho). On the other hand, over in this post, I told the story of a lightning damaged 2466SW. When I called (probably in 2016) to return that (it was probably 6 months old) they wanted to "troubleshoot" on the phone before they would give me an RMA. I told them it had already been uninstalled, and all the steps I had gone thru. He wanted me to re-install it, so that "we could troubleshoot it together on the phone". I finally hooked it up to an extension cord pig-tail and asked what to do next. The ISY (he was new, he had to ask someone if an ISY was compatible) wouldn't find/re-add it and he then told me I actually needed to re-install it in the wall box and connected to the fan so that the ISY could find it. At that point think i requested talking to someone else, who gave me an RMA without much more hassle. At that point the 2466SW and the 2477S were the same retail price, I tried to get them to replace the 2466SW with the 2477SW but they refused that.

Interesting... I've never really paid much attention to the date codes, except involving fanlinc's where I was having issue at one point. a date code of 1921 will certainly be ambiguous soon!

Something has definitely changed in the cloud. I make all of my spoken's pretty unique and she's questioning me a lot about what I mean..... for like the past 2 weeks, maybe 3

@Teken So this thread made me go look at the full version of the manual. which makes no mention of the jumper block. and then I had to walk around an inspect most of my 2843-222's which are version 1.b date code 3815. the user manual doesn't mention the jumper block, although in the picture I can see where it was on the board, by the 38th week of 2015 it is just unused holes on the board. Checking the admin console, all of my have the closed node, but I've never used that and wonder in what conditions it becomes useful? Extra credit: I just ordered some 2342's during the sale and had them on my desk to link today.... the date codes seem reversed v2.0 1921.... i wonder why? especially since after the 19th week of 2021 that will become confusing.....

The theory all sounds great, except I can tell you first hand about two specific problems I've had in the past (my system is all Insteon and large i don't know how many devices anymore but over 100, none more than a few years old at that time, and all DUAL-BAND, with zero z-wave): Case 1: I used to have a deep fryer in the kitchen that got used once a week for taco shells and chips, for the one hour per week it was plugged in most Insteon didn't work. Some items coming from the PLM would ultimately execute very late as soon as the plugged was pulled for the deep fryer. This is a 110v counter top deep fryer, on a kitchen counter receptacle circuit that has NO Insteon device on the circuit. The deep fryer didn't even have to be turned on, just simply plugged in and Insteon would be dead in the water. We just lived with that problem since it was only an hour per week. Eventually that deep fryer kicked the bucket, it's replacement and Insteon very happy co-exist together. Case 2: After a storm most Insteon didn't work, but the weird part was some did. At first I was sick to my stomach because I thought I was going to have to replace 50+ devices. In the end I started playing with circuit breakers-- the first goal was to figure out if it was all devices on one phase and the other phase was fine, but it wasn't one phase or the other. Eventually I turned off breakers in big groups then further narrowed it down to one when one breaker labeled "Furnace Blower" was turned off my entire Insteon system worked perfectly. The kicker was I then tested heating and Air Conditioning... everything checked out and worked, but with that breaker turned on my Insteon system was essentially dead in the water. It suddenly dawned on me.... the attic fan was also on that circuit. I remember because it was actually hard to find the attic fan breaker when I installed it's Insteon switch, no breakers were labeled attic fan, no breaker seemed to turn the circuit off, of course I skipped "furnace blower" because why would it be that circuit? Well during the initial install I finally just decided to "trip" the breaker so I could install the Insteon switch so went up and created a dead short so the breaker would trip...haha it was the furnace breaker, but stupid me didn't add it to the label at that time. So I installed a 2466SW to control the attic fan. I decided it need to be that switch because its advertised by smarthome as being "better" for motors and florescent lights than 2477S. Anyway to wrap up this long story the 2466SW sustained storm damage, it was generating noise that brought down most of the Insteon dual band system... once I popped that single switch out and replaced it with a 2477S that I had on hand my entire system was back up and running. Moral of the Story.... you have to get rid of noise makers and signal suckers follow the standard troubleshooting steps, and no you can't assume the radio portion of insteon will take over and heal the network in the event of line noise.

I spoke too soon becuase I was thinking of the networking module being much like the cron interface and it's not. This is very doable still tho. The ISY's networking module just needs to call a URL on the pi that runs a script via http, the Pi script would run shutdown on the pi. If you need help making that happen I'm going to let someone else take over my idea and help you out. I could get it done but it doesn't role off my fingers like I bet it will for someone else. the steps: 1) create a pi script that can be called via the pi's webserver that contains a single command to run shutdown. 2) create network resource on ISY that runs the pi script 3) create an ISY program that runs network resource, waits, turns off plug.

if you have the network module on the ISY you could go in reverse. the ISY program calls a network resource that SSH's to the pi and runs shutdown, then waits, then shuts off the plug.

You could write a script for the RPI that does 2 things: 1) execute a REST API call to the ISY 2) then initiate the rPi shutdown sequence. The REST call could run an ISY programs 'then'.... example: /rest/programs/0032/runThen the isy program can be disabled, and doesn't need an 'if' or 'else', the 'then' body should "wait" the number of minutes (or seconds) that will take the rPi to reach the safe shutdown state plus some cushion time, after the wait, it should turn off the plug.

Another thread recently lead me to File > Themes > font size Since changing it to 15 I can actually read the funky magenta text easily. (hint: 14 breaks display of some selector boxes, skip that size).

I'm surprised it works. Try the instructions in this post to install the launcher on your desktop. It's the modern way of always opening the correct version of the Admin Console.

I periodically run the check for updates also and since they seem to appear frequently try to remember to check every week at least. I also run the check again after I apply the updates to make sure it returned to zero. At one point in history months ago, it didn't return to zero and the updates continued to mount and ultimately Michel ultimately had me sudo pkg update && sudo pkg upgrade sudo service udx restart I've often wondered about the contents of the updates and whether there needed to be a more pro-active method of making them obvious. I'm happy that @asbril asked. In the early days I was also rebooting polisy after applying any updates, however they were so frequent that I've stopped doing that, figuring it would tell me to restart if I really needed too. I must mention again tho that the non-persistent green boxes that you have to stare at the screen and wait for are quite annoying. I hope that its high on the list that those become persistent until dismissed.... at least the subset that say things like "Update Check complete. 1 package available for update. Click on the "System > Update Polisy" button to start."

I think @ronvond is refering to this notice: which does make me wonder what people without a UDI portal account are supposed to do....

There should be a factory "query all" program in your program tree that is already set to run daily at 3AM. On large systems this can take awhile and is best run when no one is moving about or turning things on and off during the query. (example in my house the query all takes almost 10 minutes.) that said the solution is probably not to have that run more often, nor to add a method to cause an auto reboot, the actual solution is most likely to find the root cause, which is most likely a noise problem. Is your system composed in Insteon, Z-wave or both? how many of each type device roughly? is it always the same devices and tasks with problems?

in current versions of the admin console the font size is File > Themes > Font Size. That said if you really mean you're still using a 99i you'll have to wait for someone else to answer... I have no idea, i wasn't a customer yet in the 99i days and have no idea what that version looked like.

There are several ways mobilinc can connect and some of it depends on versions and options of mobilinc. It does sound like the option you've chosen is compatible, however, its worth pointing out, that the product "mobilinc connect" is a competing portal. This is important because the ISY can only connect to one portal. Either UDI's or Mobilinc connect, not both. If you have subscribe to mobilinc connect, you will need to unsubscribe that in order to reconnect with UDI's portal. If you have not subscribed to mobilinc connect, and you have rebooted your ISY as suggested, and then checked the Configuration > Portals tab in the admin console as suggested above, then your best bet is to open a ticket with UDI support.... shoot an email to support@universal-devices.com. Be sure to include your UUID and a link to this thread to expedite things. UDI answers quickly even on weekends usually, but this being a holiday weekend may add a slight delay.