I have two devices that I need to establish communication between (IP Camera --> Automation Controller). I've made some progress, but I've run into a road-block that I'm looking for some assistance with. Any help would be greatly appreciated.
1. IP Camera - Sends a plain text string to 192.168.2.XXX:XXXX; expects this port (socket?) to remain open indefinitely. When the port is closed, it takes up to 3 minutes for the camera to recognize this (and reconnect) and during this time no communication is transmitted - a big problem.
| transmits to
2. Automation Controller - Receives commands via HTTP GET interface. Closes the socket after the GET command is received and really irritates the IP camera.
The Automation Controller can be triggered by opening a browser window and entering:
WHERE I'M AT SO FAR:
I have changed the text string that the camera sends to:
n: Basic xxxxxxxxxx[CRLF][CRLF]
where [CRLF] = carriage return / line feed (i.e. new line)
This works great the first time. However, after the command is received the Automation Controller responds with a 200 and closes the connection.
WHAT I'M LOOKING FOR:
A method to transmit a text string (i.e. "motion detected") to an Automation Controller that doesn't result in a closed socket connection. This may be a change in the text string format, or a small program that runs on my server PC, etc.
Actually, I don't really care about the specifics - only that the end result is reliable communication from the IP camera to the Automation Controller. Open to ideas...
SOME MORE SPECIFICS:
After doing a bit of research on my own (and you'll have to excuse my inexperience here), apparently the camera is expecting the server to be a simple TCP server, as opposed to an HTTP server that closes the connection after each GET request.
The camera is simply sending a plain text string to a port. In this case, the default string from the camera is "motion detected". As an example, if I send this string to PC-based recording software, it accepts the string with no reply and does not close the connection. I confirmed this with telnet - the port remains open indefinitely on the recording software waiting for additional strings. Apparently, this method is fairly standard in the IP camera industry...
Thanks for the help!