MQTT mapping outgoing command to value

Setup, Configuration and Use Items & Sitemaps
21

For every ZWave device I’ve tried Off is 0. There isn’t a separate state. Which makes sense. If you set something to 0 there is no other way to describe it other than off. On can be a whole range of values though.

22

Okay, so if you ramp down to 0 the last state is always 1, got it.

23

So I tried this. Or at least something similar. But it looks like the binding must already be changing ON to whatever is defined as max. So if (x == "ON") is never true.

24

Yes, if you are dealing with it all in your custom transform you don’t want any of the on/off/min/max stuff at all. Get rid.

I do suspect the dimmer channel code is flawed though, and the ‘raw’ command is not available. Bug, I’d call that.
You could confirm by logging
yourtransform.js

(function(x){

var log = Java.type("org.slf4j.LoggerFactory").getLogger("org.openhab.model.script.mytransform") ;
log.info("Received command " + x)

// rest of your transform
25

Yeah that will log 99 as the received command. I’m assuming

    public String getMQTTpublishValue(@Nullable String pattern) {
        if (state == UnDefType.UNDEF) {
            return "";
        }
        // Formula: From percentage to custom min/max: value*span/100+min
        // Calculation need to happen with big decimals to either return a straight integer or a decimal depending on
        // the value.
        BigDecimal value = ((PercentType) state).toBigDecimal().multiply(span).divide(HUNDRED, MathContext.DECIMAL128)
                .add(min).stripTrailingZeros();

        String formatPattern = pattern;
        if (formatPattern == null) {
            formatPattern = "%s";
        }

        return new DecimalType(value).format(formatPattern);
    }

Is my problem. Guess I need to figure out how to setup a development workspace to modify the binding. Though as not a programmer by trade [Developer Guide | openHAB]-(Developer Guide | openHAB) seems to come up a bit short as a jumping off point.

26

In response to … ? I thought you wanted special action for command ON, where’s 99 come from? Remove the min/max/on/off stuff from the channel.

27

The 99 was in reference to log.info("Received command " + x). If I remove the on/off/min/max it will return 100 instead. Unless I’m also not making it a Percentage Value type Channel. Any OnOffType.ON command is going to return max or 100 as far as I can see.

I ended up rebuilding the Mqtt.Generic Binding with a custom getMQTTpublishValue function that returns the on or off value if supplied and the command sent to Update was of the type OnOffType.

I’m not happy with my current code for doing that. Java isn’t my favorite language. But it is at least working.

28

Can you find out? That was the purpose of the logging, send a command ON to your dimmer Item and see if the binding interferes with it before passing it to the transformation.

29

Yes the binding converts everything to a PercentType before doing any transformations for the Dimmer channel.

Here is my modification to the binding if anyone else comes accross this.
PercentageValue.java

I’m sure someone more familiar with Java could clean it up a bit.

So I don’t use any transform on outbound now.

30

I think that is a binding bug, an “unwanted limitation”, and channel commands should be passed as-is to user defined transformations.
I’m sure that has come up before, and was also worked around with no github issue being raised, so here we are again.

I would recommend raising a github issue, with your suggested solution.
There may need to be some tweaking because there is a risk of introducing a breaking change, where existing users may be relying on ON->100 conversions by default.

I’d be inclined to work around it with a rule and a proxy Item in the meantime, so that you can use the ‘standard’ binding. Link a Number Item to a number MQTT channel. Control a Dimmer Item from your UI, rules, etc., have a rule intercept commands and reprocess into commands for the Number, have Number state updates update the proxy Dimmer.

31

There actually already is a github issue. That was the first thing I checked. [MQTT] Dimmer channel on/off properties not sending “ON” or “OFF”. I added a link to my code in the comments. It is literally the first piece of functional java code I’ve written so I didn’t quite feel ready to make a pull request with it.

Now that I already setup the build environment I don’t think I’ll go through the hassle with proxy items. That would turn into a mess quick. Nearly every switch in my house is a dimmer.