Everything posted by Xathros
-
Couldn't Resolve Localhost error on OSX Maverick/Java 7 up45
See this thread: http://forum.universal-devices.com/viewtopic.php?f=25&t=12658
-
Couldn't Resolve Localhost error on OSX Maverick/Java 7 up45
go to the System Preferences, Sharing Applet: The bottom line there is what should be in the hosts file. Try editing the computer name - change it to something else, save the change then change it back and save again - that may update the file for you. -Xathros
-
Couldn't Resolve Localhost error on OSX Maverick/Java 7 up45
OK. Thats good. Thje only thing odd that I noticed in your hosts file was a missing entry for your computers name. Mine looks like: # Host Database # # localhost is used to configure the loopback interface # when the system is booting. Do not change this entry. ## 127.0.0.1 Xathros-MacBook-Air.local 127.0.0.1 localhost 255.255.255.255 broadcasthost I wonder if that missing entry is the culprit. -Xathros
-
Hi Guys! Dumb question / programs and keypad lights
If KPL-C is already controlling the water feature, this tells me that you already have a scene in which the KPL-C is a controller. If that is the case, then the program should be turning the scene On/Off rather than the device that powers the water feature. -Xathros
-
Couldn't Resolve Localhost error on OSX Maverick/Java 7 up45
Try typing: ping localhost See if it returns: 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.xxx ms You will have to hit Ctrl-C to stop the ping once started. -Xathros
-
Couldn't Resolve Localhost error on OSX Maverick/Java 7 up45
Hi Kentinada- It sounds to me like your hosts file is damaged or has the wrong permissions. Bring up the Terminal program and type: cat /private/etc/hosts And see what is returned. You should see a line included that says: 127.0.0.1 localhost Have you run a repair permissions since upgrading to Mavericks? If not, launch the DiskUtility and click RepairPermissions - See if that helps. -Xathros
-
KPL LED to show current state of Light
Hi Drew- If the Other scene that turns on the light but not the KPL led is the issue, then the KPL button needs to be added to the OTHER scene as a responder. Sorry, I had misunderstood your original post. If the KPL is operating a scene, it must already be a controller in that scene. I guess I need a cleaner understanding of your scene definitions and what exactly you want to happen with this KPL button from both a control and feedback standpoint. It sounds like you have some overlapping scenes and you may require a program or two to accomplish your goal. -Xathros
-
KPL LED to show current state of Light
Drew- If you want the KPL button to also turn the linked light(s) on/off, then the button should be a CONTROLLER in the scene along with any other devices that you wish to control the scene. If the KPL LED has not been accuratly representing the status of the scene as a responder, that indicates a communications issue to me. -Xathros
-
Current transducer to monitor secondary pump.
Some UPS's have dry contact alarm terminals that you could use to drive an IOLinc or Open/Close sensor (if you want battery powered). If yours does not, you could just drive a pair of 110V relays - one coil powered with the ups output and the other with the line then wire in series through the NO contacts on the UPS powered relay and the NC contacts on the line powered relay. A completed circuit indicates UPS power with no line power. Additionally, you could use the NC terminals on the UPS powered relay to indicate complete power fail. -Xathros
-
Thermostat: Fail-safe if program does not turn heat one
Elk is in my longer range plans as well. I do believe that you can take advantage of all of the Elk sensors from within the ISY. Line Powered Pet-Immune motion sensors to replace all of my battery operated insect detecting Insteon motion sensors! I can't wait! -Xathros
-
Thermostat: Fail-safe if program does not turn heat one
Rolled my own laundry monitoring with a combo of some MT-800 current transformers and a CAI Web Control board. As for the locksets, it depends on the lockset I guess. I have a few BE599's From Schlage that work well with the ISY alpha Zwave and have been pretty good in terms of manual use and battery consumption. I have a Schlage BE469 deadbolt that I haven't been able to use with the ISY (yet) but I think in a few weeks that will be resolved with the beta. The 469 has what they call a touch screen (actually a backlit membrane keypad). Its working great so far but I have a feeling that the keypad is the weak link on this unit. I suspect the plastic outer membrane will degrade with weather/UV exposure and once it cracks, it will be all over for that keypad. Of course, all of these locksets have manual key override so a dead battery is not the end of the world (as long as you have your key...). I expect I will be able to monitor battery status and alert will in advance before they quit. after about 6 months installed, I had to change batteries in the oldest 599. That one gets the most use but I think the replacement name brand batteries may last longer and since the kids have gotten over the newness of that lockset, It's seeing alot less usage. -Xathros
-
Thermostat: Fail-safe if program does not turn heat one
Just counted. 85 (including PLM and 3 access points) - Many more nodes as I have 4 KPL8's, 7 Motion sensors, 4 Open/close sensors, 3 IOLincs, 1 Stat all of which have multiple nodes. Will be adding a few more SwitchLinc relays and probably some door sensors after they release and are proven. I have 7 ZWave devices (locksets, dimmer, and some outlet relays) that are included in the count. -Xathros
-
Thermostat: Fail-safe if program does not turn heat one
I fully agree that it should work the way you are asking for it to. Hopefully, this last bit will pin down whats causing this. -Xathros
-
Thermostat: Fail-safe if program does not turn heat one
Not having one of the Insteon TStats to play with, I'm afraid I'm running out of ideas on this one. I have not seen this behavior reported here before and can only attribute this to program activity. Can you monitor the ISY Log and see if there are any entries at the time the stat reverts back. Also check last run times on programs for a matching time stamp. -Xathros
-
Thermostat: Fail-safe if program does not turn heat one
I wonder if Mobilinc is enforcing the scene for you. I don't use scenes with my TStat which might explain why I don't see this problem. I have my programs simply change the setpoint rather than call a scene. Try this when you are home. Instead of using the phone, use the stat to change the set point up or down a degree or two. see if it changes back on it's own after a few minutes. If not, take out your phone and refresh - again, see if it changes. -Xathros
-
Thermostat: Fail-safe if program does not turn heat one
I just reviewed your programs and see no reason why the stat would revert to the Work scene after a manual change. I wouldn't think that a change in the temp reading would trigger "Status Mode is Heat". Is there anything changing your AwayMode button? -Xathros
-
questions on toggling events
Actually, now that I look at it again, you only need the master program: FireToggle (ALWAYS DISABLED) If Status 'Fire-Relay' is Off Then Set 'Fire-Relay' On (Then Path) Else Set 'Fire-Relay' On (Else Path) -Xathros
-
Any successful integration of Asterisk PBX and ISY?
Sorry, I'm at a loss. -Xathros
-
Thermostat: Fail-safe if program does not turn heat one
Right. That is a system variable - not a user defined one. See this section of the Wiki for more: http://wiki.universal-devices.com/index.php?title=ISY-99i_Series_INSTEON:Custom_Email_Substitution_Variables -Xathros
-
questions on toggling events
Since your triggering the master program manually, you might as well just leave it disabled. No need to disable/re-enable. How about this instead: MASTER PROGRAM (DISABLED ALWAYS) - the only one that I call directly (typically from SIRI -> ProxyServer -> Ruby -> ISY99) If Status 'Fire-Relay' is Off Then Run Program 'fireOn' (Then Path) Else Run Program 'fireOn' (Else Path) TURNS IT ON/OFF (ALWAYS DISABLED) If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Set 'Fire-Relay' On Else Set 'Fire-Relay' Off -Xathros
-
Thermostat: Fail-safe if program does not turn heat one
My BAD! Wrong () Should be {} Try: ${sys.node.22 17 8E 1.ST} -Xathros
-
Thermostat: Fail-safe if program does not turn heat one
2441TH - INSTEON Thermostat OK. I don't own that model so maybe someone else can comment on it's desire to return to 57. I still don't believe it should do that on its own. I believe this IS the model reported with a very directional antenna so IO am going to stick with my recommendation to install an access point across from it. -Xathros
-
Thermostat: Fail-safe if program does not turn heat one
What model stat is this? This certainly does not sound like the right behavior to me. I still think comm failure. -Xathros
-
Thermostat program did not work this morning...
That cabinet is certainly not helping it's rf capabilities and as I recall, that power block has a sure suppressor. Quite often surge suppressors contain noise filters that adversely affect Insteon signaling on the powerline. The fact that you haven't noticed any problems up till this stat issue is a good thing but I think you may have some marginal communications. Launch the admin console and open up the event viewer, set it to level 3 then using the admin console, turn on/off various devices around the house and make some changes to your stat. Look at the data returned in the event viewer for Max Hops=3, Hops left=0 or 1. if you are seeing a lot of 0's or 1's in the remaining hop count, that indicates poor communications. -Xathros
-
Thermostat program did not work this morning...
Your home electrical feed consists of 2 110V legs (phases) and a neutral with 220Volts from leg to leg and 110 volts from either leg to neutral. Generally, half of the circuits in your home are on one 110V leg and the other half are on the other. Insteon signals do not travel well from one leg to the other through the utility company's transformer out on the pole. We use access points (or other dual band devices) one installed on each leg and both within rf range of each other to couple (or bridge) the legs of your home's electrical feed so that signals can travel from one leg to the other. The general guideline is to install 2 access points on opposite legs (phases) near the main electrical panel. If you have a dual band PLM (2413S), you may consider that to be one of the access points and simply install a second access point in proximity but on the opposite leg. -Xathros