BLE connection handling update.#979
Conversation
5829b2f to
78c801a
Compare
|
@NorthernMan54 I've added the extra data conditions to this if you'd like to test them. I don't know what the extra data is but if you would like to provide that information I can incorporate it as well. |
|
I need to figure out my test environments and likely drop my fork of the main openMQTTGateway codebase and switch to yours. Will do that over the weekend, I just have a couple of small checkins to openMQTTGateway to get out of the way first. |
|
Rebasing to develpoment after the updates, seems to be an issue with discovery. Investigating now. |
5f7ca18 to
42782e6
Compare
|
Issues resolved, works well with LYWSD03MMC. Hopefully @NorthernMan54 can test with the DT24. |
|
@h2zero I cloned your ble-connect branch to my dev environment this am, then took the family to the beach. should be able complete testing tomorrow am |
|
No hurry, you'll need to rebase as I just pushed an update. Thanks! |
|
@h2zero That works really good, I didn't see any issues PS I added the temp from the second part of the message, but got stuck in git hell trying to create a pull request on your fork. Am thinking once this is merged into the main development branch I can add it then. Your second message handling worked perfectly. My WIP on DT24 Temperature |
Great!
😆 I know the pain. Agreed, it would be better to submit a PR for the update after this is merged. |
|
@NorthernMan54 does this device have any readable/writable characteristics? |
|
The device does have this interface, https://github.com/NiceLabs/atorch-console/blob/master/docs/protocol-design.md#command but in the grand scheme of things it is not very useful. I have been using it for a while, and never used these. |
|
Thanks, I thought if there was something useful there I could add the write functions. |
|
Did you look at #980 ? im thinking that the trigger is the ble data message and sensor data on the same topic. Should they be combined into a single message? I have the same with the DT24, but my client ignores the message of the field is missing. |
|
I briefly looked at that issue, I will keep it in mind with the changes I'm working on. |
|
@NorthernMan54 I just added a commit that I think will resolve #980, could you test it when you have a chance? |
|
@h2zero That's an interesting approach On startup/restart I see a signal strength/BLE message Then afterwards just these every ~3 minutes ( device status ) Which I believe is what you were expecting |
|
Thanks for testing it! Yes, that is the expected result as it addresses the issue referred to. It was a pretty simple solution to add with this PR, hopefully @fhb can confirm it resolves it. Not sure if this would cause issues for other uses though, @1technophile would need to judge that. |
|
I was thinking about what it would take to combine the data into a single message. Would it make sense to include the signal strength etc with the device status ? |
|
Looks like I missed adding the return call on line 127 in ZgatewayBLEConnect.ino. If you'd like to add that and try again I'd appreciate it. |
1 step forward and 2 back lol. No idea why it would fail after publishing there. I would need to decode that backtrace. |
|
Give me a couple of hours, just need to wait for the end of my day job |
For the 2 devices that require a connection, I don't think we need rssi. So we can go forward on with this change. If you could just add a macro to deactivate this filter (the filter is activated per default), this way if somebody needs to see the rrsi and what the connectable device is advertising (could be useful also for debugging) |
|
This is the backtrace |
|
@1technophile will do, thanks. @NorthernMan54 are you also operating a BLE server instance? That is what the backtrace is suggesting. |
|
@h2zero Nope |
|
That's really strange then. Seeing this |
|
I enabled 'CORE_DEBUG_LEVEL=4' and rerunning...Hopefully it gives a better clue |
|
With CORE_DEBUG_LEVEL=4 |
|
This is a successful BLE Connect |
|
Exception from BLE Connect begin |
|
Thanks @NorthernMan54, that's very helpful. Looks like a timing issue, I'll look into it now. |
|
@NorthernMan54 I just pushed a commit to the branch here https://github.com/h2zero/OpenMQTTGateway/tree/bugfix/ble-connect. Sorry to bother you testing this but I do not have access to that device or I would test it myself. The issue seems to be that it sends notifications constantly regardless of subscribing, so if this doesn't work we might simply be able to remove the subscribe call completely and just wait for the data. |
|
I started it about 15 minutes ago, and no exceptions yet. Going to leave it overnight and see what happens. PS I thought this should be before the subscribe, to ensure it was initialed prior to the subscribe as I had seen cases where the response was received prior to the taskhandle being initialized. |
Awesome, thanks!
I re balanced that in the notification handler, this way it should avoid the timing issue, at least that's what I'm hoping for. |
|
That fix nailed it |
|
Thanks! I'll merge those changes into this PR. |
Uses 1technophile#979 This allows reading and writing BLE characteristics from an MQTT message. Example format: mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoBT/config -m '{"ble_write_address":"AA:BB:CC:DD:EE:FF", "ble_write_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b", "ble_write_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b", "ble_write_value":"TEST", "ttl":4 }' mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoBT/config -m '{"ble_read_address":"30:AE:A4:7C:3C:A6", "ble_read_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b", "ble_read_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b", "ttl": 2 }' The ttl parameter is the number of calls to connect (defaults to 1), which occur after the BLE scan completes. A response is provided over MQTT in the format: write : {"id":"30:AE:A4:7C:3C:A6","service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b","characteristic":"cba20002-224d-11e6-9fb8-0002a5d5c51b","write":"TEST","success":true} read : {"id":"30:AE:A4:7C:3C:A6","service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b","characteristic":"cba20002-224d-11e6-9fb8-0002a5d5c51b","read":"TEST","success":true}
|
Thanks for the PR! |
Uses 1technophile#979 This allows reading and writing BLE characteristics from an MQTT message. Example format: mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoBT/config -m '{"ble_write_address":"AA:BB:CC:DD:EE:FF", "ble_write_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b", "ble_write_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b", "ble_write_value":"TEST", "ttl":4 }' mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoBT/config -m '{"ble_read_address":"30:AE:A4:7C:3C:A6", "ble_read_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b", "ble_read_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b", "ttl": 2 }' The ttl parameter is the number of calls to connect (defaults to 1), which occur after the BLE scan completes. A response is provided over MQTT in the format: write : {"id":"30:AE:A4:7C:3C:A6","service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b","characteristic":"cba20002-224d-11e6-9fb8-0002a5d5c51b","write":"TEST","success":true} read : {"id":"30:AE:A4:7C:3C:A6","service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b","characteristic":"cba20002-224d-11e6-9fb8-0002a5d5c51b","read":"TEST","success":true}
* EXPERIMENTAL: Ble read/write characteristics over MQTT. Uses #979 This allows reading and writing BLE characteristics from an MQTT message. Example format: mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoBT/config -m '{"ble_write_address":"AA:BB:CC:DD:EE:FF", "ble_write_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b", "ble_write_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b", "ble_write_value":"TEST", "ttl":4 }' mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoBT/config -m '{"ble_read_address":"30:AE:A4:7C:3C:A6", "ble_read_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b", "ble_read_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b", "ttl": 2 }' The ttl parameter is the number of calls to connect (defaults to 1), which occur after the BLE scan completes. A response is provided over MQTT in the format: write : {"id":"30:AE:A4:7C:3C:A6","service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b","characteristic":"cba20002-224d-11e6-9fb8-0002a5d5c51b","write":"TEST","success":true} read : {"id":"30:AE:A4:7C:3C:A6","service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b","characteristic":"cba20002-224d-11e6-9fb8-0002a5d5c51b","read":"TEST","success":true} * Add generic BLE connect class and read data as hex. * Add value_type parameter and document usage * Add note to docs
* EXPERIMENTAL: Ble read/write characteristics over MQTT. Uses 1technophile#979 This allows reading and writing BLE characteristics from an MQTT message. Example format: mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoBT/config -m '{"ble_write_address":"AA:BB:CC:DD:EE:FF", "ble_write_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b", "ble_write_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b", "ble_write_value":"TEST", "ttl":4 }' mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoBT/config -m '{"ble_read_address":"30:AE:A4:7C:3C:A6", "ble_read_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b", "ble_read_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b", "ttl": 2 }' The ttl parameter is the number of calls to connect (defaults to 1), which occur after the BLE scan completes. A response is provided over MQTT in the format: write : {"id":"30:AE:A4:7C:3C:A6","service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b","characteristic":"cba20002-224d-11e6-9fb8-0002a5d5c51b","write":"TEST","success":true} read : {"id":"30:AE:A4:7C:3C:A6","service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b","characteristic":"cba20002-224d-11e6-9fb8-0002a5d5c51b","read":"TEST","success":true} * Add generic BLE connect class and read data as hex. * Add value_type parameter and document usage * Add note to docs
Create a class for each connectable device to handle the specific parameters separately in an extendable form.