… does hubitat plan to support this?
thanks.
Not at present. Do you have some use case in mind?
ok. quite a few but here is a simple example:
if you check my device handler here i have sections of with tiles commented out so the user can uncomment them if they want to see those tiles. there is no way for me to update the tile layout based on user input on settings.
then for settings its a bit more obvious but i cant update settings to show dynamically based on what tiles are selected or not selected to display.
thank you.
Hubitat drivers do not have tiles.
is that because there is no hubitat app yet or is it not expected to support device tiles?
if the later a straight port from DTH to driver will obviously not work. is there a recommend strategy for how to deal with this?
thanks.
We never intended to design around a mobile app as the centerpiece of the system, unlike SmartThings. It is another aspect of their architecture that makes no sense to us. So, if you have a DTH that is centric around tiles, you will need to rethink how you do things. Our mobile app is not intended to mimic ST’s mobile app. Our emphasis is not on control UI, but on automations.
A conventional DTH (in the historic sense) ports quite easily, with minor modifications. I’m not familiar with your app or DTHs so really can’t suggest what you should do.
Correct, we do not plan to support tiles.
UI does not always need to be a control mechanism it can be simply informative and thats how it is used in the rooms occupancy DTH.
all conventional DTHs (in the historic sense) from motion sensors to thermostats seem to have device tiles in ST to both inform and sometimes control.
so lets forget my app and DTH for a second. if devices in hubitat will not support tiles how are users expected to view device information like temperature, motion, presence, etc?
thanks.
Hey, your hub shipped today. Perhaps you should fire it up and find out!
ST mixed many things in their mobile app. It was part control interface, part configuration interface, and an essential element of their architecture. Stepping back you can see that their entire architecture was born of an iOS app talking to the cloud. We didn’t start there. None of us ever found the mobile app to be a compelling solution, certainly not as it was done in ST. So we reject both it’s control aspect, and its configuration aspect, as having merit. Obviously, we have rejected the notion that the cloud is the centerpiece of how all of this should work.
Hubitat has a very different architecture than ST. Yet, many things are largely compatible between the two. Mobile app and cloud centric approach are not on the list of compatibility.
5 Likes
ahh nice! drone left the hubitat warehouse already? 
thats my problem right now ... cant get my fingers on it. 
still good here. but there is a 3rd aspect to the mobile app which i believe should be considered. thats information delivery. users will want to view information about whats causing their automation to behave the way it is. not control it but view it to understand the behaviors they may see from their home automation.
rejecting cloud as the centerpiece is good here. however having the device in home does not take away the user need to quickly view various device information at a glance.
while ST may have conflated the mobile app with their cloud centric approach that is not necessarily a reason for hubitat to do so also. the mobile app as a standalone information mechanism is still going to be valuable for users to view device information quickly and easily.
my ২ paisa.
thank you.
1 Like
This is done in Hubitat, and is available in a mobile view, and will be available quite soon for remote viewing. Some users have SmartTiles running, using code they were in possession of.
You will see soon enough that your wants are met with Hubitat. And, looking forward to your own efforts to make it even better!
1 Like
cool. i try to stay away from control UI. 
looking forward to it!
thank you.
1 Like
Configuration parameters are sometimes added or changed in a firmware update so having a way to dynamically change the preferences based on the device's firmware version would be really useful.
Dynamic pages might be overkill for my use case, but it would probably get around the issue of not being able to use the device's data or attributes while generating the options for an enum preference.
2 Likes
Maybe not related to dynamicPage as such. But I did want to pitch in on how HE displays devices.
I agree with bangali that viewing information and status is essential. And although we do have that in the current device driver details, it is somewhat cluttered or hard to see things at a glance. That where tiles come into play and also where the mobile app will be important for people to quickly get an overview of their devices.
An example where the current device driver page is not ideal. I wrote a device driver for my Zigbee thermostats and although it works just fine, HE automatically added “pseudo” commands to the device page. I say “pseudo” because those commands don’t exist in my driver at all - they were just added by HE based on the provided thermostat functionality. This clutters up by screen and makes it difficult to actually find wha I am looking for.
So, the way I see the “tile” functionality in device drivers is the ability to control what is displayed in the device detail page. If I could for instance hide commands that HE would automatically add because I have no plans on adding them, that would be great. Also, having the ability to define which pieces of information my device provides to actually show and maybe even rearrange things so I can prioritize which information gets shown up top etc. would be good.
I am not complaining about the decision to concentrate on automation vs. control or cloud vs. not cloud. I like those decisions. But, wanting some sort of control both over the devices and how they show up in the HE UI or Mobile App doesn’t necessarily mean expecting a dependency on a mobile app or cloud. It’s just a request to have some more say-so in what is displayed. Especially with regard to things that currently display and are of no use.
1 Like
Just to give you an idea what I mean, since many device drivers do display few details and don't resemble what I am talking about.
This is what gets displayed by my Zigbee thermostat device driver:
Since this is a TRV it is always in "Auto" mode, so no sense in displaying it. It doesn't support "Cool" or "Fan" functionality, so another 6! pieces that are unnecessary in this view.
I also don't have setSchedule, setThermostatModeor emercencyHeat commands in my device driver.
As you can see my device view is cluttered with mostly commands that don't exist in my driver and the ones that do exist are scattered alphabetically and can't be grouped into like functionality. For instance "decreaseHeatSetpoint" and "increaseHeatSetpoint" would typically be next to each other. Of course here I could rename the commands to get them close together. But it would be nice to be able to set the order of commands as they are shown. And hiding unnecessary commands would be ideal.
The Current States to the right are fine for seeing data quickly. But, to be honest that would be better included into the device overview screen so you don't have to enter each device to see it. The device overview screen is a little low on useful information as it basically only shows if a device is ACTIVE or INACTIVE. Would be nice to see the "Current State" data in that table for a quick overview.
Don't get me wrong, I am not trying to be a complainer. I am just suggesting improvements from a usability perspective. In general I am quite satisfied with HE, especially the reliability so far (in addition to the local processing of course 
). And I am just steps away from cutting the cord completely on ST!!
2 Likes
