TRACE log during camera connect the first time - as proposed by @matt1 shows:
2022-02-19 11:20:12.886 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request:GetSystemDateAndTime
2022-02-19 11:20:12.934 [TRACE] [amera.internal.onvif.OnvifConnection] - Onvif reply is:<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>400 Bad Request</title>
</head>
<body>
<h1>400 Bad Request</h1>
</body>
</html>
2022-02-19 11:20:16.889 [DEBUG] [era.internal.handler.IpCameraHandler] - About to connect to the IP Camera using the ONVIF PORT at IP:192.168.178.34:80
2022-02-19 11:20:16.890 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request:GetSystemDateAndTime
2022-02-19 11:20:16.915 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.178.34:80/bha-api/image.cgi
2022-02-19 11:20:16.918 [TRACE] [amera.internal.onvif.OnvifConnection] - Onvif reply is:<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>400 Bad Request</title>
</head>
<body>
<h1>400 Bad Request</h1>
</body>
</html>
2022-02-19 11:20:16.952 [TRACE] [era.internal.handler.IpCameraHandler] - HTTP Result back from camera is :<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>401 Unauthorized</title>
</head>
<body>
<h1>401 Unauthorized</h1>
</body>
</html>
:
2022-02-19 11:20:16.956 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.178.34:80/bha-api/image.cgi
2022-02-19 11:20:17.088 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP:192.168.178.34 gave a reply with a response code of :500
2022-02-19 11:20:17.089 [DEBUG] [era.internal.handler.IpCameraHandler] - Camera has no Content-Length header, we have to guess how much RAM.
2022-02-19 11:20:17.928 [INFO ] [era.internal.handler.IpCameraHandler] - The alarm stream was not running for camera 192.168.178.34, re-starting it now
2022-02-19 11:20:17.935 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.178.34:80/bha-api/monitor.cgi?ring=doorbell,motionsensor
2022-02-19 11:20:18.009 [TRACE] [era.internal.handler.IpCameraHandler] - HTTP Result back from camera is :<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>401 Unauthorized</title>
</head>
<body>
<h1>401 Unauthorized</h1>
</body>
</html>
:
2022-02-19 11:20:18.011 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.178.34:80/bha-api/monitor.cgi?ring=doorbell,motionsensor
The only other thing worth mentioning is that if you have the camera open in another software or app, some cameras from Doorbird brand only allow a single connection at a time. It may even be this binding trying to connect multiple times for the stream and the snapshot that is tripping the camera up.
I am using MJPEG URL channel in Habpanel on several tablets. There is no difference whether Doorbird app is opened or closed. The Image Item of Doorbird binding is āonlineā all the time, no broken image. Not sure if this information is helpfull for you at all.
There is a dedicated Doorbird binding you should check out.
I am working with the Doorbird binding. But sending a picture of an Image Item (this is what Doorbird binding provides) as attachment is much more complicated than sending the http-URL directly. I guess this is what you are mentioning here for example. Thatās why my intention was to use the IPcamera binding.
The camera is not giving a reply to the 'GetSystemDateAndTime` ONVIF request so this means the onvif port of 80 is wrong. Having looked online I can see no evidence that Doorbird actually has ONVIF advertised and no details on what their port is probably means they do not have onvif in them. The binding should be modified if this is the case. This wont be causing the problem you are seeing.
You wont be able to use both at the same time. Doorbird only can talk to 1 piece of software or app at a time.
A HTTP error code of 500 probably indicates that the camera is already in use by another app, binding or something else.
What happens when you type this into a linux terminal? NOTE remove the Auth header which will look like scrambled characters but it can be used to get your password if you post it in the forumā¦
The output of the above command should show in more detail what is going on.
The gray square shows that the binding does not have a valid snapshot either the camera is not online or the snapshot was never successfully completed.
It appears that the camera is giving a HTTP 200 OK reply when the user/pass is reported as wrong which is incorrect, the above curl output should confirm if this is the case.
I guess you are right. The Doorbird devices were auto-detected by the binding, I guess through API.
Hm, actually all channels of both, Doorbird binding and IP camera binding are working - except for ImageUrl channel in IP camera binding. I do not recognize any issue when using the App in parallel. Maybe you are right that there is a restriction from Doorbird side, but indeed it seems to work.
Why is this only affecting ImageUrl? I thought MJPEG is created by the single snapshots. MJPEG is working without any issue. Another thing I am struggling with: when Doorbird binding thing is paused, the image channel is still not working. Doorbird App is not in use at the time of checking this. But MJPEG-stream is shown in Habpanel. May this affect Image Url?
I will send the output via PM directly to you since I honestly do not know which information are confidential and should not be shown to the forum. If it will make sense, you can delete password information and so on and post my output here, I agree in case you are assessing this to be helpfull for others.
Not sure if this is an evidence at all, but the camera is shown as online in OH and all channels are working properly (at least those channels I am using). If I change anything in thingās config (like change port or pwd), the thing itself goes offline immediately. When opening the image Url in a browser, there is in some (rare) cases a picture. If I continously press F5 every few seconds, there is most of the time the grey dot, but randomly there is a picture also. Thatās why I think the camera is online but something went wrong with the snapshot only.
I did not get this, sorry. How can you know user/pwd is wrong? I double-checked it and is definetly correct. When changing one of them, the corresponding things will directly go offline (Doorbird binding + IPcamera binding).
Looking forward to your assessment of the curl-log.
Thanks so far!
That is very possible as the Doorbird range states very clearly that only 1 connection to the camera can be done at any time. Other brands of camera can do 10 or even 20+ connections at a time so the binding has not been tested by myself on Doorbird brand cameras and since a separate binding has been created its possible a problem exists and no one is reporting it as they are happy with the other binding.
Does the snapshot work if you use āsnapshots.mjpegā instead of the āipcamera.mjpegā stream? This way the binding can fetch only snapshots and feed both use cases from the same source.
Also what happens if you set the ONVIF port to ā8999ā instead of port 80? It is possible the binding trying to connect to ONVIF is counted as a connection and stops the snapshot from working.
That was enough detail to see thatā¦
The camera only support DIGEST auth.
It is HTTP 1.0 and not 1.1
It reuses the same http connection to do both of the DIGEST requests, the binding uses a second new connection and may get seen as two connections instead of just 1.
I think its best you try using āsnapshots.mjpegā to see what happens and dont use āipcamera.mjpegā until this is sorted out. Try the different ONVIF port as well and report back if anything has changed as the 3rd idea to do what curl is doing is a bigger change needed to prove it is the cause. Its less likely to be this since the mjpeg stream works and it uses the same code to open the stream and fetch a snapshot.
Yes, I also think so. I am also happy with the Doorbird binding, but to be honest I love the mjpeg stream in habpanel since it is much more smooth and I also prefer the ImageUrl to be accessible by http directly.
Now itās getting strangeā¦ For my Doorbird D101 the ImageUrl is now working. The - as far as I know - newer D1101 shows still the same behavior. The D1101 is IP 34 at the end, the one which Iāve send you the curl logs.
Port 8999 makes no difference for both Doorbird devices.
Weird. Based on your explanations, I was pretty sure that this will be the solution
Ok, got it. I guess it then makes more sense if I will find another way instead: (1) download current snapshot from Doorbird binding Image item or (2) create a 1sec gif per IPcamera binding as this will be shown in a preview as āpictureā in a mail also - different then *.mp4 - and the file size is also very small. Or do you see a chance to solve the issue within the IPcamera binding without ātoo muchā work?
This is not clear what you mean. Did it get fixed? If so what change fixed it and can you break it again by reversing the change to confirm it by reversing the fix?
What happens if you stop using the binding and open the mjpeg url directly from the camera in one browser and open a second browser and try and open the snapshot url and press refresh a few times. Does it work without issues doing it manually from the camera?
I do not know the cause of the problem. First confirm the cause and then we can talk about the fix. Also there is probably a work around or two that may work. But first letās confirm what the root cause is.
Ok, you are right, this was not really clear. Iāve double-checked all settings and combinations in both directions in detail again, please let me summarize for both cameras by its own:
My D101 is now working in all cases. I was struggling a bit first, but Iāve checked the first mails sent by mail binding - the ImageUrl was definetely not working before! In the first trial-loop (last post in this thread) I deleted the image widget in habpanel in order to elimate the MJPEG stream (btw: snapshots.mjpeg shows the broken image icon only). Then the ImageUrl was working. This is what Iāve posted before. Now it doesnāt matter what I am doing, the ImageURL Channel is working properly in all cases. Iāve double-confirmed with a test rule which sends a snapshot by mail per ImageUrl. The picture now is sent.
For my D1101 Doorbird device there is no difference in port and / or whether another stream is running in parallel or not - ImageUrl shows the grey dot only in all cases. The picture which is sent per Mail also.
This is really strange, I know. Any idea what should I check now?
The 500 http error code the camera is giving means an unknown internal error. You should look for a firmware update AND also power cycle the camera. The logs you sent showed that the http server in the camera is giving http version 1.1 for the 401 error which is normal for digest, then it reports http version 1.0 for the 200 OK snashot. This mixing of http versions seems strange to me.
Since you have 1 working and 1 not working, I would look at updating firmware and reporting this to their tech support for comment.
Also web browsers these days will keep streams running even when you navigate away from a page or delete a widget. You need to press STOP on the browser, refresh after you navigate away, or better still close the tab that the stream was open in. They keep streams running in case you push the back button and return to needing the stream. This may be complicating the testing if you think it is closed, yet it is still running. Rebooting the camera would be another way to ensure it has all stopped.
The firmware is the most recent one. I shut off / restart the cameras several times already (once again now), but still no difference. I also cleared the cache of fully kiosk and completely stoped it after deleting image widget (mjpeg stream) at all tablets. I even shut the tablets down. Unfortunately no change.
I will try to get help from the Doorbird support, but to be honest, I expect not so much helpā¦ However, thanks once again for your support! As workarround I will send a 1sec gif created by the binding per mail for the cam for which ImageUrl is not working. This is acceptable for the time being.
Based on your feedback it seems that this is not connected to having multiple connections open from a App or mjpeg streams. Also you have shown it works for the curl command. This leads me to believe it is the way the binding connects and asks for the snapshot unless the same thing occurs using curl and you just got lucky the time you ran the command.
So I have made some changes to the code as the binding was asking the camera to keep the connection alive, and then closing the connection on the camera, it is possible this change to telling the camera to close the connection may be a fix to the problem. It also wont try to connect to ONVIF and also wont try to accept a snapshot when the response is not a normal OK. Minor changes.
You can download the changed jar from here, just install the Tellstick binding to install the dependencies and uninstall the ipcamera binding before dropping it into the addons folder unzipped:
Does the camera have the ability to use BASIC instead of DIGEST auth if you look at the cameras setup settings? @wosch87
EDIT: I looked at the Doorbird binding and it only uses basic auth and not digest like this binding does, as the camera is telling the binding to only use digest. If the Doorbird binding does not have the same issue, then it would also point to this being a DIGEST issue and the fix in the jar may be the solution.
Also you may be able to replicate what the binding in this modified JAR does with this curl command, so if this command works I would be surprised if the binding fails.
Google what dependancy with java means. The log was not helpful as it appears that the whole command was cut short or I was reading it wrong. But the output appears to have created a feedback loop. Will be interesting to see if the binding works.
Maybe my question was unclear, sorry. I do not understand why I do need Tellstick binding as I do not use any Tellstick device at all? And what dependencies do you mean with respect to Tellstick binding (not in general - I did not get any help by Google therefore)? What does this all do have to do with my Doorbird devices?
I read the Tellstick binding docu, but as far as I can assess, the binding has no āotherā use than providing bridge / things for Tellstick devices. Thatās why I am struggling and do need a short info from your side please, whether I need to install it (and why) and also what I do need to setup as I expect that I will not be able to setup a Tellstick bridge - and no devices will be auto-discovered also. Thanks!
Edit: Iāve PMed another curl output as you are right, there was a mistake at my side!
You do not need to setup the telstick binding ,nor any brdige. Simply installing the binding is enough. Itās only needed when the changes are not merged but the hopefully fixed jar will not work unless you do.
Hi! Iāve followed your instrcutions and now the imageUrl channel is working properly, great job @matt1! Thank you very much for your help!
P.S.: I had an OOM shut down a few minutes after restarting OH with the jar file in addons folder. Unfortunately my PC was restarting completely, thatās why the log file was empty as OH starts at startup automatically. I do not know if this was somehow related to IPcamera binding or anything else happened. However, since this OH is running without any issue, so maybe it was just a single incident.
I highly doubt the changes made could cause a OOM condition. Thanks for testing and posting it works, I will look to get the changes merged. If you notice anything else does not work in the binding for Doorbird then please post so we can tidy it up. The binding should be able to know when the doorbell is pressed and also be able to switch light and door relays if your unit has them.
Hi @matt1,
I am facing following problem: The IPcamera Things are getting offline from time to time:
Of course IP and PORT are correct (and nothing has been changed in Thingās settings). Also the cameras itselves are reachable in the Doorbird App e.g. When pausing the Things and start again in Main UI, they become online again immediately.
Somewhen this night this happened again (I guess it was the 3rd or 4th time in total now). Iāve set the log level to DEBUG some days ago. So I was now checking the logs between the time when the last picture was send by Mail correctly (yesterday evening) and when the first Mail with a broken picture was sent (today morning). The only thing which appears to be something like an error is:
2022-03-10 22:00:32.552 [DEBUG] [camera.internal.servlet.StreamOutput] - FIFO buffer has run out of space:Queue full
[...]
2022-03-11 00:11:36.344 [DEBUG] [camera.internal.servlet.StreamOutput] - FIFO buffer has run out of space:Queue full
[...]
2022-03-11 00:17:36.645 [DEBUG] [camera.internal.servlet.StreamOutput] - FIFO buffer has run out of space:Queue full
[...]
At each time the lines appear several times with the same information.
Not sure if this has really something to do with the offline issueā¦ Do you have any idea where to look at? Maybe I need TRACE log, even the logs are very heavy then and itās difficult to check this high amount of lines when I do not know the exact time when the things are getting offline since the doorbell is not acting so often a day and the things may work a few days before getting offlineā¦
P.S.: I still have the jar file in addons folder, I did not change back to āofficialā version installed via UI, yet.
You should open a new thread. New thread so that it only contains 1 issue and then mark it as solved against the solution as you did in this one. This helps others find the solution when they search.
I think this is best to approach it as two things to work out.
What causes the camera to go offline.
Why does the camera not come back online automatically which is what should happen.
So try to get some TRACE level log output with all other cameras PAUSED so they dont make confusing log lines when the issue is already occured and we can hopefully get an answer to point number 2. This may be enough to work out a theory as to why it happens in the first place so we dont need to get log output when point 1 occurs.
Please do this and open a new thread and I can take a look.
