@David_Graeff
Hi,
I’m struggling with the dimmer type channel/dimmer item combo. The Dimmer item can send PercentType commands (0…100) which should be converted on thing level to 0…255 range expected by the device.
The NumberValue class doesn’t apply any min/max transformation to percent type commands only for decimals:
...
else if (command instanceof PercentType) {
numberValue = ((PercentType) command);
} else if (command instanceof DecimalType) {
double v = ((DecimalType) command).doubleValue();
v = (v - min) * 100.0 / (max - min);
numberValue = new PercentType(new BigDecimal(v));
}
...
Any suggestion how to archive this?
I’m using Number channels with Setpoint controls on sitemap as workaround but it renders ugly…
Thanks
Hi,
I have a problem with the migration from oh2.3 stable to oh2.4 stable (MQTTv2):
on the picture you can see that with the new version of the mqtt bindings “on” and “OFF” can be seen in the sitemap, at the bottom of the picture you can see the old mqtt binding. how can I remove this “ON” resp. “OFF”?
Same problem here, my solution was to use a MAP transformation and hide the unwanted state. This problem is related to the new MQTT binding, perhaps there is a more elegant solution that I dont know.
Are you sure that this problem (a switch item showing its ON /OFF as text additionally) is related to MQTT?
IMHO it is a problem (or even a wanted? new feature) of the sitemap.
Maybe the MQTT binding is not the right place to implement this outbound transformation. I have a feeling that implementing it on profile level would be a better solution. WDYT?
I think we are all in agreement with this but that is a longer term project. Adding outbound transforms to the MQTT binding is a stop gap solution until something like that gets implemented.
David did say elsewhere that profiles will probably not be the right approach but he didn’t provide details for why. I suspect profiles are set up to only process incoming data.
Assuming you are running OH 2.5 M1 (which you should because of many bug fixes in MQTT 2 binding immediately after 2.4 released there is a new default value in the Map transform. So if you create a .map file containing
=ON
and apply that transform to the incoming Channel any message should get transformed to ON.
rule "Publish all"
when
Channel "mqtt:broker:myUnsecureBroker:myTriggerChannel" triggered
then
//this is variable where all incoming messages is stored separated by #
val parts = receivedEvent.split("#")
//but i do not understand this line
sendCommand(parts.get(0), parts.get(1)
end
This is to replace part of the replacement for the EventBus capability. The Rule get’s triggered for all messages published to the myTriggerChannel. The receivedEvent implicit variable carries the event as a String. The format of the String is <topic>#<value>.
So when events are received on the topic we can command the Item of the same name with the value. Thus you can sort of federate OH instances over MQTT by having them publish all events and using a Rule like this to synchronize them.
Since i install new MQTT binding (2 days ago), i have 2 mqtt_v_1 stops. This was never happen before. And strange, mqtt v1 cannot reconnect to broker, only OH restart helps (i try to restart mosquitto service - doesnt help). I use same name “zbox” on mqtt1 and “zbox” in bridge mqtt2 - is this possible fail reason?
OH 25M1 Xubuntu x86
Most likely. Each needs to have it’s own client ID. Only one client with a given client ID can be connected to the broker at a time. When a client tries to connect with the same ID as a client already connected, the broker will kill the connection to the already connected client and use new connection instead.
Hi, after several months I have now decided to migrate to MQTT 2.4.
Most of items are simple ON/OFF item with On=1", Off=0", but I also have some LEDS with a fadein/out and strange on/off message.
With MQTT1 the item was:
