I have a test JAR available that matches the current state of this pull request and I would be very happy if others were to test it in their environments. I’ve tested both the MQTT Item and the MQTT Event Bus bindings on two of my openHAB servers (one at 1.7.1 and one a recent 1.8.0-SNAPHOT).
This is what should be different:
The two bindings (MQTT Item and MQTT Event Bus) determine the kind of openHAB item to which a message is intended, and will only convert the message into an update or command that is appropriate for that kind of item. This allows the following scenarios that are not currently possible:
- Send a decimal number to a String item.
- Send a string that looks like a lat,long to a Location item.
- Send ON, OFF, OPEN, CLOSED, etc. to a String item.
- Any other accepted combination that would otherwise fail with the current binding.
Prior to this pull request, there is a hardcoded list of types in the MQTT binding (ON/OFF, OPEN/CLOSED, UP/DOWN, something that can be parsed as a hue/saturation/brightness, a percentage, a decimal number, a date and then, lastly, a string), and which one is chosen is based on the first one that parses correctly. This can lead to problems, as described in this thread earlier.
Also, this pull request’s MQTT Message Bus binding will not put subscribed messages on the local openHAB message bus for items that do not exist in the local system. If you turn on DEBUG logging for the binding, you will see them being dropped, as they have nowhere to go.
I believe that this set of changes will not break any existing working configurations, but will allow more flexibility out of the MQTT bindings by dynamically accounting for items’ accepted types. I need you to try to prove me wrong!
@rlkoshak, @steve1, @tramlaan, @ben_jones12, and anyone else who could replace your current MQTT binding JAR with this one, I would appreciate it much. Testing should focus on 1) nothing breaks, and 2) the new flexibility works as advertised.