Image (stream) in OH3UI

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:

Image item=dummy2 url="http://user:PW@IP/record/current.jpg" refresh=2000

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.

Any ideas what workaround could be pulled here?

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

Unfortunately neither has worked so far…
The image card stays empty, the mjpeg stream from the ipCam Binding does not show anything…

I read a few things that mobotix useres were able to use the image card… but I dunno what they did to get it working.

There’s lots of discussion on this on the thread @denominator posted above.

Here’s a simple example.

IPCamera Thing

UID: ipcamera:generic:garage_camera
label: Garage Wyze Camera
thingTypeUID: ipcamera:generic
  mjpegOptions: -q:v 5 -r 2 -vf scale=640:-2 -update 1
  mjpegUrl: ffmpeg
  updateImageWhen: "0"
  gifPreroll: 0
  ffmpegLocation: /usr/bin/ffmpeg
  ipWhitelist: DISABLE
  mp4OutOptions: -c:v copy -c:a copy
  pollTime: 1000
  port: 8888
  snapshotUrl: ffmpeg
  snapshotOptions: -an -vsync vfr -q:v 2 -update 1
  gifOutOptions: -r 2 -filter_complex scale=-2:360:flags=lanczos,setpts=0.5*PTS,split[o1][o2];[o1]palettegen[p];[o2]fifo[o3];[o3][p]paletteuse
  hlsOutOptions: -strict -2 -f lavfi -i aevalsrc=0 -acodec aac -vcodec copy -hls_flags delete_segments -hls_time 2 -hls_list_size 4
location: Garage

The Item is linked to the hlsUrl Channel.

You’ll need to configure the Thing and link to the proper Channel based on your Camera.

An example widget.

                - component: oh-image-card
                    item: GarageWyzeCamera_ImageURL
                    refreshInterval: 3000
                      height: auto
                      width: 100%

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

this would be your yaml code:

- component: oh-image
    height: auto
    lazy: false
    refreshInterval: 100
    url: =''
    width: 100%

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.

Thank you all for your suggestions.

The IpCamera Binding is supposed to access the camera stream and provide a mjpeg url. So far I did not get this to work. this is the code I use:

UID: ipcamera:generic:a9363a1b36
label: Mobotix
thingTypeUID: ipcamera:generic
  mjpegOptions: -q:v 5 -r 2 -vf scale=640:-2 -update 1
  updateImageWhen: "0"
  gifPreroll: 0
  ffmpegLocation: /usr/bin/ffmpeg
  ipWhitelist: DISABLE
  mp4OutOptions: -c:v copy -c:a copy
  pollTime: 1000
  password: "xxx"
  port: 80
  snapshotOptions: -an -vsync vfr -q:v 2 -update 1
  username: admin
  hlsOutOptions: -strict -2 -f lavfi -i aevalsrc=0 -acodec aac -vcodec copy
    -hls_flags delete_segments -hls_time 2 -hls_list_size 4
  gifOutOptions: -r 2 -filter_complex
  ffmpegInput: rtsp://
location: Haustuere

The port I have used here is the rtsp over http port, but I have also tried the “regular” rtsp port.

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?


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.

Are you sure? You can set the rate to any value through refreshInterval. See my yaml code above

Not all cameras can supply a snapshot faster then a particular rate and I have found mine stop at 1 fps. If yours can go faster then that is great.

Snapshot (usually only 1 fps) is different from Motion JPEG (MJPEG) stream :slight_smile: