search

fablabnbg / inkscape-silhouette

An extension to drive Silhouette vinyl cutters (e.g. Cameo, Portrait, Curio series) from within inkscape.
GNU General Public License v2.0
491 stars 113 forks source link

Please add Bluetooth support #88

Open tuxfunk opened 4 years ago

tuxfunk commented 4 years ago

It would be nice, if Bluetooth interface of newer plotters could be used. My Silhouette Portrait 2 supports Bluetooth, and I was able to pair the device using the Linux Bluetooth desktop utilities. With pairing the Bluetooth LED on the plotter turns from blue to violett (a PIN was not needed). The plugin do not support that interface yet, but a support would be nice.

FlyingSamson commented 4 years ago

I'm working on it. On macOS it seems, as if a rfcomm file is created automatically on device connection, and is named after the bluetooth device. Could you provide me with the Bluetooth name of your device? I presume it would be something like PORTRAIT 2-<some alphanumeric characters>.

If somebody owns another device with Bluetooth support, it would be helpful to know its name as well. Again I would assume <DEVICE>-<some alphanumeric character>.

Furthermore, if someone uses a Bluetooth capable device on macOS it would be helpful if you could verify that the created rfcomm file is indeed named /dev/<DEVICE>-<same alphanumeric characters>-SerialPo on your system, too.

tuxfunk commented 4 years ago

Hello, that is great news! On Linux in my KDE Desktop Bluetooth-tool it is displayed as "Portrait2-00168A" with a Connect button. After pressing on it the LED on the cutter changes from blue to violet.

But there is nothing with rfcomm or Serial in /dev ?

dmesg has the following lines: [ 27.132808] Bluetooth: RFCOMM TTY layer initialized [ 27.132814] Bluetooth: RFCOMM socket layer initialized [ 27.132820] Bluetooth: RFCOMM ver 1.11

But how to configure that device? rfcomm is deprecated: Das Programm 'rfcomm' kann im folgenden Paket gefunden werden:

The new tool bluetoothctl gives the following information, but I don't find a command to create the serial device. [Portrait2-00168A]# info Device C0:1B:41:AD:FA:9D (random) Name: Portrait2-00168A Alias: Portrait2-00168A Paired: yes Trusted: yes Blocked: no Connected: yes LegacyPairing: no UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb) UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb) UUID: Vendor specific (e2088282-4fde-42f9-bb22-6ec3c7ed8f91)

I found a description for python as replacement here: https://unix.stackexchange.com/questions/352494/alternative-to-the-now-deprecated-rfcomm-binary-in-bluez

Sorry, I can't really help here, since I'm not a programmer.

Cheers, Frank

On Sat, Jul 11, 2020 at 12:55 PM FlyingSamson notifications@github.com wrote:

I'm working on it. On macOS it seems, as if a rfcomm file is created automatically on device connection, and is named after the bluetooth device. Could you provide me with the Bluetooth name of your device? I presume it would be something like PORTRAIT 2-.

If somebody owns another device with Bluetooth support, it would be helpful to know its name as well. Again I would assume -.

Furthermore, if someone uses a Bluetooth capable device on macOS it would be helpful if you could verify that the created rfcomm file is indeed named /dev/--SerialPo on your system, too.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fablabnbg/inkscape-silhouette/issues/88#issuecomment-657042611, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOD4WFYHCPBI66YYFTC7IWDR3BAK7ANCNFSM4J7FUEQQ .

FlyingSamson commented 4 years ago

Thanks for your feedback!

Interesting... I wasn't aware that rfcomm has been deprecated. I'm on Ubuntu 18.04 and there it is still around and apparently also on Ubuntu 20.04.

I first used the rfcomm binary myself, but then I found the nifty GUI-Application blueman which can bind rfcomm ports, too. So maybe they internally don't use the rfcomm binary, so it might work on systems lacking rfcomm? Maybe you can give that a shot?

I was able to get the plugin (from my current bluetooth branch: https://github.com/FlyingSamson/inkscape-silhouette/tree/bluetooth-support) running on the 18.04 machine with the following steps:

Maybe you can try that, too, so I can see whether this works on other OSs and Devices as well.

tuxfunk commented 4 years ago

Ok, I will try next week.

As far as I understand the Python code example in my link, there is no need for rfcomm dev at all. So the cutter plugin can look for supported devices, read out the own and remote address and do this connection via a socket. May be ask, if there are more the one device. The needed connection is already provided by the actual desktop tools.

Is this a bad idea?

On Sat, Jul 11, 2020 at 5:10 PM FlyingSamson notifications@github.com wrote:

Thanks for your feedback!

Interesting... I wasn't aware that rfcomm has been deprecated. I'm on Ubuntu 18.04 and there it is still around and apparently also on Ubuntu 20.04.

I first used the rfcomm binary myself, but then I found the nifty GUI-Application blueman which can bind rfcomm ports, too. So maybe they internally don't use the rfcomm binary, so it might work on systems lacking rfcomm? Maybe you can give that a shot?

I was able to get the plugin (from my current bluetooth branch: https://github.com/FlyingSamson/inkscape-silhouette/tree/bluetooth-support) running on the 18.04 machine with the following steps:

  • Copied the plugin as described in the README to inscapes extensions folder
  • Copied the udev rule I included in the misc folder of the plugin to /etc/udev/rules.d
  • Uncomment the correct device in that file (in your case PORTRAIT2, third line)
  • Add the hardware address of your device instead of the 00:11:22:33:44:55 part
  • This then will automatically create a tty.PORTRAIT2 file in /dev whenever a rfcomm file is created (no reboot or anything required)
  • Then I used Blueman to create the rfcomm port (doesn't matter which port it generates as the udev rule takes care of it). Just right click on the device and click on Connect to→Serial Port
  • Check that it created /dev/rfcomm and if that does exist then hopefully also /dev/tty.PORTRAIT2 should exist
  • If the last step showed the files, you should be good to start Inkscape and give it a shot

Maybe you can try that, too, so I can see whether this works on other OSs and Devices as well.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fablabnbg/inkscape-silhouette/issues/88#issuecomment-657078270, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOD4WFZHFDQJYVESYR3IHA3R3B6GDANCNFSM4J7FUEQQ .

FlyingSamson commented 4 years ago

No not a bad idea at all. Thanks for the pointer by the way.

I will definitely try this out, but until I get this working anybody who needs BT-support as they don't like 3 chained USB extension cables running through the whole room (as myself) can try it with the existing code.

FlyingSamson commented 4 years ago

I had another look into this, and there are two problems with the approach described on stackexchange (using build-in sockets):

So for now I don't see any other option then to use the method described above.

mooomooo commented 3 years ago

Maybe you can try that, too, so I can see whether this works on other OSs and Devices as well.

Fedora 31, Cameo 4, Inkscape 1.0 checking in; using @FlyingSamson's bluetooth-support branch -- the udev rule didn't seem to do anything, but I manually rfcomm binded then symlinked /dev/rfcomm0 to the right tty1. Then I observed:

Any suggestions to get this cutting? Thanks for these updates, I'm excited to get this working!

1: feature request: can you auto-detect the machine from the get_version() string rather than the tty name so we don't need to bother with udev/symlinking? Alternately, would the pybluez library work to remove rfcomm altogether? https://github.com/pybluez/pybluez

t0b3 commented 3 years ago

@mooomooo You may want to try Inkscape 0.92.5 which still uses the old API but works fine with python3. To get things work with Inkscape 1.0+ some more efforts are needed. I proposed to include automated testing with travis (#98 ) to detect breaking changes, that will help a lot for future migration work.

insanity54 commented 3 years ago

I would like to see this feature implemented. I created a bounty to create some extra incentive. https://www.bountysource.com/issues/86013830-please-add-bluetooth-support

FlyingSamson commented 3 years ago

Fedora 31, Cameo 4, Inkscape 1.0 checking in; using @FlyingSamson's bluetooth-support branch -- the udev rule didn't seem to do anything, but I manually rfcomm binded then symlinked /dev/rfcomm0 to the right tty1. Then I observed:

  • misc/silhouette_move.py worked just fine;
  • misc/silhouette_cut.py threw up all sorts of unexpected keyword argument errors (I guess that hasn't been updated to match api changes?); and
  • trying to actually export from inkscape (or manually using send_silhouette.py) fails with the same KeyError as in this comment (and the same DeprecationWarnings too).

As already suggested by @t0b3 you should try it with Inkscape < 1.0, as my branch does not include any of the fix-ups performed to support Inkscape 1.0, yet. I will merge that changes into that branch as soon as they are included in master. You can also try to cherry-pick those changes on top of the changes in my branch, if you really need to use Inkscape 1.0.

You might need to elaborate a bit further on the udev rule doing nothing. Do I understand correctly that you copied it to /etc/udev/rules.d and then connected to the serial port using rfcomm or blueman or something, but this did only create an rfcomm port and no tty?

1: feature request: can you auto-detect the machine from the get_version() string rather than the tty name so we don't need to bother with udev/symlinking? Alternately, would the pybluez library work to remove rfcomm altogether? https://github.com/pybluez/pybluez

I did try to use pybluez but trying to get it to work on OSX resulted in one problem after the other (mainly because this plugin - as I understood - is supposed to support both Python 3 and 2).

When trying to install pybluez with pip2.7 (latest version 0.23) it installs but importing bluetooth fails with "AttributeError: attribute 'doc' of 'instancemethod' objects is not writable". On the PyBluez side it does say to use version 0.22 for Python 2, but installing it using pip2.7 with 'pybluez==0.22' does abort with "unknown type name 'IOBluetoothDeviceInquiryRef'".

Furthermore when I looked on their install package it states for Linux and Windows, that it requires at least Python 3.5. So until this plugin has moved completely to Python 3, I fear we are out of luck (at least for OSX, I didn't got to test the same on my Ubuntu machine yet).

Maybe I will find time to give bluez another try next week(end) (especially on OSX, I presume once I figured that out Linux should not be that difficult, but my Windows skills are close to not existent...).

Regarding the idea of using get_version(): The way get_version() is implemented atm we require an already established connection to the plotter to ask for the device name / version. But our goal was to establish that very connection.

mooomooo commented 3 years ago

As already suggested by @t0b3 you should try it with Inkscape < 1.0, as my branch does not include any of the fix-ups performed to support Inkscape 1.0, yet. I will merge that changes into that branch as soon as they are included in master. You can also try to cherry-pick those changes on top of the changes in my branch, if you really need to use Inkscape 1.0.

Thanks, I did exactly that: merged the 1.0 changes from @uxwalter's PR #105 (with a few additional fixes) on top of the bluetooth-support branch. I had to add a few additional minor tweaks to the bluetooth-support fork as well; I'll send pull requests for both of them. But now it works! The final results are here: https://github.com/mooomooo/inkscape-silhouette/tree/bluetooth-support-v1.0

You might need to elaborate a bit further on the udev rule doing nothing. Do I understand correctly that you copied it to /etc/udev/rules.d and then connected to the serial port using rfcomm or blueman or something, but this did only create an rfcomm port and no tty?

Correct -- I used bluetootctl to pair and trust, then rfcomm to bind (which created /dev/rfcomm0 but not /dev/tty*) and then manually ln -s /dev/rfcomm0 /dev/tty-CAMEO4.

Regarding the idea of using get_version(): The way get_version() is implemented atm we require an already established connection to the plotter to ask for the device name / version. But our goal was to establish that very connection.

Right, I was suggesting to modify BTConnection.__init__ to instead (or also) try pat = re.compile("rfcomm.*"). Then, if a connection is successful, set self.hardware based on the results of get_version() rather than the filename.

Fair concerns re: pybluez; my OSX and Windows skills are even less extant. Thanks for your thoughtful response.

FlyingSamson commented 3 years ago

I found some time today to give PyBluez another shot and get it to install and work on OSX. I had at least a little success as I was able to find a workarround to both problems mentioned earlier ("AttributeError: attribute 'doc' of 'instancemethod' objects is not writable" and "unknown type name 'IOBluetoothDeviceInquiryRef'"). However, it does not work as smoothly as I hoped for and not as smoothly as it does on my Ubuntu 16.04 machine. I will see whether I can further improve this.

But on Ubuntu as mentioned it does work quite nicely. Only downside is that it takes quite some time to detect the Cameor4. I will see wether I can improve that performance by using some sort of machine cache (I presume most people will use the same machine over and over and not another one each time they plot something).

I included a file PyBluez.md that contains introductions on how to setup pybluez on OSX and Ubuntu (hopefully similar on other Linux systems). I did not try to install on Windows yet. If this should work for other people, too I will include the introductions in the readme.

Please give it a try, if it is not too much work to apply your Inkscape 1.0 patches on top of my recent changes. Would be great to hear whether this is working for you, too.

tuxfunk commented 3 years ago

On Sun, Sep 13, 2020 at 8:53 PM mooomooo notifications@github.com wrote:

You might need to elaborate a bit further on the udev rule doing nothing. Do I understand correctly that you copied it to /etc/udev/rules.d and then connected to the serial port using rfcomm or blueman or something, but this did only create an rfcomm port and no tty?

Correct -- I used bluetootctl to pair and trust, then rfcomm to bind (which created /dev/rfcomm0 but not /dev/tty*) and then manually ln -s /dev/rfcomm0 /dev/tty-CAMEO4.

Hm, I'm not an expert on this topic, but as far as I understand rfcomm is depreciated with newer Bluetooth stacks. For example on OpenSuse there is no rfcomm anymore. Maybe it is possible to get an old version of this tool, but this has then potential conflicts with the newer stacks and config tools.

rysolv-bot commented 3 years ago

insanity54 has contributed $10.00 to this issue on Rysolv.

The total bounty is now $10.00. Solve this issue on Rysolv to earn this bounty.

rysolv-bot commented 3 years ago

An anonymous user has contributed $10.00 to this issue on Rysolv.

The total bounty is now $20.00. Solve this issue on Rysolv to earn this bounty.

insanity54 commented 1 year ago

Just checking back after 6 months. Adding $2 to the Rysolv bounty. Just a reminder, as of writing there are 2 separate bounties for this issue. $50 on Bountysource, $22 on Rysolv.

lilphil commented 1 year ago

It looks like this was fairly close at one point, so I'm just wondering what needs to happen next. Does the @FlyingSamson branch need updating? Now that python2 support has been dropped, does that change things?

ciroiriarte commented 1 year ago

Hello!, I would also love to see bluetooth support. My usecase doesn't make USB connection possible.

uxwalter commented 1 year ago

I got tired of dealing with a long USB cable cluttering the area between the PC and the cutter so decided to go down the Bluetooth rabbit hole to see what it would take to enable Bluetooth. As mentioned somewhere above, rfcomm is no longer a thing it seems so this uses ble-serial to abstract away some of the complexity. It may be worthwhile collecting feedback here for different cutter models and OSes to see what works and what doesn't.

tl;dr: Install and configure ble-serial, transcribe commands to ble-serial's pipe, bluetooth cutting FTW

This works for me on Fedora Linux, a TP-Link Bluetooth dongle and a Cameo3 cutter. Inkscape verions 1.2 and latest inkscape-silhouette (as of 4/18/23). Experience around an xterm is strongly suggested. Also you may want to try a different bluetooth device like a mouse or headset first to make sure the basics work.

  1. Install ble-serial pip install ble-serial

    I suggest reading and following the instructions at https://github.com/Jakeler/ble-serial especially when trying this on Windows or a Mac ble-serial requires python3.7+.

  2. Enable Bluetooth on the PC/laptop and the cutter. For the Cameo 3 it's tapping the gear icon, then scrolling down to find the Bluetooth option. Google is your friend. Some bluetooth adapters require fairly recent Linux kernels. Apparently the TP-link I am using requires at least 5.16. Hence my suggestion to try out bluetooth on something else first.

  3. Pair the cutter. It doesn't have to be connected (yet)

  4. run ble-scan from the command line

   $>ble-scan

   Started general BLE scan

   /usr/local/lib/python3.11/site-packages/ble_serial/scan/main.py:34: FutureWarning: BLEDevice.rssi is deprecated and will be removed in a future version of Bleak, use AdvertisementData.rssi instead
     sorted_devices = sorted(devices, key=lambda dev: dev.rssi, reverse=True)
   /usr/local/lib/python3.11/site-packages/ble_serial/scan/main.py:37: FutureWarning: BLEDevice.rssi is deprecated and will be removed in a future version of Bleak, use AdvertisementData.rssi instead
     print(f'{d.address} (RSSI={d.rssi}): {d.name}')
   C0:██:██:██:██:23 (RSSI=-46): CAMEO3-1█████R
   5█:██:██:██:██:█3 (RSSI=-66): ██-██-██-██-██-██
   C█:██:██:██:██:█0 (RSSI=-74): ██-██-██-██-██-██
  1. run ble-scan again but this time with the -d option and the cutter's bluetooth address (6 hex numbers)
   $>ble-scan -d C0:██:██:██:██:23

   Finished general BLE scan

   Started deep scan of C0:██:██:██:██:23

   Found device C0:██:██:██:██:23  CAMEO3-1██████R (out of 1)
   /usr/local/lib/python3.11/site-packages/ble_serial/scan/main.py:30: FutureWarning: This method will be removed future version, use the services property instead.
     return await client.get_services()
   SERVICE 0000180a-0000-1000-8000-00805f9b34fb (Handle: 16): Device Information
        CHARACTERISTIC 00002a24-0000-1000-8000-00805f9b34fb (Handle: 17): Model Number String ['read']
        CHARACTERISTIC 00002a29-0000-1000-8000-00805f9b34fb (Handle: 19): Manufacturer Name String ['read']
   SERVICE e2088282-4fde-42f9-bb22-6ec3c7ed8f91 (Handle: 21): Unknown
        CHARACTERISTIC 6d92661d-f429-4d67-929b-28e7a9780912 (Handle: 28): Unknown ['write']
        CHARACTERISTIC 8dcf199a-30e7-4bd4-beb6-beb57dca866c (Handle: 25): Unknown ['write', 'indicate']
            DESCRIPTOR 00002902-0000-1000-8000-00805f9b34fb (Handle: 27): Client Characteristic Configuration
        CHARACTERISTIC 61490654-b5b4-458c-a867-9e15bc1471e0 (Handle: 22): Unknown ['write', 'indicate']
            DESCRIPTOR 00002902-0000-1000-8000-00805f9b34fb (Handle: 24): Client Characteristic Configuration
   SERVICE 00001801-0000-1000-8000-00805f9b34fb (Handle: 12): Generic Attribute Profile
        CHARACTERISTIC 00002a05-0000-1000-8000-00805f9b34fb (Handle: 13): Service Changed ['read', 'notify']
            DESCRIPTOR 00002902-0000-1000-8000-00805f9b34fb (Handle: 15): Client Characteristic Configuration

  1. This is were the magic and my ignorance starts

    Pick a read or indicate UUID and a write UUID "CHARACTERISTIC" from the "Unknown" SERVICE above. Which one? Heck if I know, my first pick worked. "Unknown" as in not Device Information or Generic Attribute Profile (GATT)

  2. Launch ble-serial with the cutter's bluetooth address and the two UUIDs from step 6. For Windows/Mac, check the page mentioned in step 1.

   $>ble-serial -d C0:██:██:██:██:23 -w 6d92661d-f429-4d67-929b-28e7a9780912 -r 8dcf199a-30e7-4bd4-beb6-beb57dca866c

       Creating UART port
    20:20:47.320 | INFO | linux_pty.py: Port endpoint created on /tmp/ttyBLE -> /dev/pts/20
    Done creating UART port
    Setting up BLE interface. adapter=hci0  s-uuid=None
    Done setting up BLE interface
    20:20:47.321 | INFO | ble_interface.py: Receiver set up
    Uart start
    BT connect  C0:1B:41:AA:8B:23, public, 5.0
    20:20:47.465 | INFO | ble_interface.py: Trying to connect with C0:██:██:██:██:23  CAMEO3-1██████R
    20:20:48.875 | INFO | ble_interface.py: Device C0:██:██:██:██:23 connected
    Setup chars 6d92661d-f429-4d67-929b-28e7a9780912, 8dcf199a-30e7-4bd4-beb6-beb57dca866c, rw
    20:20:48.876 | INFO | ble_interface.py: Found write characteristic 6d92661d-f429-4d67-929b-28e7a9780912 (H. 28)
    20:20:48.876 | INFO | ble_interface.py: Found notify characteristic 8dcf199a-30e7-4bd4-beb6-beb57dca866c (H. 25)
    20:20:49.048 | INFO | main.py: Running main loop!

  1. Note the two paths towards the top: /tmp/ttyBLE and /dev/pts/20. You'll need one or the other later. Which one doesn't matter on Linux but on Windows it might.

  2. Now launch Inkscape and do your thing. When ready to cut, select Extensions > Export > Send to Silhouette... Select any options as usual Don't click "Apply" just yet

  3. Select the "Log and Dump" tab In the "Transcribe cutter command" field, enter the path from step 8 (e.g., /tmp/ttyBLE) Unselect "Include cutter queries" (although not sure it really matters) Select "Dry run" Select your cutter model in "Override cutter model" Click "Apply"

    If all goes well the cutter should get going after ~5-6 seconds.

Troubleshooting

If nothing happens in step 10, check the output of step 7. Is ble-serial still running (it should). Any errors? Is the cutter still on? It seems to go to sleep faster without a cable although I may be making this up Is the cutter still visible in the OSes bluetooth dialog? At least for me it doesn't have to be connected, just visible and paired. ble-serial should connect once it receives data.

I'd like to get some feedback if this works for people especially under Windows, Mac, and different flavors of Linux. I'd also be interested if the UUIDs for the Cameo3 are the same (I expect they are) and what the values are for other cutters.

Adding ble-serial functionality to the silhouette extension will require some design decisions. I'd rather have folks test drive this first to see if a) it's even needed and b) which way to go. Would love to collaborate if anyone is up for it or use this as a starting point and have at it.

jmb commented 8 months ago

I've just tried it with a Cameo 5 and MacOS (I just selected Cameo 4 as the machine) and it works! on Mac OS it uses UUIDs as addresses instead of MAC addresses, but it works the same.

$> ble-scan
Started general BLE scan
...
EF██████-████-████-████-███████████D1 (rssi=-51): CAMEO 5-9██████C
...
Finished general BLE scan
$> ble-scan -d EF██████-████-████-████-███████████D1
Started deep scan of EF██████-████-████-████-███████████D1

Found device EF██████-████-████-████-███████████D1: CAMEO 5-9██████C (out of 1)
SERVICE 0000180a-0000-1000-8000-00805f9b34fb (Handle: 16): Device Information
     CHARACTERISTIC 00002a24-0000-1000-8000-00805f9b34fb (Handle: 17): Model Number String ['read']
     CHARACTERISTIC 00002a29-0000-1000-8000-00805f9b34fb (Handle: 19): Manufacturer Name String ['read']
SERVICE e2088282-4fde-42f9-bb22-6ec3c7ed8f91 (Handle: 21): Unknown
     CHARACTERISTIC 61490654-b5b4-458c-a867-9e15bc1471e0 (Handle: 22): Unknown ['write', 'indicate']
         DESCRIPTOR 00002902-0000-1000-8000-00805f9b34fb (Handle: 24): Client Characteristic Configuration
     CHARACTERISTIC 8dcf199a-30e7-4bd4-beb6-beb57dca866c (Handle: 25): Unknown ['write', 'indicate']
         DESCRIPTOR 00002902-0000-1000-8000-00805f9b34fb (Handle: 27): Client Characteristic Configuration
     CHARACTERISTIC 6d92661d-f429-4d67-929b-28e7a9780912 (Handle: 28): Unknown ['write']

Completed deep scan of EF██████-████-████-████-███████████D1
$> ble-serial -d EF██████-████-████-████-███████████D1 -w 6d92661d-f429-4d67-929b-28e7a9780912 -r 8dcf199a-30e7-4bd4-beb6-beb57dca866c
13:27:45.799 | INFO | linux_pty.py: Port endpoint created on /tmp/ttyBLE -> /dev/ttys003
13:27:45.799 | INFO | ble_interface.py: Receiver set up
13:27:46.320 | INFO | ble_interface.py: Trying to connect with EF██████-████-████-████-███████████D1: CAMEO 5-9██████C
13:27:47.513 | INFO | ble_interface.py: Device EF██████-████-████-████-███████████D1 connected
13:27:47.514 | INFO | ble_interface.py: Found write characteristic 6d92661d-f429-4d67-929b-28e7a9780912 (H. 28)
13:27:47.514 | INFO | ble_interface.py: Found notify characteristic 8dcf199a-30e7-4bd4-beb6-beb57dca866c (H. 25)
13:27:47.572 | INFO | main.py: Running main loop!
jmb commented 8 months ago

Adding ble-serial functionality to the silhouette extension will require some design decisions. I'd rather have folks test drive this first to see if a) it's even needed and b) which way to go. Would love to collaborate if anyone is up for it or use this as a starting point and have at it.

This would be awesome... Looks like things are pretty standard at least for the Cameo range. What next? 😃

hifi commented 5 months ago

I'm slightly interested in this. I've solved my long USB cable problem by connecting my Cameo 4 to a Raspberry Pi which exposes it via USB/IP on wifi so I can use any Linux system to remotely attach the real USB device over network. It's very reliable but is a bit janky to setup. Though, after the device is attached the extension works as-is without any changes which is a plus and would work with older models without Bluetooth as well. That might be worth documenting in the wiki.

I haven't yet looked into ble-serial that much but it would be ideal if it could expose a stream IO API that could be hooked to directly from the code so it could be fairly easily abstracted to swap between using the USB serial device or a "fake" one that actually talks over Bluetooth.