match only checks against the beginning of the string, so the “sensor.” in each of your entity IDs will cause them to be rejected from the list. You would need to replace entity_id with object_id in the selectattr() if you want to use match.
Ok but In both cases, right now I should get “No error” since there are no problems, but instead I get:
Errors found: Solarman Fault 1, Solarman Fault 2, Solarman Fault 3, Solarman Fault 4, Solarman Fault 5, Solarman Fault 6, Solarman Fault 7, Solarman Fault 8, Solarman Fault 9, Solarman Fault 10, Solarman Fault 11, Solarman Fault 12
I would need to get “no error” or the sensor value if I have the error.
There something wrong with the state of those sensors… rejectattr('state', 'eq', '0') should remove any of them with a state of ‘0’ so that it doesn’t show up in the list.
Paste the following in your Template editor then share the results:
So that shows you have sensors that match the search criteria which are returning “No Error” as their state, not “0”… You can find all the sensors that match the criteria with:
According to the two template we have tested you have 12 sensors that are currently returning “No Error” not “0” as you indicated previously. Is “0” a possible value for them to return? When they return something other than “No Error” (or “0”), what should the template sensor return? The entity ID, state, entity name… some other attribute… some combination of those?
But, as demonstrated by the previous tests, the state is not returning bits, (at least in the case of “0”/“No error”) it’s returning the descriptive value.
No, it’s almost definitely possible… but no one can help you design a working template if the information you provide doesn’t make sense. In you first screenshots
In your previous post for “Fault 1” what is that example? It doesn’t look like the attributes of an entity from the States tool… is it a configuration of some kind? If so what kind? What integration is being used?
Copy the following into your Template editor and share the results: