apostolakisl

OK, thanks. It works! I also had to increase to 1500 ms the time out. . . at least to not have ISY show an error. Where did you get this syntax "&user=" etc? I have not seen the "amp;" in any of the foscam docs.

I had already tried both with and without the colon. I tried increasing time out to 1500ms but no go. Purdueguy PM'd me that he thinks the new Foscam firmware is requiring encrypted passwords. I don't know that this is possible with ISY. The ISY and the Foscam are on the same LAN, so I'm not terribly worried about encryption.

I don't manage the presets via ISY, I do those via the standard camera webpage. I then use HTTP calls from ISY to set the camera to certain presets. For example, to set my camera to Preset2, I use the command: http://CAMERA_IP:PORT/decoder_control.cgi?command=33 To enable the automatic IR: http://CAMERA_IP:PORT/decoder_control.cgi?command=95 When doing this from ISY Network Resource: Protocol Information: - HTTP - GET - Host = IP address of Camera - Port = Port of camera (default is 80) - Path = /decoder_control.cgi?command=XX (replace XX with your command number) - Details -> Headers -> Click Add, choose "Authorization" and fill in the name/password for an "Admin" or "Operator" user (a "Visitor" user shouldn't be able to move the camera, etc) More info here: http://www.zoneminder.com/wiki/index.php/Foscam Trying to have ISY turn my camera alarm on/off. I am getting error "tcp client request failed net module rule 134:401", which I believe is th user/password failing. I included the authorization header with the correct user name (admin) and password. ISY is translating that to base 64 which I reverse translated and it shows admin: mypassword I tested my syntax in IE and it works (turns the alarm on/off) Any ideas on what I am doing wrong? Thanks

Very sorry to hear of your loss. The first thing to try would be to pull the power disconnect tab to reset it. This is a small piece of clear plastic at the bottom middle of the keypad immediately below the lowest button(s). Use a butter knife or small screw driver to pop it out. The tend to be a little tough to pull out, but it should come out 1/8 inch or so and stay out when you let go. Let it sit out for 10 seconds or so then pop it back in by just pushing on it. Don't push and hold it, just push it in and as soon as it snaps in let go. If you hold it for too long, it will do a factory reset. Hopefully that is all it takes. If not, we can take you further down the road. Again, sorry to hear about your husband. We will miss him around here as well.

A cai webcontrol board can accept the one wire temp input and post directly to ISY variables.

I'm thinking bad plm. If your regular, non-isy, scenes are all working, then a noise issue is low probability. I doubt it is the ISY.

And then restore PLM. I agree it should work, but it is expensive. And you would have to keep both ISY/PLM's up and running waiting for the possibility of being called into action. Since it seems that PLM's have a ticking time bomb in them that explodes just after 2 years, you might find that the backup PLM is also no good when it comes time to switch to it. That is why I would suggest not having the backup PLM powered up until it is needed.

As Lee said that would be very difficult. If you are concerned about a PLM failure, you could run 2 plm's and use a relay to switch the 120v power between the 2. You would also need a splitter for the rj45 so that both PLM's would be connected at the same time to the ISY, but since only one is powered on, the other would be invisible to ISY. You would need a controller for that relay that could be operated via a network connection. If the PLM failed, you could switch to the second PLM, reboot your ISY remotely and then do a restore PLM remotely.

Glad to hear you have it going in the right direction. I would be curious to know what device ends up being the problem.

So you are saying that querying the links table from a device is yielding only 1 link, despite the fact that the device currently functions properly as a member of one or more scenes? That I don't quite understand. It seems that the links must be there or it wouldn't work in a scene. But how a query from ISY is only showing one link I don't know. It seems to me that it should either show all of the links or fail to show any. I assume you have installed the new PLM in the same spot as the old one? This would make me think that a comm issue is not the problem. However, you might try putting the PLM onto a power splitter (just a plain splitter, no other surge suppressors as they can create comm issues) behind an Insteon noise filter and check the communication and ability to write links between the plm and that device. If that all works, it would seem that some sort of comm issue is the problem. You might also just have a bad PLM. ELA mentioned in a thread that he had an RF device that was jamming his system. It doesn't seem like that is what you have, but it would be worth reading.

It sounds like you did things correctly And my modem also died just after the warranty. I have read this same thing many many times. Based on what you are saying, it sounds like your devices do not have the correct address for the PLM written into them and the plm doesn't have the right device addresses written in it. When you did restore modem, it should have written the link between each device and the PLM. So each device should have the PLM address and the PLM should have each device. The process of restoring the PLM can take a long time depending on how many devices/scenes you have because it is not only writing the links in the PLM, it is also erasing and rewriting the links in the device that reference the PLM. If it didn't take a while, then that would indicate a problem. Mine took I think like 2 hours. If you can manage to bring up the links tables on your individual devices, you should see your plm address in there. Also, you can bring up your PLM links table and you should see the addresses of all your devices in there plus a whole bunch more relating to all the scenes. For example, I have 366 links in my PLM and about 60 devices. You can check your "tools" "diagnostics" "plm info/status" and see if it lists the PLM as connected and also what the address is.

Yeah I just realized myself that might be the problem. So if I understand correctly, programs that are disabled won't re-evaluation the "IF" clause while they are being executed. So I'll need to change the dimmer program to be event based... Programs that are disabled never evaluate the if clause unless directed to do so by another program (or manually).

I think I see the issue. Your last program is disabled. It won't trigger from the status of those 2 programs changing condition. That last program must be called by another program.

Yep, I could do that indeed. My intent was to not have multiple scenes with different ramp rates. When I click a scene controllers, I want the 2 second ramp. The long ramp is only acting as a warning that the lights are going to be turned off soon, so better activate the motion sensor to turn them back on. For your second question, I think I answered it in the last post, which is that only the "Kitchen Occupancy" scene is "active" You would be better off having 2 scenes. They both can have the same lights in them but different ramp rates. The 19 second ramp rate scene would be activated by your program, the 2 second ramp rate would be activated by the switches. This is a much better way to do that then the repeat dims.

I was looking at the last program with the repeats. Why are you doing 20 dims separated by a second? Why don't you create a scene with those lights and have the dim rate happen over 19 seconds (which is the choice closest to 20 seconds)? Then you just have the "then" clause execute the scene. Of course this doesn't answer the question as to why the else isn't running when the "if" condition changes. I'll have to look closer, but I have to wonder if your else clause isn't doing something that makes the "if" clause true again. You can open the program summary page and watch the status of each program change as it happens.

Copy and paste all the program to the forum. Please add the name of each program since the copy/paste doesn't include the name and we will need those names here.

Keeping the program "true" does not stop it from re-evaluating the if and starting the timer over. For example, If control light x is switched on Then wait x minutes do something Else blank This program will restart the wait every time light x on button is pushed, even if it is already on. In short, anything in the "if" clause that experiences a triggerable event, will kill a wait/repeat and either start it over again, or run the other clause. At times, this is a good thing. Like if you have a motion detector and want every re-trigger of it to restart a timer.

The issue with non-interruptable waits/repeats has been beaten to a pulp. Indeed, it would be nice to have it both ways and probably UD will do something that allows you to choose. In the mean time, you accomplish the same thing by splitting the program in 2. If various conditions Then wait x time do something Else blank Can be changed to Program 1 If various conditions Then run program 2, then clause Else blank Program 2 If blank Then disable program 1 wait x time enable program 1 do something Else blank Now your "wait" clause will run to completion no matter what.

Right click on the program and click "run if". The program should turn true if it is during the day, or stay false if it is at night. Also, using the admin console, turn your fountain (or light) on/off to make sure that the communication is working between ISY and the target device.

Since you haven't said otherwise, I assume your programs are still running and all the stuff you expect to happen is happening?

You could put a micromodule controlling the load behind a KPL. Then one button would control a scene where the micromodule turns the light off and a different button would control a scene that turns the light on. This all seems way too complex in my mind, however. I use the cree lights and am quite happy with them. They do not flicker, but they do "pop" a little when they first light. They aren't capable of anything much less than 12% so as you ramp it up, you get nothing until you hit 12% then "pop" is on at 12%. Same thing on the way down, but it goes lower before it "pops" off.

CAI webcontrol has a function called "webset". You can have 8 of them where each one can be set with an ISY REST command. CAI can append the REST command with any of its values (like temp, analog input voltage, a variable, etc). You can look at CAI's user manual to see all of the values on page 27-30. Usually this would mean that you set an ISY variable, but you could also use a REST command to tell ISY to set an Insteon device directly rather than set a variable. Also, you can use a REST that doesn't get appended with a value, like a device fast on command. If you care to learn all of the the REST commands it is in the wiki. This thread has a lot of info viewtopic.php?f=81&t=10141&hilit=webset&start=15 And this link is to the CAI user manual. http://www.cainetworks.com/manuals/webc ... 02-17f.pdf

Xathros is probably right. Especially if you can use that scene to turn the lights on without issue but then struggle to turn them off. That is classic sign of a noisy load. Many CFL's are noisy, but there are also quite a few that don't cause any trouble.

----- Front House-Garage Test Results ----- [Failed] Garage Outdoor Lights (23 F2 6E 1) [Failed] MB C - Front House (24 16 3B 5) [succeeded] Hallway A - Front House (22 CB 5B 3) [Failed] Front House Lights (23 F2 B0 1) ----- Front House-Garage Test Results ----- This was the scene test, and you had 3 out 4 devices fail. You appear to be having comm issues.

The "or" line won't block the sunset line from running true. The level 3 is in the tools, diagnostics, event viewer menu, but before confusing yourself with that, just look at the program summary page and report that. The level 3 check will tell you about communications, but you won't understand it without a lot of research. You need to open the event viewer and set it to level 3 shortly before sunset plus 4 hours so that it is running when that program is supposed to execute. You can then copy and paste that to the forum for interpretation. Also you can run a "scene test" on that scene. This will give you an idea of how strong the comm is. If you are needing multiple hops that is a sign of weak comm.