MrBill

Same here.... Paging @bmercier?

Have you tried this: https://wiki.universal-devices.com/index.php?title=ISY_Portal_Admin_Console

Mismatched. Follow the instructions here:

Do you have any idea what firmware version your ISY is currently running? Have you not updated firmware in 7 or 8 years? or am I reading too much into your wording? The best method is the Launcher, It will automatically match the UI version to the firmware version. Instructions are here:

$Fireplace.down.cycle = State Variable '#1704 / Downstairs Fireplace' Temperature = Wireless tag Temperature Node '$Fireplace.down.setpoint Fahrenheit'Is = State Variable If you don't want to have an override switch, you could skip $Fireplace.down.cycle There is actually 3 more programs that work with these 2 for a group of 5. Essentially there are 2 buttons on a 8 button controller that are controllers for the scene. 'DN Fireplace#' is also a responder to the scene. The extra "status" line in the IF of the cycle-on and cycle-off programs takes are of updating when the scene is turned on / off via alexa, or an iphone APP. the single Status is perhaps all that's needed, except this forum taught me to use Control in If's early on.... then when Alexa came along I added the 'status' lines also. I actually have another set of 5 programs for another fireplace.... these have worked very. Haven't needed delays, the temps only update once per minute. All 5: =================================================================================== Fireplace-Downstairs - [ID 007C][Parent 0001] Folder Conditions for 'Fireplace-Downstairs' If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Allow the programs in this folder to run. ----------------------------------------------------------------------------------- Fireplace-cycle off - [ID 0078][Parent 007C] If $Fireplace.down.cycle is 1 And '#1704 / Downstairs Fireplace' Temperature >= '$Fireplace.down.setpoint Fahrenheit' And 'DN Fireplace#' Status is On Then Set 'DN Fireplace#' Off Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Fireplace-cycle on - [ID 0079][Parent 007C] If $Fireplace.down.cycle is 1 And '#1704 / Downstairs Fireplace' Temperature < '$Fireplace.down.setpoint.hysteresis Fahrenheit' And 'DN Fireplace#' Status is Off Then Set 'DN Fireplace#' On Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Fireplace-Downstairs-off - [ID 007B][Parent 007C] If 'DN Back Door Recessed+# / {hide}Fireplace Downstairs' is switched Off Or 'DN Back Door Recessed+# / {hide}Fireplace Downstairs' is switched Fast Off Or '{hide}OUT Lower Fans - High / {hide}DN Fireplace' is switched Off Or '{hide}OUT Lower Fans - High / {hide}DN Fireplace' is switched Fast Off Or '{hide}OUT Lower Fans - High / {hide}DN Fireplace' Status is Off Or 'DN Back Door Recessed+# / DN All Off' is switched Off Or 'DN Back Door Recessed+# / DN All Off' is switched Fast Off Then $Fireplace.down.cycle = 0 Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Fireplace-Downstairs-on - [ID 007A][Parent 007C] If '{hide}OUT Lower Fans - High / {hide}DN Fireplace' is switched On Or 'DN Back Door Recessed+# / {hide}Fireplace Downstairs' is switched On Or 'DN Back Door Recessed+# / {hide}Fireplace Downstairs' Status is not Off Then $Fireplace.down.cycle = 1 Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Setpoint hysteresis - [ID 00E4][Parent 007C] If $Fireplace.down.setpoint < 80 And $Fireplace.down.setpoint >= 60 Then $Fireplace.down.setpoint.hysteresis = $Fireplace.down.setpoint $Fireplace.down.setpoint.hysteresis -= 1 Else $Fireplace.down.setpoint = 73 $Fireplace.down.setpoint.hysteresis = 72 When the setpoint value changes, and the new value is sane, then set hysteresis value. When the new value is NOT sane, set default values.

I'd separate this into two programs so that it can turn on at >= 90 and off at <88 or somethings. With only a single program two things come to mind the fan would go on/off frequently. Also I'd use and AND in If's to prevent excess traffic because each time the temp changes on or off is sent regardless of whether it's already on / off. Here's examples I use with my fireplace: Fireplace-cycle off - [ID 0078][Parent 007C] If $Fireplace.down.cycle is 1 And '#1704 / Downstairs Fireplace' Temperature >= '$Fireplace.down.setpoint Fahrenheit' And 'DN Fireplace#' Status is On Then Set 'DN Fireplace#' Off Else - No Actions - (To add one, press 'Action') Fireplace-cycle on - [ID 0079][Parent 007C] If $Fireplace.down.cycle is 1 And '#1704 / Downstairs Fireplace' Temperature < '$Fireplace.down.setpoint.hysteresis Fahrenheit' And 'DN Fireplace#' Status is Off Then Set 'DN Fireplace#' On Else - No Actions - (To add one, press 'Action')

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.