Issues with fibaro heat controller (temperature, battery, status)

[patrickjane]

I am having 4 fibaro heat controllers, updated to the latest firmware (4.4).
They are connected to my home assistant setup (Z-Wave USB stick), however home assistant cannot get the values for battery and the internal temperature sensor correctly. Also, when controllers are switched on, home assistant will not reflect the updated state, and will instead still show them turned off (not sure if this is a HA issue or OZW issue).

Please see this post: https://community.home-assistant.io/t/fibaro-heat-controller-temperature-battery-not-displaying-correctly/70842
As user Rendeik suggested, one should remove the second instance of the battery command class. However when I do this, after a restart of home assistant, the second instance is there again, and the battery still always displays 100%.

In the fibaro home center light, both the internal state/temperature as well as the battery was displayed correctly. So there should be a way to have this information in OZW/HA?

[Fishwaldo]

Logs?

[patrickjane]

OZW_Log.txt

As stated in the issue guidelines, I stopped HA, removed the zwcfg_* file, started HA again. This is the resulting log.
As addition to my initial post:

• After doing the above, HA now correctly shows the battery status for the heat controllers
• HA still does not report temperature from the internal sensors of the heat controllers
• HA still does not report the correct state of the heat controllers when turning them on/off

And one more thing:
My fibaro Z-Wave multi sensors (which I have 4 of them) are now broken in that they show up as "zwave.unknown_node_3", "zwave.unknown_node_16", "zwave.unknown_node_21", "zwave.unknown_node_22", and they don't have any of the sensors for luminance, motion or temperature. Do I need to factory reset them and re-attach them to the Z-Wave network?

[Fishwaldo]

Batteries are on endpoint 1:

2018-10-26 12:06:12.959 Info, Node017, Received MultiChannelCapabilityReport from node 17 for endpoint 1
2018-10-26 12:06:12.959 Info, Node017, Endpoint is not dynamic, and is a General Thermostat V2
2018-10-26 12:06:12.959 Info, Node017, Command classes supported by the endpoint are:
...
2018-10-26 12:06:12.960 Info, Node017, COMMAND_CLASS_BATTERY
...
2018-10-26 12:06:12.960 Detail, Node017, Expected reply and command class was received
2018-10-26 12:06:12.960 Detail, Node017, Message transaction complete

and endpoint 2 (which is weird - I'd check with Fibaro on this)

2018-10-26 12:06:13.041 Info, Node017, Received MultiChannelCapabilityReport from node 17 for endpoint 2
2018-10-26 12:06:13.042 Info, Node017, Endpoint is not dynamic, and is a Routing Multilevel Sensor
2018-10-26 12:06:13.042 Info, Node017, Command classes supported by the endpoint are:
...
2018-10-26 12:06:13.042 Info, Node017, COMMAND_CLASS_BATTERY
...
2018-10-26 12:06:13.043 Detail, Node017, Expected reply and command class was received

If its not updating - you have to check the configuration of this device to see if it can periodically send a update. Otherwise you have to enable polling.

What is strange is that the battery is on a endpoint and not a root device. Unless there are "multiple" batteries on this device?

As far as temps go:

2018-10-26 12:06:19.393 Info, Node017, Received a MultiChannelEncap from node 17, endpoint 2 for Command Class COMMAND_CLASS_SENSOR_MULTILEVEL
2018-10-26 12:06:19.393 Info, Node017, Received SensorMultiLevel supported report from node 17: Temperature

But:

2018-10-26 12:06:41.792 Info, Node017, Received a MultiChannelEncap from node 17, endpoint 2 for Command Class COMMAND_CLASS_SENSOR_MULTILEVEL
2018-10-26 12:06:41.792 Info, Node017, Received SensorMultiLevel report from node 17, instance 1, Temperature: value=0.0C

The device sends 0C. Something is wrong with the device.

HA still does not report the correct state of the heat controllers when turning them on/off

There is nothing in the logs around that. Again check the device configuration and see if there a option to enable that.

My fibaro Z-Wave multi sensors (which I have 4 of them) are now broken in that they show up as "zwave.unknown_node_3", "zwave.unknown_node_16", "zwave.unknown_node_21", "zwave.unknown_node_22", and they don't have any of the sensors for luminance, motion or temperature. Do I need to factory reset them and re-attach them to the Z-Wave network?

They are sleeping devices. Wake them up.

[Fishwaldo]

ping?

[patrickjane]

Sorry for not coming back to you. The motion sensors got back after a while, and are now working correctly again.

As for the heat controller issues, the device manuals did not reveal any useful options, so it still won't show state/temperature/battery. I contacted fibaro customer support, I have not yet received a response.

[patrickjane]

Maybe as small addition, as described here: https://community.home-assistant.io/t/fibaro-heat-controller-temperature-battery-not-displaying-correctly/70842/8 I was finally able to get the battery display to work. It turned out that deleting the second instance of the battery sensor out of the zwcfg_*.xml did in fact work. However in my previous attempt I made the mistake of editing the config while home assistant was running, which made HA discard my changes after restart.
Now with stopping, editing the config, starting, my HA correctly displays the battery status for the heat controllers. One step further now :)

Would it be possible for OWZ to have this by default, so that it will work out of the box for users? Or would this be uncommon/non-generic and possibly break things in the future?

[Fishwaldo]

the zwcfg_*.xml despite its name is a cache file and not a configuration file. So it will be overwritten often.
The battery displaying on two endpoints is what the device advertises, so either that is a potential bug in the device, or HA doesn't have the ability to display two batteries (which would be an HA issue).

So - No. We can't do anything here. If the device says it has two batteries on different endpoints, and it only has one, then its a firmware bug in the device and needs to be fixed by Fibaro

[patrickjane]

Okay, I see. Regarding temperature readings I got a reply from fibaro:

the Heat controllers has two temperature sensors built-in. The fact that both are located inside the plastic cover and we install it next to the heating radiators makes the readings a little bit different than probably expected. It is never “room temperature”.
The both sensors place its role in the algorithm of the device. The Heat controller always tries to operate on opening/closing the valve intelligently – not ON/OFF basis, but will slightly open/close the valve to achieve the setpoint. This is economical approach and the valve is also capable of “learning” the environment.
So the internal sensors are purely for the valve purposes.

In fact, we do not allow the readings in any system – even if you use it with Fibaro HC2, HCL.

It is not possible to display readings from internal sensors on any Z-wave gateway at the moment.
As you are not the first customer asking about, we will revise options and the readings may appear in one of the next upgrades of the Heat controller.

So theres also not much which can be done on this side, as it seems.

[patrickjane]

One more question about the non-updating state of the heat controller. I just enabled the heaters, and took a look in the OZW logs (waited about 15 minutes). One of the heaters is node 17, and this is what I can find for node 17:

2018-11-07 14:01:51.542 Info, Node017, Value::Set - COMMAND_CLASS_THERMOSTAT_MODE - Mode - 0 - 1 - Heat
2018-11-07 14:01:51.542 Detail, Node017, Queuing (Send) ThermostatModeCmd_Set (Node=17): 0x01, 0x0a, 0x00, 0x13, 0x11, 0x03, 0x40, 0x01, 0x01, 0x25, 0xa4, 0x35
2018-11-07 14:01:51.542 Detail, Node017, Queuing (Send) MultiChannel Encapsulated (instance=1): ThermostatModeCmd_Get (Node=17): 0x01, 0x0d, 0x00, 0x13, 0x11, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x40, 0x02, 0x25, 0xa5, 0x59
2018-11-07 14:01:51.542 Detail,
2018-11-07 14:01:51.542 Info, Node017, Sending (Send) message (Callback ID=0xa4, Expected Reply=0x13) - ThermostatModeCmd_Set (Node=17): 0x01, 0x0a, 0x00, 0x13, 0x11, 0x03, 0x40, 0x01, 0x01, 0x25, 0xa4, 0x35
2018-11-07 14:01:51.551 Detail, Node017,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2018-11-07 14:01:51.552 Detail, Node017,   ZW_SEND_DATA delivered to Z-Wave stack
2018-11-07 14:01:52.804 Detail, Node017,   Received: 0x01, 0x05, 0x00, 0x13, 0xa4, 0x00, 0x4d
2018-11-07 14:01:52.804 Detail, Node017,   ZW_SEND_DATA Request with callback ID 0xa4 received (expected 0xa4)
2018-11-07 14:01:52.804 Info, Node017, Request RTT 1261 Average Request RTT 646
2018-11-07 14:01:52.804 Detail,   Expected callbackId was received
2018-11-07 14:01:52.804 Detail,   Expected reply was received
2018-11-07 14:01:52.804 Detail,   Message transaction complete
2018-11-07 14:01:52.805 Detail,
2018-11-07 14:01:52.805 Detail, Node017, Removing current message
2018-11-07 14:01:52.805 Detail,
2018-11-07 14:01:52.805 Info, Node017, Sending (Send) message (Callback ID=0xa5, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): ThermostatModeCmd_Get (Node=17): 0x01, 0x0d, 0x00, 0x13, 0x11, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x40, 0x02, 0x25, 0xa5, 0x59
2018-11-07 14:01:52.814 Detail, Node017,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2018-11-07 14:01:52.814 Detail, Node017,   ZW_SEND_DATA delivered to Z-Wave stack
2018-11-07 14:01:52.837 Detail, Node017,   Received: 0x01, 0x05, 0x00, 0x13, 0xa5, 0x00, 0x4c
2018-11-07 14:01:52.837 Detail, Node017,   ZW_SEND_DATA Request with callback ID 0xa5 received (expected 0xa5)
2018-11-07 14:01:52.837 Info, Node017, Request RTT 31 Average Request RTT 338
2018-11-07 14:01:52.837 Detail,   Expected callbackId was received
2018-11-07 14:01:52.863 Detail, Node017,   Received: 0x01, 0x10, 0x00, 0x04, 0x00, 0x11, 0x08, 0x60, 0x0d, 0x00, 0x01, 0x22, 0x01, 0x01, 0x02, 0xb5, 0x00, 0x0b
2018-11-07 14:01:52.863 Detail,
2018-11-07 14:01:52.863 Info, Node017, Response RTT 57 Average Response RTT 134
2018-11-07 14:01:52.863 Error, Node017, Cannot find endpoint map to instance for Command Class COMMAND_CLASS_APPLICATION_STATUS endpoint 0
2018-11-07 14:01:52.863 Detail, Node017,   Expected reply and command class was received
2018-11-07 14:01:52.863 Detail, Node017,   Message transaction complete
2018-11-07 14:01:52.863 Detail,
2018-11-07 14:01:52.863 Detail, Node017, Removing current message

This was the time when I enabled the heater via HA Z-Wave service call. To me this looks like a command to set the operation mode was sent, and then 1s later, the command mode was queried (maybe to also refresh the state in HA?) Since it did not refresh (HA still displays 'Off'), this probably means the response did not contain the updated operation mode? Now the heaters are also on battery, thus mainly sleeping. Could it be that they don't actively report the operation mode after change, and HA would have to wait a while for querying the state, or use some regular polling?

[no-response]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[Fishwaldo]

Sorry about the Bot Closing the issue...

Regarding your last question... if its a sleeping device - Was its status QueryStage_Complete? If not, then OZW is waiting for it to wake up and complete the interview process... so anything that comes in during that time might be discarded.

Regardless - The COMMAND_CLASS_APPLICATION_STATUS message indicates that the device was busy when the request came in:

2018-11-07 14:01:52.863 Error, Node017, Cannot find endpoint map to instance for Command Class COMMAND_CLASS_APPLICATION_STATUS endpoint 0

Regarding the can't find endpoint - I've just commited a fix for that issue, but it wont fix the APPLICATION_STATUS message.

[Fishwaldo]

(Specifically the APPLICATION_STATUS returned a "Try again in 2 seconds" message. )

[patrickjane]

Okay so I am no expert in all these things, and I am in no way familiar with the Z-Wave protocol, so I'm not fully understanding whats going wrong here. I am just trying to find out if all this is a fibaro issue, HA issue or OZW issue, to report to the right person.

I asked fibaro again and the response was,

for the battery:

this is some kind of incompatibility.
The device has just one battery, of course. The battery does not come as an “endpoint” such as temperature sensor, heating mode endpoint etc.

for the state:

The Heat controller works on a FLiRS basis with frequent beam. It is quite different than standard battery-operated device.
Check if your system is capable of receiving information in this standard.
No additional polling is required.

Does this shed any light onto the issues? Should I open an issue at HA github?

[Fishwaldo]

Sorry for the long reply.

Regarding the Battery - Tell them that the device is reporting a Battery on a endpoint (point them here if necessary, or copy the below log extracts too them to show them this is what the device says).
Its not incompatibility if the device says it has a BATTERY on endpoint 1 and 2, its a bug :)

2018-10-26 12:06:12.959 Detail, Node017, Received: 0x01, 0x1c, 0x00, 0x04, 0x00, 0x11, 0x14, 0x60, 0x0a, 0x01, 0x08, 0x06, 0x5e, 0x8e, 0x40, 0x43, 0x53, 0x98, 0x9f, 0x59, 0x6c, 0x71, 0x75, 0x80, 0x81, 0x85, 0x22, 0xae, 0x00, 0x39
2018-10-26 12:06:12.959 Detail,
2018-10-26 12:06:12.959 Info, Node017, Response RTT 60 Average Response RTT 402
2018-10-26 12:06:12.959 Info, Node017, Received MultiChannelCapabilityReport from node 17 for endpoint 1
2018-10-26 12:06:12.959 Info, Node017, Endpoint is not dynamic, and is a General Thermostat V2
2018-10-26 12:06:12.959 Info, Node017, Command classes supported by the endpoint are:
2018-10-26 12:06:12.959 Info, Node017, COMMAND_CLASS_ZWAVE_PLUS_INFO
2018-10-26 12:06:12.959 Info, Node017, COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION
2018-10-26 12:06:12.959 Info, Node017, COMMAND_CLASS_THERMOSTAT_MODE
2018-10-26 12:06:12.959 Info, Node017, COMMAND_CLASS_THERMOSTAT_SETPOINT
2018-10-26 12:06:12.960 Info, Node017, AddCommandClass - Unsupported Command Class 0x53
2018-10-26 12:06:12.960 Info, Node017, COMMAND_CLASS_SECURITY
2018-10-26 12:06:12.960 Info, Node017, AddCommandClass - Unsupported Command Class 0x9f
2018-10-26 12:06:12.960 Info, Node017, AddCommandClass - Unsupported Command Class 0x59
2018-10-26 12:06:12.960 Info, Node017, AddCommandClass - Unsupported Command Class 0x6c
2018-10-26 12:06:12.960 Info, Node017, COMMAND_CLASS_ALARM
2018-10-26 12:06:12.960 Info, Node017, COMMAND_CLASS_PROTECTION
2018-10-26 12:06:12.960 Info, Node017, COMMAND_CLASS_BATTERY
2018-10-26 12:06:12.960 Info, Node017, COMMAND_CLASS_CLOCK
2018-10-26 12:06:12.960 Info, Node017, COMMAND_CLASS_ASSOCIATION
2018-10-26 12:06:12.960 Info, Node017, COMMAND_CLASS_APPLICATION_STATUS
2018-10-26 12:06:12.960 Detail, Node017, Expected reply and command class was received
2018-10-26 12:06:12.960 Detail, Node017, Message transaction complete

2018-10-26 12:06:13.041 Detail, Node017, Received: 0x01, 0x18, 0x00, 0x04, 0x00, 0x11, 0x10, 0x60, 0x0a, 0x02, 0x21, 0x01, 0x5e, 0x8e, 0x31, 0x98, 0x9f, 0x59, 0x6c, 0x71, 0x80, 0x85, 0x22, 0xae, 0x00, 0x81
2018-10-26 12:06:13.041 Detail,
2018-10-26 12:06:13.041 Info, Node017, Response RTT 59 Average Response RTT 230
2018-10-26 12:06:13.041 Info, Node017, Received MultiChannelCapabilityReport from node 17 for endpoint 2
2018-10-26 12:06:13.042 Info, Node017, Endpoint is not dynamic, and is a Routing Multilevel Sensor
2018-10-26 12:06:13.042 Info, Node017, Command classes supported by the endpoint are:
2018-10-26 12:06:13.042 Info, Node017, COMMAND_CLASS_ZWAVE_PLUS_INFO
2018-10-26 12:06:13.042 Info, Node017, COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION
2018-10-26 12:06:13.042 Info, Node017, COMMAND_CLASS_SENSOR_MULTILEVEL
2018-10-26 12:06:13.042 Info, Node017, COMMAND_CLASS_SECURITY
2018-10-26 12:06:13.042 Info, Node017, AddCommandClass - Unsupported Command Class 0x9f
2018-10-26 12:06:13.042 Info, Node017, AddCommandClass - Unsupported Command Class 0x59
2018-10-26 12:06:13.042 Info, Node017, AddCommandClass - Unsupported Command Class 0x6c
2018-10-26 12:06:13.042 Info, Node017, COMMAND_CLASS_ALARM
2018-10-26 12:06:13.042 Info, Node017, COMMAND_CLASS_BATTERY
2018-10-26 12:06:13.042 Info, Node017, COMMAND_CLASS_ASSOCIATION
2018-10-26 12:06:13.042 Info, Node017, COMMAND_CLASS_APPLICATION_STATUS
2018-10-26 12:06:13.043 Detail, Node017, Expected reply and command class was received

For the State issue, we are working at the SerialAPI Level, FLiRS is at the RF level essentially. So that doesn't matter at all. Additionally, its got nothing at all todo with APPLICATION_STATUS, or polling. I can't help further there, as it seems Fibaro don't understand the issue here. All I can say is this largely is a device issue and nothing wrong with OZW.

[patrickjane]

Thanks for your reply. Meanwhile I decided to have all my fibaro heaters replaced by those from eurotronic, which worked like a charm out of the box. I am really so much happier with them now.

So from my side, this topic is done, however I know others experience the same issues. I told the fibaro support all of the above, and also send them a link to this issue multiple times, but at some point they just didn't respond anymore, so I gave up on it.

Thanks for your support.