Closed TroyFernandes closed 4 years ago
Hi, is there any reason why you changed this from direct subscribing to sensor reading? It seems much more complicated for configuration to add extra sensors for every topic in the media player.
Although I agree its more work to get it setup, I feel it makes more sense to do it this way for two reasons:
1) people can modify their sensor values to fit their specific application in case it isn't how they like (rare case)
2) I want to decouple the dependence on the MQTT component within the code as much as possible. Even when making the component, I didn't like the idea of subscribing to topics within the code and the template_result
is a good alternative. Id much rather the MQTT Component itself handle all the data processing and only use the mqtt.publish
service.
TLDR: it should be easier to maintain and perform as expected
Ok, i think it you are right. Its much easier to maintain. I am currently working on some improvements to use your project for my musiccast2mqtt bridge. I recently added some topics and services. In addition I made supported features depending on the config. Perhaps its interesting for you too.
Ill check it out, but most likely wont be implementing some of the other media player services. Check out my comment here
Hi, is there any reason why you changed this from direct subscribing to sensor reading? It seems much more complicated for configuration to add extra sensors for every topic in the media player.