Not working on B35T

[a-v-s]

On line 490 it says

    // changed this from 43 bytes to 19 (which is what this clamp-meter uses for gatttool payload string
    if (strlen(p) != owon_length) {
      //if (g.debug) printf("strlen not correct, skipping\n");
      continue;
    }

My OWON B35T appears to return an strlen of 42 here. It appears to be using a different protocol.
Some sample data from my multimeter

Notification handle = 0x002e value: 2b 33 37 31 34 20 34 31 00 40 80 25 0d 0a 
Notification handle = 0x002e value: 2b 33 37 31 31 20 34 31 00 40 80 24 0d 0a 
Notification handle = 0x002e value: 2b 33 37 31 30 20 34 31 00 40 80 25 0d 0a 
Notification handle = 0x002e value: 2b 33 37 30 38 20 34 31 00 40 80 25 0d 0a 
Notification handle = 0x002e value: 2b 33 37 30 38 20 34 31 00 40 80 25 0d 0a 
Notification handle = 0x002e value: 2b 33 37 30 36 20 34 31 00 40 80 25 0d 0a 
Notification handle = 0x002e value: 2b 33 37 30 36 20 34 31 00 40 80 24 0d 0a 
Notification handle = 0x002e value: 2b 33 37 30 34 20 34 31 00 40 80 25 0d 0a 

[sercona]

is that the 'plus' version or without a plus in the model name? maybe the plus changed the protocol.

[sercona]

I recently added a debug mode that prints the computed value and the hex string that comes out of the meter. the value will probably be wrong or the code may exit due to not being the exact protocol it expects but if you can comment out some of those checks and get the debug output, I can see if this is the old proto and if its possible to fold that (from another source) into this code base.

[a-v-s]

It is a model without a plus. OWON B35T, with a "Hergestellt für Pollin" sticker on the back.
I wanted to make a picture, but the thing was a bit dirty. I tried to clean it with IPA. That was a mistake. I'm cleaning the printing off. That might suggest a prototype, but the thing was bought at Pollin. I don't expect to buy a prototype in a store.

It seems https://github.com/inflex/owon-b35 works with this meter.

[sercona]

ok, that mostly proves its the older model and it uses an older protocol. when I was looking for a starting point, I found many sources (c and py) that support this brand but most of them did not work with the latest '+' style meters. must be a chipset change.

I can look at that code and see if its possible to create a non-plus protocol variant.

if you want to verify that it works with yours, get the latest code from here and run a few various ranges with just 1 or 2 values. an ohms range, a dc volts range, etc. it will be much easier to validate any new code if we have known good samples.

thanks for testing.

[sercona]

funny, that was one of the sites I used when testing this for my own meters. I must have commented out or outright removed the parts that 'did not work' on my meter but it looks like his was setup for the old series. it should not be too hard to bring his code parts back into my base. if you want to verify it on your end, let me know and I'll give the code a look.

if you are happy with the other code, that's fine too.

[sercona]

It is a model without a plus. OWON B35T, with a "Hergestellt für Pollin" sticker on the back. I wanted to make a picture, but the thing was a bit dirty. I tried to clean it with IPA. That was a mistake. I'm cleaning the printing off. That might suggest a prototype, but the thing was bought at Pollin. I don't expect to buy a prototype in a store.

my guess is that this is what current china manufacturing is getting us. we cant expect the old HP style injection molded calculator buttons, where the printing went all the way thru. for this price point, I would expect the plastic to start to wear and even get 'sticky' over time, if it has rubber-like parts. things at this price point just are not meant to be used for long. ;(

[a-v-s]

I've got this B35T at home. I've got a B41T+ at work, so it would be nice to have both working.
Either way, I was planning to have a look at the gatttool dependency.
As gatttool is deprecated, and removed. I didn't manage to get it installed at my work computer.
I still seem to have it at home. Therefore I was planning to have a look at some replacement.
So, if I have a working base that works on either multimeter, I can start on that at home,
and later test it later at work with the other meter.

[sercona]

I dont love the idea of using cli tools and parsing their outputs, but otoh, talking direct BLE is a big pain and there's a lot of complexity that the gatttool kind of utility deals with entirely for you. I have to admit, its appealing to call bluetooth as a blackbox and not get involved in its protocol and just get the payload and parse it, which is all we really care about.

my longer term goal is to get an esp32 to receive the adverts and have it be a webserver for data it collects. that way, no pc needed and nearly instant boot time on the esp32.

[a-v-s]

I mostly deal with BLE on Microcontrollers, mostly on nRF52.
I haven't done much on PCs. I have come across https://github.com/pisontechnology/nativeble
A Multi Platform BLE library, unfortunately looks unmaintained.

[sercona]

I just added some early beta code that will run ENTIRELY on esp32 !

Feel free to give it a try. I'm going to make it web/rest style, later; but for now it outputs to serial console with millis timestamp and ascii meter value.