larryllix

WoL needs to be on the same subnetwork as the ip address is xx.yy.zz.255 for any device. The MAC address us what is particular. With or eithout a bridge between subnets I doubt it will ever work. Sent from my SM-G781W using Tapatalk

The nomenclature must match the positive logic and then anything is possible and good.. Many times people label things with generic labels...like "BattStat" which does not indicate either state as logic True.

I don;t know why any device that supports echoing it's own protocol cannot monitor that same protocol signal for a group device code that it belongs to. Scenes and instant group responses, without any popcorn effect, should be a natural built-in feature of any device used in a esh protocol. I can;t help but wonder this is planned as Zwave Ultra that will cause all the Zwave followers to (again) buy all new devices and dump their old devices in 2023. Marketing plan?

Nobody said it won't be free...yet. But I would have thought WoL would have been just transferred to polisy as a native piece of internal code. However, I have learned to trust UDI to do the "better thing" for ISY in the end. Having some sidetrack piece of code for the data stream, may be of some detriment to IoP's internal logic engine and better placed into a sideline stream monitor like a PG3 NS. My guess is that the majority of user never use it or even know what it does. Now we need a SoL (sleep on LAN) function to turn things off. I read in a few blogs now, about reversing the MAC address and sending it. Yeah right.

Almost all smart TVs, receivers, BlueRay Players and Ethernet smart A/V devices accept WoL without authentication. The Packet is secure enough I guess. ISY994 had a place to insert security. I never had to use authentication on my 6 devices I used WoL/ISY with. I have never needed WoL for a thermostat, mobile cell phone, or iPad yet but I would bet they accept it when needed also.

What protocol are you using? HTTPS:// or HTTP:// What port address are you using?

WoL could be implemented as an option under the NR, if the protocol option was in the pulldowns. I'll be sticking with ISY until then I guess.

@Michel Kohanim Two things I am waiting for before returning to IoP. WoL still doesn't function on any of three devices tested. Sony SoundBar, Samsung 75" TV, Samsung 55" TV. These all worked well on ISY994 V.4.x but never on IoP. -------------------------------------------------- Modulus function gives erroneous results yet. Decimal values do not function at all. Some Integer values function. 13 %= 12 = 1 13 %= 12 = 4.000 13.000 %= 12 = 4.000 26 %= 12 = 2 26 %= 12 = 8.000 26.000 %= 12 = 8.000 28 %= 12 = 4 28 %= 12 = 4.000 28.000 %= 12 = 4.000 29 %= 12 = 5 29 %= 12 = 8.000 29.000 %= 12 = 8.000 Close, but no cigar, yet! More work on decimal precision needed still. (factor of 4.000 seems consistent??) Thanks!!

Moved to here

Ewww. I had to have Michel fix mine when it was doing that. IIRC it had to do with udx not running as it issues the ID to ISY software.

I guess I am not understanding this "flashed the disk". Is this a hardware change (SSD size upgrade) or is there some "firm" method that limits the sectoring size and limits the size of access?

Geeesh. [admin@polisy ~]$ df -h Filesystem Size Used Avail Capacity Mounted on zudi/ROOT/default 4.6G 2.6G 2.0G 57% / devfs 1.0K 1.0K 0B 100% /dev procfs 4.0K 4.0K 0B 100% /proc zudi/tmp 2.0G 26K 2.0G 0% /tmp zudi/var/crash 2.0G 23K 2.0G 0% /var/crash zudi/usr/home 2.0G 5.1M 2.0G 0% /usr/home zudi/var/empty 2.0G 23K 2.0G 0% /var/empty zudi 2.0G 23K 2.0G 0% /zudi zudi/var/log 2.0G 541K 2.0G 0% /var/log zudi/var/polyglot 2.0G 54M 2.0G 3% /var/polyglot zudi/var/db 2.5G 521M 2.0G 20% /var/db zudi/var/run 2.0G 53K 2.0G 0% /var/run zudi/var/tmp 2.0G 25K 2.0G 0% /var/tmp zudi/var/db/pkg 2.0G 12M 2.0G 1% /var/db/pkg [admin@polisy ~]$

When you first install node servers they are unmanaged due to not connecting to the end devices. Once those parameters are setup and connected the NS will install the nodes into your IoP.

Saturday is usually Michel's day of the week off. Expect more action on Sunday, usually.

Have you tried using a variable counter to prove it isn't your notification comm technique? Sent from my SM-G781W using Tapatalk

I know my MS Is will not work on LioN batteries. The 9V style Lion batteries put out 10.4 volts and the MS will either burn out, or constantly send lowBatt signals with a voltage that high. Since LioN cells only put out multiples of 1.7 volts you take you pick, high or low voltage.

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.