[evohome] binding: one actuator say TempZoneActuatorLowBattery

[stefanoboccato]

The actuator keep offline after a while, and it returns to openhab some sort of COMMUNICATION_ERROR, specifying a code like "TempZoneActuatorLowBattery". This also when I put new batteries.

Expected Behavior

I'm expecting a normal behaviour like others actuators, it must connect to the central unit as usual, and reports right status and temperature using the external account to openhab, but something in second part is not working.

Current Behavior

I've many actuators, 10 more or less, and only one is having this issue. It connects to the official account and apps, and everything is working well. For others actuators everything is fine in my openhab instance. This particular actuator doesn' t report right informations to openhab. OH says: OFFLINE, COMMUNICATION_ERROR and TempZoneSensorLowBattery.

Your Environment

I've just updated OH to latest version, so now I've 3.4.2. Java is Zulu11.56+19-CA (build 11.0.15+10-LTS) everything on rpi4 with 4gb of ram

I've downloaded the code, and I've found something interesting on EvohomeHeatingZoneHandler.java, at the end of class. In this part we can have a list of "activeFaults" but no method to log, retrieve or show the full list, only first object is used. Don't know if it can matter.

[stefanoboccato]

I've just checked using postman api on mytotalconnectcomfort.com, using my account obviously. Everything seems ok, so, every zone has right infos

[stefanoboccato]

looking into log at startup of openhab service, I noticed that I've 3 active faults in the room called "office", and... they is alive until 1 year ago, more or less. So they are very old. I'm looking for how to clean this faults. Using the display of central unit, I've found nothing useful.

[stefanoboccato]

I try to remove batteries from central unit, waiting for more tan oneh minutes, hoping that this clear errors, but unfortunately it doesn't.

I found different apis from wich ones are used in this binding. This binding has this host: tccna.honeywell.com but I found a set of working apis also in: mytotalconnectcomfort.com the responses are similar, but for example, in my case the second set of api doesn't have the "activeFault" list object populated.

For now I'll try to bypass "activeFaults" when error messages are older than one week or month.

[lsiepel]

Can you share the return results for both api's? That might help in troubleshooting and coming up with a fix.

[stefanoboccato]

Im' trying to replicate the authentication used in binding, but I'm not able to do it. Something wrong in my postman call. When from UI I pause and restart the thermostat thing, after a while, in logs I found the full gateway response, like this:

{ "locationId": "1111111", "gateways": [ { "gatewayId": "2222222", "temperatureControlSystems": [ { "systemId": "3333333", "zones": [ { "zoneId": "4444444", "temperatureStatus": { "temperature": 18.0, "isAvailable": true }, "activeFaults": [], "setpointStatus": { "targetHeatTemperature": 18.0000, "setpointMode": "FollowSchedule" }, "name": "Soggiorno" }, { "zoneId": "5555555", "temperatureStatus": { "temperature": 19.0, "isAvailable": true }, "activeFaults": [], "setpointStatus": { "targetHeatTemperature": 18.5000, "setpointMode": "FollowSchedule" }, "name": "Cucina" }, { "zoneId": "6666666", "temperatureStatus": { "temperature": 16.5, "isAvailable": true }, "activeFaults": [], "setpointStatus": { "targetHeatTemperature": 13.0000, "setpointMode": "FollowSchedule" }, "name": "Matrimoniale" }, { "zoneId": "7777777", "temperatureStatus": { "temperature": 16.0, "isAvailable": true }, "activeFaults": [], "setpointStatus": { "targetHeatTemperature": 15.0000, "setpointMode": "FollowSchedule" }, "name": "Bagno" }, { "zoneId": "8888888", "temperatureStatus": { "temperature": 19.0, "isAvailable": true }, "activeFaults": [], "setpointStatus": { "targetHeatTemperature": 5.0000, "setpointMode": "FollowSchedule" }, "name": "Centralina" }, { "zoneId": "9999999", "temperatureStatus": { "temperature": 10.5, "isAvailable": true }, "activeFaults": [], "setpointStatus": { "targetHeatTemperature": 9.0000, "setpointMode": "PermanentOverride" }, "name": "Bambini nord" }, { "zoneId": "1222222", "temperatureStatus": { "temperature": 17.0, "isAvailable": true }, "activeFaults": [], "setpointStatus": { "targetHeatTemperature": 16.0000, "setpointMode": "TemporaryOverride", "until": "2023-02-15T19:20:00Z" }, "name": "Bambini sud" }, { "zoneId": "1333333", "temperatureStatus": { "temperature": 19.0, "isAvailable": true }, "activeFaults": [], "setpointStatus": { "targetHeatTemperature": 19.0000, "setpointMode": "FollowSchedule" }, "name": "Bagnetto" }, { "zoneId": "1444444", "temperatureStatus": { "temperature": 20.5, "isAvailable": true }, "activeFaults": [ { "faultType": "TempZoneActuatorLowBattery", "since": "2022-05-10T09:49:46" }, { "faultType": "TempZoneSensorLowBattery", "since": "2022-05-10T09:49:50" }, { "faultType": "TempZoneSensorCommunicationLost", "since": "2022-05-11T06:38:37" } ], "setpointStatus": { "targetHeatTemperature": 20.0000, "setpointMode": "FollowSchedule" }, "name": "Office" } ], "activeFaults": [], "systemModeStatus": { "mode": "Auto", "isPermanent": true } } ], "activeFaults": [] } ] }

but using anoter api, this one: GET https://mytotalconnectcomfort.com/WebApi/api/devices/{{deviceId}}/thermostat?allData=true&include=true the reponse is: { "units": "Celsius", "indoorTemperature": 20.2000, "outdoorTemperature": 128.0000, "outdoorTemperatureAvailable": false, "outdoorHumidity": 128.0000, "outdootHumidityAvailable": false, "indoorHumidity": 128.0000, "indoorTemperatureStatus": "Measured", "indoorHumidityStatus": "NotAvailable", "outdoorTemperatureStatus": "NotAvailable", "outdoorHumidityStatus": "NotAvailable", "isCommercial": false, "allowedModes": [ "Heat", "Off" ], "deadband": 0.0000, "minHeatSetpoint": 5.0000, "maxHeatSetpoint": 23.0000, "minCoolSetpoint": 50.0000, "maxCoolSetpoint": 90.0000, "changeableValues": { "mode": "Off", "heatSetpoint": { "value": 20.0, "status": "Scheduled" }, "vacationHoldDays": 0 }, "scheduleCapable": false, "vacationHoldChangeable": false, "vacationHoldCancelable": false, "scheduleHeatSp": 0.0000, "scheduleCoolSp": 0.0000 }

[stefanoboccato]

googling a bit, I've found something in this post: https://community.smartthings.com/t/obsolete-honeywell-evohome-integration/44953/209?page=11 the post number 203 tells to change the api, from tccna.honeywell.com to mytotalconnectcomfort.com/WebApi Don't know why, but it seems an obsolete api.

[stefanoboccato]

I solved my issue with many operations, because I'm using OH 3.x but in git I found addons starting version from 4 snapshots. So, in order, I've done this tasks: -fixed code in order to ignore the active faults, and try in any case to retrieve the zone informations, like temperature, setpoint and so on. Once done, I uploaded the jar file to my raspberry, in right place as documentation. Following the logs I see that my bundle is not starting for some dependencies, so, I fixed a couple of this in pom.xml. But this wasn't enough. One strange sort of dependency osgi.ee was driving me crazy. I saw it on list of bundles, trying to activate my last bundle. Looking for a solution, I noticed that people on internet was using java 17, so I decided to upgrade it. -I upgraded the jdk from 11 to 17, using sdkman. I tryed first 19 version, but was not working, so... I used 17.0.6-tem version, the default proposed version by sdkman. OH was still using the 11 version, so... next step. -I forced the OH to start with a specific jdk modifing the /etc/default/openhab file, adding a row: JAVA_HOME=/home/pi/.sdkman/candidates/java/17.0.6-tem/ restarting the service everything worked like a charm.

So, now, I can see the missing data. Offcourse this is not the right way, but it works for now, and I'll hope the new apis will be implemented in next versions.

[lsiepel]

Can you share the code changes?

You probably changed something to:

 private boolean handleActiveFaults(ZoneStatus zoneStatus) {
        if (zoneStatus.hasActiveFaults()) {
            updateEvohomeThingStatus(ThingStatus.OFFLINE, ThingStatusDetail.COMMUNICATION_ERROR,
                    zoneStatus.getActiveFault(0).getFaultType());
            return true;
        }
        return false;
    }

When i look at the API-response, only the 'TempZoneSensorCommunicationLost' fault seems to be a real communcation problem. The others should only be warnigs as there is still some battery juice left.

"activeFaults": [ { "faultType": "TempZoneActuatorLowBattery", "since": "2022-05-10T09:49:46" }, { "faultType": "TempZoneSensorLowBattery", "since": "2022-05-10T09:49:50" }, { "faultType": "TempZoneSensorCommunicationLost", "since": "2022-05-11T06:38:37" } ]

Anyway, filtering those 'warnings' will not fix you problem as these faults keep appearing even after the battery has been replaced. As said before i do not own such a device so i cannot tinker with it. Did you follow the instructions (especially opposite placement of battery's) from: https://www.honeywellhome.com/us/en/support/how-do-i-delete-the-low-bat-message-displayed-on-my-ct3200-ct3300-t8112-t8132-thermostat-screen/

[stefanoboccato]

my changes, in order to understand something about, at first I've added a logger, and then:

`private boolean handleActiveFaults(ZoneStatus zoneStatus) {

    boolean activeFaults = false;

    try {
        new DecimalType(zoneStatus.getTemperature().getTemperature());
    } catch (Exception e) {
        logger.error("error retrieving temperature for zone: [{}]", zoneStatus.getZoneId());
        logger.error("exception is: ", e);
        activeFaults = true;
    }

    try {
        new StringType(zoneStatus.getHeatSetpoint().getSetpointMode());
    } catch (Exception e) {
        logger.error("error retrieving set point mode for zone: [{}]", zoneStatus.getZoneId());
        logger.error("exception is: ", e);
        activeFaults = true;
    }

    try {
        new DecimalType(zoneStatus.getHeatSetpoint().getTargetTemperature());
    } catch (Exception e) {
        logger.error("error retrieving set point target temperature for zone: [{}]", zoneStatus.getZoneId());
        logger.error("exception is: ", e);
        activeFaults = true;
    }

    if (zoneStatus.hasActiveFaults()) {
        zoneStatus.getActiveFaults().stream().forEach(activeFault -> {
            logger.error("zone id = [{}] has active fault type: [{}] since: [{}]", zoneStatus.getZoneId(),
                    activeFault.getFaultType(), activeFault.getSince());
        });
    }
    return activeFaults;
}

`

doing so, only if I retrieving informations and something goes wrong, I consider a true fault.

Anyway, I've 10 "smart" valves of honeywell HR92 linked to central unit display, and the reverse battery is not mentioned as a way to clear faults. When something goes wrong, a message is displayed into central unit, giving the possibility to clear error messages. But in this case, I don't have this chance, so display is as usual, and the error message, this very old error message, appeared on openhab response and nowhere else.

[lsiepel]

Wrong link sorry https://support.resideo.com/s/article/How-to-clear-a-fault-error-symbol-on-the-evohome-controller?language=en_US

It’s just that you seem the only one having this issue. I don’t find any post online about these faults remaining in the API response. As that response comes from Honeywell, the binding is not the cause. I agree the handling can be improved, but the ‘communicationlost’ fault will keep blocking.

If this won’t help, maybe you can repeat the process by putting in almost empty battery’s? Maybe if the process is repeated it triggers the old faults also to get cleared from the api?

[stefanoboccato]

At first I've checked if the log registry entry into evohome controller was present, but... it wasn't. So, it was impossible to clear. I follow your suggestion, I've used old batteries and so the registry entry appeared with usual message of low battery. I've cleared it, switched batteries, and now just restarting openhab service, the response contains only one fault: "activeFaults": [ { "faultType": "TempZoneSensorCommunicationLost", "since": "2022-05-11T06:38:37" } ],

[lsiepel]

While that is an improvement. The blocking fault is still there. Unofrtunately i cannot find any documentation for this API.

From the response there doesn't seem a proper way to determine if the fault is relevant or not. The property name suggests it is allways is relevant (activeFault, as in active would suggest it is ongoing). But i don't think that is the case. There does not seem to be a different timestamp that can be matched to the activeFaults (like last update or similar) to mark the activeFautls is 'historical/no longer active' I also noticed the isAvailable field of the zone.temperature do you know the meaning of that field? As this is the only field that might come close to a fault filter, but only if it means the zone is available / processing commands as expected. But that is probably also not true as it is a property of the temperature object.

Maybe @Nebula83 can comment on the issue?

I workaround would be to ignore the faults, or make ignoring optional in the binding. But yeah, if this is only affecting you it might be worth trying to fix the root cause of the problem in 'your' API-calls.

The evohome smartphone app does not show anything ? (just a lucky shot, i don't even know if that uses the same API) https://apps.apple.com/nl/app/total-connect-comfort-intl/id783653368 https://play.google.com/store/apps/details?id=com.honeywell.totalconnectcomforteurope&hl=en&gl=US

[stefanoboccato]

I don't know the meaning of isAvailable property, it is inside the temperatureStatus, but I never had different value from true. So, I cannot understand the meaning of this. Neither from smartphone app I found something interesting, it is everything as usual.

The strange thing is that I've found the post in which someone tells that this set of api is obsolete and there is something new. Anyway, the old one still works except this particular case. I know that someone else created its own server in order to have it in local network. Its purpose was to have a more userfriendly schedule panel and avoid the controller go online.

[lsiepel]

I can't find a source for this API being obsolete/eol. If this woudl be an API issue, i would expect more users to have this issue as evohome is a populair heating system. Maybe not something you would want to hear, but did you try to rasie a ticket at honeywell? As there API is reportin an activeFault while there is none. (maybe this got stuck somewhere in there databse or who knows.

[stefanoboccato]

good suggestion. I'm looking for where I can raise a ticket, but honestly, not found yet. I've found something to create "one application" like a developer, but do not understand how it works.

[lsiepel]

As this is something that can't be fixed from the binding. I prefer to close this. Honeywelll seems a decent company and probably has proper support for their services. As by now it seems something is wrong with a messager being stuck in their API.

Maybe a bit out of the box, but you could always try to factory default your system and/or create new accounts. Unfortunately there is nothing we can do here.