Maybe it’s stupid question, but which item is responsible for showing view from camera?
I have configured thing i paper ui and it’s showing online status, but I’m struggling with displaying it on sitemap. Any help?
New build 2020-09-04 now uploaded. This build will be the last one before some breaking changes will be introduced, so if you want to stay on this build and wait until openHAB V3.x is out then this build is using the latest code.
@Kim_Andersen This build should not put the entry in your logs anymore as it has a whole new way of doing things under the hood.
2 Likes
I thought that when your PR 8329 is closed binding will be included in addon refresh procedure and will be avaiable in 2.5.x versions. Addon update is still running.
If the binding will be merged before 2.5.9 is released I can not say, it is not up to me.
I need help testing the massive number of changes before it gets merged, so I plan to make a build for people to test with maybe tomorrow.
Anyone that has not set up the binding should wait a day as a test build with the breaking changes in it would be best to use before it is merged so you don’t have to deal with a large number of changes.
I am currently running the changes on my system and they appear to be working fine.
Ok I will check it on Jfrog time to time that it is included or not. What will be the exact name? IPcamera I suspect. As I use manual install still I will test latest version when you upload. I have 3 Pcs of Foscam 9800ip.
EDIT: binding is now merged into openHAB 2.5.9
Basically if you see anything in ALL CAPS in your files, they need to be converted to the newer standard in the docs.
1 Like
thank you matt hope i will find the time , i am in the middle renovation of for the new (olddd ) house i got
thanks allot for all the help!
1 Like
I was on the build version 2.5.4 (installed on 2020_07_23) - all worked fine. I renamed the old file and copied the new testing file into my addons directory, but now my cam stopped working in openhab. All my items, where i can see the path to the streams (rtsp, mjpeg and so on) are empty now.
Is this my fault? Do i have to change something, when i want to use the new test-binding?
Only short answer… If i have to change something, i hope i will find the information in this thread or the readme.
I don´t see anything in the logs (i have NOT enabled debugging yet).
Yes, you need to look at your text based files and everywhere you see something in ALL_CAPS you need to replace it with the camelCase version out of the new readme file. Just use find and replace to go through the files with, and you should be up and running pretty quickly as it is only renaming that has taken place.
If the binding gets merged for 2.5.9, you will have to do this then and also in openHAB 3.x so if you don’t want to do it right now there is a newer version without the breaking changes in the ‘old versions’ folder.
I would love people to help test the latest changes to ensure what gets merged is:
- As bug free as possible
- All cameras get auto detected correctly by the binding.
- It is painless to get things running and a helpful message is in the logs to say what went wrong.
- Default settings work for all cameras.
- Readme is accurate and helpful.
Thanks but it is still not working:
old
Thing ipcamera:DAHUA:CamEingang "Cam Eingang" @ "Cameras"
[
IPADDRESS="192.168.102.46",
USERNAME="admin",
PASSWORD="admin",
POLL_CAMERA_MS=1000,
SERVER_PORT=50001,
IP_WHITELIST="DISABLE",
IMAGE_UPDATE_EVENTS=1,
GIF_PREROLL=1,
GIF_POSTROLL=20,
FFMPEG_INPUT="rtsp://192.168.102.46:554/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif",
FFMPEG_OUTPUT="/tmpfs/camera1/",
FFMPEG_GIF_OUT_ARGUMENTS="-filter_complex fps=4,scale=480:-2:flags=lanczos,setpts=0.25*PTS,split[o1][o2];[o1]palettegen[p];[o2]fifo[o3];[o3][p]paletteuse",
UPDATE_IMAGE=false
]
new
Thing ipcamera:dahua:CamEingang "Cam Eingang" @ "Cameras"
[
ipAdress="192.168.102.46",
username="admin",
password="admin",
pollTime=1000,
serverPort=50001,
ipWhitelist="DISABLE",
updateImageWhen=1,
gifPreroll=1,
gifPostroll=20,
ffmpegInput="rtsp://192.168.102.46:554/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif",
ffmpegOutput="/tmpfs/camera1/",
gifOutOptions="-filter_complex fps=4,scale=480:-2:flags=lanczos,setpts=0.25*PTS,split[o1][o2];[o1]palettegen[p];[o2]fifo[o3];[o3][p]paletteuse",
updateImage="OFF"
]
Any idea?
ipAddress has two ‘d’ and the rest can be removed, so try this…
Thing ipcamera:dahua:CamEingang "Cam Eingang" @ "Cameras"
[
ipAddress="192.168.102.46",
username="admin",
password="admin123",
serverPort=50001,
gifPreroll=1,
ffmpegOutput="/tmpfs/camera1/",
gifOutOptions="-filter_complex fps=4,scale=480:-2:flags=lanczos,setpts=0.25*PTS,split[o1][o2];[o1]palettegen[p];[o2]fifo[o3];[o3][p]paletteuse"
]
edit:
@halloween dont forget that your item files will have DAHUA in them so do an auto find replace on them as well.
If camera is ONLINE the thing file should be correct.
If channels dont work it will be in the item files.
Thanks, that helped 
Will Onvif enabled cams get detected by name or by protocol (onvif) ?
Dahua cameras should get detected as ‘dahua’ thing type.
If you have a camera like Reolink that is not an API camera listed by the binding it should get then detected as onvif thing type.
In the newest binding, the moment you add the auto detected camera, it should take you to the page for user/pass and serverPort. After giving it those 3 things the camera will be online if all went well.
1 Like
Hy matt, thx for this longs and greats works.
I’ve got a problem with my foscam FI9826p V2 it’s an ONVIF devices and i can’t manage PTZ to work correctly. at the beginning (one year ago) with an older version of your binding PTZ worked but now…
i use the lattest version of the binding et openhab 2.5.8.1, everything works great except PTZ, automatic discovery working good too
here are my log
2020-09-08 22:42:09.829 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - End of FOSCAM handler reached, so closing the channel to the camera now
2020-09-08 22:42:17.442 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - Sending camera: GET: http://192.168.1.41/cgi-bin/CGIProxy.fcgi?cmd=getDevState&usr=XXXXX&pwd=XXXXX
2020-09-08 22:42:17.734 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - HTTP Result back from camera is :<CGI_Result>
<result>0</result>
<IOAlarm>0</IOAlarm>
<motionDetectAlarm>1</motionDetectAlarm>
<soundAlarm>0</soundAlarm>
<record>0</record>
<sdState>0</sdState>
<sdFreeSpace>0k</sdFreeSpace>
<sdTotalSpace>0k</sdTotalSpace>
<ntpState>1</ntpState>
<ddnsState>0</ddnsState>
<url>http%3A%2F%2Fhe4516.myfoscam.org%3A4143</url>
<upnpState>0</upnpState>
<isWifiConnected>1</isWifiConnected>
<wifiConnectedAP>Livebox-7166</wifiConnectedAP>
<infraLedState>0</infraLedState>
</CGI_Result>
Thx for your attention
I changed to using my own implementation of onvif recently to gain onvif events and make more possible. To fault find and possibly fix your issue I will need trace log when the camera is connecting where it does a onvif hand shake talking back and forth to look into it. Change a config that does not matter for the camera and it will reconnect and create the logs I need or restart the binding/openhab. Feel free to PM this to me to keep it out of the forum.
will HIKvision also detected ?
Yes mine does. I have tested with 3 models from completely different brands and they all work here. If you have any ONVIF camera that does not, then I just need some trace log when the camera does a hand shake.
Hi, maybe, this helps you:
I had simmilar problem with other Foscam camera - R4M. It hasn’t worked PTZ. First, I’ve checked response from the camera and I’ve noticed I haven’t got the XAddr but in the response I had something like this:
<tt:PTZ xsi:type="tt:PTZCapabilities">
<tt:XAddr>http://192.168.1.17:888/onvif/device_service</tt:XAddr>
</tt:PTZ>
Then I’ve checked sources of the binding and I’ve noticed that binding expects element '<tt:PTZ>' not '<tt:PTZ xsi:type="tt:PTZCapabilities">'. I’ve corrected this part of the code and now Foscam works properly with PTZ functions.
@yippicai
Thanks for sending the logs via PM, new build with hopefully a fix in it is uploaded.
@Lukas_1st
thanks for posting, it was useful to have your post as I can be sure the fix implemented should work on your cam as well. There was an additional issue for yippicai on top of what you pointed out.