I was chatting with the CEO a while back and pitched the idea of replacing the Bluetooth protocol with a Matter implementation. It seemed like he was intrigued by the idea, especially since it wouldn’t lock them into one smart home system, but I never heard if they made any progress on that.
They wanted to work on an embedded Alexa stack, but I warned him against that, since if they went in the Matter direction instead, it would work with all smart home solutions automatically. With the Alexa SDK they’d be locked into Amazon and would have to spend 3x the R&D to work with Google and Home Kit as well, and would have to produce 3x separate dongles most likely.
At the moment they are maxing out the firmware storage, and that’s why they’re going in the dongle direction unfortunately. I suggested that abandoning the BLE stack in favor of Matter over wifi might just be enough to fit all into the existing esp32 device they already have onboard.
I told him I’d be interested in getting the serial protocol specs, but not interested in contract development for it, and I haven’t heard anything more since.
Quite a pity. The guy who owns the BedJet business seems decent and seems to want to provide a good product and after sales service. But a promise is a promise and the device still doesn’t work with smart home systems years later… Shot himself in the foot with that one.
If anyone is interested who finds this thread, If you have a bluetooth dongle connected to your home assistant, I made a little more advanced version of a bedjet service that allows you to automate things around your bedjet in home assistant. You do need to use HACS to use it though. The one I forked from only created an entity and didn’t create a proper device. asheliahut/ha-bedjet
I downloaded and am using yours now. Thank you. I was looking through the code to see how to make percent changes in fan speed possible. I see it in the code but my UI doesn’t see that as an option.
This looks great, thank you! Sadly it doesn’t seem to work with my Bedjet V2. It seems to only support Bedjet V3
However, your code does inspire me to try to see if I can add support for V2. Now I just have to look around and see if I can find my lost free time. haha
Hello, I was able to set up your integration but I think my long range bluetooth dongle was not going far enough to reach the bedjet. I just installed an ESP32 bluetooth proxy and still have trouble reaching it. Do you know if bluetooth proxy will work with the bedjet? It may be that I didn’t set up the proxy correctly.
@madcoder, thanks for all your work for the bedjet v3 it works amazing
I recently got a bedjet powerlayer which has a remote and wondering if there is a way for me to catch the Bluetooth signals to try to integrate it
Thanks
The chances of the Power Layer sharing any parts of communication with the BedJet climate system are probably slim.
But to answer question directly:
I assume there’s an app for it? Is it the same BedJet app as would be used for the BedJet climate system? Or a new app?
Assuming it communicates with an app, that likely means it is Bluetooth, which means you can use an app like nRF Connect (Android, but maybe something similar for iOS, not sure?) to watch and inspect the bluetooth connection. It would likely involve a series of BLE characteristic UUIDs for sending and receiving state.
Re (1) an app can be decompiled to reverse engineer the communication protocol at a code level, which helps with things like data model naming (to put a name to a byte field that might otherwise just be a bunch of bits you can’t decipher). Decompiling the app helps explain what an otherwise anonymous bit actually means to the product.
Re (2) nRF Connect helps with reverse engineering the bluetooth protocol itself: it can identify the BLE service UUIDs and characteristic UUIDs that would be needed in order to connect with it. This is useful to get the UUIDs you need in order to read and send states, but the actual data structure that you get/send is still a guessing game - sometimes that’s easy (like if it only reports a temperature value, it can be easy to correlate that a byte value of X results in a temperature of Y°C, then it’s easy to decipher. But if it’s a large data packet, like is the case with the BedJet Climate system, that’s not so easy, which means that reverse engineering via the app is more helpful.
On the off (super unlikely) chance that the BLE characteristic UUIDs match those of the BedJet climate system, it could be incorporated relatively easily, just by modeling the data structures of the BLE data packets.
However, more likely, the Power Layer itself has a whole new BLE service UUID and/or new set of characteristic UUIDs. That would mean that the integration would require reverse engineering from the ground up, and very likely not much could be reused from the current component.
I’m happy to offer assistance deciphering what you can gather from those options above, but not having the device myself, I don’t think I can fully integrate something like this on my own
I don’t think the remote is going to be useful, because at least for the BedJet climate system, the remote does not communicate over bluetooth, like the app does (and like the ESPHome component emulates). The remote seems to be RF, from what I can tell. I say that specifically because there is a limit of 1 BLE client connected to the unit at a time, but the ESPHome and remote control both work together at the same time, which means the remote is not using BLE. I have not looked into scoping the RF signal that the remote uses, as I haven’t had a need to, and I don’t have the equipment necessary for that.
However, if you have the Power Layer currently, you can try to inspect what kind of BLE UUIDs it is advertising. Even if the app is not currently available, there is a good chance that a lot of the implementations will be shared, if possible. You can still use the nRF Connect app as noted above, in order to discover nearby BLE devices, and the service/characteristic UUIDs that it is advertising. The actual data structure of those characteristics might still be unknown, but there’s probably a reasonable amount of info that could be deciphered just from that. If you go down that path with the nRF Connect app, and you’re able to find a BEDJET* or PL* device, you can share the UUIDs here, and it might be possible to add support for it.
And another possibility, is that support for the Power Layer might already be in the BedJet app, and might be discoverable from the app, even if the app UI itself is not exposing that functionality yet.
Finally, you may be able to try to get into the beta program, which might give you early access to the app. If they’re saying mid-next-year, then it probably isn’t ready for beta yet, but it doesn’t hurt to try. You could try to email [email protected] to inquire about a possible beta program for the PowerLayer version of the app.
C
Flags:
00000110 = 0x06
LE Limited Discoverable Mode
LE General Discoverable Mode
BR/EDR Not Supported
LE and BR/ERD Capable (Controller)
LE and BR/ERD Capable (Host)
Reserved
Complete List of 128-bit Service Class UUIDs:
00001000-bed0-0080-aa55-4265644a6574
This is what the app shows
Name is bedjet bf
Will ask them if there is a beta for the app thanks for the idea
So for the Bedjet Power Layer i tried the same options as the Bedjet v3 and for sending buttons i got most of them just by trial and error and added them as buttuns on esphome
so mostly works!!!
Yeah that’s not too surprising, and what I was hinting at above (a company tends to keep what works for them, in order to reduce cost). So the actual values might differ slightly, but the high-level architecture is usually the same or similar.
Nice job - excellent detective work figuring it out and making it work!
Do you mind sharing your ESPHome yaml that works? I’d be curious if we can do something quick and easy to add support for it. Theoretically it might even be able to talk to both a BedJet v3 climate system, and the power layer at the same time - just add both BLE mac addresses as bedjet clients, and depending on what kind of functionality we can actually support, we might be able to represent the PowerLayer as a cover entity
Have you tried any of the other commands from BedJetHub - any info on what works or what doesn’t (like update_firmware(), set_clock(), etc)? Did you use one of the predefined button_*() methods, or did you have to manually create and call send_button(BedjetButton)? Also, is it able to register for status notifications, and does it receive anything?
Is it possible to get the BedJet working without going the ESP32/ESP Home route? I’ve tried @asheliahut’s integration which appears to claim it can connect to HASS over BLE but the documentation is lacking and I’m unable to get my HASS instance (located just on the other side of thin wall) to see the BedJet. Perhaps I need to put the BedJet in pairing mode or something? Holding/double-pressing the LowPower button doesn’t seem to do that for me.
I know this is like over a year old but when i bought mine was pretty skeptical, but i liked putting my blanket over my old air purifier at the end of my bed. I was VERY surprised at how much i love this thing. Like, so much more than i thought.
The key for me though is that you have to use the cloud sheet too. Without it, its nice and all but the cloud sheet is really the secret sauce to this vs my previous hack.
It is possible without esp32. I have my BedJet V3 one room over from the NUC that I run HA on. After the usual HACS install of asheliahut’s repo, it started up like a breeze, auto-detected it so I didn’t even have to grab the mac address.
I will add that while I did not have to do anything special in this regard, the BT on the bedjet only supports one connection at a time. So maybe take the batteries out of the bedjet remote and turnoff bluetooth on any phones that have the BedJet app installed while you’re getting set up.
