Displaying HTML in a Dashboard Tile from a Device Variable

[garyjmilne]

I can format a device variable with HTML. Is there a way to have that HTML displayed properly in a dashboard tile.

Thought this would be easy, I should have known better. I suspect the HTML is not rendered to "protect" from attack but perhaps I'm wrong.

Any pointers?

Thanks.

[Navat604]

You can display your html link on an image tile.

Here's an example of my Google traffic map.

[garyjmilne]

Unfortunately it’s not an HTML link, just text wrapped in HTML for emphasis and formatting.

[snell]

If you are talking something like saving it from a Preference field, you cannot. Hubitat removed that capability as a code-safety/security issue.

However... I use a method for a number of my child drivers based on what mircolino originally had for HTML templates. Here is a link to one of them to see it.

In this case it consists of a number of parts because it is customizable by the users in Preferences, but if you want to hard-code the formatting you could (and that would make it easier). Basically it has:

1. An attribute "Tile" of type String that can be selected in the Dashboard to display the formatted data.
2. A Preference "TileTemplate" that allows the users to set what they want the Tile attribute to display.
3. Then you need to check every time a value is changed to see if it would alter the template. In this case (you can see in the code) I call UpdateTile within my ProcessEvent and ProcessState functions (which actually send events and update state variables respectively).
4. Then UpdateTile replaces the workaround formatting (users must put [] instead of <> around HTML in the Preference) and adds in any values that will be displayed.

Ex: The Preference is saved with:

[B]Temperature[/B]: ${ state.temperature }°${ location.getTemperatureScale() }[/BR][B]Humidity[/B]: ${ state.humidity }%[/BR]

The Tile attribute in the dashboard would display as (with some fake values):
Temperature: 60°F
Humidity: 35%

Of course you could add in formatting to set colors, italics, etc...

[garyjmilne]

Thanks for the post which contained the solution I was looking for.

I had tried a few different templates in the dashboard including variable and text. But reading through your post it mentioned using type “attribute” which I did and the embedded HTML displayed correctly.

So I can generate an HTML table, store it in a device attribute and the display it in a dashboard. Exactly what I was looking for.

Thanks.

[snell]

Glad it could help.

[garyjmilne]

@LibraSun

how to get a simple line break
into some text to be displayed on my Dashboard.

That was where I started a few days ago. Now I'm here.

[garyjmilne]

@garyjmilne

That was where I started a few days ago. Now I'm here.

And after a little more time I am here and most of the elements are customizable.

I'll be publishing my app in the next day or two so you can always wait and grab my code if it's helpful.

[snell]

Few pieces of feedback (assuming you have a preference for how many days inactive before a device gets added to this list):

1. Would you want to make the table have a gradient to it, where the "worst" devices are progressively more red?
2. Would you want a "warning" threshold? Some range where devices that are notorious for being quiet might end up, but before you know for sure they have gone completely silent? Not sure how many do it, but maybe things like contact sensors in unlikely locations or flood sensors...
3. Not sure if this would be easier to build in as two separate attributes OR you want to go to the hassle of building it into the HTML table... but the ability to sort it by Device Name OR Days Inactive might be good. If someone has a bunch of devices in the table, or they are flipping between the table and their Devices list.

I was going to add a 4th saying it would be nice to have the Device names link to the device page... but opening up a few of mine on one of my hubs shows their page is based on a number NOT the DNI as I had assumed when I thought of it. Not sure how/if it would be possible to correlate that anywhere.

[thebearmay]

The number should be the device.id. One word of caution attributes need to be <= 1024 characters to be displayed on the dashboard.

[garyjmilne]

Hi, all good ideas. This is where I'm at.

Because the device attribute is limited to 1024 characters it maxes out at about 10 rows of data it's pretty easy to take in at a glance. The more complex the HTML the less room there is for data. I'm of the opinion that this should be empty most of the time and that the presence of a device is probably an actionable event. But that is just personal preference.

I doesn't show on this screen but you can select the devices to monitor and you can have multiple instances of the app so you might have one instance for battery devices and a low inactivity threshold. A second instance might be plugged in devices with a higher activity threshold.

I do plan on adding a device link but have not got to that yet. The origins of this for me is that I have battery devices that die claiming they still have 100% of charge. Even quality devices like Samsung typically die at around 50%, so clearly using battery level as a pre-cursor to device failure is not a reliable method. So I took the approach of, how can I find out quickly if something has died.

I did try Device Watchdog and while it is very comprehensive I found it to be rather weighty with multiple apps, drivers and devices. So I wanted to do something lightweight hence this app that uses the built in Hub Variable as it's data store.

Thanks for the feedback.

[garyjmilne]

@thebearmay

One word of caution attributes need to be <= 1024 characters to be displayed on the dashboard.

I don't know if you have found the same thing but I have been able to store more than 1,024 characters and have them display, but eventually I get errors and then the whole tile malfunctions.

[snell]

I like how you have it mentioning how big the table is in your interface there. I keep forgetting about that character limit because I really do not have anything that would hit it with my drivers, but this is a good example of something that could!

I also totally agree with devices not bothering to say they are running down... I have things "stuck" saying there is motion or such because they have died off... but the battery also still says "good".