Thanks, this one: actionVariableValue: =( vars.rewind > 1 )?(vars.rewind - 1):1 is genius. And with much more clear brains today i’ve seen my mistakes. Almost did it, but a rather big issue still remains - the video is not loading when i popup the widget until two switches from live to archive. And used all kind of css sizes, but still can’t fit the entire video into page - a small part in bottom is hidden and shows up only in fullscreen mode.
I don’t see any obvious reason for this behavior, and the widget appears to function as expected when tested in the widget editor. This is just a guess, but I can only surmise that this has something to do with calling an f7-card as a popup. Since you’re only using it as a container anyway and not really taking advantage of any card specific features, you might try changing the base component here to a f7-popup. That might also make the final bit of css easier to fix that last problem of hidden bottom.
If i use f7-popup instead of f7-card or f7-block, then video height becomes NaN.
The error with non-loading video seems to come from parent widget not passing modalConfig (it’s shown as [object Object] in page inspector). Inside parent widget modalConfig is described like this:
to get away from all these ternary and undefined variables and got the same issue! No video on initial popover, but if i close popover and reopen it again - then i see hls stream working from the very first milliseconds, as if the stream itself started in the first popover.
I have had a lot of trouble today playing with the - component: oh-video-card and using it with the url: I found behaviour similar to yours until I changed to using it like this…
props.camera is the equipment level group, then all your member items can be guessed based off the auto naming convention that is used when you create equipment from things.
When ever you refresh the page, it fails a lot of the time if your using the url and not the item.
I can’t use item because for mp4 history i have to use URL. Maybe some kind of auto-refresh (like changing some variable inside key: ) needed on the first widget load.
Do you have more than one widget on a page calling this popup widget? I wonder if there’s some conflict with the settings.
It’s worth testing with matt1’s suggestion just to see if that is the problem. 1) Because it might be worth a github issue (if there isn’t one already) and 2) It would be possible (and only a little awkward) to convert this to a system that uses an item state instead of a variable if that turns out to be a fix.
And I’m pretty happy with them except the issue mentioned above. And note popoverClose: .popover.modal-in that’s the only way i’ve figured out to close the popover, adding class didn’t helped, maybe because the popover is called from another widget.
Try the following code, but make sure you have all items created first with the default naming convention, or just create the items with the “create equipment from thing” feature of oh3. You will need to tick the show advanced box to see the extra channels and add the mp4History and mp4HistoryLength channels to items/equipment, as well as all the non advanced channels.
If there is an easier way to fetch a uniqueID of a thing AND the IP of openhab. This would make the setup easier instead of needing a baseURL to be filled in by someone who may not know these details.
The first issue is not related to undefined variables but to the way oh-video and oh-video-card handles item: and url: properties. And… I’ve found a fix! And the fix is a bit crazy.
So what’s changed? Archive button visibility! So the widget accesses items[props.history].state before user can click to switch to archive, so when user actually switch to archive, that state is available already for oh-video!
@matt1 : When I click at the widget, the screen turns blurry. The small preview of the widget is fine and sharp. This is not only in edit mode; it’s always - also in run mode and in the app. Any idea what’s wrong here?
2022-08-21 22:46:49.013 [WARN ] [era.internal.handler.IpCameraHandler] - Binding has not been supplied with a FFmpeg Input URL, so some features will not work.
I also noted some “strange” options at the thing I never entered there:
Well, the binding has not been supplied with a FFmpeg Input URL, so some features will not work. =)
All options are ok, but does your camera has HLS-stream and is this stream enabled in Ipcamera binding? Do you see the stream, if you pass the URL from HLS-stream channel to videoplayer like VLC? If you don’t, could you check your camera with any tool like ONVIF Device Manager, get the camera’s stream URL from there and paste it to FFmpeg Input property of binding?
They are the DEFAULT settings which are needed for the binding to work, but the binding allows you to modify them if you choose to do something advanced.
If you have set it up as an INSTAR I would like to know why you get the WARN message you posted as ONVIF should discover the FFmeg input url automatically for you. To know what is going on I would need the TRACE level log from when the camera first connects and does its hand shake. Best to start a new thread on the forum for that. It may be that your firewall is blocking the ONVIF port so the binding can not connect.
did anyone get managed this to work on Android?
on my PC the widget works fine within the browser, and my cams are also working in the OH-app (Basic UI), but they showing just a grey block in the widget on Main UI.
I´ve read the topic, but didn´t find a solution.
Any idea?
Works the same in my case on any android starting from 5.1. @matt1, do you know if this a known issue?
In my case it sometimes work fine but mostly the thumbnail is greyed or blinking. When thumbnail is clicked it works fine.
Did you found a solution? My snapshot image is most of the time outdated and from the last time I checked.
The image which is use from the ip camera binding is fine.