Mulitple Temperature Sensors on aiko

[Robb01]

Hi guys
This post is copied from the Hackerspace email list since it is most
relevant to the aiko code.

Thanks Andy for your code "trick" for unique node names for the device
addresses:
globalString = "(temperature_";
globalString += (address[7] & 0x0f) + '0';

I have used this successfully on my installed devices. However on my
test set-up with 3 other devices I did find that unique names did not
result from (address[7] & 0x0f) + '0';
The device addresses are shown below with the output:

OneWire device: 28 50 C6 EE 2 0 0 9D 10 18

(node sol_adv ? (temp_61 23.68 C))

OneWire device: 28 6 A3 69 2 0 0 9D 10 18

(node sol_adv ? (temp_61 23.68 C))

OneWire device: 28 15 9C 69 2 0 0 74 10 18

(node sol_adv ? (temp_52 23.68 C))

Note that 2 devices get node name temp_61.

I can only guess as to why this is happening since I don't fully
understand what "(address[7] & 0x0f) + '0';" actually does. It does
suggest though, that for the general case this may not provide unique
node names based upon device addresses.
For now this has helped me to get the aiko-segmeter code working for
my 3-off 18B20 devices but some more work may be required. Hopefully
the output info above is enough for you to amend the line for the
device address - if not I can try another few 18B20s and get some
more data. Let me know.

Thanks
Rob.


Luke
View profile

So, it starts off with the first part of the GlobalString string as
"(temperature_", and then it's taking address[7], which is the 8th
element of the address array (remembering that an address, in this
case, is an array of 8 bytes), and doing a bitwise AND of that byte
with the byte 0x0f, and taking the resulting byte (number) and
"adding" it (actually concatenating the string) onto the end of the
previous part of the string, and then adding a 0 on the end.

I hope that helps, it's a slightly dodgy explanation.



Rob
View profile
More options Jan 1, 10:31 pm
From: Rob <rebrow...@gmail.com>
Date: Sat, 1 Jan 2011 03:31:18 -0800 (PST)
Local: Sat, Jan 1 2011 10:31 pm
Subject: Re: Multiple 18B20 devices on OneWire

Find messages by this author
Luke that elegantly states what I vaguely understood to be the case.
So with what I am seeing this implies that the 8th element of the
array is not unique to the device(!?). The datasheet says that after
the least significant 8 bits of the 64 bit ROM code the next 48 bits
contain a unique serial number. The most significant 8 bits contain
the CRC check so I take this to mean that address[7] is just the CRC
check info. In which case is it entirely unique or do we actually need
something like address[1-6] (not even sure if this is a valid form)
for the unique 48 bits? I don't yet understand the significance of the
bitwise ANDing of the 0x0f and the 0 on the end.
Thanks for your reply.

On Jan 1, 8:06 pm, Luke Weston <reindeerfloti...@gmail.com> wrote:

Rob
View profile Translate to Translated (View Original)
More options Jan 8, 10:20 pm
From: Rob <rebrow...@gmail.com>
Date: Sat, 8 Jan 2011 03:20:19 -0800 (PST)
Local: Sat, Jan 8 2011 10:20 pm
Subject: Re: Multiple 18B20 devices on OneWire

Find messages by this author
Ok, well I have found that "(address[6] & 0x0f) + '0';" is pretty much
useless as all returns from this were identical so maybe the last 8
bits of the 48 for the unique serial number are zeroes or similar.
Anyway "(address[1] & 0x0f) + '0';" has given some more useful stuff
with the responses (nodenames) being unique among the six devices
tried so far.
I guess to construct something from the full 48 bits of info would be
fairly involved but would provide a totally unique nodename for the
general case.

[Robb01]

I have found, since first getting the multiple temperature data
streams to arrive at the SEGmeter site, that after several hours (can
be 6-8 or more) that two of the sensors stop sending data. I have
confirmed this by stopping the aiko gateway and running
telnet localhost 2000
on the router and this shows that in this mode that the arduino is not
sending the data so I must have a glitch in the sketch somewhere. It
is a little hard to troubleshoot this as you need to leave the PC
running with the USB connection to the arduino board and the serial
monitor enabled for the several hours until the fault arises. Has
anyone encountered anything like this? Sometimes this will re-start
without intervention. Maybe its a memory issue?

Thanks
Rob

[Sam Sabey]

Hey Rob,

Perhaps have a look at what Kayne is doing?
https://smartenergygroups.com/groups/kaynos_things

He has a device that has a bunch of temperature sensors on one arduino.

Thanks,
Sam.

> --
> You received this message because you are subscribed to the Google Groups "Aiko distributed platform" group.
> To post to this group, send email to aiko-p...@googlegroups.com.
> To unsubscribe from this group, send email to aiko-platfor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/aiko-platform?hl=en.
>

[Robb01]

Hi Sam
It looks like Kayne is using a different processor to the Arduino and
is also using the DS1820 rather than the DS18B20. I guess I am going
to persist with the Arduino basis for a bit longer. If it looks like
going nowhere then Kayne's project could be a good option.

Thanks
Rob.

On Jan 11, 8:05 pm, Sam Sabey <sam.sa...@esskware.com.au> wrote:
> Hey Rob,
>

> Perhaps have a look at what Kayne is doing?https://smartenergygroups.com/groups/kaynos_things

[Scott Penrose]

We read 4 on our hot water controller off the one pin.
But we had to hard code the IDs into our software - which means if we change them (and we did once, when we broke a pin on one) that we have to upload new firmware.

Scott

[Scott Penrose]

I have, in an experiment, had over a dozen off a single digital IO

Scooter

On 11/01/2011, at 8:59 PM, Robb01 wrote:

> DS18B20

[Sam Sabey]

Nice tip Scott!

Rob, if you get the Aiko code to send the ID to SEG with the value, then setup in SEG the stream_name to be the ID then it will work just fine. Then it's possible to label the temperature something depending and there won't need to be any other changes to the firmware if you substitute the DS18B20 for another.

Sam.
and his 2 cents.

[Allan Nelson]

Hi Rob,

I am using 8 sensors currently with a project, and can talk to each of them individually if I want to.

I am using a library provided by the Arduino community for dealing with these specific sensors. Have a look for the DallasTempreature library (http://milesburton.com/index.php/Dallas_Temperature_Control_Library).

Using the library, you can do a lot of stuff very easy, one of which is to query the bus and have each sensor respond with it's unique code. This can then be stored in the Structure provided and used elsewhere in your code.
You can also use a mixture of DS18 devices and the library will be able to deal with each differently. (i have tested this with 2 different types, but I cant remember the numbers atm).

I have tested up to 16 sensors on one pin, and that worked. You should be able to do more, but I ran out of sensors. One problem I did run across was the pull-up resistor value. I found that when i have the sensor on the end of a cable run that was more than about 10 meters, I had to use a lower resistor value.

You can have a look at my code here:

https://github.com/hurgh/Data-Structure-read-and-write/blob/CutDownVersion/

I am not using the Aiko framework but you should be able to integrate it with Aiko no problems.

If you have any questions about the code, let me know.

Hope this helps you.

Allan