Some MQTT commands not recognised. Can't see why

Setup, Configuration and Use Items & Sitemaps
1

I have run into some trouble with MQTT on OpenHAB. I can’t really understand why.

I have updated the MQTT.cfg and OpenHAB is happily receiving and displaying mqtt messages I send from MQTT-Spy, so I know the configuration is right.

I have an arduino online that fires the mqtt topic “hal/humid” with the readings of a humidity sensor as payload.
When I check in MQTT-spy or in MQTT-Fx that topic/ payload is received.

In Openhab I defined the following item
Number Humidity_GF_Garage "Humidity [%.0f %%]" <humidity> (GF_Garage) {mqtt="<[mosquitto:hal/humid:state:default]"}

sadly though that keeps giving a blank, does not react to the message sent by my arduino. However, MQTT-spy and MQTTFx do recieve the message.

If I then send a message with the same topic ‘hal/humid’ from MQTTspy… Openhab does see it and publishes it.

I have gone over it and gone over it, compared with other peoples examples, but for the life of my I can’t see what I am doing wrong.

I also have my Arduino send the state of a Switch (“OPEN”/“CLOSED”) and that IS seen and published by Openhab, but not my reading of the humidity sensor, nor a reading of a thermometer.

Anybody have some tips??

2

It looks all OK to me… however try %s instead of of the float %.0f.
If this works, then you have an extra blank (space) (most likely at the end) of that message.
I haven’t tried it, but you may have to change the Number Humidity… to String Humidity…
All this only to proof you are receiving a string instead of a number.
If the string works, find the blank your Arduino is sending, and you can revert back to 'number’
Good luck :slight_smile:

3

Thanks, Indeed I also have thought about string vs number and indeed I am sending it as a string coz as far as I know that is what PubSub library expects and it has worked for me before.
-using %s instead of %.0f did not work
-using the above and String instead of Number indeed does work :slight_smile:
Odd, as I see evrybody using ‘number’ and as far as I know all MQTT messages are sent as strings. This is how I did it mqttClient.publish("hal/humid", dtostrf(h, 6, 2, msgBuffer));

Oh well, I could be wrong. I will check that space character in my arduino as well, but that ofcourse is somewhere in an not easy accessible spot.
Will try it for temperature as well, hope I still will keep the fraction after the dot

Thanks

4

Hmm, my items feeding of mosquitto are numbers (were appropriate).

Number   Battery_SOC		"Battery State of Charge [%.1f %%]"	<inverter>	(gBattery, gBattery_Chart)	{mqtt="<[mymosquitto:ArgyleCourt/Shed/Tower/BMS/SOC:state:default]"}
Number   Battery_Capacity	"Battery Capacity [%.1f kWh]"		<inverter>	(gBattery)			{mqtt="<[mymosquitto:ArgyleCourt/Shed/Tower/BMS/BatteryCapacity:state:default]"}
Number   Battery_Power		"Battery Power [%.0f W]"		<inverter>	(gBattery)			{mqtt="<[mymosquitto:ArgyleCourt/Shed/Tower/BMS/BatteryPower:state:default]"}

Arduino code…

const char MQTT_PUB_BMS_SOC[]             = "ArgyleCourt/Shed/Tower/BMS2/SOC";
const char MQTT_PUB_BMS_BatteryPower[]    = "ArgyleCourt/Shed/Tower/BMS2/BatteryPower";
const char MQTT_PUB_BMS_BatteryCapacity[] = "ArgyleCourt/Shed/Tower/BMS2/BatteryCapacity";

using a function to publish…

          dtostrf(batteryPower, 6, 2, bufBatteryPower);
          publishTopicAndMessage(MQTT_PUB_BMS_BatteryPower, deblank(bufBatteryPower));

and removing spaces with:

char * deblank(char *str) {
  char *out = str;
  char *put = str;

  for (; *str != '\0'; ++str) {

    if (*str != ' ') {
      *put++ = *str;
    }
  }
  *put = '\0';
  return out;
}

… which is in principle the same as you did.

However, I would say a number expects a number in OH. If there is a non-numeric value in your string; e.g. 0x00 OH will not accept it as number.

You could add braces around the number or print to HEX on the serial monitor to see, whether you’ve really got a pure number.

Also, you said ‘keeping the fraction’ you would need %.1f for that.

5

Thanks, yes I use the same function “dtostrf” and has worked in the past. I don’t think the conversion of a number can suddenly have a non numerical value/space in it, but I will check.

Indeed, need to keep the %.1f… but then ‘String’ flags an error.

Oh well I am happy to see you did the same, at least I wasn’t crazy. It works with a string, but especially for rules I like to have my temp and humidity and stuff as numbers.

Anywat, thanks for your input, stimulates me to seek further and not just accept ‘ok i will use a string then’ (although for the mean time I am happy with that solution)

6

tried with a reading from analog port, which is a pure number… same result. Had hoped maybe the DHT library was the culprit. Will do some further research

7

Hmm, where you read from does not matter…
The issue is that OH expects a number for your number item.
While mqtt treats the messages as strings, a numeric value is sent as string too, but if a numeric values arrives in OH it seems to be interpreted as number – but not, if a non-numeric char is in that ‘string’… hope this makes sense :slight_smile:

8

Yes, makes sense, and I understood that already but I just wanted to make sure it was a pure number (as string) I was offering as mqtt payload, not a number with a non number character attached in string format
So if it is a pure number I am offering to my dtostrf conversion to be transformed to string and it arrives as string in OH that apparently cannot be considere to have only cipher characters then dtostrf must be the culprit… never realised it could introduce unwanted chard

number ------> number as string ---->mqtt publish ------------mqtt arrive in OH --> string that canot be considered a number

oh well, the search goes on
I will try your deblank function… if I have space (using an old enc28j60 shield)

9

I am now using mqttClient.publish("hal/humid", deblank(dtostrf(h, 6, 2, msgBuffer))); and that seems to work with items set back to Numbers.
I am amazed, i had never expected the dtostrf function to do that.
In the past I have used ‘String’ to do the same, but apparently the Knolleary pubsub has problems with that. The Imroy fork could handle that.

Anyway… thanks a bundle… if you dont mind your deblank will be added to a lot of my sketches

1 Like
10

No… it expects a char array :slight_smile:
I am glad you figured it out though :slight_smile:

11

’ problems with that’ as eufemism for “wants something else” :slight_smile:
Yes with help from uou and yr great function.
Adding mqtt input now is a breeze. Tnx again :slight_smile: