Is there any support in OpenMQTTGateway for writing a value to a BLE characteristic on the remote device? It’s not functionality I’m seeing in the documentation, and an old post suggests that there isn’t any.
I do realize that @shmuelzon has created BLE2MQTT which has BLE write functionality, but I’m hoping to have a multi-purpose gateway with LoRa support. One device instead of two – that sort of thing. 
Thanks!
I’m thinking about having a connect component that handles read and write, what would the API looks like in your point of view?
That’s an interesting question. There seems to be two issues here: the choice of what is writable and the problem of security.
The choice of which MQTT topics are writable could be as simple as OpenMQTTGateway examining the GATT access permissions for the BLE device.
Authorization and encryption permissions then lead the need for security. Having writable characteristics, which potentially cause some action to be taken by the device, would require pairing between OpenMQTTGateway and the BLE device. This seems to suggest an addition to the web interface to allow a Bluetooth PIN to be entered.
What could be the device you would like to write a characteristic on ?
Tasmota has simple connect/write/disconnect functionality for BLE on ESP32.
BLE on ESP32 is still not terribly stable - if connecting to devices regularly, expect uptimes of not more than a few days.
s
I suppose one would write to any device that performs a function, but is battery powered and requiring the low power connectivity that BLE provides. A simple example might be a battery powered window shade mechanism that will be receiving commands from the home controller.
Thanks for that info, @btsimonh . Can that issue be worked around by rebooting the device if BLE connections seem to be failing?
yes, the device first tries to restart the BLE stack, and if that fails, restarts itself from scratch.
It takes a fairly ‘belt and braces’ approach to restoring operation.
We don’t have anything on security apart for MI sensor key use.
Examples of use: I developed it so I could interface with EQ3 radiator valves (and wrote an additional TAS driver specifically for them). Latest use case was controlling a cat laser!.
Is this an issue with the ESP32 SDK in general, or is it an issue with OpenMQTTGateway or Tasmota?
I could see using an encryption key for general sensor data, but I’d hope there was some sort of basic pairing / security for the radiator valves. I can imagine this in an apartment building, with others in range of the valves, and some kid playing with a BLE app who thinks it would be funny to turn up the heat…
The cat laser use case could be a lot of fun! Add in a vision / AI system like the Nvidia Jetson and have it learn where to point the laser to get the most activity out of the cat, etc.
I disagree somewhat with this, it can be very stable depending on many factors, but mostly dependent on how it’s used and what else is going on. I have a device that connects to multiple peers every 30 - 300 seconds that has been running solid for nearly a year.
For the security part mentioned, if this is a custom server device you could use bonding and “just works” security, only allow one bonded peer and disconnect anything that connects after that is not bonded. Would be the simplest method IMO.
“I disagree somewhat with this”
yes - agreed - the devices we are talking to (EQ3 valves) could be the reason for regular failures; or indeed the other stuff going on in Tasmota (web & MQTT etc.)
Thanks for that info. I’m just starting into Bluetooth, and it wasn’t clear to me that the bonding would work in this way. I’m not overly paranoid in regards to security, so as long as the security is more than checking the MAC address it’ll work for me.
There are many ways to skin this cat as far as unauthorized access, security is important if something is being controlled. I’m interested in what sort of system you are considering?
In any case, it wouldn’t be much trouble to add writing / reading characteristics to OMG since it already has the connect and subscribe functionality. For security, bonding would be a simple matter of enabling it in the initialization.
I’m looking at small, battery powered devices that will perform an action of some kind, and so they need to be able to accept a command. A couple examples would be devices for adjusting window blinds and devices for adjusting an air vent in a room. The use cases for devices like these requires them to be online and ready for commands (a few seconds of delay is acceptable), but at the same time to be as conservative with power as they can be.
BLE appears to be a good option here, although it has the downside of requiring a nearby gateway. Another route could be to use the ESP8266 / ESP32 modem sleep along with long Wi-Fi DTIM intervals, and that removes the gateway requirement, but it does require messing with the Wi-Fi AP’s DTIM settings.
It is good to hear that adding the necessary code to OMG wouldn’t be too much trouble. I haven’t looked at the codebase yet, but I’ll have do that. It’s definitely modular, which is a good sign.
BLE was made for that sort of application.
A bit off topic; the stated use would also require significant power on demand when activated, necessitating a powerful battery to drive the servo’s.
It’s definitely doable, the tools are all there to put to work.
Yeah, the initial plan is to use 18650s and perhaps (where possible) trickle charge them with small solar panels. Whether or not an appropriately sized solar panel that’s not in direct sunlight can keep the battery charged is a whole other issue. 
There are some interesting ICs available for harvesting power from small sources, though, but that’s an issue for sometime later.