I have a door that's normally open. So it should be green on my dashboard. It should turn red when closed. Is there a way to set it up that way?
Try modifying the template for the door device and reverse the colors.
Wouldn't that change the colors for all of the sensors that use that template? I just want to apply this change to the one sensor that needs it.
Is there a way to add another template? I didn't see a way to do it.
Pick your sensor and then assign Door Status template to it.
Modify the open and closed background colors for Door Status. For all the other contact sensors that you want to use the normal green when closed, assign the contact sensor template to them.
2 Likes
Thanks, @SmartHomePrimer, that totally worked. Actually, I just switched my normally-open door to the contact sensor template, then modified the contact sensor template to be green/open and red/closed.
AFAICT, this approach is the only way to solve this example currently. Still, it's a bit of a kludgy solution. It means that my contact sensor shows door icons for all contact sensors. It's ok for me for now because I'm not using any other contact sensors. But if I add another contact sensor that I need to not be a door, I can't. I think the devs need to fix this: a solution would be to allow the individual overrides have different true/false colors/icons.
Thanks, @SmartHomePrimer and jkudave, for the help!
2 Likes
Yes, that was my reasoning for choosing door instead of contact sensor, as I has assumed you would have more contact sensors to monitor than doors, but if this works for you then great!
I think the solution will be custom templates, but they are not available right now.
Awesome tip guys !!
1 Like
There are no plans for custom templates any time soon. This is not technically possible in how dashboard is written.
With that said, we are looking at options for additional customization options down the road.
3 Likes
Just looking back at my early dashboard construct where I followed a path similar to what is discussed in this thread.
I had exactly the same Normally Open case where I had a Multi Sensor tile showing Temp, Battery, and Open or Closed. I had reversed the color and threw in a valve icon because this multisensor was hard wired to a small amp clamp that tells me when a submersible well pump is ON and pumping water.
But it has bugged me from Day 1 that I altered the default template for multisensor knowing full well this was going to bite me in the rear as I added new multisensors used more conventionally.
Add to this the confusion that the displayed word "OPEN" really was the inverse of my pump's state. In fact in the notification I send I actually have to remind myself, " CL=ON/OP=OFF %status% " . (Mind you, this is close monitoring of a remote irrigation well. )
So in reviving this old thread I guess I'm saying that yes, there is value to leaving templates alone while allowing some customization and actually some interpretation of the state so that the intended status/activity may be presented on the dash.
Thinking about the read of the actual device I wonder if there might be a call for a rename and/or reverse name back in the configuration to accommodate the NO/NC uniqueness. I haven't thought the implications of this through. Just saying, the permutations of on/off, open/closed, high/low, flowing/not flowing, etc maybe need to be flexibility interpreted beyond static device templates and driver configurations associations.
Cringing as I post this to an old thread in fear that it has since been discussed in much more detail and understanding elsewhere.
But I will jump the line to circumvent any retorts of the likes of: "oh, you can achieve what you want by setting up a variable and in RM interpreting that and blah blah blah...etc.….and then going into your dash template CSS/HTML and making blah blah blah....etc".
I'll plead GUILTY to using a multisensor in a non-conformable manner, beyond that I'm not agreeing that what this whole thread discusses is an unusual out of the ordinary circumstance necessitating an assortment of user generated kluges to maintain as the platform evolves 
1 Like
+1 for the idea to add a reverse option to contact sensor - or at least add a reversed device contact driver!
I'm thinking through the idea of a virtual door that reads it's state from the open closed. not sure how to accomplish that but it's in the brainpan now.
1 Like
