[CLOSED] MQTT binding version 2.4 (Pre-release !)

aart · December 5, 2018, 12:31pm

The number channel works well. The issue is in the percentage channel.
A percentage channel can be mapped to a dimmer item, a number channel can’t.

danielwalters86 · December 5, 2018, 12:45pm

OK, well in that case see my above posts discussing aligning the acceptable values for a channel to the acceptable values for the corresponding item types

Kai · December 5, 2018, 9:04pm

This is done through the TypeParser class.

danielwalters86 · December 5, 2018, 11:54pm

Much appreciated Kai.

@David_Graeff that class might be useful if you have time to look. If not I will try once I manage to fix my dev environment (java seems to crash when I run the new version of Eclipse IDE).

aart · December 7, 2018, 10:06pm

@David_Graeff
Will this issue been fixed for the 2.4 release?

David_Graeff · December 7, 2018, 11:36pm

This is the file in question:

github.com

eclipse-archived/smarthome/blob/master/extensions/binding/org.eclipse.smarthome.binding.mqtt.generic/src/main/java/org/eclipse/smarthome/binding/mqtt/generic/internal/values/NumberValue.java

/**
 * Copyright (c) 2014,2019 Contributors to the Eclipse Foundation
 *
 * See the NOTICE file(s) distributed with this work for additional
 * information regarding copyright ownership.
 *
 * This program and the accompanying materials are made available under the
 * terms of the Eclipse Public License 2.0 which is available at
 * http://www.eclipse.org/legal/epl-2.0
 *
 * SPDX-License-Identifier: EPL-2.0
 */
package org.eclipse.smarthome.binding.mqtt.generic.internal.values;

import java.math.BigDecimal;
import java.util.Collections;
import java.util.stream.Collectors;
import java.util.stream.Stream;

import org.eclipse.jdt.annotation.NonNullByDefault;

This file has been truncated. show original

~~But I do not see any error in parsing the incoming string.~~ Well there is no minimum/maximum range conversion at all, that needs to be added. That is probably the cause why only decimals [0,1] are accepted for the dimmer item.

David_Graeff · December 8, 2018, 10:04am

Fixed.

github.com/eclipse-archived/smarthome

MQTT: Fix disconnect. Fix generic percentage channel.

eclipse-archived:master ← davidgraeff:mqtt_dimmer

opened 09:56AM - 08 Dec 18 UTC

davidgraeff

+127 -118

* Use TypeParser for all generic channel types for String parsing. (Allows IN…CREASE/DECREASE mqtt topic value for a number channel for example) * The percentage channel is automatically fixed by the change above. * Paho 1.2 apparently changed how connections are closed (which results in no closing at all in the async callback variant). Fixed by using the non-callback API and wait for the token to finish. * Fix test launch file Signed-off-by: David Graeff <david.graeff@web.de>

danielwalters86 · December 8, 2018, 10:37am

Awesome news! Can’t wait to try it when we get a new ESH build.

aart · December 10, 2018, 7:44am

Confirmed!

vzorglub · December 10, 2018, 7:52am

Hello @David_Graeff
I have been testing the waters to start writing a MQTTv2 tutorial
So for so good. I like it and I have migrated a number of items to the new binding.

I have question though about UoM.
Would it be possible to add a dimension to the Number channels?

Thanks

vzorglub · December 11, 2018, 9:48am

I have a problem…

I have been doing some testing and changed some items to the new binding.
Switches and Contacts work well

My problem is with Number items
They seem to be divided by a 100 by default.
It is a number channel:

The item:

Number:Temperature   LargeBedroom_ThermostatAmbientTemp    "Large Bedroom Ambient Temp. [%.1f %unit%]"    <temperature> (LargeBedroom, LargeBedroom_Thermostat, Temperatures, AmbientTemps)   [ "CurrentTemperature" ]         { channel="mqtt:topic:LargeBedroomThermostat:Ambient" }

And the log:

2018-12-11 09:32:28.934 [vent.ItemStateChangedEvent] - LargeBedroom_ThermostatAmbientTemp changed from 0.184 °C to 0.183 °C

The value received from the broker: 18.3

I have the same issue on other items too…

Now I have tried to set the binding on debug:

log:set DEBUG org.openhab.binding.mqtt

But that is for MQTTv1
How do I set the new binding on DEBUG?

David_Graeff · December 11, 2018, 9:58am

The mqtt.generic binding lives in the “eclipse.smarthome” namespace, not openhab.
But that doesn’t help much. I do not log what is send to and can be seen by the user anyway.

Have you tried without UoM? And you might want to tick the “Is decimal” option as well.

vzorglub · December 11, 2018, 10:22am

Yes, no effect apart from breaking some rules…

Done
No effect

2018-12-11 10:20:50.174 [vent.ItemStateChangedEvent] - LargeBedroom_ThermostatAmbientTemp changed from 0.18200000 to 0.16900000

I have the same problem on sonoffs RSSI values sent as integers by the device and divided by 100 by default and no UoM on the items.

Number MasterBedroom_HotBlanket_RSSI "Master Bedroom Hot Blanket: RSSI [%d %%]" (gRSSI, Persist) { channel="mqtt:topic:MasterBedroomHotBlanket:RSSI" }

And Humidity values too…

2018-12-11 10:20:50.199 [vent.ItemStateChangedEvent] - LargeBedroom_ThermostatHumidity changed from 0.668 % to 0.65 %

Value received from device via mosquitto: 65.0
Item:

Number:Dimensionless LargeBedroom_ThermostatHumidity       "Large Bedroom Humidity [%.1f %%]"             <humidity>    (LargeBedroom, Humidity, BedroomsHumidity)                                                             { channel="mqtt:topic:LargeBedroomThermostat:Humidity" }

David_Graeff · December 11, 2018, 10:30am

No idea what is going wrong. The code in question:

public void processMessage(String topic, byte[] payload) {
  String strvalue = new String(payload, StandardCharsets.UTF_8);
  ...
  Command command = TypeParser.parseCommand(value.getSupportedCommandTypes(), strvalue);
  ...
  if (command instanceof DecimalType) {
       numberValue = (DecimalType) command;
  }
}

There is no division involved, as long as it is a number and not a percentage channel.

vzorglub · December 11, 2018, 10:36am

Yes and I didn’t think there would be any divisions involved.
The is Decimal option is only for outbound commands, isn’t it?

For me, that is a breaking problem. I can’t use the binding.

Now, when I started yesterdays (Or the day before) only with one RSSI channel, it was working.
Then I updated the SNAPSHOT.
Stopped OH
Cleared the cache
Updated (sudo apt-get…)
Started OH

And then it started doing that
When I started transferring the Thermostats to MQTTv2 then I saw it was doing the same thing even on temperature items…!!!

I am now on SNAPSHOT #1458

EDIT: It must be somewhere in the binding because MQTTv1 is working fine

David_Graeff · December 11, 2018, 1:14pm

The last commit that meant to fix the percentage channel apparently broke the number channel. Sigh.

bartus · December 11, 2018, 1:21pm

Maybe a longshot, but since you mention this issue stems from ESH, perhaps it’s related to what I’m seeing with some UoM Number representation issues (I opened an issue https://github.com/openhab/openhab-core/issues/436 on it). In my case, values with 0 (60, 70, 80,…) are represented in scientific notation (6E+1, 7E+1, …) and then truncated to 6, 7, 8, respectively.

David_Graeff · December 11, 2018, 1:24pm

That could be related. I reference your issue in the mqtt issue as well and notify the ESH core developers.

If that is really an issue in the core they will not be amused, because ESH 0.10 got released just on the 6th of this month.

David_Graeff · December 12, 2018, 10:40am

There is a fix and small feature update for MQTT v2.

3 Channels types have been added:

Location
Date/Time
Image

The rgb color channel has been fixed.

The setting “IsDecimal” has been removed.

Cheers,
David

vzorglub · December 12, 2018, 10:47am

Will you be adding a UoM dimension option for number channels and percentages, please?