so... that was wierd! I began the task of putting all icons back - I switched ONE to what I wanted, and all the others that I had previously switched all came back! Odd behavior, and I'm not complaining - it's just ultra curious! Time to snapshot so I dont gotta do that again....
I have android 4.4.4 1.0.1674 works, nothing above that. All the links above go to 1.8.xx. The version page on the document goes up to 1.0.14. I'm just looking for 1.0.1674, please.
It might be this change. That might be a side-effect but the buttons should be customizable now like any other tile
@jpage4500 - After returning home, I found that the video tile had failed again while I was away. This was before debug logging was turned on and was different to the previous failure as it displayed a message on screen. Unfortunately the message (that was also in the logs) was just:
5:49AM ERROR_CODE_IO_UNSPECIFIED, ExoPlayer (default) (14723496)
That's not usual but I'm not particularly concerned about it as it's the first time I've seen that.
I have since updated to the latest version (1.0.1859) and the video tile has failed within an hour or two and has not reconnected to the stream. It was sat with the red spinning circle on screen as usual. I left the dashboard to use the side menu, 'support', to save the logs to my hub and the stream started again when I went back to the dashboard.
The log at the time of failure shows:
12/19 17:44:35 D DeviceVideoView ExoPlayer (default) (170911518): onDroppedVideoFrames: 19
12/19 17:44:35 D DeviceVideoView onPlaybackStateChanged: state:2, ExoPlayer (default) (170911518)
After the failure I can see the following line in the log. However whatever this command does did not refresh the tile and the frozen image/spinning loading circle remained:
12/19 17:52:09 D DeviceVideoView connect: same URL:rtsp://myusername:mypassword@192.168.0.250:50002/Streaming/Channels/202/, ExoPlayer (default) (170911518)
With this version I have an unwelcome change. I have a number of virtual switches setup to operate as momentary buttons by setting the Auto Off option to .5s. On the dashboard I've changed the icons to red/green buttons and, until this version, they would momentarily change from the Off state to On and back. Now all switches and outlets bring up an on/off dialog instead of just switching like before. Any chance of making the old behavior optional, @jpage4500 ?
2 Likes
That's the additional step that was added to prevent accidental activation - Joe detailed it further up the thread.
I agree, it's an additional step, unwanted for most devices. I'd rather see a "are you sure" prompt added instead that required "ok" to be clicked, but I'd never want to add it globally to any device type. It would be great to be able to add that individually to specific tiles as I do in SharpTools (where you can set View, Control, Confirmation, Pin on a per tile basis). I use it for specific devices - Garage Door, the outlet that powers my CCTV NVR, and a virtual switch I have for 'Hub Reboot' - all things that I don't need a PIN for but prefer to safeguard against accidental operation.
1 Like
I'm sitting in a waiting room,bored. I saw this as well but mine fixed with slid right to open menu. Select More. Settings and change CLICK Action. That fixed me!
Ah, yes, I had missed the More Settings -> Click Action bit so I'll just go on my merry way. Sorry, @jpage4500 , for posting a non-issue.
EDIT: Perhaps the individual tiles should be able to override the global default?
Yeah, I did change that - sorry! I'll look into adding a way to customize what happens when you click on a tile. I can allow it to be per device type (ie: lights, outlets, valves, etc) or maybe even per device (although that might be overkill)
I don't have many use cases and as of now I'm good with all "toggles" but I think it unlikely that people will want all of one or the other.
That state:2 is buffering (which is why you see the red spinner) and is fairly normal. What I was hoping to see was something after this that started with onPlayerError: error: XYZ that indicated the stream failed.
Are you able to send me the log or at least any lines that start with DeviceVideoView:?
If there's nothing else in there about a failure that means I'm not getting any kind of failure to know the stream has stopped. I can look into if there's a way to 'check' if the stream is good and maybe do that periodically.. what's really going to help me is figuring out how to reproduce this. I did actually display 1 stream all day to see if it'd timeout and it never did.
/**
* The player is not able to immediately play the media, but is doing work toward being able to do
* so. This state typically occurs when the player needs to buffer more data before playback can
* start.
*/
int STATE_BUFFERING = 2;
I don't want the popup confirmation for switchs but want keep it for my door locks. Is there a way to disable confirmation by device type?
The issue with confirmations per device type is that it doesn’t take into account use case for the device. For instance in my system:
Shades. I have shutter modules controlling curtains and my garage door motor. I’d like some prompt on the garage door but not when I open the living room curtain.
Outlets. Connected to table lamps but also my CCTV NVR. Ideally I would confirm operation of the CCTV outlet so I can cleanly shut it down first but don’t want additional actions needed for turning on a lamp.
Switches. Used for lights generally, but I also have virtual switches for ‘Goodnight’, Hub Reboot etc. Confirmation is desirable for those but not for lights.
Currently my choice is to pin protect certain tiles. However a confirmation for many would be more appropriate. Operating a device with a confirmation prompt is one additional tap but adds some safety against accidental operation, while operating a device with pin takes around 6 taps which is likely to result in a steep decline of WAF.
In summary I don’t think ‘per device’ is overkill. It would probably be preferable for all tiles to default to standard operation, a per device option to alter to confirm or PIN, and perhaps that usual pop up we see elsewhere in the app (‘apply to this device or all ??? type devices’)
2 Likes
There was nothing else in the log other than periodic 'DeviceVideoView connect: same URL....' messages. However it has failed again this morning at 6:59 AM. I'm heading out but have saved the logs and will post back anything relevant a little later. Thanks
Edit:
Filtered logs shown below - there is no 'onPlayerError' message anywhere in the logs. There looks to be a set of actions carried out every 10 minutes:
- 'sync devices'
- 'fetchAllDevices'
- 'checkIfAllResposesReceived' and
- 'DeviceVideoView connect: same URL.....'
Summary
12/20 06:06:58 D DeviceVideoView connect: same URL:rtsp://admin:@192.168.0.250:50002/Streaming/Channels/202/, ExoPlayer (default) (167851414)
12/20 06:16:58 D DeviceVideoView connect: same URL:rtsp://admin:@192.168.0.250:50002/Streaming/Channels/202/, ExoPlayer (default) (167851414)
12/20 06:26:59 D DeviceVideoView connect: same URL:rtsp://admin:@192.168.0.250:50002/Streaming/Channels/202/, ExoPlayer (default) (167851414)
12/20 06:37:00 D DeviceVideoView connect: same URL:rtsp://admin:@192.168.0.250:50002/Streaming/Channels/202/, ExoPlayer (default) (167851414)
12/20 06:47:01 D DeviceVideoView connect: same URL:rtsp://admin:@192.168.0.250:50002/Streaming/Channels/202/, ExoPlayer (default) (167851414)
12/20 06:57:02 D DeviceVideoView connect: same URL:rtsp://admin:@192.168.0.250:50002/Streaming/Channels/202/, ExoPlayer (default) (167851414)
12/20 06:59:56 D DeviceVideoView ExoPlayer (default) (167851414): onDroppedVideoFrames: 15
12/20 06:59:56 D DeviceVideoView onPlaybackStateChanged: state:2, ExoPlayer (default) (167851414)
12/20 07:07:03 D DeviceVideoView connect: same URL:rtsp://admin:@192.168.0.250:50002/Streaming/Channels/202/, ExoPlayer (default) (167851414)
12/20 07:17:04 D DeviceVideoView connect: same URL:rtsp://admin:@192.168.0.250:50002/Streaming/Channels/202/, ExoPlayer (default) (167851414)
12/20 07:27:04 D DeviceVideoView connect: same URL:rtsp://admin:@192.168.0.250:50002/Streaming/Channels/202/, ExoPlayer (default) (167851414)
The failure this time was at 6:59:56. Although there is no error shown, each time it occurs the log entry is 'onDroppedVideoFrames:xx' so this seems to be key to the issue.
Again the failure is happening on all tablets at the same moment, so would appear to a momentary issue here - loss of connection to the NVR or suchlike. However there is no loss of recording or any event at that time in the CCTV logs (which are comprehensive). Anyway it certainly seems to be an issue at my end but it would be great to have it reconnect successfully when that occurs.
I saw that log entry too when testing my Reolink camera but it would always continue playing after a few seconds of buffering.
I'll spend some time looking into ExoPlayer issues and see if there's something similar I can find. Maybe I can keep track of when that 'dropped frames' entry happens and do a re-check in a few seconds to see if playback has started or not. If not, I can try forcing it.
However, in the meantime, I'd like to see if I can get the RTSP driver working for you instead. While the ExoPlayer video player can handle all kinds of video formats, that RTSP library is meant for IP cameras so that would probably be better to use anyway.
This is the github page of the RTSP driver. I just got the latest source code, built the sample app and put it here. Would you be able to load this apk on your device and try it? If it works (and stays connected for a while) then I'll try to figure out what I might be doing differently in the app. I remember there was someone else a while back who could get that demo app to work but not the dashboard.
1 Like
FWIW I have several switches/outlets and I also use many of them for lights. There's no 'light' capability/device type in Hubitat though. I'd either have to either change the device type from switch/outlet to lights or what I do is just add "light" (or "lamp") to the Hubitat label and the app will default it to a light device type.
For example, "garage lights", "bedroom lamp", etc.. all of these are just switches but the app will show them as lights. So, by default a single click toggles these on/off where any other switches/outlets will prompt me first. Anyway, that's how I get the app to distinguish these without any extra setup.
I can add this -- my only hesitation is the UI for it (and keeping it simple). I can test it and see what it looks like
2 Likes
I've loaded that RTSP demo onto one of my Fire's and it connects fine to the same Hikvision stream that I use in the dashboard (the one that will not let me choose RTSP for and so I have to use exoplayer). I'm not sure how long it will remain connected as the screen goes to sleep after a few mins. (Edit: I've enabled 'Stay Awake' in the Developer settings)
If I was to select RTSP in place of Exoplayer in the app - would the resulting debug of that attempted failed connection yield any useful information for you?
Edit: Here are the logs when I switch to RTSP for the stream in your app. No errors, but continuous reconnection attempts. Could it be failing to grab the username and password correctly?:
Summary
| 12/20 18:22:11 | D | DeviceVideoView | setDriver: updating driver:RTSP (custom), from:null |
|---|---|---|---|
| 12/20 18:22:11 | D | DeviceVideoView | playVideoRtsp: rtsp://admin:password@192.168.0.250:50002/Streaming/Channels/202/ |
| 12/20 18:22:11 | D | DeviceVideoView | parseLoginDetails: url:rtsp://192.168.0.250/Streaming/Channels/202/, port:50002, user:*****, pass:********** |
| 12/20 18:22:11 | D | DialogHelper | showEditDialog: TYPE_VIDEO, {attributes:{hd-videoDriver:VIDEO_TYPE_RTSP,hd-resizeMode:0,cropOption:CROP_FIT,tileWidth:7,url:rtsp://admin:password@192.168.0.250:50002/Streaming/Channels/202/,tileHeight:4},capabilities:,commands:,id:ID_VIDEO1,label:Video: rtsp://192.168.0.250/Streaming/Channels/202/,lastUpdateTime:1671034373795} |
| 12/20 18:22:16 | D | DeviceVideoView | handleMessage: reconnecting: RTSP (custom) (76348018) |
| 12/20 18:22:16 | D | DeviceVideoView | playVideoRtsp: rtsp://admin:password@192.168.0.250:50002/Streaming/Channels/202/ |
| 12/20 18:22:16 | D | DeviceVideoView | parseLoginDetails: url:rtsp://192.168.0.250/Streaming/Channels/202/, port:50002, user:*****, pass:********** |
| 12/20 18:22:21 | D | DeviceVideoView | handleMessage: reconnecting: RTSP (custom) (76348018) |
| 12/20 18:22:21 | D | DeviceVideoView | playVideoRtsp: rtsp://admin:password@192.168.0.250:50002/Streaming/Channels/202/ |
| 12/20 18:22:21 | D | DeviceVideoView | parseLoginDetails: url:rtsp://192.168.0.250/Streaming/Channels/202/, port:50002, user:*****, pass:********** |
| 12/20 18:22:26 | D | DeviceVideoView | handleMessage: reconnecting: RTSP (custom) (76348018) |
| 12/20 18:22:26 | D | DeviceVideoView | playVideoRtsp: rtsp://admin:password@192.168.0.250:50002/Streaming/Channels/202/ |
| 12/20 18:22:26 | D | DeviceVideoView | parseLoginDetails: url:rtsp://192.168.0.250/Streaming/Channels/202/, port:50002, user:*****, pass:********** |
| 12/20 18:22:31 | D | DeviceVideoView | handleMessage: reconnecting: RTSP (custom) (76348018) |
| 12/20 18:22:31 | D | DeviceVideoView | playVideoRtsp: rtsp://admin:password@192.168.0.250:50002/Streaming/Channels/202/ |
| 12/20 18:22:31 | D | DeviceVideoView | parseLoginDetails: url:rtsp://192.168.0.250/Streaming/Channels/202/, port:50002, user:*****, pass:********** |
I seem to have some issues with devices not updating their states correctly in the app, or rather the tiles not correctly reflecting the correct state. I don't know how to replicate this. It seems to occur when I have more than one copy of a device. As an example I have my door locks (which are actually generic sensors) on the main dashboard with a copy of them in another folder. The icons and tile colours are set exactly the same for both. If I open 'recent history' for both, it is identical and correct (currently closed). Yet one of them shows open and one closed. I'm having the same issue with a shade. Lounge Curtain has a tile on the main dashboard in the lounge and a copy in a folder. The one on the main dashboard was showing closed (when it was open) while the copy in the folder was showing open.
edit: So I deleted the copy of the tile that would not update and recreated it. Unfortunately every time I dragged it the copy to the folder I wanted it in, it would also appear in another folder where I didn't want it. Deleting the unwanted copy removed both. I also tried using manage folder items, instead of drag and dropping it but that emptied all of the spacer tiles out of the folder and dumped them on the main dashboard. I had to restore an earlier backup.
Sorry, not sure if this has been asked before, but just wondering if there's any plans of porting or making this app for iOS? This is by far the best dashboard and app I've found, it just sucks that I'm mostly an apple household with iPads, iPhones, etc. Only have one Fire HD tablet that this is running on, but I love it. Even if this could have an option for a webapp that could be used on any device, that would be amazing.
Why arent people just using pin's to protect against accidental activations? I cant understand why anybody would want to confirm anything. That would be entirely app breaking IMHO.
2 Likes
