[New Binding] AM43 Blind Drive Motor Binding

Add-ons Bindings
1

Hi all,

I managed to reverse engineer the bluetooth protocol that BlindsEngine app uses to control the AM43 Blinds Drive Motor. I created a binding built on top of the openhab official bluetooth binding that allows for control of most of the motor’s information.
Things you can control/access:

  • Up/down/stop motor controls
  • device configuration data
  • light sensor data
  • motor battery level

These motors can go under many names, the one I’m personally testing against is the A-OK blinds motor that I got on amazon, but much cheaper versions can be found on aliexpress.

I’m not sure what the best way to setup the repository for snapshots so for now I’m just shoving them in another branch and uploading them manually for people to try out.

https://github.com/cpmeister/openhab-addons/blob/blind-engine-snapshots/org.openhab.binding.bluetooth.am43-2.5.2-SNAPSHOT.jar

Also through the course of debugging, I’ve also made some stability improvements to openhab’s official bluetooth plugins. These snapshots are completely optional and are not necessary for the am43 binding to work. I’m still waiting on the PR to go through with them but until they go through My changes are already in the latest official snapshot build, but for those that don’t want to build them yourselves, you can get them here:

https://github.com/cpmeister/openhab-addons/blob/blind-engine-snapshots/org.openhab.binding.bluetooth-2.5.2-SNAPSHOT.jar

https://github.com/cpmeister/openhab-addons/blob/blind-engine-snapshots/org.openhab.binding.bluetooth.bluez-2.5.2-SNAPSHOT.jar

https://github.com/cpmeister/openhab-addons/blob/blind-engine-snapshots/org.openhab.binding.bluetooth.bluegiga-2.5.2-SNAPSHOT.jar

Here is the repository for those that want to look at the source:

Details of use:

  • Requires the official bluetooth binding, I didn’t go with the unofficial one since it seems that it is broken and not getting supported anymore.
  • It should be discovered automatically but if not you can create the Thing manually with the bluetooth address.
  • There are a lot of channels to use but the primary one is the bluetooth:am43:xxxx:position channel. That one has most of the Rollershutter functionality working and tested, but I still need to test for percentage support PercentType is fully supported.
  • Light sensor values will range from 0 - 10, Could be useful for having blinds activate automatically in harsh sun.

Edit 1:
I finished writing the readme, you can find it in the repository link above. Cheers!

1 Like
2

Tested and working excelent, thank you!
Percentage support functioning very well; 0% is fully open and 100% means closed.
This post helped me to get it clean in my sitemap: OpenHab App Rollershutter control

3

Only RSSI and PercentPosition do work for me, different SW version maybe?

openhab> log:set TRACE org.openhab.binding.bluetooth.blindsengine - does not output a thing
How do I get DEBUG reports on OH 2.5.1 with log4j2 (code refers to slf4j)?

4

@ggaljoen
I’ve found that debugging on the entire bluetooth package and subpackages to be a bit more insightful:
openhab> log:set DEBUG org.openhab.binding.bluetooth
I’ve been having some trouble with the bluez binding dropping notification events that are required to update the device data in the binding. I still don’t know if there is something wrong with my bluez installation or what else but I know it isn’t an issue with the AM43 binding itself. I’m currently trying to get BlueGiga working since I’ve heard that it is more reliable. :crossed_fingers: Are you using bluez or bluegiga?

When you watch the debug logging you should see Write events and Receive events if it is working properly. Can you post some of your logs?

I would also suggest using the latest version of the AM43 binding that I just linked in my initial post. I fixed a bunch of exceptions that I was seeing and it should be much more reliable overall. I changed the package and name of the binding to a more appropriate permanent one so you will need to uninstall the old one to use the new one otherwise they will both pick up the same devices during discovery. You would probably need to delete the old thing and create a new one.

5

The forever read-only channels are:

  • rssi
  • electric
  • lightLevel

All the other channels can theoretically be written to if I eventually see a purpose in implementing write support for them. But the only writeable channels right now are:

  • direction
  • operationMode
  • position

The following are currently writable but I might make this read-only since I don’t see a purpose of setting this using openhab vs setting this using the actually device:

  • topLimitSet
  • bottomLimitSet

If there is a really good reason to keep the above writeable let me know, I’m just not sure how people want to use it.

6

@cpmeister my RPI3 openHAB 2.5.1-2 is connecting with bluez and your updated modules:

295 │ Resolved │ 80 │ 2.5.1 │ org.openhab.binding.bluetooth
296 │ Active │ 80 │ 2.5.1 │ org.openhab.binding.bluetooth.bluegiga
297 │ Resolved │ 80 │ 2.5.1 │ org.openhab.binding.bluetooth.bluez
298 │ Active │ 80 │ 2.5.1 │ org.openhab.binding.bluetooth.blukii
299 │ Active │ 80 │ 2.5.1 │ org.openhab.binding.bluetooth.ruuvitag
301 │ Active │ 80 │ 2.5.2.202001202111 │ org.openhab.binding.bluetooth.bluez
302 │ Active │ 80 │ 2.5.2.202001202111 │ org.openhab.binding.bluetooth
303 │ Active │ 80 │ 2.5.2.202001210446 │ org.openhab.binding.bluetooth.am43

2020-01-21 19:38:25.933 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value ‘[-102, -94, 5, 0, 0, 0, 0, 100, 89]’ for characteristic ‘0000fe51-0000-1000-8000-00805f9b34fb’ of device ‘02:xx:-)’

2020-01-21 19:38:25.939 [DEBUG] [.bluetooth.am43.internal.AM43Handler] - updating battery lebel to: 100

2020-01-21 19:38:30.905 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value ‘[-102, -86, 2, 0, 1, 51]’ for characteristic ‘0000fe51-0000-1000-8000-00805f9b34fb’ of device ‘02:xx:-)’

2020-01-21 19:38:30.911 [DEBUG] [.bluetooth.am43.internal.AM43Handler] - updating lightLevel to: 1
and a typo - updating battery lebel to: 100

On startup everything gets updated, just one update of all channels is received, poll interval change always result in:

2020-01-21 20:13:19.324 [DEBUG] [.bluetooth.am43.internal.AM43Handler] - failed to enable notifications for characteristic: 0000fe51-0000-1000-8000-00805f9b34fb

Is there a way to force it to receive an update?

BTW great reverse app engineering you did!

7

Thanks for pointing out the typo, just fixed it. :slight_smile:

As far as forcing an update, for whatever reason, it looks like the AM43 doesn’t allow properties or sensors to be read through a bluetooth read operation. Instead requests have to be sent to the device and then it responds with a notification containing the requested data. So there is no way to receive data without enabling bluetooth notifications.

But I wouldn’t worry too much since the binding will make continued attempts to enable notifications until it succeeds. I would only start to worry if it never succeeds…

But assuming that notifications are active, the binding does handle refresh commands and will issue a request to the device for up-to-date data.

8

I just updated the snapshot to include a few new configurations that should be helpful:

  1. polling interval
    By configuring the polling interval you can adjust the update frequency of the battery and light sensor channels. Making it longer might reduce the battery drain rate (I haven’t tested whether this is true).
  2. inverse percentage support
    This inverts the position percentage so that 0 -> 100 and 100 -> 0. I’ve used this to make it behave as expected to alexa commands.
9

@cpmeister no updates after first serie received

Configuration - Things - AM43 Blind Drive Motor
Changes on Polling Interval result in:

2020-01-23 17:24:24.959 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Disconnecting '02:xx:-)’
2020-01-23 17:24:24.998 [me.event.ThingUpdatedEvent] - Thing ‘bluetooth:am43:5869f9b1’ has been updated.
2020-01-23 17:24:27.268 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received services resolved event for '02:xx:-)’: false
2020-01-23 17:24:27.272 [hingStatusInfoChangedEvent] - ‘bluetooth:am43:5869f9b1’ changed from ONLINE to UNKNOWN
2020-01-23 17:24:27.292 [hingStatusInfoChangedEvent] - ‘bluetooth:am43:5869f9b1’ changed from UNKNOWN to ONLINE
2020-01-23 17:24:27.293 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Connection state of '02:xx:-)’ changed to DISCONNECTED
2020-01-23 17:24:27.316 [hingStatusInfoChangedEvent] - ‘bluetooth:am43:5869f9b1’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)
2020-01-23 17:24:27.388 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Exception occurred when trying to read characteristic ‘0000fe51-0000-1000-8000-00805f9b34fb’: GDBus.Error:org.bluez.Error.Failed: Not connected
2020-01-23 17:24:27.401 [hingStatusInfoChangedEvent] - ‘bluetooth:am43:5869f9b1’ changed from OFFLINE (COMMUNICATION_ERROR) to OFFLINE (COMMUNICATION_ERROR): Failed to set characteristic 0000fe51-0000-1000-8000-00805f9b34fb to value 00FF00009AA701013D
2020-01-23 17:25:22.305 [hingStatusInfoChangedEvent] - ‘bluetooth:am43:5869f9b1’ changed from OFFLINE (COMMUNICATION_ERROR): Failed to set characteristic 0000fe51-0000-1000-8000-00805f9b34fb to value 00FF00009AA701013D to OFFLINE (COMMUNICATION_ERROR)
2020-01-23 17:25:22.314 [hingStatusInfoChangedEvent] - ‘bluetooth:am43:5869f9b1’ changed from OFFLINE (COMMUNICATION_ERROR) to OFFLINE: Device is not connected.
2020-01-23 17:26:17.331 [hingStatusInfoChangedEvent] - ‘bluetooth:am43:5869f9b1’ changed from OFFLINE: Device is not connected. to OFFLINE (COMMUNICATION_ERROR)
2020-01-23 17:26:17.341 [hingStatusInfoChangedEvent] - ‘bluetooth:am43:5869f9b1’ changed from OFFLINE (COMMUNICATION_ERROR) to OFFLINE: Device is not connected.

And does not resume, only after a restart.
If I understand it well, it should report (with polling) the values; if the position is changed on the device buttons, this should be changed in the channel?
Strange side remark, only the general bluetooth device is discoverd (over and over), needed to assign it manual to the AM43 thing.
Busy neighborhood, since 2 days it has found 300 devices (and counting)…

10

I’ve been trying to deal with similar issues as well. From your logs it appears that you get disconnected from the device and when attempting to reconnect the bluetooth binding wasn’t able to discover the gatt services again.

This tells me two things:

  1. That although you showed that you installed my bluetooth binding, it is still using the old one. I think I found that I have to uninstall bluetooth binding in paperUI for it to finally use my snapshot binding. My snapshot bluez binding fixes the 300+ discovery issue that you can see, it isn’t actually 300+ devices but can be a single mobile device that is broadcasting a changing mac address.
  2. That an attempt to write to the characteristic occurred when the device was disconnect. This is a bug in my binding so I’ll try to fix that.

Once bluez gets into a funk the only way I know how to fix it is to restart. The binding is currently designed to retrieve the basic immutable motor settings only once at startup. The device doesn’t send notifications on movement (although from the reverse engineered code it looks like it should). But I didn’t think to have a polling request to handle position updates since it never occurred to me that manual updates would happen after it is integrated into openhab (why do things manually you have automation :slight_smile:). I’ll see what I can do about implementing periodic update requests for the position.

The binding is currently looking for a device with the name “A-OK”. What name is your device broadcasting, if any? I’ve been getting some inconsistency with regards to bluez giving me names.

One of my primary issues that I’ve been dealing with is the AM43’s short bluetooth range. While I can discover the device down to a RSSI -96 the AM43 seems to automatically disconnect when the RSSI drops below -80. My raspberry pi is only 5 meters away with clear line of sight and I still get disconnects! I suspect that my issue might be with my use of the pi’s built in bluetooth so I’ve gotten a bluetooth dongle with antenna that I’ll test with in hopes that it will boost signal.

Of course that doesn’t even mention the other errors on my system I’m trying to figure out:

2020-01-23 08:12:14.675 [WARN ] [bluetooth.bluez.BlueZBluetoothDevice] - Characteristic '0000fe51-0000-1000-8000-00805f9b34fb' is missing on device '02:16:E9:71:63:8A'.

2020-01-23 08:12:19.455 [WARN ] [bluetooth.bluez.BlueZBluetoothDevice] - Characteristic '0000fe51-0000-1000-8000-00805f9b34fb' is missing on device '02:16:E9:71:63:8A'.

==> /var/log/openhab2/events.log <==

2020-01-23 08:12:21.060 [hingStatusInfoChangedEvent] - 'bluetooth:am43:ff6afc54:025469815904' changed from ONLINE to UNINITIALIZED

2020-01-23 08:12:21.115 [hingStatusInfoChangedEvent] - 'bluetooth:am43:ff6afc54:025469815904' changed from UNINITIALIZED to UNINITIALIZED (DISABLED)

2020-01-23 08:12:22.426 [hingStatusInfoChangedEvent] - 'bluetooth:am43:ff6afc54:0216e971638a' changed from ONLINE to UNINITIALIZED

2020-01-23 08:12:22.484 [hingStatusInfoChangedEvent] - 'bluetooth:am43:ff6afc54:0216e971638a' changed from UNINITIALIZED to UNINITIALIZED (DISABLED)

2020-01-23 08:12:24.896 [hingStatusInfoChangedEvent] - 'bluetooth:am43:ff6afc54:0216e971638a' changed from UNINITIALIZED (DISABLED) to INITIALIZING

2020-01-23 08:12:24.956 [hingStatusInfoChangedEvent] - 'bluetooth:am43:ff6afc54:0216e971638a' changed from INITIALIZING to UNKNOWN

2020-01-23 08:12:24.963 [hingStatusInfoChangedEvent] - 'bluetooth:am43:ff6afc54:0216e971638a' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): Signal lost

2020-01-23 08:12:24.967 [vent.ItemStateChangedEvent] - AM43BlindDriveMotor1_RSSI changed from -79 to NULL

2020-01-23 08:12:26.199 [hingStatusInfoChangedEvent] - 'bluetooth:am43:ff6afc54:025469815904' changed from UNINITIALIZED (DISABLED) to INITIALIZING

2020-01-23 08:12:26.242 [hingStatusInfoChangedEvent] - 'bluetooth:am43:ff6afc54:025469815904' changed from INITIALIZING to UNKNOWN

2020-01-23 08:12:26.250 [hingStatusInfoChangedEvent] - 'bluetooth:am43:ff6afc54:025469815904' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): Signal lost

2020-01-23 08:12:26.255 [vent.ItemStateChangedEvent] - AM43BlindDriveMotor2_RSSI changed from -72 to NULL

The strange thing is that I never have these problems when using bluetoothctl directly, but when using the java bluetooth library I get missing notifications (they show up in bluetoothctl!) and other instabilities.

11

I think I figured out why:

2020-01-23 11:34:42.937 [DEBUG] [oth.bluez.handler.BlueZBridgeHandler] - Refreshing Bluetooth device list...

2020-01-23 11:34:42.942 [DEBUG] [oth.bluez.handler.BlueZBridgeHandler] - Found 0 Bluetooth devices.

Looks like my bluetooth died somehow…time to restart!

12

Good news, I managed to get light sensor readings up to 8 out of 10. So looks like the light sensor is working as expected :slight_smile:

Now if only I can solve the notification issue…

13

Managed to get it working, removed BT binding and addons.
Started with your snapshots only, no succes, no BT functions.
Re-installed the basic BT binding and now it seems to run fine (both 2.5.1 & 2.5.2 have state Active), no overload on discovered devices.

No doubt it will get solved!

My goal for automation is to add functionality, keep the basic going and interact between housemates classic and openhab automation.

My device info:
[DEBUG] [y.internal.BluetoothDiscoveryService] - Discovered bluetooth device ‘Blind’: BluetoothDevice [address=02:xx:-), name=Blind, rssi=-71, manufacturer=null]

Hope you get better RF connection with an external module/antenna.

As you said: GOOD news :slight_smile:

Could not resist and took mine apart (unscrewed the cover); the sensor/panel on of the 2.5mm jack: tip “+” and body/ring 3 “-” of solar panel, sensor (LDR ?) color “white” ring 1 and “green” ring 2

14

So did your AM43 always broadcast itself as Blind or did you change it using the BlindsEngine app?
I don’t have any generic AM43 models so I wouldn’t be surprised that they broadcast a different name. My code is looking for A-OK which is what my AM43 broadcasts so I’ll need to change my code to accept this other name too. Although ultimately the way this device should be discovered isn’t by its name but by the bluetooth services that it has. But unfortunately Openhab’s bluetooth framework doesn’t have the ability to do such a nuanced discovery method (yet). But for now just getting a list of possible names should suffice since there aren’t any other Openhab bluetooth bindings that such an approach would conflict with.

So far I’ve tried the bluegiga dongle (not enough range and unstable support in openhab) and an old bluetooth antenna dongle which isn’t supported on the newest raspberry pi. So my search continues.

Are you experiencing any notification issues on your system? In the logs you should always see a characteristic write followed by a characteristic receive but on my system I only get receives for about a minute after connecting and then it stops (the writes go through fine but I never get any more notifications). If I monitor the device in bluetoothctl I can see that the device is responding with notifications to those writes but for whatever reason the notification doesn’t reach the bluetooth binding. If you are seeing something similar then I know it isn’t something specific to my setup which would narrow down my list of probable causes.

Hah, I didn’t take mine apart, but I did use my multimeter on and I think you are correct. The top and bottom bands of the jack are the solar panel and the middle two are the sensor. I didn’t get any voltage from the sensor but I got a nice resistance reading on it so I suspect that it is an LDR.

15

Not needed to change your discovery code, at the startup configuration manually changed ‘device name setting’ to “Blind”. Can be triggered on a predefined name “A-OK”. Picked up the device when renamed. And what about the ‘password’? I changed it as well but the binding does not need it, IoT security, right? :wink:

Unfortunaly the same receiving behaviour here.
Just noticed this in my log:

[DEBUG] [bluetooth.bluez.BlueZBluetoothDevice]
Enabling notifications for device ‘02:xx:-)’
[INFO ] [g.discovery.internal.PersistentInbox]
Added new thing ‘bluetooth:am43:hci0:02xx:-)’ to inbox.

All messages have pre-fix: [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice]
Connection state of '02:xx:-)’ changed to CONNECTED
Received services resolved event for ‘02:xx:-)’: true
Received new value ‘[-102, -88, 0, 50]’ for characteristic ‘0000fe51-0000-1000-8000-00805f9b34fb’ of device '02:xx:-)’

Polling (interval) is for device or thing level? Maybe I do not understand what I am talking about :innocent:

16

Well without getting into the specifics kinda both, but the polling interval is strictly a configuration for the binding. At every polling interval the binding will send a request (seen in the logs as a write to a characteristic) to the device for information (battery level, current light sensor reading, position, etc…) at which point the binding will wait for a response from the device (seen in the logs as a Received new value ... for characteristic) containing the requested information. But sometimes (at least on my system) a request will go out but I never receive a response. Basically what I see in the logs is a batch of Wrote [...] to characteristic in the logs without any Received new value ... for characteristic in between. Every write should have one or many responses shown in the logs.

17

Good you pointed it out this way; nowhere writes ‘to charactersitic’ visible in my logs… thus no responses?
Must start to talk once on (re-)establishing the connection? This is all found on restart:

2020-01-26 10:53:47.144 [hingStatusInfoChangedEvent] - 'bluetooth:am43:hci0:02xx:-)’ changed from OFFLINE: Device is not connected. to ONLINE
2020-01-26 10:53:48.228 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received services resolved event for '02:xx:-)’: true
2020-01-26 10:53:48.586 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -89, 7, 30, 50, 0, 0, 0, 0, 0, 22]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02:xx:-)’
2020-01-26 10:53:48.767 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -88, 0, 50]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02:xx:-)’
2020-01-26 10:53:48.770 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -87, 16, 0, 0, 0, 17, 0, 0, 0, 0, 1, 1, 17, 121, 7, 30, 17, 0, 82]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02:xx:-)’
2020-01-26 10:53:48.774 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -89, 7, 30, 50, 0, 0, 0, 0, 0, 22]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02:xx:-)’
2020-01-26 10:53:48.864 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -88, 0, 50]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02:xx:-)’
2020-01-26 10:53:48.867 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -87, 16, 0, 0, 0, 17, 0, 0, 0, 0, 1, 1, 17, 121, 7, 30, 17, 0, 82]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02:xx:-)’
2020-01-26 10:53:51.756 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -94, 5, 0, 0, 0, 0, 100, 89]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02:xx:-)’
2020-01-26 10:53:56.727 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -86, 2, 0, 2, 48]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02:xx:-)’

Changing Polling is now showing this in the log, no writing ‘to charactersitic’:

[DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Disconnecting '02:xx:-)’
[me.event.ThingUpdatedEvent] - Thing 'bluetooth:am43:hci0:02xx:-)’ has been updated.
[DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received services resolved event for '02:xx:-)’: false
[DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Connection state of '02:xx:-)’ changed to DISCONNECTED
[hingStatusInfoChangedEvent] - 'bluetooth:am43:hci0:02xx:-)’ changed from ONLINE to UNKNOWN
[hingStatusInfoChangedEvent] - 'bluetooth:am43:hci0:02xx:-)’ changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR)
[hingStatusInfoChangedEvent] - 'bluetooth:am43:hci0:02xx:-)’ changed from OFFLINE (COMMUNICATION_ERROR) to OFFLINE: Device is not connected.
[vent.ItemStateChangedEvent] - AM43BlindDriveMotor_RSSI changed from -71 to -72
[DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Connection state of '02:xx:-)’ changed to CONNECTED
[hingStatusInfoChangedEvent] - 'bluetooth:am43:hci0:02xx:-)’ changed from OFFLINE: Device is not connected. to ONLINE
[DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received services resolved event for '02:xx:-)’: true

Hope this can help your development, other things that I can do/test?

18

You shouldn’t get responses without seeing corresponding writes. So I suspect that that the writes are still occurring. Can you double check your logging levels
make sure that org.openhab.binding.bluetooth is at DEBUG and org.openhab.binding.bluetooth.bluez is set to DEFAULT?

I think the polling change is working as intended. When you change the settings of a Thing it basically destroys the handler for the Thing then creates another handler with the new polling interval. In the process, the old handler disconnects from the device then the new handler reconnects with it.

Please let me know if you have any long term stability issues with the binding, like if you stop getting sensor updates after a while or can’t control the blinds. You have been a great help, Thanks!

19

It works fine for a few hours, connection cashes between 6h and 12h active (after reset RPI):

2020-01-28 18:23:34.415 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received services resolved event for '02xx:-)’: false
2020-01-28 18:23:34.418 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Connection state of 02xx:-)’ changed to DISCONNECTED
2020-01-28 18:23:34.428 [hingStatusInfoChangedEvent] - 'bluetooth:am43:adapter1:motor1' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)
2020-01-28 18:24:25.897 [hingStatusInfoChangedEvent] - 'bluetooth:am43:adapter1:motor1' changed from OFFLINE (COMMUNICATION_ERROR) to OFFLINE: Device is not connected.
2020-01-28 18:25:20.928 [hingStatusInfoChangedEvent] - 'bluetooth:am43:adapter1:motor1' changed from OFFLINE: Device is not connected. to OFFLINE (COMMUNICATION_ERROR)

Only received messages/updates after a restart:

2020-01-28 19:04:53.777 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Connection state of '02xx:-)’ changed to CONNECTED
2020-01-28 19:04:53.788 [hingStatusInfoChangedEvent] - 'bluetooth:am43:adapter1:motor1' changed from UNKNOWN to ONLINE
2020-01-28 19:04:54.014 [hingStatusInfoChangedEvent] - 'bluetooth:am43:adapter1:motor1' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)
2020-01-28 19:04:54.621 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received services resolved event for '02xx:-)’: true
2020-01-28 19:04:54.960 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -89, 7, 14, 50, 100, 0, 0, 0, 0, 98]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02xx:-)’
2020-01-28 19:04:55.110 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -88, 0, 50]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02xx:-)’
2020-01-28 19:04:55.112 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -87, 16, 0, 0, 0, 17, 0, 0, 0, 0, 1, 0, 17, 121, 7, 30, 17, 0, 83]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02xx:-)’
2020-01-28 19:04:55.115 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -89, 7, 14, 50, 100, 0, 0, 0, 0, 98]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02xx:-)’
2020-01-28 19:04:55.174 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -88, 0, 50]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02xx:-)’
2020-01-28 19:04:55.177 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -87, 16, 0, 0, 0, 17, 0, 0, 0, 0, 1, 0, 17, 121, 7, 30, 17, 0, 83]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02xx:-)’
2020-01-28 19:04:58.422 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -94, 5, 0, 0, 0, 0, 100, 89]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02xx:-)’
2020-01-28 19:05:03.394 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -86, 2, 0, 0, 50]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02xx:-)’
2020-01-28 19:05:58.483 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -94, 5, 0, 0, 0, 0, 100, 89]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02xx:-)’
2020-01-28 19:06:03.455 [DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received new value '[-102, -86, 2, 0, 0, 50]' for characteristic '0000fe51-0000-1000-8000-00805f9b34fb' of device '02xx:-)’

No changes of light sensor (or anything else) throughout the day (max value read after restart was a 7).

Never thought to be able to operate this in this connected manner!

20

Not sure if it can help for the debugging, each connection lost is starting with

[DEBUG] [bluetooth.bluez.BlueZBluetoothDevice] - Received services resolved event for '02:xx:-)': false