well, they are different… Tradfri lights push their state, and Hue needs to be pulled. Which is exactly the issue, because this results in timing issues, and many people ask the polling period to Hub to be upped (it now is 5 seconds) while the dev’s state that would overtask the system even further, and Hue needs to change their Api to a push api…
I use both systems extensively, and have many lights, of all types. So, I suppose ones mileage may vary, and having a bigger setup, brings more issues to the light (pun intended…)
About the Deconz: I have tested it but sent it back, it was of no use, since I couldn’t get it to recognize anything. Maybe that had to do with the state of my Pi at that time and I should give it another go.
I now have the new Rpi4 with 4 gig mem. Performance has upped immensely, and processor usage went down big time. So the Deconz might be better recognized now. Then again, Hue is also responding better
Getting back to your repo now : I will keep a tight eye on it, since you rely a lot on these generic templates and auto filter cards. techniques that look magical and make the config a lot smaller, maybe even easier to maintain. In my experience though it has proven to be cleaner and lighter for the processor and system performance overall to be as dedicated as possible in each config. Also, creating a dedicated template sensor (in the backend) and using the state of that sensor in a Lovelace card seems to be leaner than having all of these templates in the Lovelace card config…
cheers!
That snippet isnt that complex, and it has more to do with the fact it constantly has to check all lights. In that it is much the same as the monster card, or the auto entities. Which result in the same performance issue (in my setup, used on the light domain). Having then them out solved that immediately.