Swiping slower helps too. You'll also see a back icon as you swipe, and as long as you don't lift your finger, you can slide back towards the edge and cancel the Back function. Still bites me a lot. I'll have to try the 2 finger swipe.
heya @jpage4500 !!!
My environment has been so useful I've not spoken up in a while. No doubt you're happy I've gone away grin.
I've always felt that HE has a big weakness - and I think you can fix/improve things. Here's my issue:
In my environment are 2 distinct categories of bulbs. I have dimmable (and dimmable CT) and I have color bulbs.
I have fixtures all over my house with multiple sockets - so that means I use groups to create a 'team' of bulbs in a fixture. Then all my rules refer to these 'teams'.
HE only offers a group of 'bulb dimmer' regardless of capability of the actual group. The result is I'm forced to be aware the group cannot do color, ignore the hue, saturation etc.
Now when I add a group to Android Dashboard, it picks up the same failure. I have 'color' capable device tiles for devices that can't do color. It truly sucks. (side note -I posted my thoughts on this matter a long while ago and got no traction with the HE folks).
My suggested solution: For devices that appear as 'Dimmable RGB Light' - allow a 'Dimmable' device type without the color features. Supporting Colortemp is, in my mind, different than color. The drag bar of CT is perfect and if separated from Dimmable RGB the distinction would allow your app to move the ball forward in this area. What do you think?
Interesting.. I hadn't used groups before but I created one to test with.
So, just to repeat what you're asking for.. basically adding the option to remove the 'set color' ability for any RGB supported device.. is that over simplifying it? That makes sense - either with a different device type or just an option to hide the color UI portion.
That actually was kind of an area I was already working on. I have several dimmable lights and get annoyed when I accidentally adjust the dimmer level while just trying to scroll through devices on the dashboard. I was adding a global setting to hide the ability to dim lights from the main dashboard. It would still be available when you press and hold any light though.
@jpage4500 Yup! I think you're vision mirrors mine!
If you have the right devices you can simulate it - its a horrid mess. Make a group of color bulbs. then make a group of dimmable bulbs - and honestly theres a 3rd, dimmable CT bulbs.
When your code senses a group it seems (at least in my case) to always assign 'Dimmable RGB Light as the device type, regardless of which of the 3 types I've just described. If your code had the ability to allow me to select , say, for example 'Dimmable Light', Dimmable CT, or Dimmable RGB' and the properly equivalent tle to match, it would be the best Christmas gift Ever.
I harped about this to Hubitat about a year ago - at that time as I recall I was told 'it's just a group, don't worry bout it'. Since then (and recently actually) there has been some small progress in groups in that there are now 'Group Switch, Group Dimmer and Group Dimmer Bulb' choices. Still, that means I get a device with buttons to click that have no use or value. (again, just speaking for myself but there MUST be so many others with the same issue!). Why have Hue and Saturation buttons on a group of CT bulbs? Same with CT values for a bulb group of dimmable only bulbs. It's senseless IMHO and undoubtedly a legacy oversight. Someday, maybe HE will get there and do this better/right.
if you're still reading - I'll add that I truly disagree with the whole implementation of HE groups in general - to me, in my mind a group is devices chained together - like a switch and an outlet. A better descriptor would be a 'team'. identical devices like 3 identical bulbs in a single fixture. Like my bathroom light has 3 bulbs in it. they are all CT/Dim. they work as a team - hence my terminology of 'Team' to describe them.
Anyways. Sure hope you decide to pour some of your considerable brain power at this! Home Automation life without your dashboard would be unbearable! I haven't had to even look at an HE dashboard in months... I LOVE IT.
version 1.0.1373 (beta)
- add option to hide dimmer controls on main dashboard
- show dimmer slider in device options
- new 'remote' device type (Logitech Harmony Hub driver)
- smaller backup file format (not saving null or empty values)
There's a new option in the edit dialog of any dimmable light - Dimmer Control. This is a global setting for all dimmable lights and lets you select between Slider, Circular Control and Hide. For now the Hide option will show the circular control with how bright the light is -- but it's not something you can use to change the brightness.
-- I debated actually hiding the circle and might change this but I did want to make it clear how bright the light is set at -- and also prevent accidentally changing it when scrolling.
Because of the new 'Hide' option, I added a new option to control brightness from the device options screen
Lastly, if you have the Harmony Hub device driver it'll use a new 'remote' device type. Right now there's only on/off/mute commands but the idea is to be able to customize this to send any custom command in the future
-- note this is for the parent Harmony Hub device, not the children 'activity' devices which only support 2 commands: on and off
2 Likes
Downloaded and installed and I see the update(s), but the app is still reporting version as 1.0.1361.
Sorry for the delay - I feel like live video support using RTSP is getting closer.. I've finally got a device that supports RTSP and it's been working - at least for the limited testing I've done. I'm relying on an open source library for this and the author of this has been making lots of changes. In fact, I see several new updates and I'll incorporate them into the app in the next update.
As for the offer - I appreciate it but I should just bite the bullet and buy one. I'm personally leery about Wyze only because from what I've read I'd have to replace the firmware to support RTSP -- and doing that will break the cloud support. I'd like a camera that will work remotely (using the supplied app) as well as locally via RTSP. I've also already got a few cameras today and if possible would like to use the same app and not have to add yet another app for just a single camera...
@jpage4500 I nearly pee'd myself! It really is a beautiful enhancement! The array of configuration choices now covers all my bulbs, groups and types!
I've one problem however. Any change I make seems to affect all bulbs. So bulbs that are color capable, I loose the ability to color config them from the tile face, although of course it still works nicely inside the tile management.
In the image below - I've got a 'team' of 2 Sengled bulbs which are dimmable only. No CT or color. As you can see, your implementation looks amazing. To the left, is a Group called Office Lights. Since the group is all-purpose and assumedly the device type is derived from HE, they pull a Device Type of Dimmable RGB light. HE is feeding you crap - there is no way in devices on the HE for me to flag this group as Dimmable only. All groups, regardless of ability appear this way.
If you can add 2 options on this screen, it would create a solution for all.
By adding 'Dimmable Light' and Dimmable CT Light' the assignment of the tile template would derive from main dashboard for each of these device templates and it would work perfectly!
Just so you know, I'm very grateful you are even considering my thoughts!
The latest change wasn't meant to address what you were asking for earlier -- hiding that color control for a given light. It was just a start to removing additional actions from the main dashboard tile. I didn't want to just remove it from existing users though so I made it a setting.
My idea was to put these non-primary actions (set color, set color temp, set brightness) into a larger view that showed when you long-press on any light tile. I'm thinking through how to implement this now. I'll also think about how to hide any given capability like setting color. Right now, I'm using the device capabilities but now I know that they're not always accurate - as in that group case
1 Like
No problem. Its here if you need it. But I'm not sure what you mean by loosing cloud support. The Wyze cams still work fine with remote access via the app with the rtsp firmware. From my experience trying to make them work with ST and habitat for the Last to years, I think that the Wyze implementation leaves something to to be desired.
I do have one feature request. While you are improving the rtsp thing, it would be nice if you could add an option to update or reload the video every so many seconds. So when the video hangs, it will simply reload. The hubitat dashboard added this option a while back and it helped a bunch.
Good to know about Wyze RTSP - I thought replacing the firmware to support it broke the cloud (app) functionality. I just ordered an outdoor camera (Reolink) which supports RTSP out of the box so I'll test with that for a while.
My hacked Yi camera works but after some time the image freezes.. Since it's a hacked camera I'm not sure if that's because of the RTSP server or the library I'm using to display. Anyway, having an official RTSP camera will hopefully give me more testing data.
I was also wondering if I should try to auto-reconnect or do something when the image freezes if this is a common problem. In my case (Yi) I don't think the app was notified that the stream had stopped -- meaning the library still thinks it was connected. But, I can try to work with the RTSP library author to see if he can figure out if something happened to the connection.
It does seem to be a common problem that the feed freezes. I have two Wyze Cam 2 cameras and an Amcrest camrea. My current setup is to go through TinyCam on a pair of Raspberry PI's. I use two to keep the load down on the PI's hoping that would help. I'm still using the hubitat dashboard simply because of being able to use the reload timer every 60 seconds on the feed. Even the http: feed from TinyCam freezes after a while but since it originates with the camera rtsp feed, its hard to get a handle on what is causing the problem. I have, like many, been fighting this for a few years with ST and hubitat. I even ventured into home assistant for a bit but had the same rtsp problems so I gave up on it. Your app is the first ray of hope I've seen for quite a while.
For me, the timer to reload the image would go a long way to helping. I could then get rtsp directly off of the cameras and can the TinyCam servers running on the pi's. Even if it freezes, it would still give me us reasonably update picture on the dashboard.
version 1.0.1375 (beta)
- update RTSP library
This version just updates the RTSP (video streaming) library to the latest version. I also built and uploaded the sample app that comes with the library for anyone to test with their RTSP enabled camera.. If it works in the demo then it should work with the app as well.
I've loaded the .1375 update. Here is what I've found with my 2 WyzeCams and 1 Amcrest camera so far;
Both WyzeCams still hang after about 10 to 60 seconds after loading the page. If I tap on one of the WyzeCam images so that it has the full screen, it will run longer, up to 30 minutes. But, it will eventually hang.
The Amcrest. I finally got an rtsp link to work for this camera's video, but.... It works on the sample app just fine but, using the same url, it will not load in the dashboard app. It just sits there and gives me a blank panel.
The dashboard I'm working with has three video panels in it, one for each of the cameras I mentioned. If I create a new folder with only the video panel for the Amcrest camera, it will still not load with the url that works with the sample app.
I got my Reolink camera and have started testing too so hopefully that's going to help. One nice thing about this camera is it has a timestamp/watermark on the feed so I should be able to tell how long it runs for. I'm starting with the demo app for now to just test the RTSP library and then test the app to track down where the issues are coming from.
I tried the dashboard and sample app on my samsung phone (s8). In messing around with it, if found that what I said before is not exactly true. I haven't really found a good rtsp url for the Amcrest camera. Everything I read says that I should use "rtsp://user:pwd@ip:port/cam/realmonitor?channel=1&subtype=0. I have never gotten this format to work on any device or app. With your sample app, I was able to get reliable feed using that format without the "user:pwd@" and putting the user and pwd in the fields in the app on both my phone and lenovo tablet. That makes me ask, is there a url format that the sample app uses to send to the camera when it combines the url, user and pwd.
One additional thing for you. With messing with my two WyzeCam's, I found that with only one cam loaded on the main dashboard page, it seems to work much better. As soon as I add the second camera tile, I start to get the hang ups more often. Sometimes both cameras will hang up within 10 seconds and sometimes only one camera will hang up. When only one hangs up, the second camera will continue longer that the normal 10 seconds, up to 10 minutes. But it will eventually hang up. I'm seeing the same behavior on the tablet and the phone.
I just managed to get the Android Subsystem running on my Windows 11 PC.
I don't think I will ever be using the official dashboard again.
5 Likes
Just started playing with this app last night. Really like how clean it is. (Playing with it on a Fire tablet 8 gen 10 and hope to see it on IOS soon!) So far, the only issue I've seen is a Garage door button. I use a zen-16 for the garage door but only switch is available for it. I think it would be more intuitive if it could be classified as an up/down garage door. (Though to be fair I may have overlooked something obvious)
I'm using a zen relay for my garage as well but I have a virtual garage controller set up for it. I have the virtual controller exposed to dashboard, not the relay itself. Works as expected.
2 Likes
