[SOLVED] Heatit z-trm2 anyone tried it in OH2?

It looks like we now don’t have the same error - it’s getting a bit further and I missed something in the database export update for the setpoint channel…

I’ve updated the binding again here a try and see if this helps…

Same as before - you’ll need to delete/add the thing.

Same procedure: lots of exceptions this time …

Now here

We’re close now :slight_smile: .

New round, setpoint didn’t change on device …

It looks like it’s probably working, but for some reason there were a bunch of errors from the controller around the time this was sent, and no commands were sent.

2018-06-10 01:17:49.298 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 85: Command received zwave:device:f180343d:node85:thermostat_setpoint_heating --> 21.5 ?
2018-06-10 01:17:49.299 [DEBUG] [ter.ZWaveThermostatSetpointConverter] - NODE 85: Thermostat command received for 21.5 ?
2018-06-10 01:17:49.299 [DEBUG] [.ZWaveThermostatSetpointCommandClass] - NODE 85: Creating new message for command THERMOSTAT_SETPOINT_SET
2018-06-10 01:17:49.300 [DEBUG] [ommandClassTransactionPayloadBuilder] - At build null
2018-06-10 01:17:49.300 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 85: Encapsulating message, endpoint 0
2018-06-10 01:17:49.300 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 85: SECURITY NOT required on COMMAND_CLASS_THERMOSTAT_SETPOINT
2018-06-10 01:17:49.300 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 85: Command Class COMMAND_CLASS_THERMOSTAT_SETPOINT is NOT required to be secured
2018-06-10 01:17:49.300 [DEBUG] [ter.ZWaveThermostatSetpointConverter] - NODE 85: Sending Message: org.openhab.binding.zwave.internal.protocol.transaction.ZWaveCommandClassTransactionPayload@2b288323
2018-06-10 01:17:49.302 [DEBUG] [.ZWaveThermostatSetpointCommandClass] - NODE 85: Creating new message for application command THERMOSTAT_SETPOINT_GET (Heating)
2018-06-10 01:17:49.302 [DEBUG] [ommandClassTransactionPayloadBuilder] - At build COMMAND_CLASS_THERMOSTAT_SETPOINT
2018-06-10 01:17:49.303 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 85: Encapsulating message, endpoint 0
2018-06-10 01:17:49.304 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 85: SECURITY NOT required on COMMAND_CLASS_THERMOSTAT_SETPOINT
2018-06-10 01:17:49.304 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 85: Command Class COMMAND_CLASS_THERMOSTAT_SETPOINT is NOT required to be secured
2018-06-10 01:17:49.305 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 85: Adding to device queue
2018-06-10 01:17:49.306 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 85: Added to queue - size 2

At least this shows that the binding is now processing the command and sending a command. I’ve not decoded the command completely, but I think it’s correct (the D7 in the command is 215 which is the temperature you set, the 22 before that I think sets the decimals, and I think the 01 before that says it’s deg C).

The controller didn’t send the command to the device, so I think it’s worth trying again to set the setpoint…

You were right.
Sending the sendCommand(heatit1setPoint, 21.5|“°C”) again made it through.

This rule:

rule 'hvac1tempAir'
    Item heatit1tempAir received update
    logInfo("heatit1tempAir", "Update: heatit1tempAir=" + heatit1tempAir.state)

still logs

2018-06-10 10:48:02.912 [INFO ] [arthome.model.script.heatit1setPoint] - Update: heatit1setPoint=21.5 ?
2018-06-10 10:48:03.110 [INFO ] [arthome.model.script.heatit1setPoint] - Update: heatit1setPoint=21.5 ?

but that could be some missing formatting on my part? This is the first time I use the Number:Temperature.
All my Aeon Multisensor 6s use only Number.

About all my controller errors; they tend to be abundant right after s restart. After that it settles.
I have s spare stick. What do you think about making a backup, restoring to the spare?
I can vaguely remember we have discussed these errors in another thread. They started showing up when my number of nodes reached a high number (>25 or so).
When you do your testing, how many nodes are in your network?

Maybe - I’m also not especially familiar with the new UOM usage, but when I was testing this a couple of weeks back I think it was logging as deg C, so I think the ? does indicate something is wrong somewhere.

For testing normally only a small number as I normally just include the device I’m trying to test with. In my production system though I have around 40 nodes.

Had a look in habmin:

PeperUI seems confused about the setpoint:

I honestly have no idea what that is showing - ie why the items seem to be duplicated?

habmin also shows duplicates when a channel is assigned to an item name.
Guess that is what it is. Anyway, it shows a value of 22, but clicking on it it changes to an input field showing 21.5 .
Changing the value in paperUI makes the change take (thanks to your latest binding. Didn’t work before), but it is not possible to set the value a second time. No matter how i click, I cannot get the input field back. So it is a once per session setting :slight_smile:

habmin does not seems to accept any editing in Description view other than switches ON/OFF.

Strange - I can’t see why the binding would prevent this, but…

Can you provide a log showing 2 (or more) set commands and I’ll see if it shows anything.

No, this is not binding related.
Must be a paperUI thing. Cannot provide a log of multiple settings when input field appears only once :wink:
Who is maintaining paperUI? Could tip him off (somehow I guess it is not a she?) maybe?

Since it is showing the current value wrong, it is probably type confused in some way.

For what it’s worth, I have updated the same .zip we used yesterday with a debug log of setting the setpoint from paperUI.

Probably @henning might be able to comment - he’s also the UoM expert :slight_smile: .

I think there is still an issue in the Zwavehandler. I tried changing the setpoint for 2 items but it was not possible:

2018-07-23 17:47:46.362 [INFO ] [se.smarthome.model.script.HVAC Rules] - PARENTS BEDROOM: Updating targets with value 12.0 °C

==> /var/log/openhab2/events.log <==

2018-07-23 17:47:46.381 [ome.event.ItemCommandEvent] - Item 'spHeatTRV2' received command 12.0 °C

==> /var/log/openhab2/openhab.log <==

2018-07-23 17:47:46.391 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Command received zwave:danfoss_lc13_00_000:b8d4da1b:node8:thermostat_setpoint_heating --> 12.0 °C

2018-07-23 17:47:46.405 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Command received with no implementation (QuantityType).

==> /var/log/openhab2/events.log <==

2018-07-23 17:47:46.414 [vent.ItemStateChangedEvent] - spHeatTRV2 changed from 14.0 °C to 12.0 °C

2018-07-23 17:47:46.427 [ome.event.ItemCommandEvent] - Item 'spHeatRoomSensor2' received command 12.0 °C

==> /var/log/openhab2/openhab.log <==

2018-07-23 17:47:46.422 [INFO ] [se.smarthome.model.script.HVAC Rules] - PARENTS BEDROOM: Change detected in Setpoint. TRV setpoint is 12.0 °C

2018-07-23 17:47:46.438 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Command received zwave:danfoss_014g0160_00_000:b8d4da1b:node5:thermostat_setpoint_heating --> 12.0 °C

2018-07-23 17:47:46.444 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Command received with no implementation (QuantityType).

2018-07-23 17:47:46.450 [INFO ] [se.smarthome.model.script.HVAC Rules] - PARENTS ROOM: do nothing

==> /var/log/openhab2/events.log <==

2018-07-23 17:47:46.464 [vent.ItemStateChangedEvent] - spHeatRoomSensor2 changed from 14.0 °C to 12.0 °C

==> /var/log/openhab2/openhab.log <==

2018-07-23 17:47:46.477 [INFO ] [se.smarthome.model.script.HVAC Rules] - PARENTS BEDROOM: Change detected in Setpoint. Room Sensor setpoint is 12.0 °C 

the problem seems to be related to the following code section:

DataType dataType;
try {
    dataType = DataType.valueOf(command.getClass().getSimpleName());
} catch (IllegalArgumentException e) {
    logger.error("NODE {}: Command received with no implementation ({}).", nodeId,

For some reason it is always catching an exception and causing it to quit too early.
I am running the latest dev build with the latest OH2 2.4 SNAPSHOT #1314

any ideas how to debug this any further?

By the way, having looked at the channels definition of the 2 related items, I can see that they are defined correctly in the database:

  <channel id="thermostat_setpoint_heating" typeId="thermostat_setpoint">
    <label>Setpoint (heating)</label>
      <property name="binding:*:QuantityType">COMMAND_CLASS_THERMOSTAT_SETPOINT;type=HEATING</property>

Which version of the binding are you using please?

latest development branch built it myself. (commit #963)

Please use the binding that I provide in the development discussion thread so we know exactly what you are using.

Alternatively, since you have built this yourself, can you debug it?

only if I insert some trace output in the code and I built it again. My OH2 is running on a RPI2.

My 2 Cents on this change to support UoM:

  • the binding should be able to interpret all kind of input thrown at it, not only the QunatityType:
    + If only a decimal (23), it should interpret it as a value in the correct Unit being used in the system (Degrees Celsius for example)
    + If a string (like 23 °C), it should be able to interpret it and do the right conversion before sending the value to the device

  • some devices have their own config parameters to set the desired Unit that is shown on the display of the device. On Z-Wave level, the unit is sent as part of the command (scale parameter). Which scale the binding uses to sent the command? is it always degrees C by default and the conversion takes place in the binding if OH2 system is set to degrees F by default? Or do you set the scale in the binding according to system settings?

Do I take it then that you are not planning to do this? Is it not possible to put the stick in the your PC to debug?

I would agreed - but you are sending a QuantityType, not a Number so this isn’t the binding problem I think - the error shows that the command is received as a QuantityType,.

Firstly, I am not sure why it is not implemented since the latest binding should provide this function - have you deleted the thing and add it back to make sure that you have the latest thing definition?

Please remember that items have types - you can’t just go and use any type that you like - you need to use the right type. For the command, it is possible to write the binding to work with different types, but the update will always be sent in a specific type.

I suggest to resolve the issue here before complicating things :slight_smile:

No - the binding will send the value that you provide directly to the device. The binding doesn’t perform scaling.

Unfortunately I am using a Razberry. I only use eclipse for building bindings. That’s why not possible.

Yes, several times, but without success. I even deleted the cache and temp folders under userdata and forced OH2 to rebuild everything.

Could it be related to the rule I am using, because from PaperUI everything works fine:

I used both of these variants and nothing worked:




@rlkoshak: Hi Rich, any ideas?