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 …
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'
when
Item heatit1tempAir received update
then
logInfo("heatit1tempAir", "Update: heatit1tempAir=" + heatit1tempAir.state)
end
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.
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 
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 
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.
@chris:
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,
command.getClass().getSimpleName());
return;
}
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>
<channel id="thermostat_setpoint_heating" typeId="thermostat_setpoint">
<label>Setpoint (heating)</label>
<properties>
<property name="binding:*:QuantityType">COMMAND_CLASS_THERMOSTAT_SETPOINT;type=HEATING</property>
</properties>
</channel>
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 
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:
spHeatTRV2.sendCommand(spTargetSetPoint2.state)
spHeatRoomSensor2.sendCommand(spTargetSetPoint2.state)
and
spHeatTRV2.sendCommand(spTargetSetPoint2.state.toString)
spHeatRoomSensor2.sendCommand(spTargetSetPoint2.state.toString)
@rlkoshak: Hi Rich, any ideas?