MrBill

I just played with this: Created a state variable name "lamp.timer" via the portal added a spoke "lamp timer" (i used the default type of 'scene') (default 'off' value: 0) (default 'On' value: 23) "Alexa, Discover devices" "Alexa, Set lamp timer to 70" -- as expected the value of the variable changed to 70. "Alexa, turn on lamp timer" -- as expected the value of the variable changed to 23. "alexa, turn off lamp timer" -- as expected the value of the vaiable became zero. so @larryllix you're correct the timer can be created in this manner. the only caveat is with the default type "scene" the value can only be set 0 to 100.. I'm not sure if any of the other "types" (portal) would expand the value that can be set. if lamp.timer > 0 then Wait 1 min lamp.timer -= 1 else <whatever happens when the time runs out>

The word off might be getting in your way. We use this routinely with lamps where the meaning of the variable actually is a percent but we don't say the word percent when we talk to her. "Alexa, set lamp one to 50" works just fine.

There is a "find". Right click the "My Programs" folder. Does that help?

have you restarted or upgraded your ISY today?

I've been on v5.0.16C since 3days after it's release. My ISY was last restarted a week ago exactly, I just looked it was literally this time of day last Sunday.

Correct. my isy is connected to the portal and alexa is working as well. my isy has not been restarted today.

except my portal connection works fine. my isy wasn't rebooted today, someone else said the same in another thread. The pattern or common denominator seems to be restarted isy's aren't reconnecting. perhaps an undesired maintenance issue. Commenting this so that we can consciously group analyze this theory which might save time identifying the issue if it's true.

I probably should have made the above post in this thread instead. my theory is ISY's that have been restarted can't re-connect to the portal, but if the ISY was already connected before this morning it stayed connected.

This isn't scientific but I've been reading posts in several threads, the general summary might be that if your isy was connected to the portal before this morning there is no problem, but if the ISY was restarted (which is the last stepup of upgrade) the connection to portal can't be re-established. That's my guess, but most of the people that have stated problems it seems the common theme is "isy restarted" and "portal/alexa offline".

I just remembered there was a scheduled maintenance earlier this morning. ((Note the date in the title doesn't match the date in Friday's post.))

I just logged into the portal and accessed my ISY and turned the light next to me off and on. I had Alexa do the same thing. All working fine for me.

I remembered 160 characters as an SMS limit from a long time ago. Apparently Verizon truncates from what OP suggests. I was confused when the question was about AT&T because last time I ran experiments between @txt and @mms on AT&T it didn't truncate, but it did break long messages up into short 160 character blocks and deliver them all, sometimes out of order, Verizon apparently accepts 160 chars and truncates. However the link I included above suggests the @vzwpix.com address accepts text to 1000 characters.

i don't know anything about verizon's gateway, but i did google and found this page. From the info here it seems @vtext.com has a limit of 160 char. It seems the verizon equivelent to @mms.att.net might be to use @vzwpix.com (also found on the same page).

if you are using [10digit]@txt.att.net to send the text messages switch to [10digit]@mms.att.net and that should solve your problem. The first addesss is limited length text messages. Also the @txt version arrives from weird numbers, the @mms version will arrive from the email address that sent.

I'd try moving to a few minutes after sunrise or sunset for that program. I'm not familiar with your ballast dimmer but its probably not a dual band device. I have one older device that doesn't work correctly if there is a lot of other traffic at the time it's supposed to turn on or off, on the other hand if i just delay it a bit it works fine.

It’s a white box 7 5/8” wide x 7 1/4” deep X 3 1/8” tall. (Although white it’s not a USPS issued box.)

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.