Johnny-five: DS18B20 addressing issues.

[overflowz]

Hi, I'm using sketch provided here:
https://github.com/rwaldron/johnny-five/blob/master/docs/temperature-ds18b20.md

I have connected two DS18B20's on pin 2 (with resistor and stuff).
But the weird part is that, callback always shows same address no matter what.
output:

27.125°C
0x4c46584
27.0625°C
0x4c46584
27.125°C
0x4c46584
27.0625°C
0x4c46584
27°C
0x4c46584
...

I tried to play with both sensors (with cigarette lighter or whatever it's called to make temp higher) but still, address stays the same.

I also used OneWire example of detecting sensors and dump data from it, here's it's output:

ROM = 28 84 65 C4 4 0 0 42
  Chip = DS18B20
  Data = 1 BA 1 4B 46 7F FF 6 10 D0  CRC=D0
  Temperature = 27.62 Celsius, 81.72 Fahrenheit
ROM = 28 AF 93 C4 4 0 0 36
  Chip = DS18B20
  Data = 1 B9 1 4B 46 7F FF 7 10 D1  CRC=D1
  Temperature = 27.56 Celsius, 81.61 Fahrenheit

As you can see, this works fine, but not in johnny-five.

Could someone confirm this? Thanks!

[overflowz]

as far as I understood by digging in code, if you don't specify address, it reads only first default sensor found, ignoring others. It would be great to read from all sensors if we don't specify addresses.

Also, if you don't plan this, could you update documentation too? It might help others too. (I would edit it, but my poor English skills don't let me to).

EDIT: could someone tell how can I get temperatures from all devices?

[rwaldron]

@BrianGenisio Can you take a look and offer some insight? Thanks!!

[BrianGenisio]

Yeah, if you don't specify an address, you only get the first one it finds. If you have more than one, then you need to set the {address} property. But how do you know what the addresses are?

You need to run your app with one sensor, then the other. Grab the address from the console, and set it in your code. Then you'll get access to both devices.

See this example: https://github.com/rwaldron/johnny-five/blob/master/eg/temperature-dual-ds18b20.js

[overflowz]

I think that makes no sense, logically. Or you have to update docs as soon as possible though.

Something like:
If you specify address = you get data from that address.
if you don't specify address = you should get data from all available sensors.

This makes sense. getting addresses manually and then writing code, it's really time consuming (depending on how large project is).

May I ask this as a feature?

[BrianGenisio]

Johnny-Five tends to have a model that for every sensor instance, you get the data from one physical sensor. I'm not aware of any sensors which multiplex multiple sensors into a single instance, other than ReflectanceArray, which is an array of individual Sensors.

The addresses of the units don't change, so it is really just a single-setup thing, so it wasn't intended to be something that should take much time. Especially since I had considered that you would want to directly address the different sensors... you usually want to know which object represents which sensor in physical space.

Perhaps, a new helper container ThermometerArray, might probe for the known addresses, and add individual sensors to that container? It doesn't solve the physical space knowledge problem, but it might make things easier to noodle about?

[overflowz]

aw, that's kind of sad story for me. well, I'll do as j5 supports it. thanks for your time!

[BrianGenisio]

@overflowz

I'm curious why that is a sad story. What workflow are we failing to support? I don't mean to discourage you from your needs... I'm curious what you think about the ThermometerArray idea?

[overflowz]

Well, I'm doing a project, which will have 50+ DS18B20 sensors on one pin via OneWire and it will be all done via configuration (it'll be dynamic) so it will consume a lot of time writing configuration for each hardware. Also, idea is great. If j5 can't handle more than one sensor on the pin, ThermometerArray would be great approach.

Also have in mind, that I'm a rookie in these things so, it would be much better if you'd ask it to people who knows it better than me. But still, in my case it should be great.

Regards.

[BrianGenisio]

Hmmm... Another option might be just a helper which probes for all the known addresses:

const allTemperatures = ds18B20.reportAddresses()
    .map(a => new Thermometer({controller: "DS18B20", pin: 2, address}));

Just spitballing here. The interface would probably be different, but the idea would be the same.

[overflowz]

Gonna try that now.

[overflowz]

Oh wow, it's so complicated for me, can't even do anything like that :disappointed:
Another approach would be getting "initialized" event and construct thermometer object on those addresses, but I'm unable to catch that event, don't even know why. still digging in the code.

[overflowz]

By the way, I could do something like this, but NOT sure if this can be right. Can someone confirm?

var five = require("johnny-five");

five.Board({repl: false, port: 'COM6'}).on("ready", function() {
  five.Thermometer.Drivers.get(this, "DS18B20", {pin: 2})
      .on('initialized', function(addr) {
        var temp = new five.Thermometer(
            {controller: "DS18B20", pin: 2, address: addr, freq: 1000});
        temp.on('data', function() { console.log(this.address); });
      });
});

output:

1472144947927 Connected COM6  
1472144952222 Component pin: 2, controller: DS18B20, address: 79991727 is already in use  
79979908
79991727
79979908
79991727
79979908
79991727
79979908
79991727

[rwaldron]

By the way, I could do something like this, but NOT sure if this can be right. Can someone confirm?

var five = require("johnny-five");

five.Board({repl: false, port: 'COM6'}).on("ready", function() {
  five.Thermometer.Drivers.get(this, "DS18B20", {pin: 2})
      .on('initialized', function(addr) {
        var temp = new five.Thermometer(
            {controller: "DS18B20", pin: 2, address: addr, freq: 1000});
        temp.on('data', function() { console.log(this.address); });
      });
});

Does that actually work? (I don't have this sensor handy to try it) If so, then I'm impressed and think that's totally awesome.

---

Tangentially related.

1472144952222 Component pin: 2, controller: DS18B20, address: 79991727 is already in use

This pin nannying has to go. I can't stand that I ever agreed to this and implemented it.

[overflowz]

Well, I don't know why that 'already in use' warning is appearing to be honest.

I tried this sketch:

var five = require("johnny-five");

five.Board({repl: false, port: 'COM6'}).on("ready", function() {
  five.Thermometer.Drivers.get(this, "DS18B20", {pin: 2})
      .on('initialized', function(addr) {
        var temp = new five.Thermometer(
            {controller: "DS18B20", pin: 2, address: addr, freq: 1000});

        temp.on('change', function() {
          console.log(
              'address: 0x%s, temp: %s', this.address.toString(16),
              this.celsius.toFixed(2));
        });
      });
});

output:

1472157613737 Connected COM6  
1472157618034 Component pin: 2, controller: DS18B20, address: 79991727 is already in use  
address: 0x4c46584, temp: 28.75
address: 0x4c493af, temp: 28.69
address: 0x4c46584, temp: 28.81
address: 0x4c493af, temp: 28.75
address: 0x4c46584, temp: 28.88
address: 0x4c493af, temp: 28.81
address: 0x4c46584, temp: 28.94
address: 0x4c46584, temp: 28.88
address: 0x4c493af, temp: 28.88

Somehow, it works fine, but that warning is annoying me.

[rwaldron]

Can you try this:

npm install rwaldron/johnny-five 

(That will get you the master branch from the repo, where I just pushed a commit that disables all that pin nannying crap)

[rwaldron]

Well, I don't know why that 'already in use' warning is appearing to be honest.

To explain: it's because you're creating more than one Thermometer instance on the same pin. These warnings were meant to be helpful in case authors accidentally re-used a pin number in their program, but the feature has become a nuisance.

[overflowz]

Works fine now!

1472158071816 Connected COM6  
address: 0x4c46584, temp: 28.63
address: 0x4c493af, temp: 28.50
address: 0x4c493af, temp: 28.56
address: 0x4c46584, temp: 28.69
address: 0x4c493af, temp: 28.63

also, I'm curious about this method:
five.Thermometer.Drivers.get

am I doing it right?

[rwaldron]

Heh, it's not a matter of "doing it right" or not. It's there, it's just not documented. I think it's super cool that you figured that out—very smart approach to solving your problem :)

[overflowz]

Thank you! I was just curious. It may be not documented on purpose (it may changed, modified) and may cause problems later on, so I was just asking about it.

[rwaldron]

It may be not documented on purpose (it may changed, modified) and may cause problems later on, so I was just asking about it.

Sure, that's definitely wise to ask about, but in this case it's definitely safe (for now! I kid ;D)

[overflowz]

Alright! Thanks for the info!

[BrianGenisio]

That's awesome. Yeah, I think that driver is not MEANT to be public, though it gives you what you want and I don't expect it to change. I'd go for it. But if you want something more obvious and documented, a PR with a more public utility and documentation COULD be added.

I'm just happy the existing capabilities can solve your needs. That's really cool.