Checked it both binding are able to open the ports. Seems that the is a Problem in paper ui?
I am having the same issue with z-wave binding, Bluetooth Binding binding-bluetooth - 2.5.0.M1, and Bluetooth Binding TinyB Transport market:binding-3769218 - 1.0.
If I have the z-wave binding by itself with no bluetooth it works. If I have both bluetooth bindings installed with no z-wave they work. The second I install both bindings and reboot, everything goes crazy and neither of them seem to work correctly. I assume they are both trying to use the /dev/ttyACM0 port. Thatâs what I have configured for z-wave but bluetooth doesnât seem to let you configure a port. It seems when the machine comes up, it does iterate through what is connected and assigns ports randomly.
This is a known problem it is possible. Just see the diskussion about 3rd party bluetooth binding
Any resolution to this problem?
I am using a âworkaroundâ with a second OH installation only for the Bluetooth marketbinding. The item updates are triggered to my main OH instance via MQTT. Like this it works stable but of course this can not be considered a final solution.
This is an interesting solution, would you mind sharing how Item updates are triggered to your main OH instance via MQTT. If this is easy then I can think about it.
On the second OH instance for the marketplace binding I have grouped my bluetooth items that should be triggered in a group called âthirdbluâ. Here a section from items file for a Xiaomi Mijia Bluetooth Temperature Smart Humidity Sensor:
Switch ON_MJHTV1_1440 "ON_MJHTV1_1440 " <switch> (thirdblu) {channel="bluetooth:ble:4C65A8DD1440:online"}
String LO_MJHTV1_1440 "LO_MJHTV1_1440 " (thirdblu) {channel="bluetooth:ble:4C65A8DD1440:location"}
DateTime LU_MJHTV1_1440 "LU_MJHTV1_1440 [%1$ta %1$td.%1$tm.%1$ty %1$tT.%1$tL]" (thirdblu) {channel="bluetooth:ble:4C65A8DD1440:last-updated"}
Number RS_MJHTV1_1440 "RS_MJHTV1_1440 " (thirdblu) {channel="bluetooth:ble:4C65A8DD1440:rssi"}
Number HU_MJHTV1_1440 "Luftf. 1440" <humidity> (thirdblu) {channel="bluetooth:ble:4C65A8DD1440:FE95-FE95-humidity"}
Number TE_MJHTV1_1440 "Temp. 1440 " <temperature> (thirdblu) {channel="bluetooth:ble:4C65A8DD1440:FE95-FE95-temperature"}
Number BA_MJHTV1_1440 "BA_MJHTV1_1440 " (thirdblu) {channel="bluetooth:ble:4C65A8DD1440:FE95-FE95-battery"}
Then I have a rule that gets triggered on the group based trigger âMember ofâŠreceived updateâ. The rule executes the MQTT Action to publish the update to my Mosquitto broker by using triggeringItem.name and triggeringItem.state . So it is basically only this one rule for all the items. Here the rules file:
rule "MemberUpdatethirdblu"
when
Member of thirdblu received update
then
val mqttActions = getActions("mqtt","mqtt:broker:MOSQ_AB")
mqttActions.publishMQTT("OHAB/"+triggeringItem.name, triggeringItem.state.toString)
end
So far the setup on the OH instance for the marketplace binding.
On the main OH instance I have a things file for the MQTT items where I subscribe to the published channels:
Bridge mqtt:broker:MOSQ_AB "Mosquitto AB" @ "AB_ABUE" [ host="192.168.178.59", secure=false ]
{
Thing topic OHAB "OHAB" @ "OHAB" {
Channels:
Type switch : ON_MJHTV1_1440 "ON_MJHTV1_1440 " [ stateTopic="OHAB/ON_MJHTV1_1440" ]
Type string : LO_MJHTV1_1440 "LO_MJHTV1_1440 " [ stateTopic="OHAB/LO_MJHTV1_1440" ]
Type datetime : LU_MJHTV1_1440 "LU_MJHTV1_1440 " [ stateTopic="OHAB/LU_MJHTV1_1440" ]
Type number : RS_MJHTV1_1440 "RS_MJHTV1_1440 " [ stateTopic="OHAB/RS_MJHTV1_1440" ]
Type number : HU_MJHTV1_1440 "HU_MJHTV1_1440 " [ stateTopic="OHAB/HU_MJHTV1_1440" ]
Type number : TE_MJHTV1_1440 "TE_MJHTV1_1440 " [ stateTopic="OHAB/TE_MJHTV1_1440" ]
Type number : BA_MJHTV1_1440 "RS_MJHTV1_1440 " [ stateTopic="OHAB/BA_MJHTV1_1440" ]
}
}
Then I have my items linked to these subscribed MQTT channels:
Switch ON_MJHTV1_1440 "ON_MJHTV1_1440 " <switch> (thirdblu) {channel="mqtt:topic:MOSQ_AB:OHAB:ON_MJHTV1_1440"}
DateTime ON_MJHTV1_1440_LCH "ON_MJHTV1_1440_LCH [%1$ta %1$td.%1$tm.%1$ty %1$tT.%1$tL]" <clock>
String LO_MJHTV1_1440 "LO_MJHTV1_1440 [%s]" {channel="mqtt:topic:MOSQ_AB:OHAB:LO_MJHTV1_1440"}
DateTime LU_MJHTV1_1440 "LU_MJHTV1_1440 [%1$ta %1$td.%1$tm.%1$ty %1$tT.%1$tL]" {channel="mqtt:topic:MOSQ_AB:OHAB:LU_MJHTV1_1440"}
Number RS_MJHTV1_1440 "RS_MJHTV1_1440 [%s]" {channel="mqtt:topic:MOSQ_AB:OHAB:RS_MJHTV1_1440"}
Number HU_MJHTV1_1440 "Luftf. 1440 [%s]" <humidity> (HUMIOUT_CHART) {channel="mqtt:topic:MOSQ_AB:OHAB:HU_MJHTV1_1440"}
Number TE_MJHTV1_1440 "Temp. 1440 [%.1f %unit%]" <temperature> (Weather_Chart) {channel="mqtt:topic:MOSQ_AB:OHAB:TE_MJHTV1_1440"}
Number BA_MJHTV1_1440 "BA_MJHTV1_1440 [%s]" {channel="mqtt:topic:MOSQ_AB:OHAB:BA_MJHTV1_1440"}
Like this all item names are identical in both OH instances. This will allow me to put it back all on one instance later if the binding is more stable or compatible with other bindings.
I also named the MQTT channels in the things file exactly like the item names so it is easier to maintain for me.
All configuration is based on configuration files, so it can also be easily moved to a new installation.
Hope that helps.
Thanks a lot but looks like this is too much for me but now I am at a point where I need to decide if I have to give up the presence or go with smartthings for my Z Wave devices. I am not sure if this is going to get fixed anytime soon.
As far as I can tell the stability problems unfortunately semm to be caused by the marketplace bluetooth binding which in newer snapshots is somehow heavily conflicting with other devices on serial port connections (e.g. Z-Wave sticks). It would be nice to know if the binding developer could help. @vkolotov : Are you ware of these problems?