I have hesitated quite a while to create a OH3UI and was still using the Classic UI. It stilll works great but I have to admit it looks a bit out of date these days.
The first thing I am struggling with is: Get my Mobotix T24 Camera image to show up.
In the classic UI I was using:
directly in the sitemap.
In oh3 UI I have tried various widgets - but none of them seems to be able to display the jpeg (stream) not even a still. As if the old basic authentication with user+pw in the URL does not work.
It depends on where and how you want to display the image. The most straight forward way to put an image on a Page is using the oh-image-card widget. oh-image-card - Image Card | openHAB
I have also Mx cameras integrated into OH. There are a few things you need to be aware of:
T24 do not support RTSP nor H.264 so you have to live with mjpeg stream. For this I recommend NOT to use faststream as this keeps the connection open even after you close the popup window
simply use /record/current.jpg instead
make the stream password unprotected. On google chrome browser passing credentials via URL is not possible anymore (http://user:PW@IP/record/current.jpg)
on iOS devices you cannot use https because of cross origin problems whereas on chrome browser on windows PCs the browser is able of handling these types of requests, but on iOS devices the screen stays blank
There is a great binding available (see above) which gives you a lot of functionality but for MX cameras don’t expect too much.
If your requirements are not too much (just live stream) I’d be doing it with oh-image and for door bell trigger or door open commands you need to use http-listener as MainUI does not accept http-get requests anymore, just http-post. T24 does not support http-post.
Thats exactly what is happening as modern browsers block it from working due to security concerns of broadcasting a password in clear text. You can use the ipcamera binding to serve the stream without a user pass if your camera can not have it disabled like a user suggested.
Yes this is the browser keeping it open in case you navigate away and back to the page for a quicker load and more responisve feel. If you press refresh on the browser after moving away from the widget, the stream stops. Or you can use the jpg file as suggested with a 1 second refresh to get a moving pic.
For these reasons, you may wish to upgrade to a camera which has more features if you are wanting them. If the camera is only missing a rtsp feed, then you need to change the ffmpeg input options to allow a mjpeg stream as the source which the change is in the readme under esp32 cameras special setup steps.
I completely understand that browsers evolve and nudge users and developers into paying more attention to security. This is a good thing and I am not complaining. Yet I am not fully convinced that this is the case here…
The chrome browser still works fine with the URL in the given format and also the app with the classic UI does.
I use a different widget showing a MJPEG stream from a different camera. This works fine so I presume there is no cross origin issue blocking the access.
I will try next to unprotect the live stream and use the oh-image widget.
From the UI it seems like it does (see screenshot). But I was not able to get any feed to show. Not with VLC and certainly not with OH. So if you are right - then I was tricked to believe in a feature which does not exist. Do you know by chance if the T25 or T26 have this feature?
[EDIT]
I just did that and it work fine now with the image card.
T24 has not enough CPU power. I found out that running rtp server, recording and maybe some other stuff like SIP call when door bell is ringing, is dramatically decreasing performance which might result in decrease of frame rate or even worse, resolution.
Overall, to me, too much hazzle - keep in mind the whole concept from end to end:
You are activating rtsp server specifically for transporting an mjpeg stream to an OH binding which loops the stream through ffmpeg (maybe additionally transcoding the stream) so that you end up with a video in an oh-image widget.
It was a better solution for myself that the camera is directly feeding the widget via an url link.
I see, I was wrong with rtp and I cannot remember exactly, but I think something was missing with MX rtp functionality. In the end, I think it worked, but it was too much performance required as my mx cams do constant recording, too.
It appears that your camera is setup to be mjpeg format and the binding assumes/defaults to needing h264 in the rtsp feed.
If you do this you need to supply this option: ffmpegInputOptions: -f mjpeg
However the better way would be to supply a http url if your camera has one to the mjpegUrl config. A rtsp url will not work in this case, so it needs to be a http url.
Yes using a jpg with an image widget on 1 sec refresh works, however it is only 1 frame per second. By using a camera that has a mjpeg url in http transport, then you can have much smoother 10 or more frames a second. The binding will also keep the mjpeg feed alive if your camera reboots if you are placing the feed on a tablet display you want to never stop. Using the cameras url directly will stop when the camera drops out or reboots, but via the binding it will auto start once the camera comes back online.
There are multiple advantages to using the binding over using urls direct from the camera, however the jpg directly with a refresh will work well and not have any downsides except it is only 1 frame a second.
Google around to see if your camera can do mjpeg via a http address. Even better if it has two streams and 1 can be h264 and the second a mjpeg stream.