Switched from fhem, Questions around Rollershutter

vasu1124 · January 4, 2018, 9:15am

Platform information:
- openHAB: w/docker openhab/openhab:2.3.0-snapshot-armhf-debian
- homematic: w/piVCCU version: 2.29.23-19
UI
- mostly using Paper UI, but also experimenting with all other UIs

Hi All,

I recently switched from fhem to openhab2 and have two questions around Rolleshutter & HM-LC-Bl1PBU-FM:

Inverse: openhab2 inverses the meaning of 0% and 100%, i.e. under Homematic 0% means the Blinds are all the way down, whereas the Rollerhutter item displays 100% for the same state. Not much of an issue, but fhem offered to inverse the interpretation. Does openhab2 also offer that?
Precision: I need half percent precision to open the blinds with a desired angle, e.g. in openhab2 to 98,5%. I can indeed set that value via openhab2. It get’s properly transmitted to Homematic and the state in Homematic is (inverse) set to 1,5% as desired. But when reading the value back, openhab2/Rollershutter rounds to 99%. How can I increase the precision of Rollershutter items?

Thanks!

rlkoshak · January 4, 2018, 10:55pm

You can use transforms or proxy items and rules to invert the percents.
I think Rollershutter saves state as a PercentType which only supports integer values between 0 and 100. I’m surprised it gets transmitted properly in the first place. You might be able to make something work using a Number Item but that won’t accept UP/DOWN commands. You could also use a proxy Number item to show on your Sitemap.

vasu1124 · January 5, 2018, 8:47am

Thanks for the hints with transforms and proxy. Will have to take a loot at that.

For reference:
Am not an expert, but looks like the commandToBinding passes full precision in

github.com

openhab/openhab2-addons/blob/master/addons/binding/org.openhab.binding.homematic/src/main/java/org/openhab/binding/homematic/internal/converter/type/PercentTypeConverter.java

/**
 * Copyright (c) 2010-2018 by the respective copyright holders.
 *
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License v1.0
 * which accompanies this distribution, and is available at
 * http://www.eclipse.org/legal/epl-v10.html
 */
package org.openhab.binding.homematic.internal.converter.type;

import org.eclipse.smarthome.core.library.types.IncreaseDecreaseType;
import org.eclipse.smarthome.core.library.types.OnOffType;
import org.eclipse.smarthome.core.library.types.PercentType;
import org.eclipse.smarthome.core.library.types.UpDownType;
import org.eclipse.smarthome.core.types.Command;
import org.eclipse.smarthome.core.types.Type;
import org.openhab.binding.homematic.internal.converter.ConverterException;
import org.openhab.binding.homematic.internal.model.HmDatapoint;
import org.openhab.binding.homematic.internal.type.MetadataUtils;
import org.slf4j.Logger;

This file has been truncated. show original

Do you think it makes sense to create an issue with https://github.com/eclipse/smarthome/blob/master/bundles/core/org.eclipse.smarthome.core/src/main/java/org/eclipse/smarthome/core/library/types/PercentType.java?
I mean, the precision is probably not an issue with Lightdimmers etc. but I am sure that most blinds need better precision than Decimal!

Thanks!

rlkoshak · January 6, 2018, 5:56pm

I would imagine if that were a common need it would have been implemented in the many years since Rollershutter was implemented. This is the first I’ve seen it mentioned on this forum or the old Google Groups forum.

This isn’t too say you shouldn’t file an issue. But realize that it would be a pretty significant change to the way Rollershutter had always worked and likely cause breaking changes to many people’s Rules, so it is kind of a big deal. We can’t just change PercentType because that is used all over the place in other Item types.

This issue would need to be filled at the ESH repo.