Add Ubisys H10 heating regulator specific attributes

[tomasbedrich]

Ubisys H10 - tech spec here

Ubisys re-uses attribute numbers from the standard hvacThermostat cluster for another purpose, hence I created their specific cluster.

[Koenkk]

Thanks!

[jorschra]

I'll check if manuSpecificUbisysHeatingRegulatorThermostat causes issues for the Ubisys H1 once this ends up in a release, there is no tech spec for the H1 yet but it seems they (mostly) stick to the regular hvacThermostat cluster from my talks with their support team when I added support for it to z2m.

I don't think it will as It's not using the ubibsys manufcaturer code.

[sjorge]

As expected this isn't a problem, as long as one does not set the manufacturer code to the ubisys one, which all the regular hvacThermostat converters do not. The frontend does now list manuSpecificUbisysHeatingRegulatorThermostat in the cluster view, but that view has a few bugs anyway and it's a known issue.

Some further manual testing with a custom converter, looks like the H1 just followes the standard hvacThermostat, none of the fields in manuSpecificUbisysHeatingRegulatorThermostat seem to exist when specifying the manufacturerCode.

Which makes sense as those don't really seem useful for the H1.

[sjorge]

@Koenkk one of my H1 lost some of it's reporting, but with this cluster present it's nearly impossible to setup again using the frontend :( (and configure is also failing, still digging into this)

  {
    "date_code": "20230206-DE-FB1",
    "definition": {
      "description": "Heating regulator",
      "exposes": [
        {
          "access": 5,
          "description": "Remaining battery in %, can take up to 24 hours before reported.",
          "name": "battery",
          "property": "battery",
          "type": "numeric",
          "unit": "%",
          "value_max": 100,
          "value_min": 0
        },
        {
          "features": [
            {
              "access": 7,
              "description": "Mode of this device",
              "name": "system_mode",
              "property": "system_mode",
              "type": "enum",
              "values": [
                "off",
                "heat"
              ]
            },
            {
              "access": 5,
              "description": "The current running mode",
              "name": "running_mode",
              "property": "running_mode",
              "type": "enum",
              "values": [
                "off",
                "heat"
              ]
            },
            {
              "access": 7,
              "description": "Temperature setpoint",
              "name": "occupied_heating_setpoint",
              "property": "occupied_heating_setpoint",
              "type": "numeric",
              "unit": "°C",
              "value_max": 30,
              "value_min": 7,
              "value_step": 0.5
            },
            {
              "access": 5,
              "description": "Current temperature measured on the device",
              "name": "local_temperature",
              "property": "local_temperature",
              "type": "numeric",
              "unit": "°C"
            },
            {
              "access": 5,
              "description": "Position of the valve (= demanded heat) where 0% is fully closed and 100% is fully open",
              "name": "pi_heating_demand",
              "property": "pi_heating_demand",
              "type": "numeric",
              "unit": "%",
              "value_max": 100,
              "value_min": 0
            },
            {
              "access": 7,
              "features": [
                {
                  "access": 2,
                  "description": "Days on which the schedule will be active.",
                  "item_type": {
                    "access": 2,
                    "features": [
                      {
                        "access": 2,
                        "name": "day",
                        "property": "day",
                        "type": "enum",
                        "values": [
                          "monday",
                          "tuesday",
                          "wednesday",
                          "thursday",
                          "friday",
                          "saturday",
                          "sunday",
                          "away_or_vacation"
                        ]
                      }
                    ],
                    "name": "day",
                    "type": "composite"
                  },
                  "length_max": 8,
                  "length_min": 1,
                  "name": "dayofweek",
                  "property": "dayofweek",
                  "type": "list"
                },
                {
                  "access": 2,
                  "item_type": {
                    "access": 2,
                    "features": [
                      {
                        "access": 2,
                        "description": "Trigger transition X minutes after 00:00.",
                        "features": [
                          {
                            "access": 2,
                            "name": "hour",
                            "property": "hour",
                            "type": "numeric"
                          },
                          {
                            "access": 2,
                            "name": "minute",
                            "property": "minute",
                            "type": "numeric"
                          }
                        ],
                        "name": "time",
                        "property": "transitionTime",
                        "type": "composite"
                      },
                      {
                        "access": 2,
                        "description": "Target heat setpoint",
                        "name": "heatSetpoint",
                        "property": "heatSetpoint",
                        "type": "numeric"
                      }
                    ],
                    "name": "transition",
                    "type": "composite"
                  },
                  "length_max": 10,
                  "length_min": 1,
                  "name": "transitions",
                  "property": "transitions",
                  "type": "list"
                }
              ],
              "name": "schedule",
              "property": "weekly_schedule",
              "type": "composite"
            }
          ],
          "type": "climate"
        },
        {
          "access": 5,
          "description": "When Vacation Mode is active the schedule is disabled and unoccupied_heating_setpoint is used.",
          "name": "vacation_mode",
          "property": "vacation_mode",
          "type": "binary",
          "value_off": false,
          "value_on": true
        },
        {
          "access": 1,
          "description": "Link quality (signal strength)",
          "name": "linkquality",
          "property": "linkquality",
          "type": "numeric",
          "unit": "lqi",
          "value_max": 255,
          "value_min": 0
        }
      ],
      "model": "H1",
      "options": [
        {
          "access": 2,
          "description": "Controls the temperature unit of the thermostat (default celsius).",
          "name": "thermostat_unit",
          "property": "thermostat_unit",
          "type": "enum",
          "values": [
            "celsius",
            "fahrenheit"
          ]
        }
      ],
      "supports_ota": true,
      "vendor": "Ubisys"
    },
    "disabled": false,
    "endpoints": {
      "1": {
        "bindings": [
          {
            "cluster": "genPollCtrl",
            "target": {
              "endpoint": 1,
              "ieee_address": "0x00124b00228120b5",
              "type": "endpoint"
            }
          },
          {
            "cluster": "genBasic",
            "target": {
              "endpoint": 1,
              "ieee_address": "0x00124b00228120b5",
              "type": "endpoint"
            }
          },
          {
            "cluster": "genPowerCfg",
            "target": {
              "endpoint": 1,
              "ieee_address": "0x00124b00228120b5",
              "type": "endpoint"
            }
          },
          {
            "cluster": "genTime",
            "target": {
              "endpoint": 1,
              "ieee_address": "0x00124b00228120b5",
              "type": "endpoint"
            }
          },
          {
            "cluster": "hvacThermostat",
            "target": {
              "endpoint": 1,
              "ieee_address": "0x00124b00228120b5",
              "type": "endpoint"
            }
          }
        ],
        "clusters": {
          "input": [
            "genBasic",
            "genPowerCfg",
            "genIdentify",
            "genGroups",
            "genScenes",
            "genTime",
            "genPollCtrl",
            "manuSpecificUbisysHeatingRegulatorThermostat",
            "64599"
          ],
          "output": [
            "genIdentify",
            "genTime",
            "genOta",
            "manuSpecificUbisysHeatingRegulatorThermostat",
            "msTemperatureMeasurement",
            "msRelativeHumidity",
            "msOccupancySensing"
          ]
        },
        "configured_reportings": [
          {
            "attribute": 28,
            "cluster": "manuSpecificUbisysHeatingRegulatorThermostat",
            "maximum_report_interval": 3600,
            "minimum_report_interval": 10,
            "reportable_change": null
          },
          {
            "attribute": 30,
            "cluster": "manuSpecificUbisysHeatingRegulatorThermostat",
            "maximum_report_interval": 3600,
            "minimum_report_interval": 10,
            "reportable_change": null
          },
          {
            "attribute": "classBTemperatureOffset",
            "cluster": "manuSpecificUbisysHeatingRegulatorThermostat",
            "maximum_report_interval": 3600,
            "minimum_report_interval": 0,
            "reportable_change": 50
          },
          {
            "attribute": 18,
            "cluster": "manuSpecificUbisysHeatingRegulatorThermostat",
            "maximum_report_interval": 3600,
            "minimum_report_interval": 0,
            "reportable_change": 50
          },
          {
            "attribute": 8,
            "cluster": "manuSpecificUbisysHeatingRegulatorThermostat",
            "maximum_report_interval": 3600,
            "minimum_report_interval": 15,
            "reportable_change": 1
          },
          {
            "attribute": "rawOutdoorTemperature",
            "cluster": "manuSpecificUbisysHeatingRegulatorThermostat",
            "maximum_report_interval": 3600,
            "minimum_report_interval": 0,
            "reportable_change": 0
          },
          {
            "attribute": "batteryPercentageRemaining",
            "cluster": "genPowerCfg",
            "maximum_report_interval": 43200,
            "minimum_report_interval": 3600,
            "reportable_change": 1
          }
        ],
        "scenes": []
      }
    },
    "friendly_name": "trv/livingroom",
    "ieee_address": "0x001fee00000098be",
    "interview_completed": true,
    "interviewing": false,
    "manufacturer": "ubisys",
    "model_id": "H1",
    "network_address": 56667,
    "power_source": "Battery",
    "software_build_id": "1.2.0",
    "supported": true,
    "type": "EndDevice"
  },

Can we somehow (for future binds/reporting configuration actions also start recording the manufacturerCode that was used? Then we can also start returning the correct attribute and cluster.

I managed to restore them manually over mqtt, but I think things things get confused because I tried to configure hvacThermostat. but it returns later that it actually has manuSpecificUbisysHeatingRegulatorThermostat.. The device still does the right thing... I think, it at least seemed to have taken the config but it's not reporting anything atm so who knows.

Or I guess somehow have a away to mask certain custom clusters for only certain zigbeeModels, that would probably also fix some others where we have 'duplicates'

[Koenkk]

Instead of storing just cluster.ID here: https://github.com/Koenkk/zigbee-herdsman/blob/2419e5ca5002621bbb160cef7d4d62ccb02934f3/src/controller/model/endpoint.ts#LL775C20-L775C20, we should store the cluster ID + name, something like cluster: {ID: cluster.ID, name: cluster.name}

[sjorge]

Perhaps cluster: {ID: cluster.ID, name: cluster.name}, attrId: {ID:, entry.attrId, manufacturer: cluster.manufacturerCode} I think we have some attributes with shared ID within clusters too with different manufacturerCode something like elkoXXX and danofossXXX IIRC.

We would need a way to migrate or deal with having properties being either numeric or object (or well I guess a new TS type)

I think we can deal with this after the TS refactor, if you are OK with that I'll create an issue for this so we don't forget. Next few weekends for me look rather busy, so I don't know if/when I will have time myself to take a stab at this.

[Koenkk]

Yes, let's do this after the TS refactor.

[Danit2]

I think we have a problem with this PR.

Since this was done my Ubisys devices that have a LevelCtrl cluster have a manuSpecificUbisysHeatingRegulatorLevelCtrl

This results in several problems.

On the D1, the valveType must be selected when reporting for the CurrentLevel.

In addition, binding of the Ubisys devices no longer works, since they no longer have a LevelCtrl. This affects all ubisys devices. Clusters from a D1

Clusters from a C4

Can this be fixed again?

@sjorge can you help? I can no longer configure any devices correctly.

Thank you very much.

[sjorge]

It also messes up the H1 TRV, currently not much thar can be done. But only the bind/reporting tabs in the frontend.

This is unfortunately not a frontend issue. See the linked feature request a bit higher up.

Sometimes i’d wish we had per-device custom clusters, but that would be even harder to implement.

[Danit2]

Ahh yes I have seen it. Thank you very much. But what can I do now to bind my c4 with a lamp? Is it still possible via mqtt?

[sjorge]

You should still be able to use the correct names over mqtt and have it work.

[sjorge]

I don't think anything is using these at the moment, perhaps we should remove them again until we can introduce them again without causing issues for other devices, which seems to be more than just the H1, as it's now confirmed the D1 and C4 are harder to use now.

@Koenkk 👆

[Koenkk]

@sjorge could you submit a pr to reverse it?

[tomasbedrich]

The implementation of H10 is WIP, currently waiting for Ubisys reply to clarify some of the details in the docs (will ping them). So while I understand the inconvenience, the revert would be rather unfortunate resolution. @sjorge do we have another solution until #717 is fixed? What about publishing some workaround script to bind levelCtrl for Ubisys devices?

[sjorge]

The correct thing to do would be to properly fix the actual issue. Or the alternative if being able to limit custom clusters on modelid or something.~ sjorgeOn 2 Aug 2023, at 20:50, Tomáš Bedřich @.***> wrote: I have an implementation of H10 WIP, currently waiting for Ubisys reply to clarify some of the details in the docs (will ping them). So while I understand the inconvenience, the revert would be rather unfortunate resolution. @sjorge do we have another solution until #717 is fixed? What about publishing some workaround script to bind levelCtrl for Ubisys devices?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[devildant]

this impl cause trouble with ubisys C4 levelCtrl replace by manuSpecificUbisysHeatingRegulatorLevelCtrl

[sjorge]

this impl cause trouble with ubisys C4 levelCtrl replace by manuSpecificUbisysHeatingRegulatorLevelCtrl

Yes, this causes lots of issues for the C4/S1/S2 as well, the 2 Ubisys specific ones that shared a standard ZCL cluster ID should never have been created. Ubisys has moved the duplicate cluster ID's so this is no longer and issue with the latest firmware update. I have a PR open fixing the H1 (not the H10 but the H10 change here broke the H1 too and I had to use ugly hacks to keep that one working), that PR should also fix the C4/S1/S2.

[devildant]

this impl cause trouble with ubisys C4 levelCtrl replace by manuSpecificUbisysHeatingRegulatorLevelCtrl

Yes, this causes lots of issues for the C4 as wel, the 2 Ubisys specific ones that shared a standard ZCL cluster ID should never have been created. Ubisys has moved the duplicate cluster ID's so this is no longer and issue with the latest firmware update. I have a PR open fixing the H1 (not the H10 but the H10 change here broke the H1 too and I had to use ugly hacks to keep that one working), that PR should also unbreak the C4. At least it unbroke my C4 I have locally.

thx @sjorge for your answer, I assume that I cannot unblock the situation for myself locally with an external file? I use haos

[sjorge]

thx @sjorge for your answer, I assume that I cannot unblock the situation for myself locally with an external file? I use haos

Once the PR is merged, you should be able to update to the dev version until it makes it's way into a release. Alternatively you could also manually bump the zigbee-herdman module to the PR commit, but I would strongly advice against the later unless you really know what you are doing. I do it because I need to while working on stuff and I sometimes mess it up.

Edit: I supose if you do not have any H10 or H1 devices, you could manually edit ..path_to_z2m../node_modules/zigbee-herdsman/dist/zcl/definitions/cluster.js and remove manuSpecificUbisysHeatingRegulatorThermostat and manuSpecificUbisysHeatingRegulatorLevelCtrl blocks. Make sure to make a backup copy of the file first in case that doesn't work.

[devildant]

thx @sjorge for your answer, I assume that I cannot unblock the situation for myself locally with an external file? I use haos

Once the PR is merged, you should be able to update to the dev version until it makes it's way into a release. Alternatively you could also manually bump the zigbee-herdman module to the PR commit, but I would strongly advice against the later unless you really know what you are doing. I do it because I need to while working on stuff and I sometimes mess it up.

Edit: I supose if you do not have any H10 or H1 devices, you could manually edit ..path_to_z2m../node_modules/zigbee-herdsman/dist/zcl/definitions/cluster.js and remove manuSpecificUbisysHeatingRegulatorThermostat and manuSpecificUbisysHeatingRegulatorLevelCtrl blocks. Make sure to make a backup copy of the file first in case that doesn't work.

thx @sjorge, I can't find the source code for z2m, I don't think it's possible with haos :(