larryllix

...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.

With such a sudden failure of so many electrical devices I think somebody needs to inspect his electrical system for noise problems, and/or high voltage, etc.. You may be playing the same tune shortly again, no matter what system you install.

Check out CAO Wireless Sensors. We have a NS for wireless Tags. They are cheap, very accurate and have versions with wired sensors. Of course you will have to change the CR2032 battery every 8-12 months.

As the simplest explanation without any background if you are turning on KPL LEDs make sure to put a short Wait just before each command. If you have Insteon MSes insert a Wait 1 second before commanding anything else after detecting motion in your programs Sent from my SM-G781W using Tapatalk

This was thought to be a clash of two or more signals and then some Insteon device decodes it as an All On signal and starts echoing it around your system. This was thought to be common in devices like the multibutton wall switches where there were many nodes inside one device that all use the same Insteon ID. For example: when a signal is received from a push button, ISY could immediately set the LED for that button on as an indicator of state. This should have a Wait 1-2 seconds before activating the LED. This situation can be aggravated by battery operated wireless Insteon devices that do not follow the power line protocols to avoid signal clashes. They have no way to detect the signal clash and in order to ensure success of transmission, repeat their commands several times. While the signal is being echoed by Insteon devices, your ISY device can start sending response signals simultaneously. It was never known or revealed exactly why this was happening or from where but the work-around seemed to be, not to fire signals immediately after a wireless device sent out a signal. This ALL ON signal appears to be an Insteon Scene style signal whereas no responses are ever sent so that ISY can detect any status change. This is according to Insteon protocol definitions. I had one OnOffLinc plug-in device drive me crazy with random Ons and partial Ons (dims) for about a year. One occurrence I recognised the a pattern of lights as a scene that I had programmed and found the logs showing the device in question not responding with an ACK signal when it was commanded on or off. A simple unplugging the device and plugging it back i solved that problem and it never returned for many years now. Remember these devices contain a CPU running firmware and can run amuck, just like any other computer.

Your nickname in your router is not used by the Finder. Many do not even name their devices in their routers for it to work. Sent from my SM-G781W using Tapatalk

I see @Michel Kohanimhas been hard at work to make the wiki a much better resource over the last years. There is actually many directory links now. 👍 BTW: I never noticed a link the the Launcher until I copied the text to my post. Then it was underlined and an apparent color. Going back I see they use a very small icon symbol beside the link but the color scheme on a dimmed LCD screen is just not apparent. I attempted to brighten the link color but it just isn't apparent. (ooops...I guess there is another def. for a used link, also)