(v2) support grouping of device types (thermostats, mixing units etc) for MQTT

[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 !

Originally posted by @proddy in #439 (comment)

[MichaelDvP]

Yes, this confusion is made by Bosch, it's odd that the thermostat has a single device-id and different type-ids for each hc, but the mixer-devices have a unique device-id for each heatingcircuit, but sending the same type-id (only EMS1.0, EMS+ uses different type-ids).
I think it's ok, user who want to have all i the same structure can set mqtt to single and thermostat publishes the hcs also as thermostat_data1, etc.

If you want to add a nested mixer publish without braking the model, you can add a dummy-device which collects the mixer-data and publishes all, whereas the mixers do not publish.

[norberts1]

@MichaelDvP also that mixer-devices (MMx00 or IPM1/2 for Junkers) and that solar-devices (MSx00 or ISM1/2) can send different type-id's (I named it: MessageID). This depend on there configuration and the use in the heater-system itself.

In that attached system-example there are 3 MMx00 moduls visible, that MM100 used only for the WW-storage cells and the other 2 MM200 for one unmixed and 3 mixed heater-circuits.
For this purposes (configuration) you will get different type-ids (messageID's) and also different device-id's depend on that heating-circuit.
Compareable procedure for solarmoduls, they can be used also for a second heater-system (heating with pellets etc.) and this is handled as 2.Solar-system with additonal type-id's (messageID's).
Any way, there are many different system out there and that configuration of the system and there device-id's using type-ids its very flexible and can make many headache for decoding and assignment.
@proddy for that above reason I'm using 'logical systemparts' and 'logitems' instead of physical type-id assignment to device-id's. It seems to me more flexible for that handling.
Also it is very good to know that the type-id's are not unique for any modul (same type-id can be send also from other moduls) but the payload of type-id's (messageID's) and the byte-meaning in that stream is unique for all of Junkers-messages.
But the length of that telegrams can differ, depend on that offset used or not. Good luck, terminating is always that break-signal.

So that handling is already done for that MQTT-messages and heating-cicruits like {hcx{....}}.
The same procedure would be good to have also for that DHW (domestic hot water, no assignment to boiler) , solar etc.
I know, isn't easy to do but this should be only an idea to think on.
Big System:

Messages send by the IPM/MM-Modul using DHW type-id's (messageID: 52_0)

Messages send by the IPM/MM-Modul using heatingcircuit type'id's (messageID's:268_0, 26_2 )

[proddy]

thanks @norberts1 for explaining that. I need to re-think the design, especially for Mixers.

[proddy]

@MichaelDvP is this something we should spend time looking into? I don't have mixing units so can't comment on whether grouping adds any value.

[MichaelDvP]

No, i dont think it would add any value. The structure now is clear one topic per device.
Maybe in the first time there will be some questions from people upgrading from v1.9.5. But that's all.
I think we can close this issue.

[proddy]

ok!

[proddy]

re-opening. For Mixing units it would make sense to group all the data into a single MQTT topic, which means handling this outside the device classes (like mixing.cpp).

[MichaelDvP]

I think we can close this, mixers grouping work fine and thermostat grouping type-ids 0x18-0x1B should work, only the real-world-test is missing.

[proddy]

yes, I'll reach out to the regulars to test. Then we can finally close and release 2.1 and take a break.