I just came upon these temperature sensors:
and I was wondering if Bluz could connect to such devices.
It is possible to use bluz for this project?
Is it possible to connect Bluz Gateway with non-bluz DK BLE Device?
Bluz Gateway to Thunderboard Sense
There doesn’t seem to be a ton of info on these, but if they are Bluetooth LE, it could be possible.
They are most likely BLE peripheral devices, so a DK couldn’t talk to one directly, but a gateway theoretically could. For example, you could use the gateway to mimic the smartphone app and publish data from the devices when you aren’t home. This would require some low level changes in the gateway, as well as some knowledge about how this device works, but it could be possible.
Any ideas on how you wanted to connect them?
Hi Eric, thanks for your response.
What I have in mind is to use it as a remote temperature sensor. Exactly as you described, I would like to use a gateway to act as the app they provide, then forward that information to the particle cloud.
So I guess I would need to contact them and find out if they could provide the BLE command (I’m inventing here since I know nothing about BLE), program the gateway to send that command anytime I require a read of temperature and publish that reading into the particle cloud and life will be good.
Is my understanding correct? is the right BLE command what I’m after here or BLE is only a transport layer and they could have implemented their own handshake - application layer protocol?
BLE works over a system of services and characteristics. These are basically identifiers, allowing people to operate different ones for different purposes. So one service can have an ID and then have multiple characteristics, also with ID’s, that can be used to send/receive data between the central and peripheral. They are very loosely analagous to sockets in the IP world, so you can think of one service (UDP, TCP, etc.) and then multiple characteristics (Socket or Port number) inside of the service. This is just to show how it works, BLE and IP are quite different.
So, their device could potentially send raw data over the BLE characteristics, I have seen a lot of simple devices do this. If that is what they are doing, then it shouldn’t be too difficult to figure it out. But yes, if they built an application on top of the BLE layer, you would have to contact them.
For example, bluz uses a Service and Characteristics to send data to/from the cloud. However, we encrypt the data on the device before it is sent over the air, so anyone trying to read it would only get gibberish. I don’t know what their devices do, so you would certainly need to ask them or just try it. If they only send raw values unencrypted over the air with no special application logic, it would be pretty straight forward.
To reprogram the gateway to work this way, you would need to alter the firmware at the Nordic SDK level. This is certainly doable, but will require C/C++ experience as well as some additional hardware devices (JTAG programmer for example). Though the programmer isn’t 100% necessary, I would highly recommend it if you wanted to flash new system firmware regularly, which you would. Also, a UART to USB converter would help you debug. All can be purchased for well under $50 total, so not a big expense. The Nordic SDK is very well documented and there are lots of examples and a great community there as well, so if you have some C/C++ experience and want to give it a shot, it shouldn’t be too bad, as long as their device will play nicely
a lot of amazing information, thank you!
I will contact the manufacturer of those temperature sensors to find out if they are willing to open the access to their sensors.
Thanks a lot again for your very detailed explanation, I take it as my crash course in BLE
Hey, did @gusgonnet did you take this project further? Some time ago I spent a few weeks of spare time trying to connect the bluz gateway to another off the shelf BLE peripheral. I didn’t get as far as editing the firmware, went down the rabbit hole of sniffing the BLE packets which the device transmitted under normal operating conditions and trying to reverse the encryption scheme. I got very frustrated and abandoned the project. I have been thinking about it since and I am thinking of looking into it again. Maybe first with a device which does not use any encryption schemes.
Hi, nope, nothing much happened with this beautiful sensor. I contacted their support line trying to get more info but the only thing I got back was “works with IFTTT”.
The closest I could get to it was this:
and I’m still debating on why I would buy one versus doing one with Bluz
That would be a typical response alright from such a request. I dream of a day when all hardware and software is open and hack able, I doubt it will ever come. I am working starting to work on interfacing with a BLE device if I have any success I will let you know.
hehe, I dream of such a day too. Maybe one day they’ll publish something on their API. For instance, I asked the same thing to these guys here, and they said they will publish their API soon like they describe in their front-page section “future range upgrades”
good luck and let me know if you break into things!
It’s kind of late in the thread == but that was my experience with the Sen.se Peanut, too. They really didn’t want anyone to connect via Bluetooth without using their own mechanism (and I even signed up as a developer!). However, there are plenty of other devices that can do similar things. I’ve just been having fun with the new RuuviTag which transmits temperature, pressure and humidity data in a fairly simple format (but watch out for the temp data – it’s a sign-magnitude byte, not a normal two’s complement signed-byte)