[somfytahoma] Cozytouch radiator integration

[lolodomo]

Cozytouch is an app for managing your thermal comfort appliances remotely from a smartphone or tablet. Remote connectivity and control of electric heaters, electric water heaters, heat pump water heaters, heat pumps, boilers and ventilation systems.

Depending on your connected product, Cozytouch is compatible with two different protocols: IO-homecontrol & Wi-Fi.

Supported devices are from different manufacturors: Atlantic, Thermor and Sauter.

Cozytouch requires a special device named the Cozytouch bridge. This bridge communicates with the devices and with the Cozytouch WEB service.

I plan to develop a new binding to control electric heaters through the Cozytouch WEB service.

As I own only electric heaters (Sauter), I will focus on that but I could then add other kinds of supported devices with the help of others.

[lolodomo]

I discovered that Cozytouch is relying on a cloud solution named overkiz which is also used by the Somfy Tahoma system. A good binding already exists that integrates Somfy Tahoma in openHAB. So I am going to enhance the existing binding to add the support for Cozytouch.

I already started and it will be easy as most of what is required is already implemented.

@octa22 for information.

[lolodomo]

@octa22 : I am a little surprised to see each action group represented as a separate openHAB thing. Can you please explain what is an action group in the Tahoma system and can you give me an example of action group ? Would it be not a better choice to create one channel for each action group on the bridge thing for example ? Or even just one channel with the ability to select the action group to run ? PS: the action groups provided by the Cozytouch are apparently different target setpoint commands for the radiator(s) in a room.

[octa22]

@lolodomo sure. actiongroups or scenarios are user defined sets of commands which can be executed in a row. For example I have an action group named “All roller shutters down” and defined in the Tahoma portal, which has 11 steps and in every step one of then roller shutters sets it´s position to down. This action group executes all these 11 commands one by one when triggered. You are right it might be realized as a bridge or gateway channel for each action group. I chose a new thing per action group since I didn’t have clue about dynamic channels that time.

[lolodomo]

Ok I understand, this is a scenario. So Cozytouch provides pre-defined scenarios for each room containing radiator(s). I think there is no need for dynamic channels but rather one unique static channel with dynamic command options, one per action group. And you're right, this channel could be either on the bridge thing or the gateway thing. I will probably try to add this feature, keeping the existing action group things as they are.

Is there the concept of room in the Tahoma system ? This is currently not implemented in the binding while present in the overkiz API. That being said, I am not yet sure what we could do with that. Maybe that is the reason you did nothing with that ;)

[lolodomo]

Please note that I believe there is a little problem in the binding, you defined channels of type Number with a dimension like for example Number:Temperature but these channels are apparently set using a state of type DecimalType while a QuantityType should be used with the appropriate unit. I will have a look to that too.

    <channel-type id="temperature">
        <item-type>Number:Temperature</item-type>
        <label>Temperature</label>
        <description>The temperature value of the sensor</description>
        <state pattern="%.1f %unit%" readOnly="true"/>
    </channel-type>

I see is that the API is providing the unit as a device attribute. Here is an example for the temperature sensor: Could you please check if you have this core:MeasuredValueType device attribute with the Tahoma system ?

[octa22]

I do not use attributes, since most of the things do not provide them. I use only the states, which provide the type (decimal, percent, string and boolean if I remember it right)

[octa22]

Is there the concept of room in the Tahoma system ? This is currently not implemented in the binding while present in the overkiz API. That being said, I am not yet sure what we could do with that. Maybe that is the reason you did nothing with that ;)

Yes, Tahoma uses this concept as well, but I haven't found it useful, because I have only ~13 devices. So I use only the Devices view and I can see almost all the devices altogether, rather than the Room view.

[octa22]

Please note that I believe there is a little problem in the binding, you defined channels of type Number with a dimension like for example Number:Temperature but these channels are apparently set using a state of type DecimalType while a QuantityType should be used with the appropriate unit. I will have a look to that too.

Thanks. I am aware of this, I had to change the xml definition because of the code review, but the code itself stayed the same. I do not have time to fix it, but it shouldn't be a problem if there is a way to distinguish channels expecting Decimal and Quantity type.

[lolodomo]

@octa22: with Cozytouch, I am getting not meaningful labels for the additional sensors (temperature sensor, contact sensor, occupancy sensor, energy consumption sensor), something like "IO (XXXXXXX)". This is what is displayed in the inbox, not very helpful. So I will enhance thiese labels but I don't want to break what is done for the Tahoma system in case you have good labels. How look your labels ?

PS: The main device has "Radiateur" as label which is OK.

[octa22]

How look your labels ?

PS: The main device has "Radiateur" as label which is OK.

Tahoma allows users to name each device as they want and the same for the action groups/scenarios. This label is shown in the OH, so it is the exact name as shown in the Tahoma mobile application.

[lolodomo]

Tahoma allows users to name each device as they want and the same for the action groups/scenarios. This label is shown in the OH, so it is the exact name as shown in the Tahoma mobile application.

Ok, good.

[lolodomo]

@octa22 : I would like to discuss about the refresh interval for polling events. Its default value is 30 seconds. This is not really appropriate when you send an action because in this case you would like to handle the events just few seconds later. When no action is executed, 30 seconds is not so bad. So, I see the need for two different intervals. Did you already think about that ? Just thinking in live: we could schedule a task every 2 or 3 seconds for example. This task will poll for new events in case actions are running. If not, it will do nothing except if the "normal" refresh time (30 seconds by default) has expired. WDYT ?

[lolodomo]

@octa22 : I would like your thoughs about another subject. I have 2 radiators in the same room and they are even paired. The Cozytouch app shows to me only the room (with the 2 radiators). So my commands through the app are applied to the room and so the two radiators.

The API is apaprently attached to a device and not to a room. While my 2 radiators are paired, when I send a command to one radiator with the binding, only this radiator is affected, not the other.

Do you think there is a special API to send a command to all members of a rooms ? Do you think there is a way to trigger the synchronisation of radiators when they are paired (I found an action named refreshSynchronisationRequest) ? Maybe the app is simply sending any command to all members of the room ?

[octa22]

I understand, as far as I know there is no API for commands within one room, only action groups (scenarios) The synchronization refresh request just triggers the sync of a device state with the cloud. So I guess the app sends commands one by one since it knows about the pairing...

[octa22]

Did you already think about that ? Just thinking in live: we could schedule a task every 2 or 3 seconds for example. This task will poll for new events in case actions are running. If not, it will do nothing except if the "normal" refresh time (30 seconds by default) has expired. WDYT ?

Currenty there are two scheduled tasks, one is for getting the events, one is for a reconciliation - synchronization of all the states of devices with the cloud (aka getState) You are right 30 s is quite long polling interval, the Tahoma portal sends reguest for events every second (I have checked it right now). I am OK with 10s default. I don't think we need some sophisticated dynamic calling of the refresh command, at least the rolleshutters send its new update every 5s, not more frequently... If you decide to implement it, please be aware of the throttling and overloading of the API.

[lolodomo]

Thank you for your feedback. 10s will be already better. But my idea remains to have more frequent event polling when some actions are still running, just to get a faster feedback. I have to thing about that.

[lolodomo]

PR #10611 is the first step of this integration. It opens the Somfytahoma binding to new portals including the Cozytouch cloud portal. A next step will then follow that adds the support for Cozytouch electric heater.

[lsiepel]

If i'm not mistaken, this issue was resolved with https://github.com/openhab/openhab-addons/pull/11855 Can you verify ?

[lolodomo]

In fact, it was partially implemented. Remains to add a handler for my radiator. I have a change started but not yet finished. I am going to rename the issue.