CT-series dustcleaner remote control protocol

[gilbertf]

Hello,
athttps://github.com/gilbertf/libft you find a software library on the remote control interface of the CT dust cleaners, e.g. used by the bluetooth module. Maybe it is helpful for anyone. Maybe anyone knows if this kind of interface follows an standard or is maybe used in other festool products, as well.

Gilbert

 

[threesixright]

Appreciated Gilbert, thanks!

Few question:
- How did you (and what) did you use to reverse the protocol (just curiosity)?
- Which functions you support?
- Any change you could change the suction level via BT?

Maybe a (small) readme would be handy for in the gitrepo  .

 

[gilbertf]

Hi,
simply by sniffing messages on the bus and analysing the content, it took some time..
At the moment my hardware interface only allows sending but not receiving messages, but the logic is already implemented. I'm able to switch the cleaner on/off and change the motor speed. Adding more functionality should'nt be a big challenge from now on. I already have a bluetooth remote control implementation, but power consumption is to high at the moment - still work in progress.

 

[VirTERM]

Hi,
simply by sniffing messages on the bus and analysing the content, it took some time..
At the moment my hardware interface only allows sending but not receiving messages, but the logic is already implemented. I'm able to switch the cleaner on/off and change the motor speed. Adding more functionality should'nt be a big challenge from now on. I already have a bluetooth remote control implementation, but power consumption is to high at the moment - still work in progress.

Pretty cool, I agree that a small README would be helpful

 

[demographic]

So, I'm wondering if there's a way to get the reciever to accept bluetooth batteries from another manufacturer as well?

Or perhaps to get the other manufacturers batteries to speak Festool?

 

[VirTERM]

So, I'm wondering if there's a way to get the reciever to accept bluetooth batteries from another manufacturer as well?

Or perhaps to get the other manufacturers batteries to speak Festool?

via proxy?

 

[threesixright]

So, I'm wondering if there's a way to get the reciever to accept bluetooth batteries from another manufacturer as well?

Or perhaps to get the other manufacturers batteries to speak Festool?

via proxy?

Yeah. I think so. If their protocol is also open. You could have a little box that listens to the tool and turns on/off the vacuum.

Sent from my X using Tapatalk

 

[demographic]

So would it be possble for one manufacturers tool with a bluetooth battery to speak to a mobile phone with Bluetooth then for that mobile phone to send another manufacturers bluetooth message to start an extractor?
So the phone kind of acting as a relay/translator?

Is that what you mean when you say Proxy? Would it work through a bluetooth phone?

Obviously, in an ideal world the manufacturers would get together and agree some form of protocol so all the bluetooth tools could work with each other which would be a massive improvement over using a phone to do the translating but I guess self interest would get in the way.

 

[threesixright]

So would it be possble for one manufacturers tool with a bluetooth battery to speak to a mobile phone with Bluetooth then for that mobile phone to send another manufacturers bluetooth message to start an extractor?
So the phone kind of acting as a relay/translator?

Is that what you mean when you say Proxy? Would it work through a bluetooth phone?

Obviously, in an ideal world the manufacturers would get together and agree some form of protocol so all the bluetooth tools could work with each other which would be a massive improvement over using a phone to do the translating but I guess self interest would get in the way.

In essence yes.

Sent from my iPad using Tapatalk

 

[Gregor]

Obviously, in an ideal world the manufacturers would get together and agree some form of protocol so all the bluetooth tools could work with each other which would be a massive improvement over using a phone to do the translating but I guess self interest would get in the way.

An ideal world would have legislation that forces manufacturers to document the interfaces and protocols (in a manmer that allows to create interoperability without having to reverse engineer) of the devices they sell.

 

[demographic]

An ideal world would have legislation that forces manufacturers to document the interfaces and protocols (in a manmer that allows to create interoperability without having to reverse engineer) of the devices they sell.

I agree totally that on items relating to health and safety and where it doesn't interfere with the safe running of the tool this would be the way forward.

Still can't see it happening anytime soon though, can you?

 

[GarryMartin]

Welcome to the FOG [member=71516]gilbertf[/member] with a fantastic first post! I'll be following along here as this looks like a great piece of work and could be very useful.

 

[Gregor]

I agree totally that on items relating to health and safety and where it doesn't interfere with the safe running of the tool this would be the way forward.

Hard to parse.

But I forgot to type 'no exceptions'. In case anyone wants to kill himself by fiddling with stuff he should be free to do it. Giving manufacturers the ability to weasel out of the requirement through the keyword 'unsafe' would just turn basically everything into a death trap (on paper, to avoid having to provide the documentation).

Hence: no exceptions. None. Zip.
In case a product is able to be unsafe should someone else connect to it then the problem isn't the someone else but the product not having working access controls.

And in a perfect world... the owner not getting the root credentials (meaning him not being the effective owner) should automatically lead to the manufacturers of such 'rentals' having the obligation to maintain the product till the heat death of the universe, for free. Simply to stop them from turning owners into something completely different.

Still can't see it happening anytime soon though, can you?

I remember getting such documentation when buying most things some 30 years ago. Full schematics

Back to the topic: I like the idea of a proxy that could couple the tools of several manufacturers. Should be relatively straightforward (as long as the protocols are known) to put into a small microcontroller with bluetooth.

 

[threesixright]

Obviously, in an ideal world the manufacturers would get together and agree some form of protocol so all the bluetooth tools could work with each other which would be a massive improvement over using a phone to do the translating but I guess self interest would get in the way.

An ideal world would have legislation that forces manufacturers to document the interfaces and protocols (in a manmer that allows to create interoperability without having to reverse engineer) of the devices they sell.

There is no need why manufactures could not play nice together. B(uetooth) L(ow) E(energy), was designed in such way it can be easily used between the different manufactures.

This is just another of example companies trying to protect their own business / vendor lock-in (well so they think). Makes me think about those smart lamps, sensors, where vendors wants you to buy a "bridge" for their own devices, while the protocol was already designed in such a way you could use one bridge and all peripherals would connect to that bridge.

Marketeers are the death of these great inventions. Bah.

If 3 major brands would set the tone, the rest would follow.

Yeah maybe, we need legislation, unfortunately [blink]

 

[VirTERM]

Back to the topic: I like the idea of a proxy that could couple the tools of several manufacturers. Should be relatively straightforward (as long as the protocols are known) to put into a small microcontroller with bluetooth.

Building such proxy should not be a problem, just not sure if I would do that with a dedicated uController, perhaps RasberryPi would be a better (less expensive) option?

 

[threesixright]

Back to the topic: I like the idea of a proxy that could couple the tools of several manufacturers. Should be relatively straightforward (as long as the protocols are known) to put into a small microcontroller with bluetooth.

Building such proxy should not be a problem, just not sure if I would do that with a dedicated uController, perhaps RasberryPi would be a better (less expensive) option?

Thats pretty heavy (RPi) and a lot of overkill. Arduino UNO with some BLE chip should work.

Assuming all vendors are using BLE, you need to get the service and characteristics UUIDs (easy to do). Next would be to understand what values you read and write. And then there is understanding the pairing. I’m guessing (i.e. FT) you pair the remote with the vac, it writes the S/N to the vac, so the vac know which remotes it should listen for. Same with pairing the battery.

Sent from my iPad using Tapatalk

 

[VirTERM]

Back to the topic: I like the idea of a proxy that could couple the tools of several manufacturers. Should be relatively straightforward (as long as the protocols are known) to put into a small microcontroller with bluetooth.

Building such proxy should not be a problem, just not sure if I would do that with a dedicated uController, perhaps RasberryPi would be a better (less expensive) option?

Thats pretty heavy (RPi) and a lot of overkill. Arduino UNO with some BLE chip should work.

I forogt about Arduino  [scared] you are right that is much better choice.

Assuming all vendors are using BLE, you need to get the service and characteristics UUIDs (easy to do). Next would be to understand what values you read and write. And then there is understanding the pairing. I’m guessing (i.e. FT) you pair the remote with the vac, it writes the S/N to the vac, so the vac know which remotes it should listen for. Same with pairing the battery.

Sent from my iPad using Tapatalk

 

[vizion2000]

Hello,
athttps://github.com/gilbertf/libft you find a software library on the remote control interface of the CT dust cleaners, e.g. used by the bluetooth module. Maybe it is helpful for anyone. Maybe anyone knows if this kind of interface follows an standard or is maybe used in other festool products, as well.

Gilbert

HI
I am not a programmer but asking is there any way I could use the bluetooth signal when using the drill so it communicates with another blue tooth receiver e.g. a remote blue tooth power switch so I could turn on a some other electrical device?
If so how could that be achieved?

 

[sladen]

So would it be possible for one manufacturers tool with a bluetooth battery to speak to a mobile phone with Bluetooth then for that mobile phone to send another manufacturers bluetooth message to start an extractor?

Yes, using a mobile phone (or Linux-based Raspberry Pi) as the hub is the realistic solution.  Status so far:

• Festool: Bluetooth (in progress, slow; very well-designed protocols, uses BLE Secure Connections for pairing... which is making reverse engineerings tedious; remote uses proper pairing to setup BLE Notify; BT Battery should be simpler...)
• Hilti: Bluetooth (not done {yet}: 1 remote + 1 retro-fit vac control panel available, ~$/€100)
• Makita AWS "Auto-start Wireless System": Bluetooth (done {both directions}: same WUT01 chip, but pairing uses a GATT service which accepts/provides the desired MAC address, but after that it is simple BLE advertisements 10-times-per-second from the tool with off/on status.  Very noisy)
• Bosch "Tool-to-tool": Bluetooth (not done; apparently "GSY42" module has the extra Tool-to-Tool support (GSY30 does not), …but currently no vacs available, yet.  Hopefully BLE advertisements, if lucky)
• HiKoki: Bluetooth (not done: 1 vac + 2 circular saws only so far: ~$/€600+...)
• DeWalt WTC "Wireless Tool Connect": 433.92 MHz FSK/Manchester (semi-done {RX from tool}, 32-bit value, last bit is tool-start or tool-stop.

Yes, it would be fantastic for the vendors to agree on a standardised Bluetooth protocol (and have OHSA just require support) but in the mean-time we might just have to do it for them/ourselves with software!  [wink]

PS. As [member=71516]gilbertf[/member] noted at the top obtaining the packet dumps/recordings of Bluetooth and serial exchanges is often the hard-part:  do you know/run a dealership/warehouse containing some of the above tools, even if broken?  This would really help.

Note2: Milwaukee One-Key and DeWalt Tool Connect are Bluetooth, but for asset tracking + configuration.  These don't appear to broadcast the run-state of the tool.  (But do correct me if you know otherwise).

 

[Bob D.]

"Yes, it would be fantastic for the vendors to agree on a standardised Bluetooth protocol..."

Maybe the Power Tool Institute of which most are members would be a place to start this coordination in the name of jobsite and personal safety for dust control.