larryllix

Interesting! However too small to read and browser magnification doesn't change video text size.

Maybe post your program here so that others can have a look at your logic. BTW: If Sunset would leave your program icon green after it ran the first time, until another logic triggered it False and turned it red. I am not sure what you are basing your deduction on.

As per @kzboray above. Open a ticket with UDI. I had the same problem a few years ago and it was just one module that didn't load properly. Michel sorted it out in a few minutes over the Internet.

Have you installed the IP address for your Eisy in you router's DHCP reservation table? This appears similar to what happens when two devices try to occupy the same IP address. Usually a power cycle of the router fixes that temporarily.

As per @IndyMike above, your If section is getting re-evaluated and running Else, which will stop the Then section from completing. Remove the time frame and make it a single time so it only can evaluate once per day, and not re-evaluate. There is no hysteresis in your temperature evaluation and the logic can bobble True/False quicky inside your five minute window. If 'WeatherLink / WeatherLink' Temperature > 97.0°F And At 2:45:00PM

@Chris Jahn

Been a long time now but the KPL buttons have modes. Toggle, send On, or send Off. For toggle, I think you can get a status update, but for send On/Off IIRC the status is bogus and toggles except it makes no sense so you just use "switched on" or "switched off" LEDs can be scene connected to the buttons but I never used that method as ISY could operate the lights for status feedback to the button pusher.

Here are the key press sequence capture programs from my old ISY. ----------------------------------------------------------------------------------- Arm Keypad Combo - [ID 00AA][Parent 00AC] If $sKey.sequence is $cARM.COMBO Then Run Program 'Armed Mode Toggle' (If) Wait 2 seconds $sKey.sequence = 0 Else Wait 3 seconds $sKey.sequence = 0 ----------------------------------------------------------------------------------- Key.A - [ID 005B][Parent 00AC] If 'Mudroom / MudRm Potlights / MudRm KeyPad.A' is switched On Then $sKey.sequence *= 10 $sKey.sequence += 1 Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Key.B - [ID 00A7][Parent 00AC] If 'Mudroom / MudRm Potlights / MudRm KeyPad.B' is switched On Then $sKey.sequence *= 10 $sKey.sequence += 2 Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Key.C - [ID 00A8][Parent 00AC] If 'Mudroom / MudRm Potlights / MudRm KeyPad.C' is switched On Then $sKey.sequence *= 10 $sKey.sequence += 3 Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- Key.D - [ID 00A9][Parent 00AC] If 'Mudroom / MudRm Potlights / MudRm KeyPad.D' is switched On Then $sKey.sequence *= 10 $sKey.sequence += 4 Else - No Actions - (To add one, press 'Action')

I just used ISY program IF section pulldown menus to select trigger commands from the KPL like any other Insteon device.

My KPL transmitted device On/Off commands. I never used scene commands for it. I used them with a program that accepted 4 key combinations of keypresses to reset my basement flood, laundry room, and utility room water sensing programs, and devices, allowing the dishwasher, laundry washing machine, and main well pump to be re-enabled. The text messages transmitted with wet detection gave instructions what to check, and each combination key codes to reset each zone. I only used the On commands sent and had Off command disabled. AFAIK All Insteon devices transmit device command codes. Not all Insteon devices transmit Insteon Scene commands.

Are they both still freeBSD O/S?

Agreed. See you again in another years when somebody raises the need again.

Yeah I got it working eventually. However, that technique does not indicate the status of a scene. It only indicates the last scene command scene command sent out from ISY for the scene it is embedded into. Changing any component device inside the scene via another scene command or device control does not affect it's status despite the scene's resultant statuses not being true anymore. Again, people are attempting to assign a status to a trigger signal. It isn't really possible as they are different types of Insteon elements and not relatable to each other.

I saw no definitions or instructions to add any keys or values to it. That may be the problem??

The noise is created by your system crashing Insteon packets. This is a known problem for Insteon RF devices that have no power line synchronisations and no proper system listening capabilities. When Insteon RF devices transmit, they repeat their messages several times to ensure they get through more reliably. If another device transmits another signal immediately it cna cause a signal clash. This would be common with MS -+--rf---->PLM-->ISY program--->PLM----wiring--+-->Insteon hop------??--> !----------------------repeat-----------------------------^

I don't consider a state variable used for conversion into a pseudodevice as useful in an Insteon Scene. I find no way to incorporate these variables, or the pseudodevices the ISY Portal converts them into, even seen inside ISY at this point. Maybe I missed something there? However, it was mentioned about the Virtual device PG3 node server, that appears to be able to perform as a pseudodevices inside ISY, can be inserted into an Insteon Scene, and has intrigued me. I have installed the Virtual node server into my PG3 and it shows up inside ISY via IoX, but I cannot get it to perform anything except read one parameter that is permanently set to "True". I can drop it into an Insteon Scene and it appears as a valid device but never changes to show anything except "True", whatever parameter that is supposed to represent.

I am confused. Your original post showed it basically correct. Your program was sunset+30 minutes. Now you are complaining about sunset-30 minutes and it not operating today? I offered an explanation for the 2 minute calc error but now you are saying it didn't operate one evening but it did the next it did? Perhaps listen to some of the experienced helpers here, that have given advise, think about it, and respond to them. i see no problems except your story appears to be changing about what the problem is.

It may have been slow to come (as most UDI improvements) but the pseudodevice was an improvement made by UDI after much discussion over the years. Perhaps they just don't brag enough when they produce updates? However, it still doesn't solve all the scene monitoring possibilities that I can foresee. Now you have me interested to experiment with the technique (now that I am aware of it). I do not use many Insteon Scenes anymore, now that my lighting is almost all WiFi, ISY programs, and three MS IIs with buggy firmware in them.

I am not sure either of these techniques will work for many situations though. If I add a spare device or a pseudo device to a scene and turn it on, and then rest the level of one (or more) device(s) with another scene with the monitoring techniques actually see the original scene is not in effect anymore? With the spare Insteon device, I know it will into indicate properly, but with the pseudo device inside ISY, who knows how many smarts they put into it?

Sunset and sunrise change by about 2 minutes every day of the year except peak winter and peak summer.

Does this "virtual" respond to external devices initiating a scene, say from a Switchlinc dimmer button press? That was always one of the problems with attempting to detect the status of a current Insteon scene. Perhaps another Switchlinc sends out a different Insteon scene command that modifies one of the devices to a different level? I believe these reasons may be why a status flag has never been successful to detect whether a scene is still intact. They are not binary statuses with just True and False....sort of.

One thing I discovered is that Insteon scenes do not get ACKs back to the PLM and therefore EISY does not log them so there is nothing to see. This was always a problem for the phantom All On, as it seemed to just be another predefined scene. I conclude phantom scenes being turned on are noise created in the Insteon system, somewhere between RF devices, the PLM, and ISY's low level drivers, somewhere.

I had about 10 units at one time and there were so many different versions of HBs.

IIRC the button in the leak sensor toggles the wet/dry signal for a quick test. However IIRC the HB goes on a separate channel. Paul's restore should work. If not, factory reset the LS and then do a restore. Make sure your monitor programs include HB ON, ORed with HB OFF. Some versions put out both signals but only every alternate day for each.

Try doing a restore on the device in IoX. Devices can use multiple channels and sometimes a link or two gets messed up or forgotten. Sent from my SM-S711W using Tapatalk