MrBill

Always been the case, even in 4.x. The workaround is put the button in a scene and turn the scene on.

Here how I worked around this issue. Note: my Insteon installation started without an ISY and with lots of 6 and 8 button controllers for N-way switching, as well as standard scenes. THEN came ISY when I decided I didn't care for Insteon's hub and found out that a better option existed. So the entire Inteon structure existed, THEN came Alexa after everything else. It initially drove me insane that I couldn't have Alexa dim scenes. Eventually I figured out how to work around. With this method Alexa can dim and keep Scene controller buttons up to date. The caveats are it's tedious to setup, uses up 3 programs per light, and uses a state variable for each light. Define a state variable for each light/scene... in this example Dim.Lamp.Bill This variable can have the following values: 0=off 1 to 100=dim percent when set by alexa sets it, or actually also when set by another program (when I created this method it hadn't yet occurred to me that another program might set the variable, but that does in fact happen in my system. ) 101=light on (unknown dim value) (it turns out that it's impossible to get the correct Dim percentage if a switch or scene controller button was used to set the brightness level Then for each light you'll need 3 programs I call them Alexa.on, Manual.on, and Off. All three are collected into a folder (hint: make a copy of the folder after the first one you do, then edit the copy for the next scene/device) First just a regular folder: =================================================================================== Bills Lamp - [ID 00AE][Parent 00B6] Folder Conditions for 'Bills Lamp' If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Allow the programs in this folder to run. Alexa.on responds to the state variable being changed. Set Alexa up in the Portal to set the state variable instead of a scene or light. (hint you'll discover its nice that you can set an ON and OFF value in the portal, always set OFF to zero, normally set ON to 100 but On in the portal setup could be any value 1 to 100) Another program, such as timer, changing the state variable also works. In the THEN block, First turn on the SCENE, wait 1 second (it doesn't work without the delay, it also doesn't actually set a dim level at that point) then after the delay set the actual DIM level from the variable. So to repeat via THEN, the first line is the SCENE, then the second value is actually being set on the DEVICE within the scene. ----------------------------------------------------------------------------------- Alexa.on - [ID 00A9][Parent 00AE] If $Dim.Lamp.Bill > 0 And $Dim.Lamp.Bill <= 100 Then Set 'MBR Lamp-Bill' On '$Dim.Lamp.Bill %' Wait 1 second Set 'MBR Bedside-Bill+#' On '$Dim.Lamp.Bill %' Else - No Actions - (To add one, press 'Action') The manual.on program is the tedious one to set up. For each scene controller button you need 3 lines in the IF, one for On, Fast On, and Fade Stop. So in this example there are 3 buttons that can control the scene. If any of them are used we don't need to know the actual dim level that was set we just set the variable to 101 (on, unknown dim level) So, this programs purpose is to update the Variable if buttons were used. 101 so that if Alexa is used subsequently the value will always change. ----------------------------------------------------------------------------------- Manual.on - [ID 00AC][Parent 00AE] If 'MBR Bedside-Bill+#' is switched On Or 'MBR Bedside-Bill+#' is switched Fast On Or 'MBR Bedside-Bill+#' is switched Fade Stop Or 'MBR Bedside-Deb+# / {hide}Bill Lamp' is switched On Or 'MBR Bedside-Deb+# / {hide}Bill Lamp' is switched Fast On Or 'MBR Bedside-Deb+# / {hide}Bill Lamp' is switched Fade Stop Or 'MBR Ceiling Fan+# / {hide}Bill Lamp' is switched On Or 'MBR Ceiling Fan+# / {hide}Bill Lamp' is switched Fast On Or 'MBR Ceiling Fan+# / {hide}Bill Lamp' is switched Fade Stop Then $Dim.Lamp.Bill = 101 Else - No Actions - (To add one, press 'Action') The final program combines an Alexa off or manual off into a single program. You need two IF lines per scene controller button, plus one for alexa setting the value to zero. The THEN body sets both the variable to zero and the scene to off. (one of which is already done, but this way we don't need two programs for off). ----------------------------------------------------------------------------------- Off - [ID 00AD][Parent 00AE] If 'MBR Bedside-Bill+#' is switched Off Or 'MBR Bedside-Bill+#' is switched Fast Off Or 'MBR Bedside-Deb+# / {hide}Bill Lamp' is switched Off Or 'MBR Bedside-Deb+# / {hide}Bill Lamp' is switched Fast Off Or 'MBR Ceiling Fan+# / {hide}Bill Lamp' is switched Off Or 'MBR Ceiling Fan+# / {hide}Bill Lamp' is switched Fast Off Or $Dim.Lamp.Bill is 0 Then $Dim.Lamp.Bill = 0 Set 'MBR Lamp-Bill' Off Else - No Actions - (To add one, press 'Action') The only thing about this method that I don't like is when you say "Alexa, set Bill's lamp to 30" it briefly comes on full brightness then dims. I realize that there is a method to ADJUST SCENE that could be used, but the method I used really works fine for me.

In reality the 2 tags with one minute updates for fireplace cycling don't use anymore batteries than the tags with 10 minute updates. I originally planned to changed the update interval on those two tags seasonally, because 6 months out of the year they provide no function. Reality I didn't bother. What does kill batteries faster are the freezers, but i expected that. Overall battery replacement hasn't bothered me too much. I don't "arm" any of the tags. They just push data on the selected update internal.

It was a version of a script I took from one of your posts way back.... I changed it some tho... anyway back when i set that up.... 7 tags had 10 minute updates 3 tags had 1 minute updates and I was sending Temp, humidity, and battery voltage to the ISY.... so 30 variables total were getting updated. Tattling on myself, I never got around to using most of that data in ISY programs. Humidity I didn't think I needed anyway, but i intended to get around to temp alarms and low battery alarms. Reality strikes tho, and the only two values I was actually using in ISY programs were 2 temperatures to cycle fireplaces. I just commented out and reconfigured the script/kumo app down to where the only things it updated are the two temperatures that I actually make use of in the ISY. I do use the 7 tags with 10 minute updates for refrigerator and freezer temps, except since i never got around to ISY programs I just rely on the Wireless tags app to notify me when temps are out of range... likewise for low battery.

Michel identified 3 things from the log. 1) DNS errors 2) that my wireless tags kumo app was hammering the ISY with updates. 3) that I should update to 5.0.14 After studying the log myself and noticing what he was referring to, I fixed #2 relatively quickly. I never realized how many updates were arriving. I had always watched those updates via Event Viewer. Event viewer apparently only reports the update when the value of the variable actually changes, not when the Tag Manager sends an un-needed update were the value is still current--- in some minutes there could be 30 some API calls spaced seconds apart. The ISY has in fact been taking this abuse on resources since Nov 2017 (I haven't made changes to the KUMO app since it was originally created) and just keeps running-- a testament to how well it just keeps running. I still don't understand what the DNS error looks like. The associated caution was don't forward UDP ports to the ISY, and use a DNS reservation if I care what the IP is. Both of those items were negatives to begin with. I haven't had any ports forwarded at all since I purchased Portal a long time ago (over a year). Also, I've always used DNS reservations on my network and never given any device a static IP. As I was writing this post Michel replied one more time, and better explained the DNS situation which was timeouts, after reading that I think it was probably all related to the hammering the ISY was talking from the kumo app and the lack of available resources. I also updated to 5.0.14 even tho I don't like to do things like that right before leaving town. That was a simple process that went without a hitch. I'll also watched that section of the forum so when another release comes out I'll get notified. I open the admin console probably at least once a week for varying reasons but I am bad about checking/following the forum because I just don't have enough hours in the day. Thanks for all your help!!

Sent.

The regular log leading up to to the random reboot doesn't give any clues either. Door Switches / LowerSlider Status On Sat 2019/03/16 11:01:10 AM System Log Door Switches / LowerSlider Status Off Sat 2019/03/16 11:01:13 AM System Log OUT Upper Deck Cans+# / {hide}Spa Motor Status Off Sat 2019/03/16 11:02:31 AM System Log OUT Lower Slider OH+# / {hide}Spa Motor Status Off Sat 2019/03/16 11:02:31 AM System Log Door Switches / LowerSlider Status On Sat 2019/03/16 11:04:04 AM System Log Door Switches / LowerSlider Status Off Sat 2019/03/16 11:04:09 AM System Log Christmas-Back# Status Off Sat 2019/03/16 11:07:10 AM System Log Door Switches / LowerSlider Status On Sat 2019/03/16 11:07:44 AM System Log Door Switches / Costco Rm NEW - Door Status Off Sat 2019/03/16 11:08:08 AM System Log Costco Rm# Status Off Sat 2019/03/16 11:08:08 AM System Log Door Switches / LowerSlider Status Off Sat 2019/03/16 11:09:32 AM System Log Door Switches / LowerSlider Status On Sat 2019/03/16 11:15:50 AM System Log 0 null Sat 2019/03/16 11:21:23 AM System Start All normal items that happen routinely. Christmas-back# is not out of place because I used a holiday light plug for a yard extension cord. Turning it on and in this case off at the device.

Thanks. As of now it looks good to me. I will watch this and see if it remains basically unchanged, which it should. Or builds up over time due to some type of issue or memory leak. Anything else I should be watching for.

(Sorry for the delayed reply here, we had a family emergency and our grand kids were with us for four days unexpectedly. The forum also didn't email me that there had been a new reply.) I don't know what queue would be full. I don't know what queue to watch, or how to watch it. I don't even know what is queued. I really have no idea what the errors in the error log mean, again this is why I came and posted about the incident here. It made zero sense to me, it still makes zero sense to me. Literally nothing was happening at that time. No scheduled events since Sunrise. No one was in the house turning anything on or off that would trigger a program. The only programs that I have that routinely show "running" are the heartbeat monitoring programs for door sensors batteries and the program that adds an hour to the uptime counter. Everything else shows "idle" 99.9% of the time, programs pretty much run because of a trigger and exits quickly and becomes "Idle" again. As for updating to 5.0.14, I think at this point I'll have to wait until we return. I don't want to introduce something new within a week of leaving the country. It was stable at 56 days since the last reboot before this unexpected reboot event. I was surprised that the admin console doesn't indicate a release after the one I'm on, I realize it's beta but still I'm surprised the update notification functionality is not in use here. That is once I moved to beta 5.x that new 5.x beta release would show in the admin console the way 4x general releases told me when to upgrade. I didn't really want to upgrade to 5.x when it was alpha, but once it went to beta I did for exactly one need, otherwise I could have stayed on the current stable general release.

Specifically I never leave the admin console just open. Only if i'm working in it. Previously the only time I have ever had reboots that were caused by some mistake I made. Not the case today. I added a few more Insteon modules and added a program in the last week, but nothing major nor complex.. and the system has been running stable for 56 days, the point of my post is to attempt to figure out the root cause of the random reboot because if there is an issue I need to resolve it before being away for nearly two weeks in the near future. I have absolutely no idea why this would have happened, that's why I came here to seek help, sorry that I was unclear.

My normally stable ISY rebooted this morning, never had that happen before except when i screwed something up. I was in the yard, when i got the notification, the admin console wasn't open. I count uptime hours and that variable was at 1349 (or around 56 days). Checking the error log at the time of reboot I find: Version 5.0.13D Anyone have any idea what might have occurred? I'm getting ready to be gone for an extended period and need to deal with anything quickly. Thanks.

I see that now. I'm on mobile, its shows the information differently there, but does show that. I had scrolled all the way to the top of the page and clicked Universal Devices, which lead to me what I thought was a UDI storefront. But I do see the quantum networks info now. in any case it's all confusing, and actually misleading, when it comes to the the mobilinc tie-in.

I just stumbled on ISY’s on Amazon. It’s awesome that ISY’s are Prime items! Thought I would point out something that might be confusing to a shopper not as familiar with UDI as I am. The very first most important thing listed in the “Features & Details” section makes it sound like you don’t get warranty if you buy this item thru Amazon. While I completely understand that Universal-Devices is the seller, and the warranty and support would apply, this statement appears to say if you buy through Amazon it’s not one of the official distributors therefore you’re screwed so don’t buy via amazon. Also why is this the very first point listed, shouldn’t it be last? Or does it need to be included at all? Or is Amazon a rouge distributor, and this statement is valid... lol. Another issue with the Amazon listing is that it prominently features MobiLinc without mentioning that it’s a 3rd party paid app while also failing to mention other 3rd party paid apps such as eKeypad. I probably read too many details, but I’ve written and proofed too many documents and details like these jump out at me. Just thought I’d point it out.

My pool literally has a toilet float. It's located under a pop-off cover that from the top (on the pool deck) looks like a skimmer cover, but pop it open and literally the inside is a Fluidmaster 400AHG toilet float valve. It's water source/fail-safe is a dedicated zone on the sprinkler system, we just set the pool to water from 6-8 at night, if it's full the float valve is closed. The problem is: if this wasn't plumbed in during construction, it still involves breaking concrete. It would be possible to plumb in to existing plumbing, away from poolside, but would have to be made to only fill when the pump is NOT running since it uses the principle that under rest water seeks it's own level.

Just a question/comment related to the forum, not the portal maintenance that was completed Friday. <Rant mode> Why are there 8 old portal maintenance notices "pinned" to the top of this section of the forum? I could understand why ONE would be pinned PRIOR to the announced maintenance, but I would expect it to get unpinned when it's no longer relevant. It also appears that there has been a "rule change" and no new portal maintenance announcements are pinned now. So again I ask why are the old announcements still pinned? As is, I can't imagine why portal maintenance announcements from 4/10/2016, 10/9/2016, 10/16/2016, 2/19/2017, 3/19/2017, 4/14/2017, 7/16/2017, and 9/10/2017 would be considered a relevant announcement that should be seen immediately by anyone visiting this section or board in the forum. If all 8 of these were to be Unpinned it would leave 3 pinned posts that are relevant for pinning and in fact make those 3 posts easier to find/see (less noise). Actually the whole forum/community suffers from pinning "noise" or "pin pollution" at the top of each section or board. Someone with the power to unpin should review every section. "As is" users will simply develop the habit of downward scrolling beyond the pinned thread without even "seeing" the pinned topics anymore. This completely invalidates pinning. Disclosure and additional comment: I used to work for a social media provider that provides hosted forums to many of the larger corporations worldwide that offer a forum. As a community specialist the advice we gave customers was to 1) be careful not to over-pin 2) be certain to "unpin" when no longer relevant 3) make certain that the first unpinned thread was "above the fold" (see note below), that is, the first normal user thread should always be visible "above the fold". Today, #3 is harder to deal with because there are so many screen sizes and screen resolutions possible. But the general idea still holds true: Keep pinned threads at a minimum and get the user directly to the content. ("Above the Fold" is a term borrowed from the newspaper industry. In the newspaper industry, "above the fold" refers to the upper half of the front page that shows when displayed on the newsstand. It's the meat that must grab the reader and "sell" the paper. In the web hosting/web application world "above the fold" refers to the portion of any page that appears after the page is loaded WITHOUT scrolling. A general rule of thumb is that the user should become engaged with the content without scrolling on most browsers.) </Rant mode>

that link to a relay with base is actually 99 cents with free shipping for me, at the moment. Shipping from China tho.

I may have the letters mixed up... Haven't touched that level of technology in years. The chips did have a window and were erased with UV. My college project that almost made me famous (not!) used apple ][ (also 6502 based) and a Novation modem which had the ability to decode DTMF. It answered a landline, then an external speech synthesizer said "Hello Please enter the codes". The correct hard coded 4 digit PIN, followed by 2 digit device, followed single digit command would control a light via X10! That was remote control at it's finest! You could control a light from anywhere in the world! (any location that had a touchtone landline phone anyway--many landlines were still rotary dial.)

I don't understand then. The 2635 device literally controls the fireplace. It is cycled with the 2 programs based on temperature. To manually control that with the app makes no sense to me. The point of the KPL buttons being lit is so that there is indication the fireplace is "on" (has the capability of cycling), turning off the scene via the KPL stops the temperature based cycling.

My first home automation controller back in the 80's, the Hypertek HomeBrain, used a 6502 processor. It literally evaluated "everything" in every loop of its operating system. It had a whopping 2k of RAM (the OS was indeed 'firmware'-- to update it required burning a new PROM--Not even EEPROM... the PROM the could be erased and reused just a few times by peeling a sticker off the chip and "dosing" it under UV light.) BUT hey... this modern marvel of the 80's spoke and listened to X10 (then called BSR) on the power lines!! Memory was very limited, as I recall there were a whopping 32 (or 64 for an upgraded model) memory locations (variables) available for program use. (I was a dealer at the time--we installed a whopping 5 units in 4 years, I still had 2 new in boxes until about 4 years ago.) Compared to what I once knew about how the HomeBrain OS worked, I know literally nothing about the ISY's OS, but I can't imagine it not using Event based processing where a change in value results in queuing. Anything else is a waste of processing power.

Right Click My Programs and pick Find/Replace. Change the first dropdown to Variable.

I also have a ridiculous number of integer variables because I decided to have two per wireless transmitter to count total transmissions and battery days. That was a nerd curiosity thing since open/close sensors don't send low battery-- i did it for the recessed door sensors tho too... (17 transmitters x 2 variables each = 34)

Curiosity... I added 55 state variables the other day for CAO gadget tags... My list is now just over 100... I'm actually going to drop 22 of those because I'll never use some of the functions and why have the tags update something i'l never use... and another 11 could fall into that category too.. it was worth setting up that way to start to understand and experiment. I wonder if I need to be conservative with variable creation, or don't care because I'll never run out.

Actually I never knew the real inside temp of any freezer in the house before this point. "Settings" on 3 of the 4 freezers consist of an arbitrary number.. the forth does have a digital control degrees is actually set. The temp sensors are all mounted "almost" suspended in air..that is they have a velco strip mounting, and they are all attached on the ceiling away from air vent flow. The icing occurs on the INSIDE of bags or containers that contain air... factory or food saver sealed vacuum packages (most of it) doesn't show icing inside. On the other hand, ziplock a steak, squeeze as much air out as possible and freeze it...it will ice crystal inside the bag in no time at all. I've never understood why until now. I've always been under the perception this was the coldest best deep freeze in the house. I'm now learning it's the opposite, wide temp delta's over short time and now that i've maxed out the control, it "averages" closer to zero than the manufactures "suggested" setting of "4" to achieve 0 degree's F. You did make me think though... moving the sensor around some to see other results... I don't really care about burried in a pile off packages, or a bag of sand) i'm sure that will be more consistent... i do want to find out of the 14 degree surface temp change is real tho.

Actually that sounds like how I had this visualized as working at one point. Then I kinda stumbled into how I did it, It actually works great, and i think for the most part is better with the added advantage of instant on/off from the KPL's and the fact that the scene would still work manually if the ISY is gone or not working). [i could always work around the issue if I was home, however a design consideration is always how the system could/might fail if I was out of town and my wife tried to turn on the fire, for example. Because the scene remains intact under my method it would still work if programs didn't.. a better situation than my wife reporting...THERE WAS NO WAY IN HELL TO MAKE THE FIRE COME ON LAST NIGHT...] The only part that doesn't work is changing scene status via mobilinc (or the admin console but I don't care about that).... I'm surprised there is not a if STATUS "scene"... or CONTROL via system/isy...

This freezer shows more what I would expect to see.... a 5 degree temperature variation over a slightly wider (per cycle) time period. (All that IS hard to digest because the graphs auto-scale... it's very difficult to compare graph A and graph B because the scales (may) change based on data.) in the FIRST example... the temp delta is almost 14 degree's over a shorter 45 minute cycle.. it really explains why icing occurs if there is ANY air in the package. The freezer is in an unfinished basement room, no direct sunlight..It full of dense food, but nowhere near packed to the point that air circulation is any sort of issue. I actually have 7 tags in refrigerators and freezers, all behave about as I would expect... Except the name brand (but I think on the low end of the product line) freezer that had a rebate from the power company for purchasing it...lol My son has a freezer in his garage... not only is it not healthy for it to sit in heat it creates more heat in the space.. it also doesn't help that the only time the coils ever get cleaned is if I notice them and just do it... I