Number Item with Dimension set as Temperature causing MQTT failure at sendCommand

lysiasthefox · April 12, 2019, 2:46am

I was about to write a help request but finally managed to solve my own issue. It took me a couple of days to problem solve so I thought I would post it here anyway, just in case others find themselves with the same issue.

I have OpenHab2 (2.5.0.M1) running on a RaspberryPi3 running Raspbian 4.14.79-v7+.

I am new to OpenHab2 and the new bindings but have slowly migrated from the old file based configurations to PaperUI config and the like. I use a number of different MQTT things and their channels relating to various topics/items. Once I got up to speed with the new structure and terminology I have started to appreciate this new direction.

I recently started to use a personal assistant to control my shower unit, so had to set up some of my item tags such as TargetTemperature for my Shower_Ideal_Temp item and CurrentTemperature for my Shower_Water_Temp item. These items were set with the Temperature Category and Number Type. They had been linked through to my MQTT Shower thing (which is a raspberry pi controlling my shower and various other bathroom items) and were successfully controlled using OpenHab2 and the MQTT 2 binding.

While I was setting up the items to work with my home assistant, I noticed that I had not set the dimension field, so I set these two items’ dimension to Temperature (this turned out to be what caused my issue as you will see below).

Anyway, my home assistant could now set the shower temperature so I was happy. That is until I realised that although my Ideal temperature was being changed by both my home assistant and my HabPanel control this change failed to be sent via MQTT to my Shower controller. I tested my shower system using different MQTT clients and these worked well and I also noticed that OpenHab would hear the MQTT messages from the other clients and update the items correctly.

So looking at the events.log and openhab.log I noticed the following error when trying to change the Shower_Ideal_Temp and send the MQTT command.

Events Log

[ome.event.ItemCommandEvent] - Item 'Shower_Ideal_Temp' received command 46
[vent.ItemStateChangedEvent] - Shower_Ideal_Temp changed from 45.0 °C to 46.0 °C

==> /var/log/openhab2/openhab.log <==
[ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.eclipse.smarthome.binding.mqtt.generic.internal.handler.GenericThingHandler@e850fa': null
java.lang.NumberFormatException: null
	at java.math.BigDecimal.<init>(BigDecimal.java:497) ~[?:?]
	at java.math.BigDecimal.<init>(BigDecimal.java:383) ~[?:?]
	at java.math.BigDecimal.<init>(BigDecimal.java:809) ~[?:?]
	at org.eclipse.smarthome.binding.mqtt.generic.internal.values.NumberValue.update(NumberValue.java:91) ~[?:?]
	at org.eclipse.smarthome.binding.mqtt.generic.internal.generic.ChannelState.publishValue(ChannelState.java:321) ~[?:?]
	at org.eclipse.smarthome.binding.mqtt.generic.internal.handler.AbstractMQTTThingHandler.handleCommand(AbstractMQTTThingHandler.java:123) ~[?:?]
	at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.11.0.oh250M1]
	at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [102:org.eclipse.smarthome.core:0.11.0.oh250M1]
	at com.sun.proxy.$Proxy144.handleCommand(Unknown Source) [214:org.eclipse.smarthome.binding.mqtt.generic:0.11.0.oh250M1]
	at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:75) [109:org.eclipse.smarthome.core.thing:0.11.0.oh250M1]
	at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:49) [109:org.eclipse.smarthome.core.thing:0.11.0.oh250M1]
	at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.11.0.oh250M1]
	at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [102:org.eclipse.smarthome.core:0.11.0.oh250M1]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]

It looked like it was having an issue with number type format problems when trying to send the MQTT message but the item would update its value

[ome.event.ItemCommandEvent] - Item 'Shower_Ideal_Temp' received command 46
[vent.ItemStateChangedEvent] - Shower_Ideal_Temp changed from 45.0 °C to 46.0 °C

I did notice that when receiving the command via another mqtt client such as…

mosquitto_pub -h 192.168.1.XX -t cmnd/shower/idealtemp -m 45

it updated as it should…

[vent.ItemStateChangedEvent] - Shower_Ideal_Temp changed from 46.0 °C to 45.0 °C

So I tested to see if it would fail if I tried to change the value in a rule and sure enough it failed in the same way. I then tried to change the item type from a number to a dimmer and it started to send decimal percentage values as it should.

Finally, I got ready to send a help request here, but before I did I thought I would try one last thing. I removed the dimension value from the item (Temperature to empty). This is what seemed to be the reason for the error above. It now all works as you would expect.

Maybe someone could explain what was going on there, but I hope this might help anyone out there with this same issue.

rlkoshak · April 12, 2019, 4:01pm

The MQTT 2 binding doesn’t yet support Units of Measure.

lysiasthefox · April 12, 2019, 8:11pm

I started to suspect something like that. That makes a lot of sense, I have no idea why I’d even fill in the dimension field in the first place. I guess when I was grouping the Thermostat items (so that I could use them with Alexa), I noticed the field and the drop-down was compelling me.

I had actually tried manually sending different value types to update the item (via a rule) and noticed that I could send ON and OFF values to the Number with Dimension set to Temperature and this didn’t cause the error as above (but unsurprisingly didn’t behave as it should).

Thanks for the heads up and kind response. I’m so impressed by all the work that has gone into getting MQTT 2 (and the many other bindings) up and running.

dlaplexurenet · October 16, 2020, 8:35pm

If I would have found this post before it would have saved me lots of time.

In my case it was a bit more weird as I want to use linked channels between KNX and MQTT and I thought I was doing something wrong with profiles or so.

I configured a channel in the MQTT thing of type number and actually nothing arrived at the MQ.

Finally, by enabling debug log for the MQTT binding, I saw that the value pushed included “V” for my item showing the voltage. When I changed the channel type to string, I finally could see values on the queue. Reverting to number and removing the UoM from the item did work as expected and I have now a numeric value on my topic.

Nonetheless, I do not want to remove now all the UoM (I use them pretty much).

I hope support for UoM in MQTT binding will soon be available.

rossko57 · October 16, 2020, 9:44pm

That’s not as easy as it looks, because the binding can have no idea what the target device expects the units to do.
e.g. for outbound, should we send state 23.4 mV as “23.4mV” or “23.4 mV” or “0.023V” or “0.023 Volts” or “0,023U” or …
Maybe something like the label [state presentation] could be applied in conjunction with transformation.

It may be simple to just discard units in the interim.

dlaplexurenet · October 16, 2020, 9:54pm

What I was about to expect, is that the value is transmitted as a raw value without any unit.

Would be interesting to have it as an option in the thing configuration, something like useRawValues=true. Personally I think it should be the intelligence of the application which is reading the value, to put a value in a certain unit context. The target system can later convert the value in whatever it needs.

Many scenarios are possible, but if by default a value is transmitted, formatted as string including the unit, that’s not a good option. Well, that’s my point of view

rlkoshak · October 19, 2020, 4:38pm

I’ve not experimented with it yet, but there is a Unit of Measurement field for Number Channel types on the MQTT Thing. It looks like this is a way that you can apply a unit type for incoming values.

For outgoing I wonder if an outgoing transformation would work. It’s on my todo list to experiment with Units of Measurement on the MQTT binding but it’s way below working on understanding OH 3.