search

openvehicles / Open-Vehicle-Monitoring-System-3

Open Vehicle Monitoring System - Version 3
http:///www.openvehicles.com/
Other
593 stars 226 forks source link

Bluetooth BLE GATT support #55

Open markwj opened 6 years ago

markwj commented 6 years ago

Add a bluetooth BLE GATT interface to metrics, notifications, and commands.

phdegen commented 4 years ago

Hi there, I would like to use the OVMS.V3 as a BLE GATT client. I'd be happy to work on that but I cant build the firmware with Bluetooth enabled (Linker says it uses too much RAM) and when trying to build it with the bluetooth sdkconfig file it fails building, lacking the ssl support for the mongoose library. can you help me out on this?

dexterbg commented 4 years ago

You're welcome to give this a try. Bluetooth component development has been abandoned early in favor for more important features.

The esp-idf bluetooth support needs a lot of RAM, so you probably will need to exclude other components. Check make size-components and probably make size-files to see how much RAM is needed by the different components.

The bluetooth sdkconfig template is pretty old. Simply start with the current default template and add the bluetooth components as necessary. You should also check for new esp-idf config options available to potentially cut down bluetooth RAM requirements. Use make menuconfig to browse through the options.

Regards, Michael

phdegen commented 4 years ago

Ok, thanks a lot for the reply! Basically that is what I was doing so far but I will try with the size cmds. Would you recommend to use a new version of the esp-idf or just modify and configure the config for the current one?

Regards, Philippe

dexterbg commented 4 years ago

The OVMS currently needs release 3.3 of esp-idf. Porting to release 4 is an ongoing issue by itself.

atroncoso-tucar commented 3 months ago

Hi all.

Is there any update on this project or Bluetooth in general? Assuming that BLE GATTS isn't yet supported (I notice it's under TO-DO in the repo projects), are there any recommendations/tips to keep in mind while trying to implement it myself?

Similarly to @phdegen, I would also like to enable Bluetooth communication via GATT. However, I need to use the OVMS.V3 launch a server and have my other device work as a client.

After skimming through the source code I noticed there's quite some work put into implementing this throughout the year 2018. Particularly, I noticed that there's a GATT Server implemented which allows for the registration of multiple Bluetooth Apps which can all read any BLE event and act on them accordingly.

So, I wanted to test this out and see if I could develop a Bluetooth App myself to serve my specific needs. After enabling the compilation of the esp32bluetooth directory using the menuconfig and powering it ON in the Init method from Housekeeping, I managed to connect a device and transmit a byte from a device (acting as a client) to the OVMS.

However, I found that after attempting to transmit multiple messages, the OVMS would reboot. Also, when disconnecting and reconnecting my device the OVMS would also reboot.

Are these known issues? If not, could it be that I'm setting it up incorrectly?

Any tips and help would be very much appreciated. Thanks!

markwj commented 3 months ago

I did quite some work on Bluetooth in the early days of v3. The goal was to have the OVMS module act as a GATTS server, exposing both the metrics and command interfaces. This would have allowed a much smoother setup process via the app using Bluetooth, rather than web browser. It would also allow local in-car connection for things like 0-60 timings and other dashboard functionality.However, at the time I hit a roadblock: memory. Specifically IRAM. When enabling WiFi, Bluetooth, and all the other stuff we needed, there was simply not enough IRAM available (even though general RAM was sufficient).The hope is that when we get SDK 5 support working, we would revisit Bluetooth - assuming the IRAM problems are resolved in the later SDK.You are welcome to ‘give it a try’ with the current SDK. With other parts of OVMS disabled, back in 2018 I did manage to get cellphone apps connected, and the Bluetooth code in OVMS now can be considered a framework, but far from complete.Regards, MarkOn 28 Jun 2024, at 11:21 PM, atroncoso-tucar @.***> wrote: Hi all. Is there any update on this project or Bluetooth in general? Assuming that BLE GATTS isn't yet supported (I notice it's under TO-DO in the repo projects), are there any recommendations/tips to keep in mind while trying to implement it myself? Similarly to @phdegen, I would also like to enable Bluetooth communication via GATT. However, I need to use the OVMS.V3 launch a server and have my other device work as a client. After skimming through the source code I noticed there's quite some work put into implementing this throughout the year 2018. Particularly, I noticed that there's a GATT Server implemented which allows for the registration of multiple Bluetooth Apps which can all read any BLE event and act on them accordingly. So, I wanted to test this out and see if I could develop a Bluetooth App myself to serve my specific needs. After enabling the compilation of the esp32bluetooth directory using the menuconfig and powering it ON in the Init method from Housekeeping, I managed to connect a device and transmit a byte from a device (acting as a client) to the OVMS. However, I found that after attempting to transmit multiple messages, the OVMS would reboot. Also, when disconnecting and reconnecting my device the OVMS would also reboot. Are these known issues? If not, could it be that I'm setting it up incorrectly?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

atroncoso-tucar commented 3 months ago

@markwj,

Thank you very much for your response. This IRAM issue you mention sounds like it could be the root problem since I struggled to identify a specific command or method that's triggering the crash. It seems like it just reboots after a few Bluetooth transactions.

I'll try deactivating some other features and see if the problem persists. I particularly don't need WiFi turned on for example, so my hope is that by deactivating that should help.

Still, I wanted to ask how I can distinguish if this problem is in fact this memory issue and not something else? Is there some function call I should find in the backtrace for example?

Would the use of GDB help here? I notice some other issues refer to the use of it, but haven't been able to find any info on how to do it myself. Is there something I can read to learn how to debug the OVMS with gdb?

Thanks again for the quick response. I'll keep you posted on any findings.

Axel.

markwj commented 3 months ago

@atroncoso-tucar I've only ever used the gdb panic handler. You enable that in the makeconfig, and then use the espressif tools to connect to the USB console. If the esp32 panics, then it will enter the gdb stub and debugger will be launched to inspect memory, etc.

As OVMS is multi-threaded, multi-processor, with many timeout handlers, it is quite hard to debug using step-by-step debuggers. I generally use log statements.

IRAM is statically allocated, so normally doesn't just 'run out' dynamically. I seem to remember 'make size' (or something like that) shows it.

atroncoso-tucar commented 3 months ago

@markwj, Thanks again for the response and tips. I'm trying it out right now. The issue I was running into was actually at runtime, not compile time. That said, I had deactivated some OVMS features via the menuconfig so it might be a different situation.

I'll keep you posted on any findings.

Regards, Axel

phdegen commented 2 months ago

Hi guys

Yea, I did some work some time ago. I implemented the GATTC service expanding the existing GATTS implementation. I had do play around with the sdkconfig as I remember to have the right modules enabled. The main problem with the IRAM as I understand is in runtime, such that Wifi and bluetooth need some specific (probably fast-fetching) IRAM for execution. The crashes seem to be when there is a race condition or double use of some fixed IRAM section. Now I am just using BLE or Wifi one at a time. This works so far, I cant remember whether I had to additionally configure something or not.

Hope this helps.

Cheers

atroncoso-tucar commented 1 month ago

Hi again,

Just wanted to post a few findings.

  1. I was able the replicate the IRAM issue @markwj mentioned. I can confirm that it isn't a runtime issue and that in fact it runs out when compiling with Bluetooth. However, I was able to work around this problem be deactivating a few modules that weren't necessary in my case.
  2. Once solving the IRAM issue, I successfully compiled and started the device but couldn't connect to it with my phone since I didn't know what pair passkey to use.
  3. After deactivating a few security parameters in the GAP handler, I managed to successfully connect to the device, send a message from my phone and confirm it was received by the device by looking at the logs. (Note: I'm using the nRF connect app from my phone). However, this connection would crash every now and then (maybe due to the same reason @phdegen mentioned).
  4. Finally, I ended up creating a new "custom app" with deactivated GAP security features and managed to maintain a stable connection to the device without any crashes.

I intend to keep investigating this. Particularly, I want to keep looking into those GAP security features I deactivated. So I hope to be back with a few updates.

atroncoso-tucar commented 1 month ago

I've got a few questions regarding the Bluetooth framework.

  1. While looking at the following lines: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/c04472809411c780de6b0eafa61b2bd7c4041fc2/vehicle/OVMS.V3/components/esp32bluetooth/src/esp32bluetooth_gatts.cpp#L160-L163 I notice it uses gatts_add_attr_tab_evt_param instead of gatts_create_evt_param, Since for all other methods, their parameters match their names, I couldn't help but wonder if this was intended or a typo.

  2. Regarding the design of the base bluetooth app class. Is there a reason why it's virtual methods are defined even though they don't do anything? I ask because, while debugging, I would often ask myself whether the base method was being called or that of the derived method. Of course this question could easily be resolved by adding logs, but I found it easier to simply declare them as "= 0" and implement them as empty in each derived class. This way I was absolutely sure that the derived class's method was being called. If you think this is a good idea, I'd be happy to propose a pull request with these changes.

Once again, thanks for your responses.

Regards, Axel.