MQTT powermeter values are re-published via MQTT

[AndreasBoehm]

While looking through the output messages of the DTU i discovered that there is a powermeter topic with subtopics.

I am feeding my DTU with powermeter data via MQTT and i am wondering if there is a reason to re-publish the same data to MQTT?

void PowerMeterMqtt::doMqttPublish() const
{
    std::lock_guard<std::mutex> l(_mutex);
    mqttPublish("power1", _powerValues[0]);
    mqttPublish("power2", _powerValues[1]);
    mqttPublish("power3", _powerValues[2]);
}

[schlimmchen]

I was probably avoiding a regression. Someone subscribes the PowerMeter to topic A but uses a script that subscribes to the PowerMeter topic... I agree that this is nonsensical. It is obvious now that the power meter refactoring is complete. Previously, this wasn't so obvious, as the power meter values were shared among all providers and the MQTT publish function did not care/know whether or not the original values were subscribed from MQTT. That's what I remember.

When removing this, how to we handle the MQTT publish function in the base class? Should it publish the total value? That would at least be something that OpenDTU-OnBattery adds, in case three values are subscribed to and OpenDTU-OnBattery publishes the total, which previously might not have been available on the broker.

[AndreasBoehm]

Got it, i expected that it was related to the PowerMeter refactoring.

I think that we can stop publishing any value when MQTT is the source, because there is already a broker and potentially another system that can take care of providing a total. From my standpoint the dtu is only the consumer of the data and not nodered where you can mix and match data as you wish.

Should we add a toggle to enable/disable publishing of the total value in case someone really needs this?

[schlimmchen]

In case someone really needs this, an issue will pop up. Remove it. I will check how you handle not publishing the total in the base class.

[AndreasBoehm]

PR created: #1250