Xathros

Because the cam is expecting the cookie and the ISY is not providing it. Try this to prove: Delete cookies and disable cookies in the browser then retest connecting to the cam from the browser. It should fail in the same way. -Xathros

I think I see the problem. This cam seems to require the ISY to support auth cookies per this from your firebug output: Cookie activatedmode=digital; viewsizemode=100; 4x3=false Host 192.168.1.42:8042 ISY does not support this. You may need a middleman to deal with this issue. Beats me why it errors with a 404 however. I would think this should be an auth failure instead. -Xathros

Is encode URL checked? Also, this part doesn't look quite right to me: /set?vi0=1 and you show: /setvi?vi0=1 in a different post. -Xathros

Most of the firmwares can be found here: http://forum.universal-devices.com/forum/15-current-release-betas-and-bug-reports/ If you can't find it there, Many of us archive them as we go along. I'm sure I or another here can come up with what you need. If not, I bet support would happily provide any previous version you desire. -Xathros

In addition to the excellent suggestions above, there is also the default UDAjax web page served by your ISY. Not as pretty as HAD but still functional and pretty light weight and usable on most platforms. -Xathros

Always happy to help. -Xathros

How about this: Program: Morning Scene A If Time is from 6:30 am To 7:30 am (Same Day) Then Run Program 'Morning Scene B' IfPath Else Set Scene 'Summer' Off Set Scene 'Winter' Off Program: Morning Scene B(Disabled) If Time is From Sunrise to Sunset (Same Day) Then Set scene 'Summer' On Else Set scene 'Winter' On The first program initiates an action at 6:30 to turn on a scene and at 7:30 to turn of both scenes (only one would have been on). The second disabled program is called by the first and turns on the summer scene if the time is after sunrise or the winter scene if the time is before sunrise. I believe this would fit the stated goal. Hope this helps. -Xathros

It is my understanding that everything in the ISY is backed up with the exception of: The firmware itself. The contents of the web server (if you have the network module). As long as you backup before upgrading, you can always reinstall an older firmware then restore a backup matching that older version of the firmware to get back to where you were. The backup names include the firmware version number in them for your convenience. -Xathros

I tend to make backups right after I make a bunch of changes. As long as I do that consistently, I can always go back the the previous backup to undo my recent changes. This way I don't need to wait for the backup before I can get to work. -Xathros

The same applies to: User variables, Scenes, Programs, Network Resources and Email customizations. All are internally referenced by an internal ID# so the name matters only to you. -Xathros

Sorry, after reading the whole thread, it seems I had missed the point and my previous suggestion was an answer to a different problem. I suspect we could work around this with the Pi however. Use the Pi to stuff the octets of the IP into 4 ISY vars then used those in your notification. I'll think about how to accomplish that. -Xathros

Couldn't you embed an identifier in the body or subject using a variable? You would need to know the meaning of the value but you are talking a fairly limited number of locations right? Or am I not understanding the issue at hand? -Xathros

It simply check for a release version higher than the installed version from what I can see. -Xathros

It's possible that you like me have been running beta versions with numbers higher than the official release when the official release is announced. That happened to me with this release as I'm on 4.3.0 and the ISY did not notify me of the official release since it's version was lower then what I have installed. -Xathros

A long long time ago in a firmware far far away... Been there for as long as I can remember. Only works with Official Final versions however. -Xathros

I think Stu means Status not Sense. -Xathros

5.X will have more advanced ZWave support and be on the leading edge while 4.X will have fully tested and certified support is how I interpreted that. -Xathros

Me too!

Or at a minimum, go back to selling the dual contact Seco-larm switch with the garage kit. -Xathros

This is what you want: http://www.smarthome.com/seco-larm-sm-226l-3-magnetic-garage-door-contact-switch.html Can be wired either way. I have mine mounted at the top of the door frame. -Xathros

I must have missed that. -Xathros

No Problem. Always happy to help. Might want to have a look at the Email Substitution Variables page in the Wiki. It covers device status as used above. I recently updated it to include user variables and the Ham weather variables. And, very soon we will be able to use these in network resources as well. -Xathros

Hi Smokegrub- What is the Insteon address of your Insteon TStat? I will format the command you need to add to a custom notification for you. -Xathros EDIT: Nevermind. Just follow this: Program: If Time is 7:00PM Then Send Notification to 'Your Email' Content 'Temp Report' Else Create a custom email notification as follows: Subject: Temp Report Body: Indoor Temp: ${sys.node.11 B2 7 1.ST} Change the address in blue above to match your insteon stat. Note: Remove any leading 0's in the address sections (07 becomes 7) Hope this helps. -Xathros

For what its worth, I have always seen this issue when backing up my ISY locally or remotely via https and never locally via http. Up until this morning that is. Today I was able to complete a full backup remotely via https with no socket open failed messages. This appears to be due to improvements in the UDI firmware in a pre-release build 4.3.0 that I'm testing. This while my router and 3 processess running on a RPi were all frequently posting data to the ISY. Additionally, my backups have always been good in spite of these socket open failed messages. -Xathros

No but that capability is just around the corner I believe. -Xathros