larryllix

That may be, but I believe it would violate the rest of the style of operation of ISY trigger logic. IMHO Consistency of trigger logic would be most important. It can get complex enough for users already. Perhaps the status vs switched logic could be applied giving users a choice. I try to avoid using the status of other programs. I find it obscure and a gotcha down the road. Sent from my SM-G781W using Tapatalk

hmmmm.. that could be LAN switch problem. IIRC Switches determine which device (IP) requests a response and only passes the packets through to the device that wants it. This would be opposed to a LAN hub that just broadcasts everything to everybody and it is up the the receiving card to only listen to it's own packets. Maybe some LAN guru knows more about whether WoL can even function through a switch. OTOH my isy was on the other side of a switch from my TVs and other devices I was turning on using WoL, just fine.

@Michel KohanimThis needs to be reported as a bug. The same thing happened during one of the version upgrades where the variables would trigger programs when the same value was written to them. (from REST commands anyway IIRC) It was corrected immediately after reporting. ISY processing logic is based on triggers of changes only for most logic.

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.