Checking the error log I see thousands of these with different port numbers but otherwise the same. The LAN ip of 192.168.1.8 is a DVR for my security cameras. I can't imagine how it could be connected to ISY.

 

Fri 5/4/2012 3:21:32 "AM System -170001 [HTTP] 192.168.1.8:35072->80 "

Fri 5/4/2012 3:21:32 "AM System -170001 0: GET-->/desc"

Fri 5/4/2012 3:21:32 "AM System -170001 [HTTP] 192.168.1.8:35076->80 "

Fri 5/4/2012 3:21:32 "AM System -170001 0: GET-->/desc"

Fri 5/4/2012 3:23:03 "AM System -170001 [HTTP] 192.168.1.8:35086->80 "

Fri 5/4/2012 3:23:03 "AM System -170001 0: GET-->/desc"

Fri 5/4/2012 3:23:03 "AM System -170001 [HTTP] 192.168.1.8:35090->80 "

Fri 5/4/2012 3:23:03 "AM System -170001 0: GET-->/desc"

Fri 5/4/2012 3:24:30 "AM System -170001 [HTTP] 192.168.1.8:35100->80 "

Fri 5/4/2012 3:24:30 "AM System -170001 0: GET-->/desc"

Fri 5/4/2012 3:24:30 "AM System -170001 [HTTP] 192.168.1.8:35104->80 "

Hi apostolakisl,

 

They are debugging information and show up when you have debug level in the Event Viewer on level 3.

Fri 5/4/2012 3:21:32 "AM System -170001 [HTTP] 192.168.1.8:35072->80

Someone from 192.168.1.8 and port 35072 (usually any network client) contacted ISY on port 80 (HTTP).

 

Fri 5/4/2012 3:21:32 "AM System -170001 0: GET-->/desc

The client above requested for resource /desc using method HTTP GET

 

 

With kind regards,

Michel

OK, so its not an error at all.

 

But I'm still baffled as to how my camera system dvr is doing this. 192.168.1.8 is a static address assigned to that unit.

 

I just manually did the get/desc command and it appears to just give a description of the ISY unit. Correct? Why the heck would anything be doing this thousands and thousands of time on a gradually incrmental port number.

It's regular UPnP discovery stuff.

 

With kind regards,

Michel

OK, thanks.

Did you have to register the camera IP addresses with the DVR?

 

It sounds like the DVR is checking the network for whatever cameras it can find.

No, its not an ip based camera. They are analog cameras wired directly to the dvr. The dvr is connected to the internet for viewing and configuring. You can also skip IP all together and just plug a monitor directly into to it.

 

It's a Swann camera system I got at Costco.

Hello apostoalkisl,

 

Is the IP from dvr or your camera? In all cases, UPnP devices DO search for other UPnP devices and that should explain it if and only if one of your devices (either dvr or camera) is UPnP enabled.

 

With kind regards,

Michel

Only the DVR is connected to IP. I believe the DVR is UPnP although my router is not so I manually configured it.

Since the router does not support it is there an option to turn uPnP off in the DVR.

Since the router does not support it is there an option to turn uPnP off in the DVR.

 

Good idea, I'll look into it.

It seems I have a similar issue with the error log after upgrading to v3.2.6.

I have a CAI WebControl board and am running WCLinc on a PC at 192.168.30.104.

The ISY Error Log fills up pretty quickly with the polls from WCLinc as shown below.

Didn't see this in v3.2.5 Error Log. Shutting down WCLinc stops the entries in the Error Log.

Suggestions, please.

 

Time User Code Message

Fri 2012/05/11 15:43:31 System -170001 [HTTP] 192.168.30.104:2481->80

Fri 2012/05/11 15:43:31 System -170001 0: GET-->/rest/vars/set/2/19/1

Fri 2012/05/11 15:43:31 System -170001 [HTTP] 192.168.30.104:2482->80

Fri 2012/05/11 15:43:31 System -170001 0: GET-->/rest/vars/set/2/19/1

Fri 2012/05/11 15:43:32 System -170001 [HTTP] 192.168.30.104:2483->80

Fri 2012/05/11 15:43:32 System -170001 0: GET-->/rest/vars/set/1/65/32

Fri 2012/05/11 15:43:32 System -170001 [HTTP] 192.168.30.104:2484->80

Fri 2012/05/11 15:43:32 System -170001 0: GET-->/rest/vars/set/1/65/32

Fri 2012/05/11 15:43:42 System -170001 [HTTP] 192.168.30.104:2487->80

Fri 2012/05/11 15:43:42 System -170001 0: GET-->/rest/vars/set/2/19/-1

Fri 2012/05/11 15:43:42 System -170001 [HTTP] 192.168.30.104:2488->80

Fri 2012/05/11 15:43:42 System -170001 0: GET-->/rest/vars/set/2/19/-1

Fri 2012/05/11 15:43:52 System -170001 [HTTP] 192.168.30.104:2491->80

Fri 2012/05/11 15:43:52 System -170001 0: GET-->/rest/vars/set/2/19/1

Fri 2012/05/11 15:43:52 System -170001 [HTTP] 192.168.30.104:2492->80

Fri 2012/05/11 15:43:52 System -170001 0: GET-->/rest/vars/set/2/19/1

Fri 2012/05/11 15:43:52 System -170001 [HTTP] 192.168.30.104:2493->80

Fri 2012/05/11 15:43:52 System -170001 0: GET-->/rest/vars/set/1/65/33

Fri 2012/05/11 15:43:52 System -170001 [HTTP] 192.168.30.104:2494->80

Fri 2012/05/11 15:43:52 System -170001 0: GET-->/rest/vars/set/1/65/33

Fri 2012/05/11 15:44:03 System -170001 [HTTP] 192.168.30.104:2497->80

Fri 2012/05/11 15:44:03 System -170001 0: GET-->/rest/vars/set/2/19/-1

Fri 2012/05/11 15:44:03 System -170001 [HTTP] 192.168.30.104:2498->80

Fri 2012/05/11 15:44:03 System -170001 0: GET-->/rest/vars/set/2/19/-1

wrj0

 

Did/do you have the Event Viewer set for Level 3? I think your messages are information about the variables WCLinc is pulling from the ISY that are produced when the Event Viewer is set to Level 3.

Thanks for the response, Lee. Event Viewer is set for Level 1.

Only began seeing this after upgrading from v3.2.5 to v3.2.6.

Hello wrj0,

 

Are you certain that the level is 1? What happens if you disable the event viewer, do you still see them in your log?

 

With kind regards,

Michel

Thanks, Michel.

The ISY was indeed in Level 1, but I found the problem: I had previously issued the telnet DON command to try to track outside ip accesses. Turning off that command eliminated the extra Error Log entries.

 

What prompted me to look into this was the situation where I could no longer open the Error Log - I had to clear it, then I could open the Error Log and see the entries previously provided, at least for a while. A couple of days later, I could no longer open the Error Log. Tools, Error Log, would causes the Windows wait hourglass to display for ~20 seconds, then the hour glass would disappear - no "Save log to..." was presented. After Clearing the Error Log, the "Save Log to..." was once again presented.

 

All's well now.