MQTT Publish "boiler_cmd_wwtemp"

[suysh]

I'm running the latest V2.0.0b8 with very nice webinterface. Great job !!!!!
Everything is working and mqtt messages are receipt well. Again amazing work !!!!
When trying to change the boiler temp, I'm facing some problems.

Starting from telnet with the command, the boiler temperature is updated and react accordingly with heating. But when publishing via mqtt to the channel "boiler_cmd_wwtemp" it's not accepted. Via mosquitto_sub -t "boiler_cmd_wwtemp I can see my values.
Any idea, or how to find what's wrong?
Kind regards Hans

[proddy]

to be honest I never tested the incoming MQTT so it's likely a bug. I'll test tonight

[proddy]

I tested it it works for me. Perhaps the leading "ems-esp/" is missing?

[proddy]

Also not in system the command show mqtt will list the active MQTT subscriptions.

[suysh]

Correct, "ems-esp/" was missing. Thanks for mentioning. Publish is working fine now.

I have found that the mixing data mqtt is split into "ems-esp/mixing_data1" and "ems-esp/mixing_data2". This was before in one string with subtype "hc1" and "hc2". Do we keep this? (before I update my code to decode the new different topics).

Regards, Hans

[proddy]

I have found that the mixing data MQTT is split into "ems-esp/mixing_data1" and "ems-esp/mixing_data2". This was before in one string with subtype "hc1" and "hc2". Do we keep this? (before I update my code to decode the new different topics).

When I was testing v2 Michael pointed out that the Mixing units each have a unique device_id corresponding to a specific heating circuit or warm-water circuit (e.g. 0x20 is HC1, 0x21 HC2 etc). I had implemented it incorrectly in 1.9 as I thought a Mixing unit behaved like a Thermostat unit and could represent all available heating circuits. This is why when you have multiple mixing units, each is an instantiation of the C++ Mixing class object and handles its own MQTT publishing.

At some point I should refactor the code to support group all device types and send as one MQTT payload, but this will be quite a change and break the underlying inheritance model. Because of this limitation, this is also why we only allow 1 thermostat to be published (which is called the Master Thermostat). So if you had two RC300 thermostats in your EMS network you'll only be able to see the MQTT data for one. I'll create a new feature issue to address this.

So for the time being stick with ems-esp/mixing_data1 and ems-esp/mixing_data2 !

[suysh]

OK. Thanks for explaining. I will adjust my code to adapt the splitted mqtt strings. No problem.
You may close this questions.