@matt1
As much as I would like to help, unfortunately I am currently away do not have access to my server/dockers for testing purposes. I will not be able to test this new binding until early November which I’m sure doesn’t meet you schedule. However just as an fyi I have been running OH3.3 docker release with ipcamera 3.4.0.202209021001 and a few rules to reconnect and keep ffmpeg alive, all is working very well.
Maybe that’s the point. I will test again this weekend and report later.
The camera is still working with the official Imou Life app on Android, and in the app timezone is set correctly according to my region. I will try to find out the reason why the timezone is so wrong
The camera will be getting the correct time from what is called an NTP server, which is why it allows the timezone to be changed.
The camera rebooting has wiped the time as it does not retain the time like more expensive cameras do. The binding tries to connect before the camera has fetched the time from the NTP. If you ever isolated the camera behind a NVR or firewall this would be a hurdle.
I suspect the camera is refusing to talk as openHAB is 22+ years in the future. So both points are connected to the reason it stops.
I am not sure about the best way to tackle this that won’t potentially break for another camera.
A rule that pauses the camera for a certain amount of time before unpausing it could be a work around triggered by the camera going offline.
I’ll have to think about this one for a way forward.
1 Like
hi matt,
I’m having some issues with the proxy stream… have a couple of ESP32CAMs (which just allow one stream with default project), but proxying has worked fine.
Then I changed and tried out on the thing properiets (e.g. gif preroll “variations”) and suddenly, the proxying is not working anymore…
what I tried so far:
- removed the cam thing
- recreated from scratch
- restarted oh / system
- checked ffmpeg output folder / properties
- reinstalled the binding
Thing ipcamera:generic:esp32cam "ESP"
[
ipAddress="192.168.100.57",
gifPreroll=1,
pollTime=1000,
ipWhitelist="DISABLE",
snapshotUrl="http://192.168.100.57/capture",
mjpegUrl="http://192.168.100.57:81/stream",
ffmpegInputOptions="-f mjpeg",
ffmpegOutput="/tmpfs/openhabcams/espbell/",
ffmpegInput="http://192.168.100.57:81/stream"
]
here’s the log, when I open a 2nd stream:
22:11:05.566 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.100.14
22:11:05.571 [DEBUG] [camera.internal.servlet.CameraServlet] - First stream requested, opening up stream from camera
22:11:05.953 [TRACE] [mera.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.100.57:81/stream
22:11:05.998 [DEBUG] [mera.internal.handler.IpCameraHandler] - Setting Content-Type to:multipart/x-mixed-replace;boundary=123456789000000000000987654321
22:11:23.096 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.100.14
22:11:23.099 [DEBUG] [camera.internal.servlet.CameraServlet] - Not the first stream requested but the stream from camera was closed
22:11:23.464 [TRACE] [mera.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.100.57:81/stream
22:11:23.484 [DEBUG] [mera.internal.handler.IpCameraHandler] - Setting Content-Type to:multipart/x-mixed-replace;boundary=123456789000000000000987654321
1st: any idea’s, why “the stream from the camera was closed” ?
2nd: is it also possible to add a timestamp to the stream?
e.g.
ffmpeg -y -i input.mp4 -vf "drawtext=fontfile=roboto.ttf:fontsize=36:fontcolor=yellow:text='%{pts\:gmtime\:1575526882\:%A, %d, %B %Y %I\\\:%M\\\:%S %p}'" -preset ultrafast -f mp4 output.mp4
as in the docu is described, the ffmpegInputOptions "Allows you to specify any options before the -i ".
what I just found…
I just commented the “mjpegUrl=” and started a stream. ffmpeg is now started:
21:29:13.747 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.100.14
21:29:13.753 [DEBUG] [camera.internal.servlet.CameraServlet] - First stream requested, opening up stream from camera
21:29:13.760 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - Starting ffmpeg with this command now:-f mjpeg -hide_banner -loglevel warning -i http://192.168.100.57:81/stream -q:v 5 -r 2 -vf scale=640:-2 -update 1 http://127.0.0.1:8080/ipcamera/esp32cam/ipcamera.jpg
21:30:12.875 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.100.14
21:30:13.450 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.100.14
21:30:19.163 [DEBUG] [camera.internal.servlet.CameraServlet] - Now there are 2 ipcamera.mjpeg streams open.
but the framerates are pretty low.
so I uncommented the mjpeg section and closed all browsers…
I expected again a high framerate and the same behaviour as on my post before…
but it behaves different…
I cannot help you unless it is a bug in the binding. The esp32 is a very low powered device and can have any number of firmwares loaded and I have no idea on what firmware you have loaded or what choices the firmware made. Because of the low powered CPU, the chip can not do high res and high frame rate video at the same time as regular snapshots. It has its limits and perhaps the firmware is making changes based on this. All I can suggest is you test the urls directly from the camera to see the results and compare, but when your getting snapshots the camera is not as capable for video, there is a trade off to be made.
I really think you should look at spending $10 more on a camera at least and you will get a far better result. The cheapest thing you can buy is not always the best VALUE you can buy. My esp32 cam just sits in the draw and only comes out when I need to run a test.
EDIT @maDDin1338
I did fix a bug last week that is merged that may have been the issue. But pausing and unpausing the camera or restarting openhab would reset things. If your using ffmpeg to create the stream and then edit the cameras settings to go back, it would not go back. The jar in this github PR will solve that or you can pause as a work around till the next milestone is released in a few weeks time.
Yes you can do that with the record to mp4 action. I use this to create mp4 files for each person that rings the doorbell that is timestamped. Then there is a MP4 history widget that makes displaying the recordings easy for the main UI. However you still have the issue with esp32 cameras that the stream is in mjpeg format and it takes a lot of CPU grunt to transcode it to h264. The widget could be modified easily to do the same with the GIF recording feature.
See the rule in this post for timestamps on the mp4 and gif recordings…
Custom Widget: Camera History and Live Popup - Apps & Services / HABPanel - openHAB Community
This post for the updated mainUI OH3 widget.
Camera MP4 Recording History and Live HLS - Add-on Marketplace / UI Widgets - openHAB Community
No idea, can you describe a way to reproduce this reliably? Suggest testing if the stream can be opened in a browser direct from the camera after pausing the thing.
Hi matt,
yes, indeed it’s not the best solution, currently it’s still WIP, later on there will come up better cams.
Just right now, I’m using the default example Code:
which is capable of streaming (1 client) and snapshotting without video breakup. on 640*480 it’s around 18-22fps, which is totally fine.
The proxying worked fine, had one stream opened in Firefox, one on Edge, one on a mobile device, but I’m not able to get it to run once again, so that I could bring you up the steps to reproduce…
I’m just always running into the same issue right now.
Opening the stream via the esp’s webinterface is working, cause it breaks up the (running) openhab stream.
After pausing and starting the thing, same behaviour…
Will continue to try and if I find a way to reproduce, will let you know.
thx 4 now.
EDIT:
@matt1 just checked you 3.4 build, same behaviour…
Just checked the binding Code… in CameraServlet.java line 177 ff:
if (openStreams.isEmpty()) {
logger.debug("First stream requested, opening up stream from camera");
handler.openCamerasStream();
if (handler.mjpegUri.isEmpty() || "ffmpeg".equals(handler.mjpegUri)) {
output = new StreamOutput(resp);
} else {
output = new StreamOutput(resp, handler.mjpegContentType);
}
} else {
if (handler.mjpegUri.isEmpty() || "ffmpeg".equals(handler.mjpegUri)) {
output = new StreamOutput(resp);
} else {
ChannelTracking tracker = handler.channelTrackingMap.get(handler.mjpegUri);
if (tracker == null || !tracker.getChannel().isOpen()) {
logger.debug("Not the first stream requested but the stream from camera was closed");
handler.openCamerasStream();
openStreams.closeAllStreams();
}
output = new StreamOutput(resp, handler.mjpegContentType);
}
}
So the handler gets lost of the Tracking (handler.channelTrackingMap.get(handler.mjpegUri); )
That cause’s the Stream’s to be closed and started from scratch, instead of adding another output.
Next question, why is it lost… or… why it is not added to the tracking map when started…
Can you clarify if you can get the first stream to work and its only the 2nd, 3rd etc streams that fail? Or is it that even the first stream fails to work? I need to know very exact details. Does the first stream continue to work when the binding is telling you the stream is closed? I can not see how your testing or using it, so you really need to spell out the exact details and circumstances or better tell me how to reproduce it here.
I did not see if you changed the settings back and if it worked again?
Its been a while since I tested and wrote the code. From memory when you press F5 or refresh a web browser with a single stream running, a race condition occurs. The browser closes the stream and opens a new one at the same time, and the order that the binding actions these two can change, which is why these are logged in case the tracking gets thrown out. In some cases the binding will try to open the ‘new’ stream which can take a second to complete, whilst the binding is closing a stream down so the binding can handle this, and the line logged is nothing to worry about, but it may be a clue that will help track down the issue. I have done in the past, very through testing on the tracking and it has handled everything I have thrown at it, but it is possible the esp32 camera is doing something different to cause something to go wrong but I would need the answers to my questions above.
My first though is that the firmware is not allowing the stream to open due to running out of cpu power in the esp32 chip, or its crashing in the camera. It also does not make sense why you can not cycle the power of the camera, put the settings of the binding back to what they were and have it work again. This makes me suspect it is the esp32 camera as the cause, but it’s worth looking at it as I do not run tests on the camera very often. I used the same example code to create mine from and had a lot of issues getting it all to run nicely but that was 2-3 years ago and I do not know the details of what was changed.
Hi matt,
1st stream is working, when 2nd is open, 1st fails, 2nd works, when 3rd is opened, 2nd fails and 3rd is working, etc.
No, the stream is not continuing to work, cause the Binding is closing it (CameraServlet.java Line 192-194)…:
logger.debug("Not the first stream requested but the stream from camera was closed");
handler.openCamerasStream();
openStreams.closeAllStreams();
Yesterday I tried a lot of variations, what I could think of, no success…
.
So, “from scratch” and procedure what I’m doing:
Thing (minimized, does not make any difference if gifpreroll used or not):
Thing ipcamera:generic:esp32cam "ESP CAM"
[
ipAddress="192.168.100.57",
// gifPreroll=1,
// pollTime=1000,
ipWhitelist="DISABLE",
snapshotUrl="http://192.168.100.57/capture",
mjpegUrl="http://192.168.100.57:81/stream",
ffmpegInputOptions="-f mjpeg",
ffmpegOutput="/tmpfs/openhabcams/espbell/",
ffmpegInput="http://192.168.100.57:81/stream"
]
Sitemap (provide the proxy stream):
Text label="ESP restream" icon="" { Video url="http://192.168.100.14:8080/ipcamera/esp32cam/ipcamera.mjpeg" encoding="mjpeg" }
Open the Stream with 1st Client (e.g. Chrome) via the Sitemap is working, Log:
09:30:07.897 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.100.14
09:30:07.905 [DEBUG] [camera.internal.servlet.CameraServlet] - First stream requested, opening up stream from camera
09:30:08.347 [TRACE] [mera.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.100.57:81/stream
09:30:08.376 [DEBUG] [mera.internal.handler.IpCameraHandler] - Setting Content-Type to:multipart/x-mixed-replace;boundary=123456789000000000000987654321
Connect with another Client (e.g. different Browser) to Sitemap and open it, 1st Stream (Chrome) is stopped, 2nd is started (and working)… Log:
09:32:18.697 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.100.14
09:32:18.700 [DEBUG] [camera.internal.servlet.CameraServlet] - Not the first stream requested but the stream from camera was closed
09:32:19.108 [TRACE] [mera.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.100.57:81/stream
09:32:19.136 [DEBUG] [mera.internal.handler.IpCameraHandler] - Setting Content-Type to:multipart/x-mixed-replace;boundary=123456789000000000000987654321
Well, the stream is working?
And of cause, the Code / ESP32Cam, can just handle 1 Client, but that’s what the binding should handle?
Cam => Openhab => Client 1
=> Client 2
=> Client 3
That makes it clearer thanks. Since the stream is still working from the camera to the binding, it is for some reason getting wrongly detected as being closed. I will need to do some further testing to see if I can reproduce it here over the next few days.
EDIT:
@maDDin1338
I was able to reproduce it and a fix is in the jar at the below PR if you wish to try or see what was changed. The bug was the mjpeg stream is using a port that is not port 80, so unless you changed the code of the firmware to serve on port 80 then I have no idea how it ever worked for you. I can open multiple streams, even turn the camera off and on again and all the streams keep working when the camera powers back up.
Also it may interest you that I got ffmpeg motion detection working by using the proxy streams as the source by doing this. I could open multiple streams up on different tabs, then start ffmpeg motion detection, turn the camera off and back on and when the camera reconnected all these were still working without intervention. I have not done tests on recording GIF and MP4 from a mjpeg source both with and without using the gifPreroll=1 vs gifPreroll=0.
If you do any tests like that or find other bugs, I would be keen to know before I pack the camera back away.
Thing ipcamera:generic:esp32cam "ESP CAM"
[
ipAddress="192.168.10.181",
gifPreroll=0,
snapshotUrl="http://192.168.10.181/capture",
mjpegUrl="http://192.168.10.181:81/stream",
ffmpegInputOptions="-f mjpeg",
ffmpegInput="http://192.168.10.12:8080/ipcamera/esp32cam/ipcamera.mjpeg"
]
Hi Matt,
just wanted to start with getting familiar with the addon coding in OH, but have seen your post 
Great that you could already find and fix the issue, so a big thank’s for that!!
Honestly, at least I didn’t play around with the webserver ports… but from what I can remember, it should have been the default project, which was working… but to be frank, I’m not really sure anymore…
Oh, the Motiondetection with the proxy stream also sounds great
After finishing this post, I’ll give it a try and install the PR Version 
EDIT: yep, working fine again thx
Will have some other things what I’ll try out in the next couple of days / weeks, if I find anything, will let you know
Just another thing which just came into my mind…
What do you think of providing a Channel (e.g. read only switch), to retreive the info if a Stream is running…?
Or a Channel, how many Stream’s are currently running / proxied…?
Currently have no concrete example in mind, but in general, it could / might be useful…
Maybe something like: if more then x streams are running (can assume, that someone is actively watching the stream), do not trigger any gif / mp4 recording…
Or… stop getting / refreshing images when stream is running…
As mentioned, no concrete watertight usecase… 
What do you think about this idea?
It may have been the FFmpeg created stream that was working and you did not notice it since the bug was preventing it from switching back to the cameras stream. This is plausible as to why you were writing it did once work for you. Thank you for reporting this and taking the time to do the tests.
Please do, the more people that contribute the better. I am happy to help people get over the initial learning curve because it is so important that we have more contributors so don’t struggle, just open a new post in the development area of this forum if you’re stuck. You found the lines of code successfully so you clearly are a valuable person that can contribute.
Great thanks for confirming. I rely on people giving feedback as I do not use these features myself on a daily basis.
I think that a number of how many are running can be used to know if the stream is stopped as well as the number, so that version makes more sense, and the binding already keeps track with a number already. You can see this number in DEBUG logs when a stream is closed the log tells you how many is left open, so it would be easy to add such a feature. As for what I think of it, I think you have hit the nail on the head, I do not see the value of doing it, nor an example of how it could make my smart home better. This means I do not want to spend my time coding it, but others are welcome to add it as this is opensource not a dictatorship There is also a cost of used system resources on the openHAB server by adding low value features that needs to be justified before I would support having it added and if you have a valid use case then go for it… For people that have 100’s of things, the load on a system can add up, this is why openHAB is a framework that is normally minimalist and does not throw all bells and whistles in with full history tracking (uses advanced channels to discourage adding all) like another software package I know of does. If you wish to know more, it would make a good thread of its own, just not here. This is why I do not have CPU load of the camera as a channel, or the date inside the camera as a channel and I could go on. The value of having it is not worth the cost it would have for what is just for a fancy UI to look impressive but would have real negatives for people with larger systems.
Has anyone experienced ipcamera logging causing your logs to go binary? Here’s what i’m seeing in my logs:
2022-10-14 15:37:36.971 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CAMERA_FrontYard_LastEventData' changed from <EventNotificationAlert version="2.0" xmlns="http://www.hikvision.com/ver20/XMLSchema">
<ipAddress>192.168.x.xxx</ipAddress>
<ipv6Address>::ffff:192.168.x.xxx</ipv6Address>
<portNo>80</portNo>
<protocol>HTTP</protocol>
<macAddress>xxxx</macAddress>
<channelID>1</channelID>
<dateTime>2022-10-14T15:27:23+08:00</dateTime>
<activePostCount>1</activePostCount>
<eventType>linedetection</eventType>
<eventState>active</eventState>
<eventDescription>linedetection alarm</eventDescription>
<DetectionRegionList>
<DetectionRegionEntry>
<regionID>2</regionID>
<sensitivityLevel>50</sensitivityLevel>
<RegionCoordinatesList>
<RegionCoordinates>
<positionX>598</positionX>
<positionY>175</positionY>
</RegionCoordinates>
<RegionCoordinates>
<positionX>598</positionX>
<positionY>47</positionY>
</RegionCoordinates>
</RegionCoordinatesList>
<detectionTarget>vehicle</detectionTarget>
<TargetRect>
<X>0.532031</X>
<Y>0.0680556</Y>
<width>0.0851563</width>
<height>0.0513889</height>
</TargetRect>
</DetectionRegionEntry>
</DetectionRegionList>
<channelName>Front Yard</channelName>
<detectionPictureTransType>binary</detectionPictureTransType>
<detectionPicturesNumber>1</detectionPicturesNumber>
<isDataRetransmission>false</isDataRetransmission>
</EventNotificationAlert>
to <{�4�ո�}Li�]���|��n{�q�ƻ+NT�z�iۛ����������oxr]���j�������M����K�a�f���Ֆ�ammb�MN�6Ŗ2
���9^�pk�>|6�¿|Wo|��C��%��\����IKC��?Ƹ�s�ӷ��x�E�w�=�̵����+�.Y���ό��s���ZJsR�ӷB-ae?#����+�k^&�e���M�����h���/:�j����|E�e�n�ǹk��#`B�F��
g�W-�w��n�F�h�]d�H����<�Qץt���ZK��i��+Q�x��Q��C�0��� �a�l�T/Z��E�*��)����Q7�#�by�����@J�#���a-��0k��.��l_fXd���,Ѫe���lg&��K���K��O�-5�3-¤�c��|����}
Þ���f��:_����eh_��̟�W��"��q�/�B|�ױ���y�-��4�<Kjf�)$0�����FY[�����ti�@�@��>�
�1C��+ �Z���U�k��J^��S{�W
�Hɕ(H� �����'Ş��2Cu������Y=�K�:�0C
t5�lK��:�S�eY���f����wc��Am*$�$��&43td��A\�ֵ
Mw��6�W��Z5��,06/��l��H皋��(�������O�f%�Kؕ����X�*�����U���h��L��o��T*7*�� �`G�k���jBчO�C��8I�7�?����ῷ�k^\�'�=��<�v���}� 0��p_[�ń��K�����G���s�c����Q��m$mj�Ħda3)%�#�<�
yDž>-Z�_R��ñ*��i�+]܌�7��8#�aڼ�
Z^ۖ���3��-e�����;Hu�GL:9�+
�6M����3�|��0j��i�Em��c%��
Hi,
does anyone connect to an annke/hikvision nvr to set `enableMotionAlarm to on or off?
Is the config below correct?
I do not get an error mesage with logging to info that would show the error…
Thing ipcamera:hikvision:MyCamera “NVR”
[
ipAddress=“192.168.4.123”,
username=“Myuser”,
password=“MyPassword”,
nvrChannel=1,
onvifPort=80, //normally 80 check what it needs
port=80
]
The API needs to be enabled by ticking a box in the cameras internal setup pages before it works and a user/pass needs to be created. See the bindings readme for info on this. Its also possible it does not have the reply stored if it works after you try to use it more then once in a row. You should activate DEBUG or TRACE level logs to get more information to fault find with, how to do this is in the bindings docs in the very first lines on how to get help.
I have my openHAB’s log look like this and then I find out the reason is the SSD is bad. Did you notice that sometimes openHAB hangs or not responding?
I thought that was the problem too but i don’t think thats the case. I do NOT get any hangs in openhab, the server runs perfectly fine.
In anticipation of hardware failure i actually just upgraded my server hosting Openhab to new hardware and new SSD’s in a RAID array. No errors on any of the new disks but the binary logs still occur.
The binary logs ONLY happen to events.log and everytime the corruption is triggered the changed to item is a camera event. Not sure if that is related, but im just trying to narrow this down
- Does the actual raw log file change, or is it only the viewing of the file through frontail for example that gets upset?
- Have you tried a different web browser?
As a work around you can filter out lines from going into the logs. I used to filter out these changes because the raw image data gets logged and was flooding the logs, hence I know it is pretty easy and I posted how to do it somewhere in this forum.
Just found it in an old readme…
events.log
By default openHAB will log all image channel updates as an event into a file called events.log, this file can quickly grow if you have multiple cameras all updating the image channel every second.
I believe it is possible for enough high resolution cameras to flood and swamp the event bus with more incoming data then the system can process, even if the logs are disabled. So I highly recommend to not use the Image channel and instead use another method outlined in the snapshot and streaming sections of this readme file. If the data is coming in faster then it can be processed it will result in an Out Off Memory Error (OOME) that can halt your Openhab server, so if your reading this to shut down the logging, reconsider the need to use the Image channel.
If you still wish to use the Image channel, the following is how to deal with the log output that is created as the raw picture data in text format is ugly and makes the log very hard to read.
You can switch to only updating the image channel on EVENTS like motion alarms.
Turn off (disable) all events from being logged.
Filter out only the events caused by the image changing before they reach the log file.
The openHAB event.log does not allow normal filtering at a binding level due to the log being a pure output from the event bus.
To disable the event.log you can use this command in Karaf console.
log:set WARN smarthome.event
To re-enable just use the same command with INFO instead of WARN.
To filter out only the image events, leaving the rest you can do the following:
sudo nano /var/lib/openhab2/etc/org.ops4j.pax.logging.cfg
Inside that file paste the following, save and then reboot.
############ CUSTOM FILTERS START HERE #################
# event log filter
log4j2.appender.event.filter.myfilter1.type = RegexFilter
log4j2.appender.event.filter.myfilter1.regex = .*changed from raw type.*
log4j2.appender.event.filter.myfilter1.onMatch = DENY
log4j2.appender.event.filter.myfilter1.onMisMatch = ACCEPT
################# END OF FILTERS ######################
You can specify the item name in the filter to remove just 1 camera, or you can use the above without the item name to remove all events from images updating, which will be for other bindings as well.
The problem is caused by a call to a resource within the camera, that is not available: /ISAPI/System/IO/inputs/1/status
Although the binding says it stops checking this feature, each change posted to the camera results in the same error.
Is there a way to disable this query to the camera? I have not found an option within the camera to enable this feature.
The trace log:
2022-10-26 09:00:34.616 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.x.x:80/ISAPI/System/IO/inputs/1/status
2022-10-26 09:00:34.629 [WARN ] [ipcamera.internal.MyNettyAuthHandler] - 403 Forbidden: Check camera setup or has the camera activated the illegal login lock?
2022-10-26 09:00:34.631 [TRACE] [g.ipcamera.internal.HikvisionHandler] - HTTP Result back from camera is :<?xml version="1.0" encoding="UTF-8"?>
/ISAPI/System/IO/inputs/1/status
4
Invalid Operation
invalidOperation
:
2022-10-26 09:00:34.632 [DEBUG] [era.internal.handler.IpCameraHandler] - Stopping checks for alarm inputs as camera appears to be missing this feature.
Does your camera have terminals for connecting to an alarm? My guess is it does not have this feature. See here for a fix which once the PR builds the link to a JAR can be used to test it out.
EDIT: It could also possible be caused by using a user/pass combination that does not have rights to access this feature of the API. There is usually media/user and admin rights so that could be another reason for it due to the 403 Forbidden http code. Either way this PR should help you out.