search

F1p / Home-Assistant-Mitsubishi-Ecodan-CN105-to-MQTT

Originally based on the CN105 decode by m000c400, this fork provides CN105 control from basic microcontrollers like the ESP8266 or ESP32
7 stars 1 forks source link

Cascade Values #7

Closed drnichols closed 1 month ago

drnichols commented 1 month ago

Hi @F1p, now that I have my systems up and running can I help collect the cascade commands/values to add to your ever expanding CN105 command capability?

F1p commented 1 month ago

The anticipated data available available for cascade is as follows:

The expected information may overlap with what you already have by putting connectors in all, can you confirm the behaviour of each CN105? I would be interested to hear about energy consumption is shared between units please

drnichols commented 1 month ago

On/off status sync's between the master and the slaves. I can power the system on or off from either the master or any of the slaves and it instantly takes effect (looking at the main controller). There is a delay in between polling where the status is out of sync in HA on the System Power switches. I don't think is specific to a cascaded system? Not sure if this can be handled in the code. As an example if I power off the master system the switch turns off as expected when switched from the UI, it then switches back to on status within a few seconds before updating some seconds later to reflect the controller status (off in this example).

drnichols commented 1 month ago

Compressor frequency is only reported on the slave with the associated external unit attached. For example, I currently have ASHP1 only enabled for DHW, compressor frequency is reported via the FTC5 connected to ASHP1 for today's DHW runs. Master does not report compressor frequency. The same applies for flow rate where the flow rate is reported for each slave that has a flow sensor connected/enabled.

F1p commented 1 month ago

There is a delay in between polling where the status is out of sync in HA on the System Power switches.

Is this still the case when running v5.2.4?

drnichols commented 1 month ago

I'm still on 5.2.3, I will test and confirm.

drnichols commented 1 month ago

I can set heating/cooling operation mode and zone target temperature only on the master controller. The change is then synced across the master and slaves at the next poll.

drnichols commented 1 month ago

Likewise DHW mode and setpoint can only be set on the master. This then syncs to be reflected on the slaves.

The tank temperature is only reported correctly on the master (it has the thermistor attached). The slaves always report a default value of 25C.

drnichols commented 1 month ago

There is a delay in between polling where the status is out of sync in HA on the System Power switches.

Is this still the case when running v5.2.4?

The 'switch bounce' appears to be fixed in 5.2.4 thank you @F1p

I did blindly update the fw on your supplied module before I realised I was using the Atom fw... took me a couple of minutes to realise what I'd done. So I've now got Atom based ESP32's in all three controllers 🤦.

One thing I did notice during this little off-piste journey was that the Ecodan had reverted from server control whilst the master ESP was offline (before I power cycled it).

F1p commented 1 month ago

There is a delay in between polling where the status is out of sync in HA on the System Power switches.

Is this still the case when running v5.2.4?

The 'switch bounce' appears to be fixed in 5.2.4 thank you @F1p

I did blindly update the fw on your supplied module before I realised I was using the Atom fw... took me a couple of minutes to realise what I'd done. So I've now got Atom based ESP32's in all three controllers 🤦.

One thing I did notice during this little off-piste journey was that the Ecodan had reverted from server control whilst the master ESP was offline (before I power cycled it).

I think i have done that before and I thought it said firmware update failed - perhaps i was trying to put ESP32 on an 8266 though!