Support for FC600

[mat2maa]

Following on from https://github.com/jvitkauskas/pyit600/issues/7#issuecomment-880160254 (also me, different GitHub account) decided to have a look at this myself - and opened this PR as a way to start the conversation.

Empirically tested on my home FC600 devices.

[jvitkauskas]

Hi, thank you for your contribution. The way I am trying to do things in this library is to try to follow Home Assistant models for easy mapping. I've started working on FC600 implementation https://github.com/jvitkauskas/pyit600/commit/73a417a5a34698a19295fe8f0bb54e8b8bdd2c76 but haven't finished it.

• Home Assistant would probably regard FC600 as a Climate Entity, so maybe it's better to expand that? I am not set on this, but AFAIK it will still need to be mapped into one class in Home Assistant integration.
• Regarding PRESET_TEMPORARY_HOLD, can you explain how it works? I think I have not observed it working with other thermostats, maybe it's FC600 feature. It's cool to have this, but I am thinking maybe maybe I am missing something.
• Regarding separate cooling and heating temperatures: I am aware those exists, but somebody reported that Salus app on the phone does not expose it as a separate values and you need to switch to cooling or heating mode first to change those temperatures. I am not sure how it should be integrated in Home Assistant, but probably a similar thing is possible. Again, maybe this library could expose those values like it is done in your PR as opposed in my WIP code. Again, I am open for discussion.
• I am exposing fan speeds as fan_modes. This is probably more in line with Home Assistant.
• supported_features also mimic Home Assistant https://developers.home-assistant.io/docs/core/entity/climate/ so SUPPORT_FAN_MODE is probably needed there.
• It's cool you have added locked field.

[mat2maa]

Hi @jvitkauskas, thanks for this. Your WIP has added context to where some of the e.g. constants were coming from. To answer each of your bullet points:

1. Yes, I think given that Home Assistant will treat them the same, and there is enough overlap in the models of these devices, to go the way you have with the big if/else in the climate block.
2. So if you've set the fan coil with a schedule PRESET_FOLLOW_SCHEDULE, which splits the day into up to 6 (I think from memory) periods of different temperature (e.g. 8am - 10am => 24°, 10am - 2pm => 22° etc), then you can temporarily (until the next period) override that temperature (e.g. it is 9am, and you lower the temp to 23°, it will still become 22° at 10am, hence temporary). See page 10, section 2.5 of the manual.
3. First, I agree with your approach for the getter, that target_temperature, max_temp, min_temp return the value based on the is_heating conditional. And I believe it is the counterpart to the format of my setter set_fan_coil_device_temperature which basically uses the same condition? What do you think?
4. Agreed re fan_modes
5. Yep (both this and for became clear with your link to the home-assistant docs, thanks).
6. 👍

I think there are probably some useful bits in this PR, but your WIP has the more solid foundations and so work should continue from that. I can take it as a starting point and continue from there if you like?

A couple of questions:

• Regarding CURRENT_HVAC_HEAT_IDLE and CURRENT_HVAC_HEAT_IDLE this was behaviour that I noticed in testing. E.g. if the fan coil is HVAC_MODE_COOL, current_temperature = 24°, and target_temperature = 24°, then the fan coil turns on with a low fan and "RunningState" logged as one of 2 or 6 or 34, but not 66 (which it is when it is cooling properly). So, is this useful? How would Home Assistant interpret it (if at all)?
• Anything you would add to the setter methods in my PR?
• Is there an equivalent WIP for FC600 in https://github.com/jvitkauskas/homeassistant_salus?

Cheers!

[MatthewAger]

This should be closed in favour of https://github.com/jvitkauskas/pyit600/pull/23

[jvitkauskas]

Thanks