larryllix

Without any experience doing this myself, IIRC you can't switch masters from ISY programs.

Did you power cycle your ISY after the purchase? Some things don't show up until reboot when they enable that feature/module. The Network Resource Module is existing in most versions of ISY firmware and just gets cloud enabled. I assume you have browsed your tabs to find it? It was an option to include it with the Portal Purchase. I didn't as I had the NR before.

What do you have updating the DDNS service?

The name shown in your device tree is for your Insteon network, not Ethernet network. Unrelated.

hmmmmm... My ISYfinder comes up with two IP addresses ( that I installed) and I have to double click one, to connect to ISY with the path I choose, every time. The local IP address and the remote IP address are easy to identify by their numbers and could identify two different ISYs also. There is no ISY friendly name used, or seen, there. Using MobiLinc Pro (android) the switching is done automatically dependent on whether your WiFi is enabled or not. Two different ISYs could be made to respond to LAN and WAN access methods. I guess I don't understand where you ever see a friendly name for your local ISY.

So you are manually switching the ISY IP addresses in your apps, to access each ISY and it's a PITA?

In the end you will probably end up writing an occupancy program using a variable to keep track if anybody is home or not. I have any Insteon action to trigger a "Home" varible and it times off with different stimuli. Like 20 minutes after I leave by my usual door. Immediately if I set the alarm system 4 hours if I trigger any other MS in the house. Never after bedtime until 7:00 AM again then 4 hours After creating this variable programs can use the variable to test for people home. If the variable is a state variable it can also trigger programs to run by itself or with other logic combined. Now you stop you furnace fan from cycling, ventilation off, temperature down or up, lock the doors after X minutes.etc..etc..

I am sure of one finger you are holding up.

That's probably the best method for 240v dryers I have heard yet. No electrical connections into the appliance. Gas dryers could be a problem using plastic in the vent line (probably not to code) but they are usually 120 vac and a SynchroLinc (as in my case) does it very simply.

IIRC, Safe mode is when ISY cannot find your PLM. You could try power cycling your PLM and then power cycling your ISY. Also check your PLM cable. It may be time for a new PLM or a rebuild but they usually don't go dead immediately, that I have heard here.

I use a variable in v5.0.4 to keep the date in format MM.DD This takes a separate program, but other programs can then use the $sMM.DD to test for date ranges, year independant.

v5.0.5 didn't solve the 2411T refusal to install. I didn't figure it was on the board for UDI, with the lump jumping they have been doing lately. Hopefully it will have a fix for all those that bought them during the SH iR Sending unit sale, recently.

Since you guys want to play with words again... Power doesn't go through a conductor. Power is consumed by conductors. Only current can go through a conductor. OTOH: In the context of a grid delivery system we do say "power goes through a conductor" (They sure do demand your ticket on a train!) Resistance is futile. You two will be assimilated.

The new iR sender module I just recived shows v0.4A formware in it. ISY can see it, read it's ID but refuses to connect with a "failed to connect" each time. I tried a dual band piggy-backed on it but the same results. It seesm to be communicating OK and ISY has the device listed in the pulldown but I suspect a new protocol that isn't supported by v5.0.4...maybe? IIRC Rast...reported a similar problem with his.

You need v5.0.x to do this or keep track of the current state via a central program that is the only one to operate the device. Some have used Network resources to feedback into the RET interface, effectively stuffing the level into a variable. Network resource --> Var substitution --> ethernet --> ISY Rest interface --> variable

I see nothing!

+3 "Hey Hal" "Hey b..."

One word that should be mentioned is . . . "Again" Which repeats the last thing you just asked for. My 6 y.o. granddaughter discovered that one with her constant gilrls music samples. grrrr..... She's getting her own Dot for Christmas.

That would be more natural for me and my cultural grouping. That covers from Colorado to Ontario. That's half the world.

By the time you are done buffering them, enclosures, power supplies, four plug-in modules may be cheaper. But you still need to protect them and their connections from weather etc. IO/Links are not dual band either. One 12v 6A power supply, four WiFi controllers and strip LEDs may be cheaper yet and easier to interface to ISY.

Nothing like being on the other side of the world and a sensor decides to go crazy. Now you get a text message, and an email, every three seconds, for the next 14 days.

Maybe you have the wrong thread for this question. This thread was discussing heartbeat functions/frequency for polyglot devices. You question appears to be about Leak sensor codes used in the reporting/trigger variable and related to different topic. Out of context I can make no sense out of it. BTW: Using a variable for notification stimuli, gives better control over constant reporting of the same thing, as well as limiting the time of reporting before declaring normal again.

The Leak sensor is battery operated only and therfore RF only.Meanwhile the IO/Lin is old Insteon technology and only powerline. Something has to translate the protocols from RF to Powerline. This can be any dual band device. I have four LS and three IO/Links and no Access Points or Phase Couplers or Range extenders. Not required with more modern protocol dual band Insteon devices.

Can't help you there. I use an iR remote that has all the functions, so far. I do have an Insteon to iR converter on order, so I may find out how to get my wife back.

Pero, no comprendo. It's a security encryption technique.