larryllix

You may have missed his main query (Can we still say that?) . All variables get prefixed with an "$" by the system. It differentiates them from other elements such as programs and scene names.

The extra beep is left over from a previous special sale UDI held for beeps. Don't announce it too loudly or everybody will want it free also. You could get a bill.

Then split it into two programs. One to sense the trigger and one to decide which way to go (and disabled so it cannot retrigger) Living Room KPS8 Lights Scene 1 - [ID 002C][Parent 0034] If 'Living Room / LivingRm KPD8.c DinRm Scene 1' Control is Switched On <-------- Then run Program2 (if) Else ---- Living Room KPS8 Program 2 * * *[DISABLED]* * * If And 'Living Room / LivingRm KPD8.c DinRm Scene 1' Status is Off Then Set 'Dining Room / Dining Room Lights / LIFX Dinning Room Light 1' Hue 15400 Saturation 65535 Brightness 65535 Color Temp 3500° K in 0 ms Set 'Dining Room / Dining Room Lights / LIFX Dinning Room Light 2' Hue 45800 Saturation 65535 Brightness 65535 Color Temp 9000° K in 0 ms Set 'Living Room / Living Room Chandelier / LIFX Chand-1 Mini 519C71' Hue 15400 Saturation 65535 Brightness 65535 Color Temp 3500° K in 0 ms Set 'Living Room / Living Room Chandelier / LIFX Chand-2 Mini 3F2BB9' Hue 45800 Saturation 65535 Brightness 65535 Color Temp 9000° K in 0 ms Set 'Living Room / Living Room Chandelier / LIFX Chand-3 Mini 383074' Hue 15400 Saturation 65535 Brightness 65535 Color Temp 3500° K in 0 ms Set 'Living Room / Living Room Chandelier / LIFX Chand-4 Mini 3D8961' Hue 45800 Saturation 65535 Brightness 65535 Color Temp 9000° K in 0 ms Set 'Living Room / Living Room Chandelier / LIFX Chand-5 Mini 3D90ED' Hue 15400 Saturation 65535 Brightness 65535 Color Temp 3500° K in 0 ms Set 'Dining Room / Dining Room Lights / Dining Room Lights' On Set 'Living Room / Living Room Chandelier / LivingRm Chandelier' On Else Set 'Dining Room / Dining Room Lights / Dining Room Lights' Off Set 'Living Room / Living Room Chandelier / LivingRm Chandelier' Off

Try. ths one. It used to work based on the order that ISY checks status vs triggers from devices. However if you are playing with a KPL they send out a toggled status regardless of which format you have them set at, or actual last real status position. A little known bug in Insteon's logic at the time. I can't remember the exact problem but Michel discussed this with me a few years ago on KPLs Living Room KPS8 Lights Scene 1 - [ID 002C][Parent 0034] If 'Living Room / LivingRm KPD8.c DinRm Scene 1' Control is Switched On <-------- And 'Living Room / LivingRm KPD8.c DinRm Scene 1' Status is Off <---------- Then Set 'Dining Room / Dining Room Lights / LIFX Dinning Room Light 1' Hue 15400 Saturation 65535 Brightness 65535 Color Temp 3500° K in 0 ms Set 'Dining Room / Dining Room Lights / LIFX Dinning Room Light 2' Hue 45800 Saturation 65535 Brightness 65535 Color Temp 9000° K in 0 ms Set 'Living Room / Living Room Chandelier / LIFX Chand-1 Mini 519C71' Hue 15400 Saturation 65535 Brightness 65535 Color Temp 3500° K in 0 ms Set 'Living Room / Living Room Chandelier / LIFX Chand-2 Mini 3F2BB9' Hue 45800 Saturation 65535 Brightness 65535 Color Temp 9000° K in 0 ms Set 'Living Room / Living Room Chandelier / LIFX Chand-3 Mini 383074' Hue 15400 Saturation 65535 Brightness 65535 Color Temp 3500° K in 0 ms Set 'Living Room / Living Room Chandelier / LIFX Chand-4 Mini 3D8961' Hue 45800 Saturation 65535 Brightness 65535 Color Temp 9000° K in 0 ms Set 'Living Room / Living Room Chandelier / LIFX Chand-5 Mini 3D90ED' Hue 15400 Saturation 65535 Brightness 65535 Color Temp 3500° K in 0 ms Set 'Dining Room / Dining Room Lights / Dining Room Lights' On Set 'Living Room / Living Room Chandelier / LivingRm Chandelier' On Else Set 'Dining Room / Dining Room Lights / Dining Room Lights' Off Set 'Living Room / Living Room Chandelier / LivingRm Chandelier' Off

Usually a router has a table of connected devices. There may be a separate one for hardwired devices too or they may be all in one. In that table typically you would find each device's MAC address and it's IP address in another column. Sometimes a router "loans out" an IP address for a limited time and if that has expired the device may not appear in the table. You may need to have ISY send /receive/ or reboot to make it's position re-appear in the router device table. Router responses may be really slow also. Sometimes it takes minute for a router to update these table for the user. You are low priority to a router.

The Isteon MS II has inherent logic problems/bugs in it's timer algorithms. Hopefully the New Insteon fixes these problems before re-releasing the same defective product. Home automation needs a good MS device. Most automation relies on sensors and an MS is a main player in that field.

...and 5Ghz is typically the last protocol fired-up when routers are rebooted.

The disable only disables the triggers from the IF section. However the conditions still work, selecting Then or Else to run, if the program (IF) is called as a subroutine from another program or manually from the menus. I like to comment the IF section with "Disabled" as when some updates are done the Enable/Disable status has often been lost and you have to recereate and analyse the whole set of programs to figure out if the program should be disabled or not. Document...document...document. ISY has various commenting styles built in for different program sections.

No actual experience with that comparison but I use hard connected Ethernet to my router to operate most of the lighting in my apartment. These are mostly WiFi lighting, but I wouldn't want any WiFi competition between HA devices and other I feel it should make my HA control over devices more secure. However I do share my WiFi with two 4K streaming TVs and a VR headset that connects at 1200 Mbps, all using WiFi 6, which is miles ahead of WiFi 5 for arbitrating bandwidth between devices. IOW: I would think it would be a close call between the two and very router quality dependent.

Sure but the "scene" method in ISY cannot do simultaneous sends from different devices without causing an annoying popcorn effect. The scene capability must be built into the protocol so that multiple devices can act on the same command as ISY has never supported fast comms to multiple devices, as far as I have ever seen so far. I have theorised on many ways to create scene groups inside a NS and have ISY able to set them up using list of devices, perhaps on boot up. Unable to handle any text messages the numbers game gets too complex for most users to use. With my method a constant variable definition must be created for each device but groups can be created and operated on the fly inside ISY programs with no previous scene/group definitions.

That question and bug has been put forward to UDI for the last 6 years and has never been addressed, other that ...it doesn't work. I have attempted to send various packet formulations but none are successful 100% of the time. ISY has no support for the response anyway.

AFAICT, nobody has discovered a way to make a Node Sever that can operate a group of devices to appear to operate simultaneously. In the past I tried a MagicHome node server and the best time between device operations was one second without mostly failures. Even using NRs, since UDI has never fixed the variable usage method, at least a 1 second wait must be interjected between any two usages of any NR using variable substitution. With NRbridge I can pass a list of devices in any command and it preps them all before operating them all to appear simultaneously. I don't know of any way to incorporate that into a node server.

If you are using python3 here are the main routines that send my heartbeat. # Main loop while(True): # Check for incoming command httpd.timeout = 5.0 httpd.handle_request() # ISY heartbeat signal if time.time() >= ISY_HBlast_sent + ISY_HBperiod: if heartbeat != 1: heartbeat = 1 else: heartbeat = -1 write_ISY(heartbeat) ISY_HBlast_sent = time.time() def write_ISY(data): ISY_rest = "/rest/vars/set/%s/%s/%s" % (ISY_HBpage, ISY_HBaddr, data) get_url = urllib.request.Request('http://' + ISY_IP + ISY_rest) #format the URL ISY_authorise = base64.b64encode((ISY_username+":"+ISY_password).encode('utf-8')) #encode it get_url.add_header("Authorization", 'Basic %s' % ISY_authorise.decode('utf-8')) try: r = urllib.request.urlopen(get_url) time.sleep(0.001) # allow I/O time slice returned = r.read() r.close() time.sleep(0.001) # allow I/O time slice except: logging.error("NRBridge: ISY heartbeat send failed!***") return

Write another thread in your remote device to set variables for responses. I have one dedicated to a "heartbeat" that tells me if the remote software is alive. A few more variables are used to indicate status when requested. The REST protocol can work both ways.

95% of my lights run off of Network resources using the same technique you mentioned. Each command uses the REST format to talk to (formerly a RPi) another process, running on my polisy, co-resident with IoX using "localhost:XXXX" commands in REST format. At the NRbridge end I parse the commands into separate parameters and operated various routines to operate the light bulbs. I use the MagicHome/LEDenet protocol to control the lights. My REST commands include On, Off, SetLevels, Effects, and Status (returns status of any bulb or group of bulbs). My last update now includes up to ten bulbs in any command so that those bulbs appear to operate simultaneously. ISY controls which bulbs in the group on the fly so there is no predefined groups/scenes, only dynamic ones. The responses are not meningful from NR responses. However my status request command can set variables from any device levels and I have found ISY never interprets the responses properly from NRs.

...but then the boards all smell of COVID spray. Wait! Windows in the containers or Windows installed on the boards?

Well done! I bring the warm white and cool white colours into play with mine. Since I use all WiFi lighting I use no Insteon scenes, only my own software written scenes. I have also found with small increments I can dim groups of lights at different times so the dimming is not very noticeable> As a side note when I first created my first method based on the system number of minutes left in each day until midnight, I noticed an expected but unexpected phenomenon. Before my dimming programs and during the pandemic, I, and my wife and S-I-L were frequenting bed about midnight to 1:30 AM. After running the programs for a few months 10-11 PM became a very common time for bedtime. The colour changes and gradual dimming did seem to modify our circadian rhythms.

How do you like them Apple's?

I had always thought GH supported the same style of things as Alexa. I have four GH boxes in a box somewhere. I found Google's attempt at so-called AI a detriment to HA controls with it's assumptions operating things I didn't want operated, so I focused on all Alexa speakers. Of course, things may have changed as GH realised the error of some of their ways.

There is no need for this program but is simplifies the programs that use it. I reserved about 20 variables for vocal outputs and a program to reset them all. I never have to use three lines per program anymore, making them easier to read and understand after that. Better programming practices mostly means easier to read and understand programs for any later corrections or edits. It's aso about centralisation of functions instead of scrambled all over the place and hard to find later. If the timing requirement ever changes, one simple change will do it all.

Just as a matter of interest...I have created a program that resets all my state variables used to trigger routines in my alexa speakers. It looks like this... Program ResetSayVars (Enabled to Run at Startup] if $sSayVVVVV is not 0 OR $sSayWWWW is not 0 OR $sSayXXXXX is not 0 OR $sSayYYYYY is not 0 Then Wait 3 seconds $sSayVVVVVVV = 0 $sSayWWWWWW = 0 $sSayXXXXXXX = 0 $sSayYYYYYYY = 0 Else ----- Now when a program uses a $sSay variable the wait and reset to 0 is done automatically to reduce line usage in every programmed usage of vocals. This simplifies the number of lines and look of many programs and makes them easier to read. Of course I have a bank of about 20 State variables (with more meaningful variable names) reserved for this usage and the program involves every one in the If and Then sections of this program. BTW: Alexa routines do not like to be hit on faster than every 20 seconds so programs that operate vocals too fast may get skipped over.

In addition to @kclenden's post above....Just select "send On only" inside the MS and then two programs are not needed.

Black electrical tape..or white vinyl tape if it shows Sent from my SM-G781W using Tapatalk

Possibly broken cable wiring inside the PSU cable at the connector from previous snags on it, or just a messed up connector contact inside the polisy. Try bending the cable multiple directions, at the connector (each end?) to see if you can cause it to happen.

You mean all my devices I purchased back in 2013 are going to be a problem some day? Your first post it sounded like you said your system never gave you any problems and now you say they did. That sounded like a contradiction but we must have misunderstood those comments. The only Insteon device problem I have had in 10 years were devices that were sent out of the factory with defects. However I have one LampLinc, removed, stored in a box that the plastic case split five different ways. Never checked the manu. date though. I have had a synchroLinc that went dead. Likely a poor electrical design that couldn't handle the motor load. I still have about 50 more devices that I removed when I moved last year, working until I stored them in a box. About half were purchased before 2015 and had no RF protocol.