MrBill

on the Help > About menu of the admin console, does the Firmware and UI version match? and what version are shown?

It's my understanding (and I just tried again) that only the Admin User, located at File > Set Userid/Password works. If you attempt to set one in Userid 1 -9 it appears to set, but is unusable for logging in to the admin console. The wiki page, doesn't contain instructions for using those entries either. I think in the past I've answered several queries about those here in the forum with essentially "they don't work, they might be for future use, but haven't yet been implemented yet" and I believe @Michel Kohanim has "liked" at least one of those past post, perhaps indicating he agrees. But on the other hand maybe it's one of those bugs that some people think is getting fixed but no one in development actually realizes exists. Or perhaps @bambamf16 is referring to the "User" tab of the portal, where sub-accounts are created. That doesn't seem likely tho because the list of Currently assigned users, shows on the Users tab, the same place they are added.

WOW, I thought this was a known bug for a long time. It's kinda like scene re-writes to battery controllers, I thought we were just waiting for it to be fixed. These are the two biggest I know of that effect my usage, but I wonder of there are others? Is there a public list of known open issues anywhere?

You build your own customized content for the texts the same way you do for emails from ISY. https://wiki.universal-devices.com/index.php?title=ISY-994i_Series:EMail_and_Networking_Substitution_Variables If your carrier is AT&T using 10digitnumber@txt.att.net means that the messages arrive from 1 (410) 000-XXX and are broken into max 160 character messages, often arriving out of order. If your carrier is AT&T using 10digitnumber@mms.att.net the messages will arrive from the email address that sent the message and has max length of 1000 char (I think). If your carrier is a different provider they all have their own similar email to sms/mms gateways. Many are listed in the table in this wikipedia article.

I believe you! I also believe my observations. Unfortunately those two things are mutually exclusive, hence my statement. That bug and the GUI bug's around Backlight, On Level, and ramp rate also never seem to get love.

@apostolakisl this has been an interesting exercise. But it just proves once again that I don't understand what's happening in the error log. I ran the THEN branch of the Factory query twice, it finishes quickly, 2.5 minutes with zero devices error-ing out. I wish I could watch it during boot. I'll have to start watching the error log again at the 3AM mark.

I literally leave the Christmas Insteon devices plugged in all year round, lol. 3 stay in place and the other, 2 I move to a plug strip under my desk. My wife bought a new fountain, so one of the "Christmas" devices became a Summer fountain controller this year. Today, I've actually been wondering if open/close sensors and recessed open/close sensors are getting hammered in the Query all. (they shouldn't be, but since V5 tries to write to them for scene changes it's made me wonder if ISY is trying to query them). I'll try running a 'query all' soon with the event viewer open to level 3 to see if anything gets queried repeatedly and/or errors.

@Michel Kohanim has told me that my assertion that the unwritten data builds up is not correct. However I'm not sure what to believe because when I remove the scene updates involving a battery device my queue full problem goes away. For me the real solution is to fix the bug so that the scene updates only write to the non-battery devices, the way it worked in v4.x.

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.