larryllix

Heartbeats only come every 24 hours. You will just have to wait.

You could use an Insteon OnOffLinc plug-in with an ISY program that turns off the power each time it boots up and then turns it back on after a minute or so. Better yet there may be a way to monitor the Hue Hub and power cycle it when no response is had.

Ohh yeah... One thing I always do when I write a value to a State Variable that controls devices...I write a -1 value before the final value. That way no programs based on the State Variable will be triggered by the extraneous value, and it guarantees the programs that control the lighting/device will actually trigger. You could have some lights that you "borrowed' with the same value in the State Variable and writing the same value will not trigger the program to do it's job. The -1 value guarantees it triggers. Another note... if you have a bank of programs all based on a State Variable as a trigger. (eg. 0,1,2,3 = Off, low, med, high) cannot have any Else code or else they will trigger with other values. Sample programs If $sLampLevel = 3 Then set lamp to 100% Else --- <----- do not use ..... If $sLampLevel = 0 Then set Lamp Off Else --- <----- do not use Program Borrow Lamp If ----? Then set $LampLevel.saved = $sLampLevel set Lamp to xxx % Wait 5 minutes set $sLampLevel = -1 (I use a constant named $cMODE.RESET) <---- ensure it changes value to trigger set $sLampLevel = $LampLevel.saved Else ----

I control most of my major lighting with state variables. When I override their setting to "borrow" the light/s I copy the variable to another variable until I am done with the light and just copy the second variable back to the controlling state variable again.

I was smart enough to not think of my ISY as an Insteon Hub. I have occupancy light switches that are just as smart and cheaper. Strangely enough, I was the owner of two Insteon Hubs when I discovered ISY. After a few questions and answers from Michel, I sent the Hubs back to the vendor. Even my old software from the X10 days, back in the 1940s?, had, and used, variables.

Since I run most of my lighting groups off state variable triggers it became an easy task to clone those variables on IoP. When a variable changed value, instead of a program triggering on ISY, a program ran a NR that used the IoP's REST interface and cloned that value in a duplicate State variable on my IoP. On IoP all my programs were cloned and the same thing happened over there, instead of ISY. ISY's programs that responded to that same variable inside ISY, had to be disabled so that I didn't get duplicate commands going out. When I had problems with my IoP upgrade I just unplugged my IoP and enabled the lighting programs again on my ISY and I was back in 20 minutes. Yes it takes a bank of programs and variables for each scene or lighting control but they just get hidden in a folder that I never see again. It just works on it's own. Inside ISY you would never even know anything has changed. Fan speeds do exactly the same thing as well as colour variables for RGBCW bulbs and strips. One variable controls dozens of scenes containing different colours and brightness levels in each case.

Stop pointing your browser at the porn sites.

Again...variables are not constantly monitored, or even monitored at all. ISY is a trigger based / event based logic engine. If nothing happens at the source of a trigger, nothing needs to be processed. No routine cycling of checking variable values, no scanning tables...nothing. Just the OS switching tasks to monitor trigger inputs. Variables not changing values do not use CPU time. That is the nature of the political concept inside event triggered processing. Using program logic states as triggers for other programs is just a disaster waiting to happen. Millions of people study programming techniques in colleges and universities for years and using such a cryptic technique would get you a complete fail due to later confusion it will cause, inevitably. I have been programming since 1971 and learned the hard way too many times. I don't use cryptic techniques now. I am over the controllers that only have less than 500 bytes of RAM. ISY used these techniques when it was just a baby too. We are way past the Y2K and memory is cheap now.

All conditions are in the "If" section. Your power loss concept could apply to any program or program condition. What if the poer failed and came back on the next morning with any of these suggested programs? Yes the lights would stay on all the next day and night. This is why it is much safer, easier, and more reliable to use a variable to control things. You can write the current condition of the variable to the "init to" variable so it can recover from a power outage. You have also lost the condition ANDed with the Sunset trigger line. That was key to making the program logic work without any variable. Another suggestion is to stop counting programs. Sometimes more programs make the concepts easier to understand if proper labels for programs and variables, and comments are installed with some forethought.

'Save yourself a variable? A whole 5 bytes? I remember the early 70s, when that was more important than being able to read your own software two years later Sent from my SM-G781W using Tapatalk

Like connecting your RPi with PG2 on it until PG3 came into full operation or your foreign protocol Hub to it.

My wife keeps telling me that also!

Oh Gawd! I remember Kermit. Wasn't it one of the first that could continue after a comm interruption, like nothin' happened? I played text golf on the University computer (Honeybun) over my ear muffin modem. I can still hear the modem tones well enough to whistle them and confuse many FAX machines. People just love the garbage that comes out all over their pages.

Geesh. Mine came with a white sticker marking the port to use. IIRC the label has a personal signature of the polisy artist, Michel Kohanim hand written on the label. This will be a valuable collectors item some day. Sent from my SM-G781W using Tapatalk

Many of my earlier RPi devices presented two different MAC addresses for WiFi and Wired Ethernet. Therefore my routers could never assign the same IP address for the two different protocols from the same RPi.

When I have multiple logics affecting the same device cycle I find a control variable the simplest and most reliable method. With a variable once the variable flag is turned on and the scene is turned on it cannot be turned on any more and cannot be reset by other logical inputs. You could try this If From 6:00:00PM To 11:00:00PM (same day) Or From at Sunset - 30 minutes To 11:00:00PM (same day) AND Light status is Off <---- pick a major light out of scene Then Set 'Kitchen RGBW + puck' On Else Set 'Kitchen RGBW + puck' Off

That and the four tap phase identification method on AC based devices are two hidden goodies that SmartHome fell down on. Were they trying to hide it from their users or just insecure that China would continue to add those features in the firmware so they didn't document them? Who knows? Doh!

hmmmm...some of the tiny pamphlet docs mention that sequence, but not all. If 5 clicks doesn't make it update within a few seconds, try seven about as fast as you can click. I usually do to test the dark while holding it under my short and/or hand. It is good to setup the sensitivity setting also.

If you really need to have the box fill in, you can - wait until dark - put the unit in a dark closet and wait 5 minutes - open the back and click the link button 5 times in rapid sequence. IIRC some may take 7 clicks in rapid succession.

Accurate temperatures in the house. I use 0.3C deadlines on both my ecobee stats without any short cycling, just no huge waves of hot and cold. Short cycling usually refers to the off time between runs for an air conditioner. ecobee allows that to be set also. Sent from my SM-G781W using Tapatalk

My older Roku Stick supports the TV off via CEC but the newer Roku has no support for that and the TV power button sends iR only now. For some reason Roku has abandoned the CEC feature Sent from my SM-G781W using Tapatalk

You cannot modify settings/options in battery operated devices unless they are put into linking mode first. If you enable the remote settings DIP switch, the rest cease functioning. IIRC you can only set options in the main page for an Insteon MS. The ancilliary pages will not allow setting options.

Sounds like you have some interference with your comms happening. Possibly your new PLM is not good? Are you using the same PLM as your ISY994? Have you done factory reset and Restore on each device?

Do you have dual band Insteon devices nearby each battery operated device? Battery operated devices are RF only and not likely to communicate with your PLM directly.

If both devices support CEC / HDMI then it should work. My older Roku Stick turns off my TV but the newer units will not. IIRC: If the Roku remote has a TV power button on it then it controls the TV via iR only. If no power button for the TV then it will control the TV via CEC/HDMI. Roku support plays dumb about this, as usual.