[BUG REPORT] Attribute Preview on an HTML string in a Device Attribute sometimes incorrect


Platform Version 2.4.1.164
Hardware Version C-7

This is my test hub but I have also observed this on my C-8 Pro. I have simplified this post as I have learned more.

I have an app that writes HTML links to attributes within a device driver. If I write 4 unique links to four different cloud endpoints then the driver displays them all as being the same, as shown below, when in fact they should all appear differently.


This behaviour even extends to providing the wrong information to the dashboard if it is linked there.

I'm using the most current version of Chrome, Version 135.0.7049.115 (Official Build) (64-bit). I've also tried Edge and get the same results. So I can only assume that this is a Hub caching issue and that it only matches a certain length of a link before it deems it a match.

You should be able to easily reproduce this error using this simplified driver code. Install it as a driver and click on the createErrorConditions button.

// Remote Builder Bug Test Driver

metadata {
	definition (name: "Remote Builder Bug Test", namespace: "garyjmilne", author: "garymilne", importUrl: "https://raw.githubusercontent.com/GaryMilne/Hubitat-RemoteBuilder/main/Remote_Builder_Storage_Driver.groovy", singleThreaded: true ) {
        //capability "Variable"
    }
    
    attribute "Remote1", "string"
	attribute "Remote2", "string"
	attribute "Remote3", "string"
	attribute "Remote4", "string"
    command "clearAttributes"
	command "createErrorConditions"
}


void createErrorConditions(){
    	state.tileDescriptions = [:]
        
        HTML1 = "[!--Generated:1745810094472--][div style='height:100%; width:100%; scrolling:no; overflow:hidden;'][iframe name=2975-A src=https://cloud.hubitat.com/api/46fae574-103e-45ae-ad0d-fb16e2c28bd5/apps/2975/tb?access_token=8fce4a96-37e6-41d6-9dc9-1d304a96aaf8 style='height: 100%; width:100%; border: none; scrolling:no; overflow: hidden;'][/iframe][/div]"
        sendEvent(name: "Remote1", value: toHTML(HTML1) )
    	state.tileDescriptions."Remote1" = HTML1
        
        HTML2 = "[!--Generated:1745810094472--][div style='height:100%; width:100%; scrolling:no; overflow:hidden;'][iframe name=3009-A src= https://cloud.hubitat.com/api/46fae574-103e-45ae-ad0d-fb16e2c28bd5/apps/3009/tb?access_token=2812af84-b0df-4de2-9359-efb7bd6f5426  style='height: 100%; width:100%; border: none; scrolling:no; overflow: hidden;'][/iframe][/div]"
        sendEvent(name: "Remote2", value: toHTML(HTML2) )
    	state.tileDescriptions."Remote2" = HTML2
        
    	HTML3 = "[!--Generated:1745811905376--][div style='height:100%; width:100%; scrolling:no; overflow:hidden;'][iframe name=3013-A src= https://cloud.hubitat.com/api/46fae574-103e-45ae-ad0d-fb16e2c28bd5/apps/3013/tb?access_token=ecd62f13-ad4a-434e-83c5-5ee98b750673 style='height: 100%; width:100%; border: none; scrolling:no; overflow: hidden;'][/iframe][/div]"
        sendEvent(name: "Remote3", value: toHTML(HTML3) )
    	state.tileDescriptions."Remote3" = HTML3
        
        HTML4 = "[!--Generated:1745810094472--][div style='height:100%; width:100%; scrolling:no; overflow:hidden;'][iframe name=2966-A src= https://cloud.hubitat.com/api/46fae574-103e-45ae-ad0d-fb16e2c28bd5/apps/2966/tb?access_token=a09deced-86d0-47a7-9f45-aa8ebb49d05e style='height: 100%; width:100%; border: none; scrolling:no; overflow: hidden;'][/iframe][/div]"
        sendEvent(name: "Remote4", value: toHTML(HTML4) )
    }   

void clearAttributes(){
 state.tileDescriptions = [:]
    sendEvent(name: "Remote1", value: "None" )
    sendEvent(name: "Remote2", value: "None" )
    sendEvent(name: "Remote3", value: "None" )
    sendEvent(name: "Remote4", value: "None" )
}
    

//Convert [HTML] tags to <HTML> for display.
def toHTML(HTML){
	if (HTML == null) return ""
    myHTML = HTML.replace("[", "<")
    myHTML = myHTML.replace("]", ">")
    return myHTML
}

//Convert <HTML> tags to [HTML] for storage.
def unHTML(HTML){
    myHTML = HTML.replace("<", "[")
    myHTML = myHTML.replace(">", "]")
    return myHTML
}

I hope this helps.

Hi Victor, I'm tagging you as this seems to be a Hub issue. I'm not sure when this bug was introduced but sometime in the last few months is my guess.
@gopher.ny

Hey guys. just curious if this bug is going to be addressed? @gopher.ny

I'm not sure this is really a bug, or just the way you are doing it. I noticed they were all trying to set HTML at once, and they were hanging and taking a long time to finish.

All I did was add a pauseExecution(1500) line in-between each of your HTML set blocks in createErrorConditions(). Now they all load one by one in a few seconds without any hanging.

Certainly something happening with the hub, but just don't throw all those sendEvents at it so quickly and it works. Could still be a bug, and giving each one time to do its thing is just a work-around. Does it matter, though?

You also have some issue with your 3rd endpoint for remote3.

You have to realize that code you are working with is just a simplified synthesis of the real problem. In the real world there are four entirely independent APPS each writing to a separate attribute on their own schedule.

If I put in a pauseExecution per your example it renders correctly the first time, but once I refresh my browser I am back to the same problem.

Try going back and refreshing that page in your device manager.

Its an interesting piece of data that might help the developers solve the issue, but it's not a solution in itself.

I see, it is not so much in creating the attributes, it is just rendering them once the HTML is set.

The pause between setting them also made them load into the page one by one, but they simply cannot load all at the same time.

Have you tried adding a unique div ID for each one? I had noticed a similar issue when creating iframe html attributes, they all became the same as the first one created, then I realized that I was not assigning a unique id to each one for them to render correctly within the device or on dashboards.

Correct, it is the rendering. The DIV ID is not the answer either I'm afraid because they also render incorrectly on the client. IE an app reads back the attribute that should point to Endpoint A and instead it renders Endpoint B, just as it does within the device screen.