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

@aart Are you on the latest snapshot?

@David_Graeff Iā€™ve tested on 2.4.0 build 1408 and build 1409, both the same issue.
What also a kind of weird is: I published the config with a retain flag. after starting the device discovery nothing happened until I published again the same message. Directly after publishing the message, the device will be discovered.
Still the same error:

2018-11-02 20:52:22.058 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'mqtt:homeassistant:192_168_5_49_1883:irrigation-' to inbox.
2018-11-02 20:52:27.223 [WARN ] [g.discovery.internal.PersistentInbox] - Cannot create thing. No binding found that supports creating a thing of type mqtt:homeassistant.

It would be really awesome when the device discovery would work! Great work David! Many many thanks!

If you are using the embedded broker, you need to publish with QOS>=1 and retain true for a real retained message.

Oke, Iā€™ve did some testing. QOS 0, 1, 2 embedded broker, mosquitto, all the same behavior. Items only pops up after I published a message, so the retained message is ignored.

Hi @David_Graeff did you get a chance to look at my issue with textual configuration?

Not yet. I guess it has to do with wrong syntax, the readme syntax was not tested and I developed MQTT 2 to actually not have to use the text syntax anymore. Iā€™m not the best person to speak to, maybe someone else has an idea on how to define channels for an extendable Thing?

I have worked on https://github.com/eclipse/smarthome/pull/6445 instead. It allows to transform a channel state before it is published to the MQTT broker. This addresses:

Cheers,
David

What is the url to download the latest snapshot so I can test it. Thanks for the quick turnaround.

I have created an issue: https://github.com/eclipse/smarthome/issues/6462

I understand the shift away from textual configuration but right now it is still very popular and more efficient to keep control over when having a lot of things and items.

@David_Graeff
Today Iā€™ve done some testing on the 1404 build.
Iā€™ve added a Generic MQTT Thing with a dimmer channel.
When I send a command form OH the value is in 2 decimals eg 35.
When I send a state from the MQTT device an error occurred:

[WARN ] [g.mqtt.generic.internal.ChannelState] - Incoming payload '28' not supported by type 'NumberValue'

The only way to get it working is sending the value as a float eg 0.35.
The ā€˜is decimalā€™ switch in paper UI does nothing, not for incoming and not for outgoing messages.

In the Number channel, there is also an issue.
By the step value, the text suggests that you can map a number channel to a dimmer, but that is impossibe.

Currently i am on the 2.4 # 1416 Build and in the process to create my first Sonoff Basisc Generic item. So far everything worked well transformation with JSONPath is ok , switches are working so far, but i have two questions

1.) Is it possible to use a generic thing as a temple for other things

2.) Is it possible to enter more than one state statement Example sonnoff switches give the same value in different states back

Thanks for this great Binding

Unfortunately not. The idea is that the firmware writers of the custom sonoff firmware you are using will adapt a convention that allows auto discovery. For example the Homie convention. Add an issue on their repository to increase the pressure :smiley:

I donā€™t understand. Are you talking about state topics?

@David_Graeff Iā€™m after some help/guidance if possible please.

Iā€™m experimenting with this binding using zigbee2mqtt and a Philips Hue dimmer as the device.

The functionality exposed by the dimmer is On/Off and an increase/decrease brightness which also reports the new dimmer value between 0 and 255.

Here are some example JSON payloads:

Press On button:

{"battery":100,"linkquality":47,"action":"on"}

Press Off button:

{"battery":100,"linkquality":36,"action":"off"}

Press Increase brightness button:

{"battery":100,"linkquality":70,"action":"up-press","brightness":55}

Press Decrease brightness button:

{"battery":100,"linkquality":76,"action":"down-press","brightness":5}

Whatā€™s the best way to model these channels so that I can have a single Dimmer item which responds to a brightness percentage command (i.e. brightness value / 255) or an On/Off command?

Edit: I managed to answer my own question. I created a single Percent channel and used a JS transformation rather than using JSONPATH.

Here is the JS transformation script which goes in the /conf/transform folder:

(function(i) {
        var val = i;
        var json = JSON.parse(i);
        var action = json.action;
        
        switch (action) {
                case "up-press":
                case "down-press":
                        var brightness = json.brightness;
                        val = brightness / 255.0;
                        break;
                case "on":
                        val = 1.0;
                        break;
                case "off":
                        val = 0.0;
                        break;
        }
        return val;
})(input)

However I still have a couple of issues:

  1. The Percent channel type canā€™t be linked to a Color Item
  2. The Color channel type doesnā€™t seem to like receiving values which arenā€™t HSV or RGB i.e. the values Iā€™m passing (0.0 to 1.0) cause the ColorValue to reject the value

Iā€™ve temporarily used a proxy item/rule as a workaround.

1 Like

A rgb or hsb color channel as it is now can only parse the respective tuple of 3 integer values, thatā€™s right. (And ON/OFF, 1/0). It sounds reasonable to me to also accept a single integer and interpret it as brightness value.

Implemented.

Yes the question is how do i define more tan one state topic for a specific channel.

I have improved the description text of the channels. The ā€œis decimalā€ switch only increases the precision for published values, by sending the number including the fractional part. It really does nothing for incoming values.

I have added the exact error to that message, because I have no clue what went wrong here. If minimum and maximum is 0 and 100 as per default, the payload 28 should be valid.

Cheers, David

You can listen to a state topic that includes wildcards, eg. ā€œsensor/+/stateā€. If you really are in need of two different state topics that both together form one functional state, your MQTT topic layout is a bit broken :wink:

Why?
I can have an item subscribe to 2 completely different topics if I want. Why not?
We should be able to subscribe and publish to several topics if desired. We can in the 1.x bindingā€¦

Come up with a use-case and convince me, but:

In openHAB 1.x there are no channels, that is an Apple / Orange comparison. In openHAB 2.x you can bind multiple channels to an Item, so you can get the same effect I guess.

Thanks for your answer and Yes the layout is maybe a little broken (Still working on the Sonoffs) :slight_smile:

As @vzorglub wrote there is maybe the chance to have such situations. For example the sonoffs:

A command Topic
A state topic to get the answer from the command
A state topic that sends out on a regular base update information

Maby it is a solution to implement a third topic for updates.

Correct didnā€™t think of it that way.

Use case:
I publish a time string over mqtt under 2 different topics.
I have some ā€œoldā€ diy ESPs and Arduinos around the house. When I was staring I wrote my own arduino code for these devices. The topic and mqtt broker and WiFi are all hard coded and I canā€™t do OTA. They work fine and some of them are near inaccessible. So I canā€™t change the WiFi, the broker address or the topics without ā€œbreakingā€ these devices.
Later on I wrote some more advances code for other devices and by that time I had changed my MQTT topic structure completely. You see, at first I was experimenting but as it was working these ā€œoldā€ devices became operational.

So now I am stuck with legacy devices that can only subscribe to very different topics than my new mqtt structure.

Therefore I need to publish to 2 very different topics.