[shelly] FTR: Control Auto-ON when setting Dimmer brightness

[VanadiumJade]

Shelly Dimmer:
Thing has combined controls for brightness and power state.

Current state

if you set brightness when light is off - then light will turn on to desired brightness.
You cant see what brightness value while light is off.

Feature

• New power item to control on and off state
• Brightness item display brightness even when light is off
• Brightness item being able to be set and light not turning on

New Feature use case

Rules can run to adjust desired brightness reguardless of state.
I can set children room brightness to 50% after 7pm and 10% after 9pm.
I can see if lounge brightness is < 10% after 8am and set to 100%.
Currently I will turn on my kids lights if I try adjust the brightness.
I have got this working correctly with MQTT but would love to move to shelly binding.

Your Environment

Openhab 2.5RC1
Docker image openhab/openhab:2.5RC1
Dell power edge r710 server / vmware / ubuntu / docker

[Rossko57]

Comment: maybe a change in terminology would clarify?

openHAB's simple Dimmer Item model does not sit comfortably with the suggestion. It has only a single state, a percentage, so if it is "off" it can only be off i.e. 0%

Real world dimmers like Shelly can have more complex behaviour - such as responding to an "on" command by resuming a previous dimmer %. Other designs behave differently, e.g. come on at minimum brightness, or full brightness, or some specially designated preset value - so we cannot make assumptions at the generalized openHAB end.
This all gets sorted out so far as openHAB is concerned when devices report their true state to OH.

It seems to me this request could be reworded as looking for a "preset" channel - a % value that can be written to, without affecting actual current state. This preset channel could optionally follow any % changes on the "real" state channel to give a memory/resume effect.
Interaction of the parts of this process between binding and real device depends on device design.

[VanadiumJade]

Yeah sounds good.

Shelly dimmers can be adjusted at the switch. If you hold down the switch. So the "preset" item would idealy show current configured brightness on Shelly device.

With your suggestion.. I could create two items
brightness thing channel defined as switch.
Preset thing channel defined as dimmer / slider.

When brightness is adjusted at hardware end preset item should update
When preset item is updated Shelly should receive a brightness only API request. Regardless of brightness item state or value.

[markus7017]

I'm confused
a) the current implementation was requested along the review process
b) it supports the combined Dimmer control e.g. in PaperUI (combines a slider and a switch)
c) I didn't get the problem

The current implementation allows to

• send an ON or OFF to the brightness channel, which will be forwarded to the device. The device doesn't change the dimmer %, but just turns the light on or off
• sending a % value to the brightness channel will be forwarded to the device. If the light is off it will be turned on (by the device, not the binding) and value is set accordingly
• only exception (as requested by the reviewers): The binding sends OFF to the device when you set a % value of 0. However, the % value in the device doesn't get updated. This allows to restore the value when the device is switched on again (also by the physical button).

There is no need for a preset value. You could have 2 separate items mapping to the same brightness channel (Switch + Number) - this is verified. The binding acts differently based on the value type send to the channel.

From my understanding the binding is following the OH paradigm for DimmableLight. So I don't get the need for an extra channel (which I had to remove).

[VanadiumJade]

I have described a use case above.

I would like to be able to set my kids lights to 10% at 9pm. Regardless of the light state.
So if we need to go in during the night if we press the light switch on the wall it will already be set at 10%. And at 9am it sets lights back to 100%.

I currently use mqtt with shellys and have this working perfectly. But binding doesn't support this.
Also in addition would be awesome to know what brightness the light is set too even if it's off.

So if light has been set less than 10% then I don't adjust brightness.

Thanks in advance. :)

[VanadiumJade]

Also brightness value is nulled if light is turned off.

[hmerk]

You usecase would need a complete redesign of the dimmableLight semantics in openHAB. But you can achieve this right know by using proxy items for your dimmer while using the Shelly binding.
Define a proxy switch for ON/OFF and one for the brightness preset. Create a rule to react on the ON/OFF proxy item and send preset brightness to the Shelly dimmer.
Or you could stick with MQTT just for the Shelly Dimmer and use the binding for other Shelly stuff.

[VanadiumJade]

thanks heaps for your time to read and respond. :)

I had a look through the code a bit. Im no expert and have never used Java before.

If below was changed to remove turn on state
public void setDimmerBrightness(Integer relayIndex, Integer brightness) throws IOException { request(SHELLY_URL_CONTROL_LIGHT + "/" + relayIndex.toString() + "?" + SHELLY_LIGHT_TURN + "=" + SHELLY_API_ON + "&brightness=" + brightness.toString()); }

Like here:
public void setDimmerBrightness(Integer relayIndex, Integer brightness) throws IOException { request(SHELLY_URL_CONTROL_LIGHT + "/" + relayIndex.toString() + "/?" + "brightness=" + brightness.toString()); }

How I have this working now is seperate switch and brightness item.
If above was changed then brightness will only be set if setDimmerBrightness is called.
And turn on and off state is controlled if switch item is turned on that uses setRelayTurn.
This seems like it would meet the need. I tried to make these changes but I couldn't get it to compile.

`private void handleBrightness(Command command, Integer index) throws IOException {
Integer value = -1;
if (command instanceof PercentType) { // Dimmer
value = ((PercentType) command).intValue();
} else if (command instanceof DecimalType) { // Number
value = ((DecimalType) command).intValue();
}

    if (command instanceof OnOffType) { // Switch
        logger.debug("Switch output {}", command.toString());
        api.setRelayTurn(index, (OnOffType) command == OnOffType.ON ? SHELLY_API_ON : SHELLY_API_OFF);
        requestUpdates(2, false);
        return;
    }

    // Switch light off on brightness = 0
    if (value == 0) {
        logger.debug("{}: Brightness=0 -> switch output OFF", thingName);
        api.setRelayTurn(index, SHELLY_API_OFF);
        requestUpdates(1, false);
        return;
    }

    ShellyShortLightStatus light = api.getLightStatus(index);
    Validate.notNull(light, "Unable to get Light status for brightness");
    if (command instanceof IncreaseDecreaseType) {
        if (((IncreaseDecreaseType) command).equals(IncreaseDecreaseType.INCREASE)) {
            value = Math.min(light.brightness + DIM_STEPSIZE, 100);
        } else {
            value = Math.max(light.brightness - DIM_STEPSIZE, 0);
        }
        logger.debug("{}: Change brightness from {} to {}", thingName, light.brightness, value);
    }

    validateRange("brightness", value, 0, 100);
    logger.debug("{}: Setting dimmer brightness to {}", thingName, value);
    api.setDimmerBrightness(index, value);

}`

Im still yet to figure out how the brightness received is being managed.

Reason im really keen to uses shelly binding - is I am able to re-enable cloud setting on the shellys so that I can store power usage in their cloud solution and use their app to view and filter the data.

But I could just build something and continue with mqtt - but cloud power monitoring is very tempting.

But fully understand if what I am suggesting is a workaround - or a hack. If your still a hard no on this then I will close it. I will find another option to visualise power data or try figure out how to compile my changes :)
I intend to move all my lights to dimmable shellys - I really love the option to dimming lights.

Thanks in advance.

[hmerk]

Your suggested changes will not work, as setting a brightness value of zero would not switch the device off. If I undertand your suggestions right, sending a value >0 to a switched off device would not turn it's state to on. This behavior is not compliant to openHABs semantic of a dimmableLight.

[VanadiumJade]

Okay thanks for your time.

[markus7017]

@VanadiumJade I thought about you use case and @hmerk comment about "conforming to the UH paradigm".

In fact triggering 2 actions on a single command is not a very clean approach. Doing the Auto-ON for the Dimmer might be more convenient for the user (only 1 action), but also intransparent, because it does "something" more. The "inconvenience" could be easily compensated by a rule.

Addressing both views I'll integrate a new thing config option: brightnessAutoOn
true: turn device on and set brightness at the same time
false: don't touch device status, just set brightness
default is true

With this both use cases could be achieved and I keep backward compatibility.
This would also allow to get rid of mqtt as you desired.

What do you think?

[VanadiumJade]

That would be perfect!

Also thanks heaps for taking a further ponder over my request.

[markus7017]

try this build:
https://github.com/markus7017/myfiles/blob/master/org.openhab.binding.shelly-2.5.0-SNAPSHOT.jar?raw=true
you need to delete and re-discover the thing, then the thing config show have a new option

[VanadiumJade]

Thanks - sorry I was late responding - Christmas time.

I tried the snapshot jar - but I get below error.

also github for some reason isn't tagging the log properly... but its all below

---

`2019-12-26 22:12:36.898 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/openhab/addons/org.openhab.binding.shelly-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.shelly [280]
Unresolved requirement: Import-Package: org.eclipse.californium.core; version="[2.0.0,3.0.0)"

    at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]

`

[hmerk]

you need to manually install coap, enter the following at karaf console
feature:install openhab-transport-coap

[VanadiumJade]

Okay, I have it working now.

Is there anyway to see the brightness that is set on shelly even when the light is off?
Looks like when the light is turned off... the dimmer value is set to null or empty.

Is anything cool at your end you could do in this situation. I always want to see the dimmer value even if the light is off.

otherwise if openhab lets me... I could add a rule to stop the dimmer update from happening if then new state is going to be null.

[markus7017]

ok, the change will then be part of #6592

Is there anyway to see the brightness that is set on shelly even when the light is off?

No, when the dimmer is off the binding has to report 0 as value

[VanadiumJade]

Awesome. Will this request be updated when other request is complete? Just so I know when I can update Shelly binding. 😃

One more question.

I'm running a VM with openhab in docker. When Shelly binding updates Shelly devices output API it's putting 172.x.x.x instead of actual 192.x.x.x IP.

Is this a bug in binding? Or expected behavior when running openhab in docker?

[markus7017]

Awesome. Will this request be updated when other request is complete? Just so I know when I can update Shelly binding. 😃

You could watch the PR: #6764
Once the PR gets merged this FTR will go into the official code base. The SNAPSHOT jar could be found here: https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/addons/bundles/org.openhab.binding.shelly/2.5.0-SNAPSHOT/
For now stay on the DEV build

[markus7017]

One more question.

I'm running a VM with openhab in docker. When Shelly binding updates Shelly devices output API it's putting 172.x.x.x instead of actual 192.x.x.x IP.

Is this a bug in binding? Or expected behavior when running openhab in docker?

Please post questions in the community thread https://community.openhab.org/t/shelly-binding
or open another Issue for a bug report or feature request.