Homematic various error messages and Unknown things

Shorty.XS · November 12, 2018, 12:32pm

Hi Everybody,
I’m quite new to HA an trieng to get my homematic up and running.

First of all, I get tons of HMGeneric.getValue errors.
How can I get rid of those?

2018-11-12 12:04:48 ERROR (Thread-40) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on JEQ0022019:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:48 ERROR (Thread-23) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on JEQ0022019:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:48 ERROR (Thread-7) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on IEQ0170715:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:48 ERROR (Thread-42) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on JEQ0060755:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:48 ERROR (Thread-43) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on JEQ0021318:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:48 ERROR (Thread-12) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on JEQ0060755:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:49 ERROR (Thread-47) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on IEQ0170715:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:49 ERROR (Thread-8) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on JEQ0061022:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:49 ERROR (Thread-28) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on JEQ0021318:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:49 ERROR (Thread-25) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on JEQ0061136:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:49 ERROR (Thread-16) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on JEQ0021318:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:49 ERROR (Thread-57) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on JEQ0061136:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:49 ERROR (Thread-58) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on JEQ0022019:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:49 ERROR (Thread-24) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on JEQ0060755:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:49 ERROR (Thread-46) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on JEQ0061022:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:49 ERROR (Thread-49) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on JEQ0061136:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:51 ERROR (Thread-20) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on JEQ0061022:1 Exception: <Fault -5: 'Unknown parameter'>
2018-11-12 12:04:51 ERROR (Thread-56) [pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on IEQ0170715:1 Exception: <Fault -5: 'Unknown parameter'>

I guess I need a template but I don’t really understand this template thing:

Do I have to create a template for each device? If yes, is there a way to output a list of all devices?
I expected to have them listet in the “known_devices.yaml” but they are not.
If no, how can I prepare a template that matches all devices of a specific type or for a specific value? The Battery, in my case?

Also there is a warning message

2018-11-12 12:04:48 WARNING (MainThread) [homeassistant.setup] Setup of homematic is taking over 10 seconds.

I have several HM-CC-VD that bring up the Valve state without any problem but the one HM-CC-RT-DN, that I have, doesn’t. How to fix that?

All my HM-CC-TC display the word “Unknown” under operation mode in the GUI.

Also the “Action” button at the bottom edge of the dialog of my HM-CC-TC does not do anything.

While it seems to allow setting the opeation mode on the HM-CC-RT-DN

Any advise on these problems would be really great. The Homematic Part of my config.yaml looks like:

# Homematic
homematic:
  interfaces:
    rf:
      host: !secret homematic_host
      resolvenames: json
      username: !secret homematic_username
      password: !secret homematic_password
    groups:
      host: !secret homematic_host
      port: 9292
      resolvenames: json
      username: !secret homematic_username
      password: !secret homematic_password
      path: /groups
  hosts:
    ccu2:
      host: !secret homematic_host
      username: !secret homematic_username
      password: !secret homematic_password

danielperna84 · November 12, 2018, 6:34pm

First of all: are you using hassio or another installation type? And what’s your HASS version?

What kind of devices are those you are getting the errors for? Judging from the Serial number I assume they are fairly old. Which shouldn’t make a difference, but the parameter where the low battery state is transmitted is different for different devices.

What do you want to do with the template?

You should see them in .homeassistant/.storage/core.entity_registry. Of much simpler in the HASS UI in the dev-section.

HomeMatic devices report their battery state differently. So for that, you would need separate templates.

The warning about the startup taking long can be ignored. That’s normal.

It should actually have the valve state in the entity attributes, along with the battery state.

That could be a bug. Although no one has reported that problem yet. So it may be a local issue for some reason. And this will probably also be the reason why the action list doesn’t do anything.

Shorty.XS · November 13, 2018, 8:28am

Could you please explain, why this matters? I expected that the software has all the same features, if I follow any of the installation guides? I’m still not fully understanding these different concepts.
While writing this, I found another instuction, that looks slightly different, to the one I followed:
Installation - Home Assistant and it adds some Linux packages, that I might have not installed. Such as Avahi, network-monitor, Apparmor

Basicly I followed this instruction here:

on plain Debian Stretch x64 in an LXC container on Proxmox.

Over here, I described that a bit more detailed.

And I listed pretty much all components, I use, in my Forum profile:

They are all HM-CC-TC

It seems I don’t have that GUI option but I’m fine with the Linux command line. I just missed that .storage folder.
That file seems to be exactly what I was looking for. I was searchign for some other stuff as well, that is in there. There is no battery entry at all for any of the homematic device, by the way.

That is the answer for your question above, what I want to do with the template. I read somehwere, I might need to add this to get rid of these errors although I expcted that all homematic devices should be ready to go, since they are on the market for a while.

If it is normal that it takes longer than 10 seconds, why does it spam the log at all?

Can you point me how to find that? Even in the .storage/core.something files I don’t see the values.

OK, how can I help, to solve that?
I’m not a programmer but I can read and modify source code and do testing.

danielperna84 · November 13, 2018, 7:17pm

The emphasis should have been on the version. The type of installation matters in case there’s some bug, which is harder to manually patch in case of hassio.

They seem to have been incorrectly implemented here. The device class is using the HelperLowBat, but looking at the device specifications the device isn’t even capable of reporting the battery state via the XML-RPC API. So one task would be to remove the HelperLowBat, which would get rid of all those errors. As a result, your plan to use templates to get the battery state can be cancelled, because the device simply does not allow you to do that (at least the above mentioned documentation has no reference to any battery paramter we could evaluate).

Yes you do. This is what I mean:

It’s not implemented for all types of devices. The pyhomematic repository is where you can contribute to add support for the devices you have.

Only the ones that have been implemented are supported. Most of the devices have been tested, but there are also some that only have been implemented by looking at the documentation. As long as nobody complains we assume they are working.

That message is independent of HomeMatic. Components should startup as quickly as possible (less than 10 seconds). But some - for technical reasons - just don’t. I assume (but don’t know) the message is logged as a warning because it can be an indicator for a problem.

You shouldn’t find any states in the storage. States are in the database or in the dev-panel I have shown you in the screenshot above. By the way: you can test templates live by using the second next button on the right.

By finding out if the problem is within pyhomematic or the relevant platform code of Home Assistant.

Shorty.XS · November 14, 2018, 11:55am

From real life usage, I don’t remember if I ever had any notification on the CCU2 regarding low battery of the HM-CC-TC. Usually they beep and I swap batteries.

I cut the line down to
class ThermostatWall2(HMThermostat, AreaThermostat):
And I don’t have any error in the logs anymore. I will keep an eye on it if I get that information somehow on the CCU2 directly and eventually come back to that issue later.

Yes, found that in the meantime. Thanks.

Is there any information, what devices have been tested and what devices were implemented based on documentation?

Thanks for your help so far.

danielperna84 · November 14, 2018, 12:29pm

I did that in the repository as well. So the next pyhomematic release won’t have those error messages anymore.

No. In general you can see which devices should work by browsing the devicetypes folder of pyhomematic. At the bottom of for e.g. actors.py you’ll find a dictionary, where each supported device points to a class. If a device is NOT listed there, it won’t work in Home Assistant.
Most devices that are implemented by specification actually work very well. Only the HmIP devices are a pain in that regard. There are however also tested devices, that just can’t operate to their full potential within Home Assistant because the device either relies on functionality directly from the CCU (there’s an old display that can’ be properly controlled via XML-RPC), or it’s too complex to recreate everything in Home Assistant without significant performance drops (there’s a wired actor with >10 channels where each one can be configured to do different stuff).
I also noticed, that from the specification the HM-CC-TC can’t set operating modes via XML-RPC. I forgot if I mentioned the above already, but that’s why the dropdown box for your device does nothing. That’s probably also a case where only the CCU is capable of setting the operation mode.

Shorty.XS · November 14, 2018, 1:01pm

Regarding this issue,
If I compare the HM-CC-TC implementation to for example the HM-TC-IT-WM-W-EU, becasue it is right above. I think I understand why there is a status unknown and the action dropdown does not work.

class ThermostatWall(HMThermostat, AreaThermostat, HelperBatteryState, HelperRssiPeer):
    """
    HM-TC-IT-WM-W-EU
    ClimateControl-Wall Thermostat that measures temperature and allows to set a target temperature or use some automatic mode.
    """
    def __init__(self, device_description, proxy, resolveparamsets=False):
        super().__init__(device_description, proxy, resolveparamsets)

        # init metadata
        self.SENSORNODE.update({"ACTUAL_TEMPERATURE": [2],
                                "ACTUAL_HUMIDITY": [2]})
        self.WRITENODE.update({"SET_TEMPERATURE": [2]})
        self.ACTIONNODE.update({"AUTO_MODE": [2],
                                "MANU_MODE": [2],
                                "BOOST_MODE": [2],
                                "COMFORT_MODE": [2],
                                "LOWERING_MODE": [2]})
        self.ATTRIBUTENODE.update({"CONTROL_MODE": [2], "BATTERY_STATE": [2]})


class ThermostatWall2(HMThermostat, AreaThermostat, HelperLowBat):
    """
    HM-CC-TC
    ClimateControl-Wall Thermostat that measures temperature and allows to set a target temperature or use some automatic mode.
    """
    def __init__(self, device_description, proxy, resolveparamsets=False):
        super().__init__(device_description, proxy, resolveparamsets)

        # init metadata
        self.SENSORNODE.update({"TEMPERATURE": [1],
                                "HUMIDITY": [1]})
        self.WRITENODE.update({"SETPOINT": [2]})

For the HM-CC-TC it is just not implemented. It seems to just handle Temperature, Humidity and Set Point.
I don’t understand the documentation, you referenced on this point for the HM-TC-IT-WM-W-EU the description is much more detailed.

However, within the CCU2 GUI, I can set all this values and it seems, even more.

Even though especially the Operating Mode has some totally different names, they describe what the mode does instead of showing the same Mode name as on the device itself.
It would be really handy to be able to set holiday mode or party mode for all or a few rooms via some automation script. (I did not double check if such probably already exist, here in the forum)

danielperna84 · November 15, 2018, 12:02am

Your screenshot is the UI for configurating the device. This has to be done via the CCU for devices like the HM-TC-IT-WM-W-EU as well. Home Assistant does not aim to handle the internal configuration of devices. That would be way to complex and would require way more work for something that already is available. Home Assistant only has the goal to use the devices like. The only part that Home Assistant tries to emulate is the part of the UI to which you get when you select your device under “Status und Bediening” -> “Geräte” -> “Device”. So the part that looks like this:

As you can see, here I can control the modes from the UI. These buttons use the prameters like BOOST_MODE, LOWERING_MODE etc… And for your device those paramters are not mentioned in the documentation. So even if the device generally is capable of doing similar stuff, it is not exposed via the API that we use to control everything.