-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not recognizing custom characteristic/service #67
Comments
Hi @r00li, it is great that you built your own devices, this is effectively what I'm trying to do as well. I'll be very keen on helping you with this. First thing to check is file names. How do you name them? Should be the same as you put in the "type" tag, e.g.:
I also suggest to change service name to something like that:
Also, you must remove and add your device in OH when you put your custom gatt specs. Basically, if a binary channel is already added, then it will not replaced with "user" channels from gatt files. So you have to remove your "thing", change "GATT services and characteristics parsing strategy" to "Recognised only" or "Recognised + system ..." and then add your thing again. In theory this should work. However, there is something you could improve in the design of your GATT structure.
The one that reports its state should support BLE "notifications", e.g. it should notify clients when its state changes. The one that changes state, effectively it is a "command" characteristic. If you look at the way how standard characteristics are designed, you may notice that if a BLE device supports changing its state, it has a special characteristic called "control point", for example: https://github.com/sputnikdev/bluetooth-gatt-parser/blob/master/src/main/resources/gatt/characteristic/org.bluetooth.characteristic.heart_rate_control_point.xml There are lots of similar examples in the standard characteristics like that. Effectively they encourage people to use "control point" as a single entry for changing device state and multiple characteristics for reading device states. It really makes sense if you think about it. I've got some good examples that I use to control some switches at my home, unfortunately I don't have them handy now, but I'll attach it here once I'm at home. |
Hi... Yeah apparently I did make a mistake while adding a type. But that is just because I copied and pasted the example files so many times that I apparently at one point forgot to change the type. I tried it again with the correct type - sadly it didn't make a difference. The service and characteristic are named v1 because there is also a v2 which supports dimming. And yeah, I know that I need to remove and add a thing when I change the specs (I also change the path to the specs files to something random and then back to correct path again when changing those files - just to force it to reload them). My parsing strategy is set to "Recognised + system..." As for the GATT style... I do have separate channels for control and status on one of my other devices. These were the first devices that I made and they have a really simple characteristic set. Besides - it was never an issue (and I've been using these switches for two years now). Currently if you set the value to anything other than something valid the V2 switch (based on NRF51, V1 is based on the Microchip BLE module) will just discard the value and set the correct one again. If I write [ff] to the binary characteristic via openhab (which should turn the light on), the switch just resets it back to [00]. The Microchip module is slightly more weird though. At least for these modules this will stay as is - mainly because they are wired into my electrical panel and I don't really want to fish them out. But I will take this into consideration for the future. |
Hi @r00li, please find an example here: https://www.dropbox.com/s/383i56s5ilbx3yx/bluetooth_smart.zip?dl=0 This is an example of gatt files for a smart lock. I believe it is a self explanatory. Please try to adapt it for your switch. |
Tried it again... still no luck... com.r00li.bluetooth.service.rswitchv1.xml:
com.r00li.bluetooth.characteristic.rswitchv1.xml:
One thing that I've noticed is that none of these examples that I've seen use full 128 bit UUID for services/characteristics. Could be anything to do with that? Another thing that I've noticed is that this service also includes the Client Characteristic Configuration descriptor. Should this be included? Also... what does Excluded mean when configuring service - that it must not have this option or that it doesn't matter if it has this option or not? |
Right.
Could you please try to use the very first bit of your UUIDs? E.g.:
This just reminds me something... There is probably a bug matching UUIDs of real characteristics with GATT definitions. Worthwhile to try before we dig further. |
Yes! This worked. My characteristic showed up correctly now. And I could also turn the light on by choosing On from the drop down. Strangely enough I can't seem to turn it off by selecting Off. I don't see any errors in the log (at least not one that would be obvious), but the light just won't turn off. What is weird here is that if I connect to it with my phone I now have to write 16 bit 0 for it to turn off. But that only happens when I modify the value using this binding. If I change it with any of my phones or my Mac or a python BlueZ library on the Pi I just write 8 bits. So something is still a bit iffy here. I have to test my V2 module with the nrf chip. |
Good, what is the type of the characteristic? Make sure you specify a correct on, quite important. Is it a signed/unsigned number? |
Here is a list of supported types: https://www.bluetooth.com/specifications/assigned-numbers/format-types play with |
I assume that it is unsigned 8 bit byte, if you write 255 value to turn it on (all bits are 1), so try |
It is uint8. I've tried uint8, 8bit and I've also tried uint16 just to see what happens. With uint16 I get errors from the binding that there was an issue while reading. |
Are you saying that uint8 does not work? |
Yes. That is exactly what I am saying. |
Ok, give me some time to get a new unittest for this. |
Ok. I will try it with my V2 switch as well when I come home to see if it behaves any differently. And I'll try connecting a debugger to it if I have some time. |
Hey @r00li, is this what you would expect?
In other words your 8bit characteristic gets written with all 1. |
btw, that branch fixes the issue with 128 bit UUIDs |
Yeah that is what I would expect to happen when writing 255. Though I would also check if 0 gets written correctly. So writing 0 to an 8bit field should get you 0b00000000. |
Ah right, the problem not in "on" but with "off". Hold on... |
It seems to me working, this means that the problem somewhere else. I'll double check if this is what exactly happens in the binding. What transport do you use? TinyB or BlueGiga? |
Hmmm shouldn't you be checking the binary string for: I use TinyB with BlueZ 5.47 on Raspberry Pi Zero W. |
The minimum what gets send to device (according to BT spec, afaik) is 1 byte. This means that and empty byte (all zeroes) your device should get. |
You are right. And you are checking for 0 anyways. Weird. |
Do you get any log entries like that when you select on/off in PaperUI?
|
Damn, that log entry gets printed if debug level is enabled, can you pls enable it in the OH console and try to select on/off values?
|
I will check when I get home (in about 8 hours). Don't have access to the device right now. But I did enable debug logging already. And I don't remember anything like that from yesterday when I was checking. |
Cool. Make sure you enable it for this package: |
Also I'd recommend to try to write on/off values by using |
Hmmm. Ok. So no log entries that would look similar. Actually I see this in the logs: And I've tried it with bluetoothctl, this is the result:
The light turned on/off just as expected. I've also tried it with my V2 device. It is working just fine with that one. And I've even connected a debugger to my V2 device - the data received was 0x00 with a length of 1. So it must be something with the V1 device. Sadly the stupid Microchip module in my V1 device doesn't have a debugger to see what actually happens. And I also don't have a spare one to see what is going on. |
Right, very interesting :)
do you mean the device receives an array of length 1 and the first element in the array is 0x0? |
Yeah. That is exactly what I mean. Basically it's what one would expect. On the other hand there obviously is something wrong since the V1 is working just fine with bluetoothctl and not with this binding. |
I just noticed something. Not sure if it is important or not... I was playing around with nrf connect on my phone and noticed that the V2 switch (the one that works fine) works with either "wite request" and "write command", but the V1 switch (the one with the issue) only works with "write request". Could it possibly be something to do with this? Though this doesn't really explain why writing 255 would work but writing 0 wouldn't. |
Possibly yes, not sure what it does though. I assume these are two different methods to write characteristics, e.g. |
Anyway, I'll try to emulate this in my OH (add your xmls) and see what exactly gets written into a characteristic. I won't be able to do this today, Friday is more likely. |
Yeah. It most certainly is weird. Awesome. I am looking forward to the results. And I'll see if I can figure something else out. |
Hey! I was just playing around a bit more today and found a way to replicate this behavior with my phone. |
Hi @r00li, sorry I was really busy irl. Interesting findings. Effectively, the "on" operation breaks your switch. Would you be able to do another experiment? Try to turn on your device with your phone, then connect it to the binding and try to turn it off. This may work if your device won't turn off automatically when disconnects. This would give us more info on what's not right. |
No worries. I tried it... no luck sadly. The thing still won't turn off. And if I want to turn it off again with my phone I need to write 0x0000 again. This is starting to get on my nerves. I have the desire to rip the damned switch out of my wall and attach a debugger to it just to see what happens. |
Can you share that piece of your firmware code that check incoming value and then make a decision what to do (on/off)? Update: just wondering what is in your |
Here is the whole thing: |
Nice one :) That would be difficult to debug that thingy, too many moving parts, e.g. bt module, uart and your controller... |
Or you can even try to leave the key as 255. |
Same thing for
I'd try these ones. Who knows what your bt module would do/send to your mcu, hopefully one of these values will work ;) |
That's why I switched to nrf51 and never looked back. The official nordic SDK has awesome documentation and their help team is very helpful if you have issues. The learning curve is a bit steep for a first time user maybe. There is a 9 bit type? Interesting. I will try these tomorrow. I don't know why I haven't seen this issue before now though. I've been using this switch from 2015 almost daily with various phones (iOS and android), linux distros with custom software written in python to BLE explorer on my Mac. |
I know this is strange. Yes, you can use an arbitrary number in Xbit notation. The binding will send only these X bits. nrf51 chips are very good, I like to work with them. I'd also recommend to look at mbed framework, which is heaps easier to use comparing to nordic sdk and you also don't have to have any chaintool installed as this all gets built in cloud. |
Well I tried these values today... 16bit doesn't work either. 65535 and 511 turn on the light, but 0 doesn't turn it off. 256 doesn't turn it on or off. Though I did notice something strange... when I turn off the light with my phone by writing 0x0000 to the device and then reconnect to it with the binding, the value shown in the UI is 256 instead of 0. |
Well I went for the extreme measures... I ripped the switch out of the wall and connected it to the debugger. The funny thing is - as soon as I connect to it with the binding no breakpoints gets triggered anymore. It just seems like the Microchip BLE module is flooding my micro controller with UART interrupts. And not even receive interrupts. When I connect to it with my phone everything works normally. No excessive interrupts, and other breakpoints work just fine. But for now I am done messing around with this. I'll just replace the V1 switch with my V2 module and be done with it. I have one final question... when will the update with the support for 128 bit characteristics be available to download via the openhab UI? |
Good to know.
I'm planning to cut a new release soon, potentiall next week. Sorry I'm a bit busy nowadays, can't do releases too often. Also I'm working on a feature that will help you to manage your devices, e.g. that feature will allow you to configure things so that they won't keep connection always open and will only establish connection when required (eg. a characteristic is changed). |
BTW, since your v2 switches are working, is this something that you could share? I mean that would be good if you could create a PR with your gatt files for the gatt parser project. This would mean that you won't have to add any external configs for your OH and it also will provide some good examples for others. |
Sure, no problem. I'll add the V2 switches and the other devices after after the 128 bit UUIDs are in so I can actually see if everything is working as it should. |
Hey @r00li, could you please try that build (with 128 bit uuid fixes)? |
I just finished testing the build... My devices seem to be working just fine with 128bit uuids now. |
Here is that pull request: Sorry that I didn't make it sooner. |
Hey, @r00li , @vkolotov Also setup the service and characteristic with an nrf52 DK and nRF Connect and got the same result. So hopefully the ESP32 code works fine. I set parsing strategy to Recognized + System + Unkown + unrecognized as binary restarted and deleted the device multiple times but my service does not show up. Also tried it with xml descriptions with the advises from above but this does not change anything. I assume the problem takes place in a point before the xml files are used because it also does not show up without the files? Is there somewhere a log file with log messages that could be helpful? |
Hi!
So, I am very new to Openhab (just installed it yesterday on my RPI 0W) and I am having some issues getting this binding to work with my custom devices.
So I have a few custom BLE devices (built by me) - powered by either a Microchip BLE module or the nordic nrf51822. Temperature sensors, blind controllers, switches and dimmers basically. I can get my devices to connect just fine, but I can't seem to get my own characteristics to show up.
For instance this is my device when connected (I have enabled for unknown channels to display as binary):
![screenshot 2018-11-10 at 18 36 57](https://user-images.githubusercontent.com/2136711/48304347-aaa95500-e518-11e8-81fd-b1a99a757cfd.png)
This is my switch module. It has a single characteristic - you write 255 to turn the light on and you write 0 to turn the light off. It has read/write/notify properties.
This is my service xml file that I added:
And this is my characteristic:
To be honest, I am not entirely sure if what I am doing is correct, but going from examples this is what I came up with. Now I think that the binding loads my xmls correctly - the logs show that it was complaining when I had an error in the XML, and it's not complaining now.
One other thing that I find weird is that changing the value for the binary characteristic from that UI does nothing. At least it doesn't look like it does anything - the light doesn't turn on/off.
The text was updated successfully, but these errors were encountered: