Xathros

Thanks Benoit. The URL for both of my ISYs changed sometime in the last 2 weeks. This was the second time I noticed since the URL changed from the uuids. I will be happy if it stays static from here on out. Any thoughts about preventing the "/" in the hash string? -Xathros Sent from my iPhone using Tapatalk

Thanks Michel. -Xathros

Hello Michel- I noticed once again that the portal URLs have changed for both of my ISY's. I had to remove the finder entries and recreate them using the new URLs. In addition, I had to update the network resources that use the portal URLs to control the other ISY. After update they are now erroring again with HTTP 423 (Locked). Last time this was because I needed to unencode the portal URL before using it in the network resource. This time I'm working with the un-encoded URL and still can't seem to get past the 423s. I thought the portal URLs were going to remain static? I will continue to poke at the resources to see if I can't find my problem. -Xathros EDIT: Solved the 423s again. Two issues here. First when I replaced the portal URL with the unencoded portal IURL, I forgot to unencode the device addresses. Then I checked Encode URL which double encoded thed device address portion. Second problem is that my unencoded URL contains 2 "/" characters that the ISY will not encode since it seems to think that they denote a path delimiter. Had to go back to using the pre-encoded URL and manually encoding the device addresses. Not sure if this can be solved. Only way I see would be to prevent the "/" character from being used in a portal URL token.

I suspect a program got inadvertently/unintentionally changed to cause this hence the search since otherwise you would likely know where to look! -Xathros

OK - Do a search with the find in the program tree for the KPL in question and look for any program that uses the notation I provided above to set the backlights on that KPL. -Xathros

I have a program that runs twice daily to enable/disable my KPL backlights in the bedrooms. Don't like the light at night. I would think you would be able to recover from this with a program like: ComeOnBabyLightMyKPL - [ID 0009][Parent 0001] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Set 'Office / Office KPL / Office KPLA' On 15 / Off 7 (Backlight Level) Else Set 'Office / Office KPL / Office KPLA' On 2 / Off 0 (Backlight Level) Just RunThen to light it up or RunElse to go dark. -Xathros

Excellent news! Looking forward to seeing how this all works! -Xathros

In my opinion, "Izzy" would be much better in term if ease of use. -Xathros Sent from my iPhone using Tapatalk

UDI has written an Alexa skill and submitted it to Amazon for approval. No idea how long this process takes. In addition, there is a community project that already has Echo working with the ISY but it requires another machine in the middle like a Raspberry Pi or full time PC. See this long thread for details:http://forum.universal-devices.com/topic/14525-amazon-echo-and-isy/ -Xathros

Between devices, 1 sec should do. After a scene with many devices in it, 3-5 seconds might be better. I usually go with 1-2 between resource calls. Network resource calls can and do queue up if things are busy. If doing variable substitution within the resource, it is possible to call a resource and have the variable change downstream in the programs before the resource is substituted and sent. Where this is possible, you may want a longer delay. Just beware. -Xathros

Shouldn't need a delay between variable changes unless they will drive insteon activity in other programs when changed. I find it to be a good idea to delay between scene and device actions to allow time for ack/cleanup messages to happen before generating more traffic. -Xathros

Mil- As Stu said, set the buttons to 'Non-Toggle ON' mode. Create scenes as follows: FanLow: Button B - Controller - On level 100% Button C - Responder - On Level 0% Button D - Responder - On level 0% Button E - Responder - On Level 0% FanLinc - Responder - Fan Low FanMed: Button B - Responder - On level 0% Button C - Controller - On Level 100% Button D - Responder - On level 0% Button E - Responder - On Level 0% FanLinc - Responder - Fan Med FanHi: Button B - Responder - On level 0% Button C - Responder - On Level 0% Button D - Controller - On level 100% Button E - Responder - On Level 0% FanLinc - Responder - Fan High FanOff: Button B - Responder - On level 0% Button C - Responder - On Level 0% Button D - Responder - On level 0% Button E - Controller - On Level 0% This makes the Off button go dark after turning off the fan. FanLinc - Responder - Fan Off If you prefer to use only 3 buttons, you can eliminate the FanOff scene and keep all of the buttons in toggle mode. Hope this helps. -Xathros

In addition, I don't believe the portal is a requirement for 5.x but rather an add-on feature like the other add-on modules. -Xathros

I do exactly what the OP is asking for and it can be done with FastOff and/or Off. In my MBR the SLD at the entry has the ceiling light as the load. On turns on that load only. Fast On of course turns on that load but also triggers a program that brings up the rest of the lighting in the room via a scene. Same with Fast Off. In addition, i have my program watch of On when On or Off when Off to trigger the same scene actions using code like this: Program: MBR_Ceiling_SLD_off.pgm If Control 'MBR_Ceiling_SLD.dev' is switched FastOff or ( Status 'MBR_Ceiling_SLD.dev' is Off And Control 'MBR_Ceiling_SLD.dev' is Off) Then Set Scene 'MBR_All.scn' Off Else This works with either a FastOff (Double Tap Off) or an off when the SLD is already off (2 single tap offs). Hope this helps. -Xathros

Ok. So there is a beacon test running on its own. Next step is to id the sender. Since the sender also blinks during the test, it must be one of the blinking devices. Unplug or air gap them one at a time with at least 5 seconds in between till you find the sender. -Xathros Sent from my iPhone using Tapatalk

Stu- Do you have any older Access Points? I have had 2 develop bad PSU's and do odd things on their way out. Maybe you have one performing a beacon test as it's death dance. -Xathros

On ALL of my devices, the beacon test flashes the Set Button LED not the Button or Paddle LEDs. Has something changed in a newer firmware? -Xathros

@larryllix- You know, now that you mention it, My blink on TX is more like you described than what Stu's video is showing. Stu's does look like the blink pattern when in linking mode or beacon test (500ms on / 500ms off) except for the fact that it's the wrong LED's blinking. Its obviously a programmatic blinking from within the Insteon devices themselves which makes me suspect it's a feature. I saw another discussion here recently that indicated a difference between "Blink on TX" and "Blink on Activity". To me Blink on TX means blink when this device transmits. That however is not what this option does on my switchlincs. Instead, they blink on any Insteon activity. I wonder if some devices have a different blink on Activity feature that blink as Stu's do. @stusviews - Can you shoot another video of the same set of devices when they are not actively pulsating and operate the switchlincs on/off while shooting? -Xathros

Hi Stu- I just watched your video. The blinking on the SLD's looks EXACTLY like what I get with "Blink on TX" enabled on mine. I suspect that is also what the KPL is doing but since my ISY does not give me the option to enable that feature, I cannot test to see if that is what it would look like. Watch the event viewer when this is happening, I bet you will see traffic. -Xathros

Stu- When does this happen? Constantly, when a button is pressed, could it be indicating insteon traffic (Blink on traffic) ? -Xathros

Do not unzip the backup. ISY expects a zip. Try Chrome or Firefox instead of Safari. -Xathros Sent from my iPhone using Tapatalk

Dave- Add a 3 second wait as the first line of the then section. The should eliminate the duplicates. I'm afraid I don't know why ALL of the conditions are triggering however. -Xathros

Awesome! Can't wait to see how this works! -Xathros

Hi Michel- Not sure if this is a portal bug or intentional but I discovered that I can access https://my.isy.io/isy/<my_uuid>/desc without any prior authentication and receive a significant XML response that reveals my ISY's name and some other data. This seems like a bit of a security risk. Removing the /desc from the URL does prompt for authorization. Thoughts or comments? Thanks. -Xathros

This works like a champ! Here is what I have done: Created 5 network resource rules on my home ISY. They are: Office KPL-G On, Office KPL-G Off, Office KPL-H On, Office KPL-H Off and Office KPL Beep. Office KPL is on my Test ISY at my office. The resource rules use the portal URL and portal credentials for my office ISY. Here are two of these resources for reference: On the Home ISY I created 2 programs to watch the status of my garage door sensors and call these resources with any change of state. Here is one: Dad-Update Office KPL - [ID 029A][Parent 0011] If 'Garage / Garage Door IOLinks / GD- Dad Garage Door Sensor' Status is On Then Resource 'OFFICE - KPL Beep' Wait 2 seconds Resource 'OFFICE - KPL-H On' Else Resource 'OFFICE - KPL Beep' Wait 2 seconds Resource 'OFFICE - KPL-H Off' Now, whenever a garage door opens or closes, the corresponding KPL button changes at the office and the KPL beeps to get my attention. Notes: The secondary KPL buttons need to be in scenes since they cannot be directly controlled. If copying the portal URL from the "ISY Information" menu item in the portal, remove the /desc from the URL before adding the /rest... portion in your path box. The host should only contain my.isy.io Place the isy/<your isy uuid> portion in the beginning of the path preceding the /rest... portion. I had to bump the timeout up to 2500ms to avoid receiving a "TCP Client Read Response Failed" message. There is about a 1,500ms delay between running the resource and the reaction at the destination ISY. This seems reasonable considering encryption overhead and round trip time from VT->CA->VT. -Xathros