Re: [Owfs-developers] Problem starting owserver on a LinkUSB with option ftdi addressing without sudo
Hi Martin,
On Thu, Aug 10, 2017 at 03:22:19PM +0200, Martin Patzak (GMX) wrote:
[...]
> Only so much, the working rule now looks like (at the moment, might change
> soon ;-) ):
>
> SUBSYSTEMS=="usb", DRIVERS=="usb", ATTRS{manufacturer}=="FTDI",
> ATTRS{product}=="FT232R USB UART", ATTRS{serial}=="A800bXHr", GROUP="owsrv",
> MODE="0664"
>
> This rule results in a node residing in /dev/bus/usb// which is read
> and writeable by the group owsrv , in my case it looks at the moment like
>
> /ls -al /dev/bus/usb/003///
> //...//
> //crw-rw-r-- 1 root owsrv 189, 261 Aug 10 15:07 006/
>
> owserver then accessess this node without sudo, in ftdi addressing scheme to
> use direct communication.
>
>
> BUT more good news, and contrary to my previous statement: "One 'S' too
> little can make or brake the rule...", it DOES work without all the S's too!
>
> SUBSYSTEM=="usb", DRIVER=="usb", ATTR{manufacturer}=="FTDI",
> ATTR{product}=="FT232R USB UART", ATTR{serial}=="A800bXHr", GROUP="owsrv",
> MODE="0664"
A small enhancement that you can add and use is to have udevd create
a predictable symlink for the device. This way if you plug in more
USB devices, or plug things in a different order so they get assigned
the same /dev/ node that your LinkUSB currently has, your owserver or
whatever programs use your LinkUSB will still be able to find it.
As an example, here's what I have on my
/etc/udev/rules.d/50-local-usb-serial.rules file:
--
#
# From
http://marc.merlins.org/perso/linuxha/2010-06.html#Dealing-with-many-USB-to-Serial-Port-Converters-on-linux-and-device-naming
#
# After making a change 'udevadm trigger' will update symlinks.
#
# http://www.reactivated.net/writing_udev_rules.html#udevinfo
# was udevinfo -a -p /class/tty/ttyUSB0
# now udevadm info --attribute-walk -p /class/tty/ttyUSB0
# (used to determine product ID, serial number, etc. to be used
# in the declarations below)
SUBSYSTEMS=="usb", ATTRS{product}=="FT232R USB UART",
ATTRS{serial}=="A5008b6u", SYMLINK+="plm"
SUBSYSTEMS=="usb", ATTRS{product}=="FT232R USB UART",
ATTRS{serial}=="A400bXjP", SYMLINK+="1wire-master0"
SUBSYSTEMS=="usb", ATTRS{product}=="FT232R USB UART",
ATTRS{serial}=="A800eIPR", SYMLINK+="1wire-master1"
SUBSYSTEMS=="usb", ATTRS{product}=="FT231X USB UART",
ATTRS{serial}=="DC00HJ03", SYMLINK+="moteino-usb"
------
These rules will create the symlinks /dev/plm, /dev/1wire-master0,
/dev/1wire-master1, and /dev/moteino-usb for the FTDI serial-to-USB
chips with those serial numbers. Applications (like owserver) then
use the symlinks instead of the actual /dev/bus/usb// path. For
example, my /etc/owfs.conf contains this:
server: device = /dev/1wire-master0
Cheers,
Eloy Paris.-
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Hobby Hoards Barometer
What about something like: echo 5 /mnt/1wire/EF.2D652015/barometer instead of using nano? Cheers, Eloy Paris.- On Mon, Jun 22, 2015 at 02:27:00PM +0200, Eric Baumann wrote: Hallo again. I found a possibly cause: The polling frequency seems to be set incorrectly : pi@raspberrypi /mnt/1wire/EF.2D652015/barometer $ cat polling_frequency 9 I tried to write to the polling_frequency file using: pi@raspberrypi /mnt/1wire/EF.2D652015/barometer $ sudo nano polling_frequency ...without success. How can I change this using OWFS? Best regards, Eric On Mon, Jun 22, 2015 at 2:04 PM, Eric Baumann eric.mannb...@gmail.com wrote: Hallo I have trouble reading from the Hobby Boards Barometer board. It seems to be stuck at these values: pi@raspberrypi /mnt/1wire/EF.2D652015/barometer $ cat pressure 67920 pi@raspberrypi /mnt/1wire/EF.2D652015/barometer $ cat temperature 36.9 Even - when unplugging and plugging the board back in - when rebooting raspberrypi and OWFS - when reading from the uncached directory the values do not change. It seems to have recognized the dive correctly though: pi@raspberrypi /mnt/1wire/EF.2D652015 $ cat type HobbyBoards_EF pi@raspberrypi /mnt/1wire/EF.2D652015 $ cat type_number 6 pi@raspberrypi /mnt/1wire/EF.2D652015 $ cat version 1.0 Thanks for any suggestions on how to proceed for troubleshooting... Eric -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Temp Logging
On Mon, Mar 30, 2015 at 12:42:31AM +0200, Stefano Miccoli wrote: On 29 Mar 2015, at 15:32, mike.kal...@gmail.com wrote: rrdtool create house.rrd --start N --step 300 \DS:garageIN:GAUGE:600:U:U \ DS:garageRTN:GAUGE:600:U:U \ DS:bedroomIN:GAUGE:600:U:U \ DS:bedroomRTN:GAUGE:600:U:U \ DS:floorIN:GAUGE:600:U:U \ DS:floorRTN:GAUGE:600:U:U \ DS:watertankIN:GAUGE:600:U:U \ DS:watertankRTN:GAUGE:600:U:U \ DS:loopIN:GAUGE:600:U:U \ DS:loopRTN:GAUGE:600:U:U \ DS:headerIN:GAUGE:600:U:U \ DS:headerRTN:GAUGE:600:U:U \ DS:basementIN:GAUGE:600:U:U \ DS:basementRTN:GAUGE:600:U:U \ DS:mechanicalRM:GAUGE:600:U:U \ RRA:AVERAGE:0.5:1:12 \ RRA:AVERAGE:0.5:1:288 \ RRA:AVERAGE:0.5:12:168 \ RRA:AVERAGE:0.5:12:720 \ RRA:AVERAGE:0.5:288:365 In fact having rrdtool working is quite complicated. It's easy if you use a frontend for it. Cacti is an excellent frontend that is very easy to use. I found Marc Merlin's writeups very useful when I was setting up my house temperature monitoring: http://marc.merlins.org/perso/linuxha/post_2010-08-06_Temperature_-moisture_-humidity_-and-UV-monitoring-and-graphing-with-1wire-devices_-owfs_-and-cacti.html Cheers, Eloy Paris.- -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Deep Blue sensor
Hi Daniel, On Mon, Mar 02, 2015 at 07:57:56PM -0400, Daniel MacKay wrote: Hey guys, is this 1-wire? The labelling suggests it is. if so - it's a very good deal. http://www.dx.com/p/temperature-humidity-sensor-dht11-module-for-arduino-deep-blue-works-with-official-arduino-board-288612?utm_source=dxutm_medium=edmutm_campaign=en20150302superbrain No, this is not Dallas 1-Wire -- a single data line is used to talk to the sensor, similar to DS 1-Wire devices, but the protocol is completely different. This is definitely not compatible with DS 1-Wire. It's a good sensor, though -- I have a couple in operation and they have worked well. There's Arduino libraries out there that allow you to talk to this sensor very easily. Cheers, Eloy Paris.- -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Read time slots and instantiation
Hi Michael, On Tue, Oct 07, 2014 at 12:35:44AM +0200, Michael Markstaller wrote: P.S.: I have a bunch of Arduinos but even more, AVRs and coded a slave and an low-level 1w-analyzer for/with avr.. Is your 1-Wire slave code publicly available somewhere? I wrote my own implementation (also for ATMega), which I have been using with no issues for about two years, but I'm always curious to see how others have tackled the same problem. Cheers, Eloy Paris.- -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Everything is (apparently) running but nothing at /mnt/1-wire
The owfs binary should also be run with a mount point of /mnt/1-wire so 1-wire devices can show up at that directory. It doesn't seem like owfs is running. Cheers, Eloy Paris.- On May 7, 2014 12:44:11 AM GMT+04:00, Roberto Spadim robe...@spadim.com.br wrote: more than one server is opening the usb port you should run the owserver, and others servers should connect to it 2014-05-06 17:17 GMT-03:00 Chris Green c...@isbd.net: I'm running owfs on a Beaglebone Black (running Ubuntu 13.10), it was working OK previously but now, after some reboots, there's nothing appearing at /mnt/1-wire. The processes are running:- chris@beaglebone$ ps -ef | grep ow root 886 1 0 May04 ?00:00:18 /usr/bin/owftpd -c /etc/owfs.conf --pid-file /var/run/owfs/owftpd.pid root 1008 1 0 May04 ?00:00:00 /usr/bin/owhttpd -c /etc/owfs.conf --pid-file /var/run/owfs/owhttpd.pid root 1050 1 0 May04 ?00:00:00 /usr/bin/owserver -c /etc/owfs.conf --pid-file /var/run/owfs/owserver.pid My owfs.conf file has only the following (apart from comments):- ! server: server = localhost:4304 server: usb = all http: port = 2121 ftp: port = 2120 server: port = localhost:4304 So what's going on (apart from very little!)? -- Chris Green -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers -- Eloy Paris -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] pseudo-bus serial bridge
Colin, Stuart, On 02/10/2014 10:30 PM, Colin Reese wrote: Anybody chime in with status on this? I think this will be where I go. On 2/10/2014 06:47, Stuart Poulton wrote: To be fair, I would have thought this was the ideal application for http://owfs.org/index.php?page=external-sensor-design Not sure where Paul is with support etc, if it even exits. I believe that what you are trying to achieve (small wireless sensors that are cheap, can run on batteries for month or years, and can potentially be integrated with OWFS) is the holy grail of data collection in a small environment like our homes. We all have done something similar with 1-Wire in one way or the other but 1-Wire uses wires so sometimes we are limited in where we can place our 1-Wire sensors. I also have been looking at ways to solve this. I've done some work using ATmega 328 and RFM12B wireless transceivers and think that it is a good and very cheap option (for new developments I'd look at the RFM69). I think Xbee is too expensive, especially when considering that the RFM12B is a very viable option. Raspberry Pi and anything running Linux is overkill and too power hungry for this application, in my opinion. I suggest you look at two options you can buy off the shelf: 1. Moteino 2. JeeNodes These two have the RFM12B integrated with the ATmega on a small board. That solves the hardware problem. The issue then becomes a software issue... I do not think anyone has been successful in integrating a non-1-Wire device with OWFS via owexternal. I can tell you that I tried but didn't find that it was ready for prime time. I just couldn't get it work and moved on to another way to build a wireless sensor network (using xPL, which shows some promise, but I still think it would have been nice to be able to integrate it with OWFS). Anyway, here's a discussion from July of 2013 when I was trying to get owexternal work: http://owfs-developers.1086194.n5.nabble.com/External-sensor-support-td9779.html As you can see from the discussion, at the time I probably was the first person to give this a try, and the discussion didn't end in anything. Please keep us posted on this as it's a very important topic. Cheers, Eloy Paris.- On 10/02/14 14:36, Colin Reese wrote: Silly me; atmega328 has i2c. I can use the 2483, but need to get data out. Per the earlier conversation, can I mount the xbee serial /dev/AMA0 as a bus if running in transparent? I believe this us possible, but limited to one bus. This may have been previously discussed, but an API-mode master to expose all remote buses would be great. I guess you'd need some glue to read all remote xbees and respond to owfs with something it would interpret as the multiple buses. On Feb 10, 2014, at 5:56, Vajk Fekete vaj...@gmail.com mailto:vaj...@gmail.com wrote: You do need some 1wire host for the AVR too. If not, that means you plan for bit banging and a passive interface. Same is possible with openwrt and a cheap router. An other option is the arduino YUN, which is an arduino and a wifi module. But the wifi module in there is a complete cheap home router with the ethernet ports stripped, and runs openwrt just like the router. And this is reflected in the price too. To me it sounds weird to have a wifi module that has at least 32Mbytes RAM, 8Mbytes flash, a ~300Mhz CPU, and use it as a communication subsystem for a uController that is running 16Mhz and maybe has 32Kbyte flash and 2500bytes RAM. Vajk On Mon, Feb 10, 2014 at 2:40 PM, Colin Law clan...@gmail.com mailto:clan...@gmail.com wrote: On 10 February 2014 13:36, Vajk Fekete vaj...@gmail.com mailto:vaj...@gmail.com wrote: There are several options - real usb 1wire host - pretty expensive - usb serial+serial host - use the internally available serial port (the console of the machine, Options 2 and 3 are not going to be significantly cheaper than the first are they? Colin like with rpi) and use a serial 1wire host - use some available gpio lines and do bit-banging I went for the first because this is only a hobby for me, and already had three 9490s on hand. Vajk On Mon, Feb 10, 2014 at 1:20 PM, Colin Law clan...@gmail.com mailto:clan...@gmail.com wrote: On 10 February 2014 12:01, Vajk Fekete vaj...@gmail.com mailto:vaj...@gmail.com wrote: I do not see what is the reason against the linux box. I do not think you could get cheaper with an avr and Xbee than a tplink 703n, http://www.ebay.com/bhp/tp-link-tl-wr703n I presume one would need a usb/1wire adaptor with that. Colin Vajk On Sun, Feb 9, 2014 at 10:48 PM, Colin Reese colin.re...@gmail.com
Re: [Owfs-developers] pseudo-bus serial bridge
Hi Colin, On 02/11/2014 01:14 PM, Colin Reese wrote: Crap. This thing runs on SPI? I've got all my SPI allocated. Yes, the RFM12B (and the new RFM69) has an SPI interface. SPI allows for multiple slaves; you do need an independent SS signal from the master for each slave device, though. Cheers, Eloy Paris.- On Tue, Feb 11, 2014 at 4:21 AM, Eloy Paris pe...@chapus.net mailto:pe...@chapus.net wrote: Colin, Stuart, On 02/10/2014 10:30 PM, Colin Reese wrote: Anybody chime in with status on this? I think this will be where I go. On 2/10/2014 06:47, Stuart Poulton wrote: To be fair, I would have thought this was the ideal application for http://owfs.org/index.php?page=external-sensor-design Not sure where Paul is with support etc, if it even exits. I believe that what you are trying to achieve (small wireless sensors that are cheap, can run on batteries for month or years, and can potentially be integrated with OWFS) is the holy grail of data collection in a small environment like our homes. We all have done something similar with 1-Wire in one way or the other but 1-Wire uses wires so sometimes we are limited in where we can place our 1-Wire sensors. I also have been looking at ways to solve this. I've done some work using ATmega 328 and RFM12B wireless transceivers and think that it is a good and very cheap option (for new developments I'd look at the RFM69). I think Xbee is too expensive, especially when considering that the RFM12B is a very viable option. Raspberry Pi and anything running Linux is overkill and too power hungry for this application, in my opinion. I suggest you look at two options you can buy off the shelf: 1. Moteino 2. JeeNodes These two have the RFM12B integrated with the ATmega on a small board. That solves the hardware problem. The issue then becomes a software issue... I do not think anyone has been successful in integrating a non-1-Wire device with OWFS via owexternal. I can tell you that I tried but didn't find that it was ready for prime time. I just couldn't get it work and moved on to another way to build a wireless sensor network (using xPL, which shows some promise, but I still think it would have been nice to be able to integrate it with OWFS). Anyway, here's a discussion from July of 2013 when I was trying to get owexternal work: http://owfs-developers.1086194.n5.nabble.com/External-sensor-support-td9779.html As you can see from the discussion, at the time I probably was the first person to give this a try, and the discussion didn't end in anything. Please keep us posted on this as it's a very important topic. Cheers, Eloy Paris.- -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] pseudo-bus serial bridge
On 02/11/2014 01:03 PM, Colin Reese wrote: These look great. How are multiple Moteinos resolved? How are remote IO addressed on the ATMega? Is there a developed python/RPi functional library? I honestly don't know. I think that there would be some amount of code that needs to be written on the RPi side. You'd have to have a gateway (USB to RFM12B) connected to the RPi and then run some code to talk to the wireless sensor. Basically, I think you'd have to come up with your own protocol for remote I/O. You can ask for suggestions and ideas on the lowpowerlab.com forums; Felix (the developer behind the Moteino) is very knowledgeable and might be able to provide some guidance. Also, there are a few projects he's done that are mentioned on his blog. Some of these might provide an idea of how to approach the problem. Cheers, Eloy Paris.- -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] pseudo-bus serial bridge
On 02/11/2014 02:10 PM, Colin Reese wrote: Yes, but I don't have to talk to the RFM. I can talk to the ATMega. I am not following; what do you mean by I don't have to talk to the RFM? If you want to send data wirelessly then someone has to talk to the RFM. That'd be the microcontroller. So you (the RPi) talks to the uC and the uC talks to the RFM. On the other side (remote sensor side) the uC only talks to the RFM. I guess I'm missing something... Cheers, Eloy Paris.- On Tue, Feb 11, 2014 at 11:05 AM, Eloy Paris pe...@chapus.net mailto:pe...@chapus.net wrote: Hi Colin, On 02/11/2014 01:14 PM, Colin Reese wrote: Crap. This thing runs on SPI? I've got all my SPI allocated. Yes, the RFM12B (and the new RFM69) has an SPI interface. SPI allows for multiple slaves; you do need an independent SS signal from the master for each slave device, though. Cheers, Eloy Paris.- On Tue, Feb 11, 2014 at 4:21 AM, Eloy Paris pe...@chapus.net mailto:pe...@chapus.net mailto:pe...@chapus.net mailto:pe...@chapus.net wrote: Colin, Stuart, On 02/10/2014 10:30 PM, Colin Reese wrote: Anybody chime in with status on this? I think this will be where I go. On 2/10/2014 06:47, Stuart Poulton wrote: To be fair, I would have thought this was the ideal application for http://owfs.org/index.php?page=external-sensor-design Not sure where Paul is with support etc, if it even exits. I believe that what you are trying to achieve (small wireless sensors that are cheap, can run on batteries for month or years, and can potentially be integrated with OWFS) is the holy grail of data collection in a small environment like our homes. We all have done something similar with 1-Wire in one way or the other but 1-Wire uses wires so sometimes we are limited in where we can place our 1-Wire sensors. I also have been looking at ways to solve this. I've done some work using ATmega 328 and RFM12B wireless transceivers and think that it is a good and very cheap option (for new developments I'd look at the RFM69). I think Xbee is too expensive, especially when considering that the RFM12B is a very viable option. Raspberry Pi and anything running Linux is overkill and too power hungry for this application, in my opinion. I suggest you look at two options you can buy off the shelf: 1. Moteino 2. JeeNodes These two have the RFM12B integrated with the ATmega on a small board. That solves the hardware problem. The issue then becomes a software issue... I do not think anyone has been successful in integrating a non-1-Wire device with OWFS via owexternal. I can tell you that I tried but didn't find that it was ready for prime time. I just couldn't get it work and moved on to another way to build a wireless sensor network (using xPL, which shows some promise, but I still think it would have been nice to be able to integrate it with OWFS). Anyway, here's a discussion from July of 2013 when I was trying to get owexternal work: http://owfs-developers.1086194.n5.nabble.com/External-sensor-support-td9779.html As you can see from the discussion, at the time I probably was the first person to give this a try, and the discussion didn't end in anything. Please keep us posted on this as it's a very important topic. Cheers, Eloy Paris.- -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] pseudo-bus serial bridge
On 02/11/2014 02:29 PM, Colin Reese wrote: That sounds right. My complaint was that I have all my SPI on the Pi occupied, although in a pinch I could use another GPIO as an additional chip select. So what I have: Sensor(s) -- (I2C, GPIO, etc) -- uC (ATMega) -- SPI -- RFM -- 433 -- RFM -- SPI -- uC (ATMega) -- UART -- Pi Oh, I see. On the RPi side, you don't have to talk to the RFM12B directly from the RPi using SPI -- you can use serial to talk to the uC, or you can get (or build) a device that has an USB port, and then connect the device (the gateway to 433 MHz) to the RPi using USB and talk to it through some serial communication protocol that you come up with. Felix apparently has the Moteino-USB, which comes with an USB interface. Cheers, Eloy Paris.- I'll start off with the bitbanging and see if I can't find a way to get a DS2483 and the AVR talking. On Tue, Feb 11, 2014 at 11:15 AM, Eloy Paris pe...@chapus.net mailto:pe...@chapus.net wrote: On 02/11/2014 02:10 PM, Colin Reese wrote: Yes, but I don't have to talk to the RFM. I can talk to the ATMega. I am not following; what do you mean by I don't have to talk to the RFM? If you want to send data wirelessly then someone has to talk to the RFM. That'd be the microcontroller. So you (the RPi) talks to the uC and the uC talks to the RFM. On the other side (remote sensor side) the uC only talks to the RFM. I guess I'm missing something... Cheers, Eloy Paris.- -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] pseudo-bus serial bridge
Hi Colin, On 02/11/2014 02:47 PM, Colin Reese wrote: I believe the USB is really just a combination of the FTDI/USB adapter and the Moteino. The FTDI bridge is for programming, not for runtime. As far as I know, that is. The FTDI bridge is used for both programming and runtime serial port. It should be just like an Arduino on that regard. Cheers, Eloy Paris.- On Tue, Feb 11, 2014 at 11:39 AM, Eloy Paris pe...@chapus.net mailto:pe...@chapus.net wrote: On 02/11/2014 02:29 PM, Colin Reese wrote: That sounds right. My complaint was that I have all my SPI on the Pi occupied, although in a pinch I could use another GPIO as an additional chip select. So what I have: Sensor(s) -- (I2C, GPIO, etc) -- uC (ATMega) -- SPI -- RFM -- 433 -- RFM -- SPI -- uC (ATMega) -- UART -- Pi Oh, I see. On the RPi side, you don't have to talk to the RFM12B directly from the RPi using SPI -- you can use serial to talk to the uC, or you can get (or build) a device that has an USB port, and then connect the device (the gateway to 433 MHz) to the RPi using USB and talk to it through some serial communication protocol that you come up with. Felix apparently has the Moteino-USB, which comes with an USB interface. Cheers, Eloy Paris.- I'll start off with the bitbanging and see if I can't find a way to get a DS2483 and the AVR talking. On Tue, Feb 11, 2014 at 11:15 AM, Eloy Paris pe...@chapus.net mailto:pe...@chapus.net mailto:pe...@chapus.net mailto:pe...@chapus.net wrote: On 02/11/2014 02:10 PM, Colin Reese wrote: Yes, but I don't have to talk to the RFM. I can talk to the ATMega. I am not following; what do you mean by I don't have to talk to the RFM? If you want to send data wirelessly then someone has to talk to the RFM. That'd be the microcontroller. So you (the RPi) talks to the uC and the uC talks to the RFM. On the other side (remote sensor side) the uC only talks to the RFM. I guess I'm missing something... Cheers, Eloy Paris.- -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net mailto:Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] pseudo-bus serial bridge
On 02/11/2014 02:58 PM, Colin Reese wrote: I have very little Arduino experience, but I was under the impression that the serial console over the FTDI was typically just used for debug. What's the difference between sending a debug message to the PC or RPi through the serial port/USB connection and sending a temperature value received from a remote wireless sensor? It's all about how the data is interpreted on the PC side, right? ;-) The Arduino/Moteino/uC will also be able to read data sent to it by the RPi through the USB connection. Cheers, Eloy Paris.- On Tue, Feb 11, 2014 at 11:54 AM, Eloy Paris pe...@chapus.net mailto:pe...@chapus.net wrote: Hi Colin, On 02/11/2014 02:47 PM, Colin Reese wrote: I believe the USB is really just a combination of the FTDI/USB adapter and the Moteino. The FTDI bridge is for programming, not for runtime. As far as I know, that is. The FTDI bridge is used for both programming and runtime serial port. It should be just like an Arduino on that regard. Cheers, Eloy Paris.- -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] pseudo-bus serial bridge
You connect the Moteino/Arduino to the RPi using USB. Your code running on the RPi opens /dev/ttyUSB0 (or whatever it shows up as) and talks to the uC on the Moteino/Arduino like if it were using a true serial port (/dev/ttyUSB0 behaves like a true serial port for all intents and purposes). You don't have to use /dev/ttyAMA0 (the Broadcom UART) to talk to the Moteino/Arduino. In fact, you cannot because the Rx and Tx pins of the uC are connected to the FTDI chip, so USB is the only option to talk to an Arduino via serial (unless the Arduino is one of the recent generations that supports more than one serial port), in which you don't have to use USB and can use the RPi serial port directly. On 02/11/2014 03:19 PM, Colin Reese wrote: Yes, but we'd connect directly to the serial connection on the Pi after disabling the console, not go through USB. On Tue, Feb 11, 2014 at 12:11 PM, Eloy Paris pe...@chapus.net mailto:pe...@chapus.net wrote: On 02/11/2014 02:58 PM, Colin Reese wrote: I have very little Arduino experience, but I was under the impression that the serial console over the FTDI was typically just used for debug. What's the difference between sending a debug message to the PC or RPi through the serial port/USB connection and sending a temperature value received from a remote wireless sensor? It's all about how the data is interpreted on the PC side, right? ;-) The Arduino/Moteino/uC will also be able to read data sent to it by the RPi through the USB connection. Cheers, Eloy Paris.- -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
[Owfs-developers] External sensor support
Hi Paul, Do you know if the external sensor support is working? I am trying to get it to work but I get this when I try to list the contents of the directory for an external sensor, or when I try to read the contents of one of the default properties: $ ls -l /owfs2/front_greenlawn/ ls: cannot access /owfs2/front_greenlawn/family: No such file or directory ls: cannot access /owfs2/front_greenlawn/temperature: No such file or directory ls: cannot access /owfs2/front_greenlawn/type: No such file or directory total 0 d? ? ? ? ?? family d? ? ? ? ?? temperature d? ? ? ? ?? type $ cat /owfs2/front_greenlawn/type cat: /owfs2/front_greenlawn/type: No such file or directory My configuration file: -- external # SCRIPT: property, family, type, length, persistance, [read func], [write func], [property data], [extra] SCRIPT: temperature, rtd_family, t, 1, v, /tmp/rtd_read.pl, , , # SENSOR: unique name, family, [description], [data] SENSOR: front_greenlawn, rtd_family, Front GreenLawn Centurion, /dev/ttyUSB0 -- Debug output from owserver is below. Is there anything else I should be doing to get this to work? I've read http://owfs.org/index.php?page=external-sensor-design and I'm wondering what I might be missing, or what the status of this code is. Cheers, Eloy Paris.- --- Debug output from owserver: DEBUG: ow_tcp_read.c:(64) attempt 24 bytes Time: 10.00 seconds DEBUG: ow_tcp_read.c:(114) read: 24 - 0 = 24 DEBUG: from_client.c:(67) FromClient payload=17 size=0 type=6 sg=0x104 offset=0 DEBUG: from_client.c:(75) FromClient (no servermessage) payload=17 size=0 type=6 controlflags=0x104 offset=0 DEBUG: ow_tcp_read.c:(64) attempt 17 bytes Time: 10.00 seconds DEBUG: ow_tcp_read.c:(114) read: 17 - 0 = 17 DEBUG: handler.c:(73) Persistence requested DEBUG: handler.c:(153) START handler /front_greenlawn CALL: data.c:(104) DataHandler: parse path=/front_greenlawn DEBUG: ow_parseobject.c:(164) /front_greenlawn CALL: ow_parsename.c:(98) path=[/front_greenlawn] CALL: data.c:(132) Presence message for /front_greenlawn DEBUG: ow_parsename.c:(62) /front_greenlawn DEBUG: data.c:(194) DataHandler: FS_ParsedName_destroy done DEBUG: data.c:(208) DataHandler: cm.ret=0 DEBUG: to_client.c:(67) payload=8 size=0, ret=0, sg=0x104 offset=0 DEBUG: data.c:(227) Finished with client request DEBUG: handler.c:(132) OWSERVER tcp connection persistence -- reusing connection now. DEBUG: ow_tcp_read.c:(64) attempt 24 bytes Time: 10.00 seconds DEBUG: ow_tcp_read.c:(114) read: 24 - 24 = 0 DEBUG: handler.c:(135) OWSERVER handler done DEBUG: ow_net_server.c:(238) Normal exit. DEBUG: ow_tcp_read.c:(64) attempt 24 bytes Time: 10.00 seconds DEBUG: ow_tcp_read.c:(114) read: 24 - 0 = 24 DEBUG: from_client.c:(67) FromClient payload=17 size=0 type=4 sg=0x104 offset=0 DEBUG: from_client.c:(75) FromClient (no servermessage) payload=17 size=0 type=4 controlflags=0x104 offset=0 DEBUG: ow_tcp_read.c:(64) attempt 17 bytes Time: 10.00 seconds DEBUG: ow_tcp_read.c:(114) read: 17 - 0 = 17 DEBUG: handler.c:(73) Persistence requested DEBUG: handler.c:(153) START handler /front_greenlawn CALL: data.c:(104) DataHandler: parse path=/front_greenlawn DEBUG: ow_parseobject.c:(164) /front_greenlawn CALL: ow_parsename.c:(98) path=[/front_greenlawn] CALL: data.c:(160) Directory message (one at a time) CALL: dir.c:(74) DirHandler: pn-path=/front_greenlawn DEBUG: dir.c:(79) OWSERVER SpecifiedBus=0 path=/front_greenlawn DEBUG: ow_dir.c:(76) path=/front_greenlawn CALL: ow_dir.c:(100) path=/front_greenlawn CALL: ow_parsename.c:(98) path=[/front_greenlawn/family] DEBUG: dir.c:(57) owserver Calling dir=/front_greenlawn/family DEBUG: to_client.c:(67) payload=24 size=23, ret=0, sg=0x104 offset=0 DEBUG: ow_parsename.c:(62) /front_greenlawn/family CALL: ow_parsename.c:(98) path=[/front_greenlawn/temperature] DEBUG: dir.c:(57) owserver Calling dir=/front_greenlawn/temperature DEBUG: to_client.c:(67) payload=29 size=28, ret=0, sg=0x104 offset=0 DEBUG: ow_parsename.c:(62) /front_greenlawn/temperature CALL: ow_parsename.c:(98) path=[/front_greenlawn/type] DEBUG: dir.c:(57) owserver Calling dir=/front_greenlawn/type DEBUG: to_client.c:(67) payload=22 size=21, ret=0, sg=0x104 offset=0 DEBUG: ow_parsename.c:(62) /front_greenlawn/type DEBUG: ow_dir.c:(195) ret=0 DEBUG: ow_parsename.c:(62) /front_greenlawn DEBUG: data.c:(194) DataHandler: FS_ParsedName_destroy done DEBUG: data.c:(208) DataHandler: cm.ret=0 DEBUG: to_client.c:(67) payload=0 size=0, ret=0, sg=0x104 offset=0 DEBUG: data.c:(227) Finished with client request DEBUG: handler.c:(132) OWSERVER tcp connection persistence -- reusing connection now
Re: [Owfs-developers] External sensor support
On 07/06/2013 08:34 AM, Paul Alfille wrote: Great! Finally a real user to test this feature. Oh, I've had big plans for this feature for a while, but it's taken me a while to get to the point with my custom sensors where I can actually start trying to get the feature to work. I'm at that point, and think that this feature could make it very easy to integrate new types of sensors (like wireless sensors) into an existing 1-Wire network. Let me look at your debugging info a little more. Great; thanks! In case it helps, below is the debugging output from both owserver and owfs for two cases. I am starting owserver like this: owserver --debug -c /etc/owfs/owfs.conf --timeout_volatile 300 --error_print 0 --error_level 7 --nozero -p 4305 And owfs like this: owfs --debug --allow_other -C -s localhost:4305 /owfs2 Cheers, Eloy Paris.- - Case #1: ls -l /owfs2/front_greenlawn/ ls: cannot access /owfs2/front_greenlawn/family: No such file or directory ls: cannot access /owfs2/front_greenlawn/temperature: No such file or directory ls: cannot access /owfs2/front_greenlawn/type: No such file or directory total 0 d? ? ? ? ?? family d? ? ? ? ?? temperature d? ? ? ? ?? type owserver: DEBUG: ow_tcp_read.c:(64) attempt 24 bytes Time: 10.00 seconds DEBUG: ow_tcp_read.c:(114) read: 24 - 0 = 24 DEBUG: from_client.c:(67) FromClient payload=17 size=0 type=6 sg=0x104 offset=0 DEBUG: from_client.c:(75) FromClient (no servermessage) payload=17 size=0 type=6 controlflags=0x104 offset=0 DEBUG: ow_tcp_read.c:(64) attempt 17 bytes Time: 10.00 seconds DEBUG: ow_tcp_read.c:(114) read: 17 - 0 = 17 DEBUG: handler.c:(73) Persistence requested DEBUG: handler.c:(153) START handler /front_greenlawn CALL: data.c:(104) DataHandler: parse path=/front_greenlawn DEBUG: ow_parseobject.c:(164) /front_greenlawn CALL: ow_parsename.c:(98) path=[/front_greenlawn] CALL: data.c:(132) Presence message for /front_greenlawn DEBUG: ow_parsename.c:(62) /front_greenlawn DEBUG: data.c:(194) DataHandler: FS_ParsedName_destroy done DEBUG: data.c:(208) DataHandler: cm.ret=0 DEBUG: to_client.c:(67) payload=8 size=0, ret=0, sg=0x104 offset=0 DEBUG: data.c:(227) Finished with client request DEBUG: handler.c:(132) OWSERVER tcp connection persistence -- reusing connection now. DEBUG: ow_tcp_read.c:(64) attempt 24 bytes Time: 10.00 seconds DEBUG: ow_tcp_read.c:(114) read: 24 - 24 = 0 DEBUG: handler.c:(135) OWSERVER handler done DEBUG: ow_net_server.c:(238) Normal exit. DEBUG: ow_tcp_read.c:(64) attempt 24 bytes Time: 10.00 seconds DEBUG: ow_tcp_read.c:(114) read: 24 - 0 = 24 DEBUG: from_client.c:(67) FromClient payload=17 size=0 type=4 sg=0x104 offset=0 DEBUG: from_client.c:(75) FromClient (no servermessage) payload=17 size=0 type=4 controlflags=0x104 offset=0 DEBUG: ow_tcp_read.c:(64) attempt 17 bytes Time: 10.00 seconds DEBUG: ow_tcp_read.c:(114) read: 17 - 0 = 17 DEBUG: handler.c:(73) Persistence requested DEBUG: handler.c:(153) START handler /front_greenlawn CALL: data.c:(104) DataHandler: parse path=/front_greenlawn DEBUG: ow_parseobject.c:(164) /front_greenlawn CALL: ow_parsename.c:(98) path=[/front_greenlawn] CALL: data.c:(160) Directory message (one at a time) CALL: dir.c:(74) DirHandler: pn-path=/front_greenlawn DEBUG: dir.c:(79) OWSERVER SpecifiedBus=0 path=/front_greenlawn DEBUG: ow_dir.c:(76) path=/front_greenlawn CALL: ow_dir.c:(100) path=/front_greenlawn CALL: ow_parsename.c:(98) path=[/front_greenlawn/family] DEBUG: dir.c:(57) owserver Calling dir=/front_greenlawn/family DEBUG: to_client.c:(67) payload=24 size=23, ret=0, sg=0x104 offset=0 DEBUG: ow_parsename.c:(62) /front_greenlawn/family CALL: ow_parsename.c:(98) path=[/front_greenlawn/temperature] DEBUG: dir.c:(57) owserver Calling dir=/front_greenlawn/temperature DEBUG: to_client.c:(67) payload=29 size=28, ret=0, sg=0x104 offset=0 DEBUG: ow_parsename.c:(62) /front_greenlawn/temperature CALL: ow_parsename.c:(98) path=[/front_greenlawn/type] DEBUG: dir.c:(57) owserver Calling dir=/front_greenlawn/type DEBUG: to_client.c:(67) payload=22 size=21, ret=0, sg=0x104 offset=0 DEBUG: ow_parsename.c:(62) /front_greenlawn/type DEBUG: ow_dir.c:(195) ret=0 DEBUG: ow_parsename.c:(62) /front_greenlawn DEBUG: data.c:(194) DataHandler: FS_ParsedName_destroy done DEBUG: data.c:(208) DataHandler: cm.ret=0 DEBUG: to_client.c:(67) payload=0 size=0, ret=0, sg=0x104 offset=0 DEBUG: data.c:(227) Finished with client request DEBUG: handler.c:(132) OWSERVER tcp connection persistence -- reusing connection now. DEBUG: ow_tcp_read.c:(64) attempt 24 bytes Time: 10.00 seconds DEBUG: ow_tcp_read.c:(114) read: 24 - 24 = 0 DEBUG: handler.c:(135) OWSERVER handler done DEBUG
Re: [Owfs-developers] External sensor support
I forgot to include debugging output from owserver's startup. There's a Duplicate family entry: rtd_family that looks suspicious. Cheers, Eloy Paris.- - DEBUG MODE libow version: 2.9p0 DEBUG: ow_opt.c:(284) Configuration file (/etc/owfs/owfs.conf:1) Program=, Option=TESTER, Value=28,3E DEBUG: ow_opt.c:(329) Configuration file (/etc/owfs/owfs.conf:1) Option TESTER recognized as TESTER. Value=28,3E DEBUG: ow_opt.c:(284) Configuration file (/etc/owfs/owfs.conf:2) Program=, Option=, Value= DEBUG: ow_opt.c:(284) Configuration file (/etc/owfs/owfs.conf:3) Program=, Option=, Value= DEBUG: ow_opt.c:(284) Configuration file (/etc/owfs/owfs.conf:4) Program=, Option=external, Value= DEBUG: ow_opt.c:(329) Configuration file (/etc/owfs/owfs.conf:4) Option external recognized as external. Value= DEBUG: ow_opt.c:(284) Configuration file (/etc/owfs/owfs.conf:5) Program=, Option=, Value= DEBUG: ow_opt.c:(284) Configuration file (/etc/owfs/owfs.conf:6) Program=, Option=, Value= DEBUG: ow_opt.c:(439) SCRIPT entry found temperature, rtd_family, t, 1, v, /tmp/rtd_read.pl, , , DEBUG: ow_parse_external.c:(626) New family entry: rtd_family DEBUG: ow_parse_external.c:(643) New property entry: temperature,rtd_family,/tmp/rtd_read.pl,,, DEBUG: ow_opt.c:(284) Configuration file (/etc/owfs/owfs.conf:7) Program=, Option=, Value= DEBUG: ow_opt.c:(284) Configuration file (/etc/owfs/owfs.conf:8) Program=, Option=, Value= DEBUG: ow_opt.c:(284) Configuration file (/etc/owfs/owfs.conf:9) Program=, Option=, Value= DEBUG: ow_opt.c:(433) SENSOR entry found front_greenlawn, rtd_family, Front GreenLawn Centurion, /dev/ttyUSB0 DEBUG: ow_parse_external.c:(622) Duplicate family entry: rtd_family DEBUG: ow_parse_external.c:(608) New sensor entry: front_greenlawn,rtd_family,Front GreenLawn Centurion,/dev/ttyUSB0 DEBUG: ow_parse_external.c:(643) New property entry: family,rtd_family,just_print_data,,rtd_family, DEBUG: ow_parse_external.c:(643) New property entry: type,rtd_family,just_print_data,,external, DEBUG: ow_opt.c:(284) Configuration file (/etc/owfs/owfs.conf:10) Program=, Option=, Value= DEBUG: ow_opt.c:(284) Configuration file (/etc/owfs/owfs.conf:11) Program=, Option=, Value= DEBUG: ow_daemon.c:(166) main thread id = 3075184320 CALL: ow_parsename.c:(98) path=[] DEBUG: owlib.c:(81) Globals temp limits 0C 100C (for simulated adapters) CONNECT: ow_fake.c:(175) Setting up tester Bus Master (0) CONNECT: ow_zero.c:(145) Zeroconf and/or Multithreading are not enabled DEBUG: ow_tcp_read.c:(64) attempt 24 bytes Time: 10.00 seconds -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
[Owfs-developers] Apple's Magsafe connector
I was not aware, but Apple's Magsafe connector has a 1-Wire device in it. I thought this was pretty interesting so wanted to share: http://www.righto.com/2013/06/teardown-and-exploration-of-magsafe.html Cheers, Eloy Paris.- -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] --nozero?
--nozero disables the Zeroconf/Bonjour functionality. http://owfs.org/index.php?page=bonjour-zeroconf Cheers, Eloy Paris.- On 04/26/2013 07:51 PM, Don Veino wrote: What does --nozero option do? Does it prevent recording of bad readings? I can't find it in the man pages on owfs.org http://owfs.org but see it used in an example at http://marc.merlins.org/perso/linuxha/post_2010-08-06_Temperature_-moisture_-humidity_-and-UV-monitoring-and-graphing-with-1wire-devices_-owfs_-and-cacti.html -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] GPIO Temperature Sensing
Hi Peter, On 03/04/2013 03:18 PM, Peter Hollenbeck wrote: There was a recent email containing a link to a GPIO temp sensing solution using a DS1820. I have searched my owfs archive but cannot find it. I would appreciate a link to it. Don't know if this is the one you saw, but Atmel Application Note 318 describes how to use a GPIO pin to talk to a DS18S20 sensor: http://www.atmel.com/images/doc2579.pdf You can download sample code that goes with it. I've used it on an ATmega and it works very well. It's C, so it can be ported easily to other architectures. Cheers, Eloy Paris.- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Microcontroller emulating a Dallas One-wire device?
There's https://github.com/smurfix/owslave. I don't know if there's a newer version, though. AVR-based. Some people here might even have used it. There are commercial versions as well. The BAE device is one that is supported by OWFS. Cheers, Eloy Paris.- On 02/25/2013 10:32 AM, Håkan Elmqvist wrote: Is there anyone aware of any software written for the emulation of a Dallas One-wire device on a microcontroller i.e. a PIC emulating a DS2406? It would be nice to be able to incorporate powerful microcontrollers in a one-wire network. Thanks in advance Håkan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Microcontroller emulating a Dallas One-wire device?
On 02/25/2013 11:39 AM, Patryk wrote: I just checked google translate http://translate.google.com/translate?sl=detl=enjs=nprev=_thl=plie=UTF-8eotf=1u=http%3A%2F%2Fwww.tm3d.de%2Findex.php%2F1-wire-device-mit-avr And it translates reasonably well. Indeed; I am reading it now. Thanks for setting it up and sending the link ;-) Cheers, Eloy Paris.- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] #pragma inside function
Hi Tomasz, I believe Paul said in a recent message that he's fixed this. Googling... Yes, right here: http://www.mail-archive.com/owfs-developers@lists.sourceforge.net/msg09417.html Cheers, Eloy Paris.- On 01/25/2013 10:22 AM, Tomasz Nieszawski wrote: Hello I have some problems with compiling the latest version p21 I get numerous errors about the use of #pragma I suspect it's to_client.c: In function ‘ToClient’: to_client.c:51:9: error: #pragma GCC diagnostic not allowed inside functions to_client.c:52:9: error: #pragma GCC diagnostic not allowed inside functions to_client.c:56:3: warning: cast discards qualifiers from pointer target type to_client.c:58:9: error: #pragma GCC diagnostic not allowed inside functions If I comment the #pragma lines it compiles. My gcc version is gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=i386-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/i386-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/i386-linux-gnu --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Fwd: Re: owfs on RasPi
Hi Mick, On 12/20/2012 06:29 PM, Mick Sulley wrote: That throws an error for me, unless I have the syntax wrong. I get - control@pi-a ~/solar $ sudo /opt/owfs/bin/owserver -p 4304 --i2c=/dev/i2c-0:ALL --nonzero /opt/owfs/bin/owserver: unrecognized option '--nonzero' Any ideas? I think that should be --nozero. Cheers, Eloy Paris.- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Fwd: Re: owfs on RasPi
Hi Mick, On 12/20/2012 08:04 PM, Mick Sulley wrote: Yes that's fixed it. I also have to add --nozero to get owhttpd to work as well. What does it do? My guess is that it disables the Zeroconf/Bonjour functionality. http://owfs.org/index.php?page=bonjour-zeroconf Cheers, Eloy Paris.- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Own 1-Wire device
Hi Paul, On 11/23/2012 11:05 AM, Paul Alfille wrote: [...] If you want support to be part of owfs, then it has to be relevant to more users. In general I like to add support for any commercial project, and any project that is easily available or buildable (descriptions, code, schematics) that fit's in with the 1-wire system. (i.e. open-source hardware). Do you also require the firmware to be open source? For instance, if the hardware is open source, well documented, etc., but the firmware itself is available for download for free but without source code, is that acceptable? Cheers, Eloy Paris.- On Fri, Nov 23, 2012 at 6:46 AM, Schinken schin...@hackerspace-bamberg.de mailto:schin...@hackerspace-bamberg.de wrote: Hi, is it possible to specify an own 1-Wire device in owfs? We used an electronic thermostat with an open firmware OpenHR20 and implemented 1-Wire to an unused processor pin. The Device correctly appears in the owfs directory (and of course the webinterface). At the moment we use the family-address 0x11, which is not defined by dallas semiconductors. Is it possible to define a schema for this device family, so we can read our thermostat by temperature f.e. and write data to set_temperature? How can we read or write the scratchpad or define commands with owfs? Our project is documented here in german: http://www.hackerspace-bamberg.de/Cooperating_radiator_monitoring_114 -- Schinken Backspace e.V. http://hackerspace-bamberg.de mail: schin...@hackerspace-bamberg.de mailto:schin...@hackerspace-bamberg.de xmpp: schin...@tai-wahn.de mailto:schin...@tai-wahn.de (otr) GPG: FFB7 E40D B2DD D24C C9B7 B5C5 703C F8B8 882C 871E -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Own 1-Wire device
Hello,
On 11/23/2012 12:05 PM, Schinken wrote:
[...]
We're currently not emulating an DS18x20 Chip, we want to use our own
device class
As for using owfs for you new chip, if you are creating the slave only
for your own use, you can modify owfs however you wish (it's open
source) and even ask for assistance.
Where can i define these device-classes / commands etc?
If you want support to be part of owfs, then it has to be relevant to
more users. In general I like to add support for any commercial project,
and any project that is easily available or buildable (descriptions,
code, schematics) that fit's in with the 1-wire system. (i.e.
open-source hardware).
It could be relevant for more users - but it wont be a commercial
project. Free to use and modify for everyone - open source ;)
It would be very nice if you can tell us how to integrate these commands
to owfs, so we can use it with ownet etc
I too have built a custom 1-Wire device, and I have integrated it into
owfs (though I have yet to officially ask Paul if it could be added to
the official owfs source tree). My device does not emulate any existing
device.
Attached you'll find the source code that I use to integrate my device
into owfs. You can use it as a starting point. It's actually pretty
simple -- you need a driver C file and its include header file
companion, i.e. ow_yourdevice.c and ow_yourdevice.h, in two specific
directories (modules/owlib/src/{c,include}), you need to modify
modules/owlib/src/c/ow_tree.c and modules/owlib/src/include/ow_devices.h
to add your new device, and you need to modify a couple of Makefile.am
files to add your new source code files.
What you put in the driver file is pretty straightforward -- just look
at how other devices are implemented and go from there.
Cheers,
Eloy Paris.-
ow-centurion-20121123.tar.bz2
Description: application/bzip
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Cat5e cable - fake?
On 10/18/2012 10:23 AM, Colin Law wrote: I saw that Cat5e ethernet cable is good for 1-wire so I bought 50m of cable from an amazon shop [1]. When the cable arrived the cable outer has printed on it PLUSCOM Cat5e UTP 4Pairs 24AWG Patch Cable. It does not contain 4 twisted pairs, which I believe it should, but 8 separate wires. Am I correct in thinking that it is therefore not Cat5e? Colin [1] http://www.amazon.co.uk/gp/product/B008EELSPK/ref=oh_details_o03_s00_i00 Interesting. The picture does show four twisted pairs. As I understand it, it is very important that the pairs are twisted. Otherwise there will be EMI issues. Perhaps what you have is the product of a manufacturing problem? I would contact the manufacturer and ask why the pairs are not twisted, when they should be. Cheers, Eloy Paris.- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] 1-Wire Presence Pulse
Hi Phil, On 06/18/2012 02:08 PM, Phil White wrote: Hello Elroy, Thanks for the reply. On 16 June 2012 21:27, Eloy Parispe...@chapus.net wrote: ... snip ... but after seeing your comment that my statement above is incorrect, I read the datasheets... Oh! Please don't interpret my comment as a statement that you are wrong! Haha. Don't worry about it -- I can be wrong! Didn't mean to imply that I am infallible; nobody is, actually ;-) It was simply referencing what I understood. As can be deduced from the preceeding posts, I know *** *** (absolutely nothing) about this - I know just enough to be dangerous but I've spent sometime getting myself familiar with the 1-Wire protocol since I created a microcontroller-based 1-Wire slave that I am using in production around my house, and coexisting with DS18B20s. I just have to rely on Dallas datasheets, which aren't very clear. The other problem I am noticing more and more is that URLs for datasheets etc. give a 404 error, so there is less info available. Yup, the datasheets aren't very clear in some cases. I like the 1-Wire flowcharts and 1-Wire timing diagrams in the datasheets, but the datasheet that says that the presence pulse is guaranteed on contact is a bit confusing for sure. this would suggest I cannot mix an i-button lock on the same bus as my temperature sensors. Good point. If the slave cannot initiate communications then polling by the master is the only option, and you are right in that a reasonable polling frequency will be necessary so the user does not experience a boring waiting time. Good. Well, that's as good as a definite for me that a lock facility should be on a separate circuit. However, a switch sensor, which I only need to poll every minute, is quite feasible. Good luck with your project! Let us know how things go. Cheers, Eloy Paris.- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] 1-Wire Presence Pulse
On 06/18/2012 02:57 PM, Eric Vickery wrote: On 6/16/2012 3:27 PM, Eloy Paris wrote: Hi Phil, On 06/16/2012 07:43 AM, Phil White wrote: On 13 June 2012 02:01, Eloy Parispe...@chapus.netwrote: All 1-Wire devices have this presence pulse feature that you mention -- that's a fundamental part of the protocol, and all slave devices need to generate a presence pulse right after they detect a reset pulse generated by the master. My belief is that this statement is not correct - and it is this that has caused the confusion and prompted the original question. I have no experience with the DS1990A and DS1990R, but after seeing your comment that my statement above is incorrect, I read the datasheets for both and I still see no indication of a slave that can act on its own, i.e. without the master initiating communication first. A slave that can do that (initiate communication on its own) would be speaking a protocol different than 1-Wire, or a 1-Wire protocol extension that I have never heard of. There is a way for slaves to announce their presence on the bus by providing a presence pulse when they are powered up. I'm not sure if all slaves to this or just some (or all) of the iButtons. Also I don't know which masters or software supports this, it is mainly used for things like door lock systems where the iButton is used as the security FOB. That's pretty weird. That'd kill any communication initiated by the master that is taking place when the iButton is powered up. Not saying I don't believe you, especially since I have no experience with these devices, but I'm tempted to order a sample just to further my knowledge of the protocol (and a possible extension to it like the one being discussed) ;-) Cheers, Eloy Paris.- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] 1-Wire Presence Pulse
application. This is my current plan - though my (lack of) free time is limiting my progress. As stated, it requires the DS18B20 to be powered, so I have been working on a suitable circuit and pcb. (I have not yet ascertained the best way of how I should deliver the power in, as I have a long bus length, and all the docs suggest that the use of adjacent wires has an impact on communication timing and reliability). Check out this PCB: http://www.digitemp.com/dt1a.shtml Very simple PCB. I used his EagleCAD files and had a bunch made. I am using them extensively throughout my house (I didn't put cat5 female connectors on all and instead just soldered a small segment of cat5 cable directly to the PCB and attached a cat5 male connector to the other side of the cable, and then into the jack on the wall). You can try sending power through the cat5 cable; the above PCB supports that (via configuration jumper). Cheers, Eloy Paris.- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] 1-Wire Presence Pulse
Hi Roberto, On 06/12/2012 09:21 PM, Roberto Spadim wrote: i don´t know if this exists but... in advantech and others rs485 modules, exists a sincronous read mode, where you send a command to all slaves and they save the value into the memory after a time you can get all slave values This can also be accomplished with the DS18B20 -- you send the Skip ROM command followed by the Convert T command. It's called simultaneous temperature conversion. I have never used it but I understand that OWFS supports it (the DS18B20s must be powered for this to work). for example in a ds18b20 you will need 1 second to convert temperature well... 1 second converting temperature in a network with 100 ds18b20 still 1 second... the time you will spent later is getting 100 values from memory, this is faster than get 1 temperature from each ds18b20 (100 seconds at least) i think it´s called sincronous ou parallel i didn´t tested it in owfs but i think it exists, must confirm with guys here Yup, my understanding is that it exists and works. There is a simultaneous directory at the root of the OWFS, with elements inside it that I understand are to be used to make use of the simultaneous temperature conversion feature. Cheers, Eloy Paris.- 2012/6/12 Eloy Paris pe...@chapus.net mailto:pe...@chapus.net Hi Phil, On 06/12/2012 08:36 PM, Phil White wrote: Hi All, This may, or may not, be applicable to this list. However, I am hoping that someone here knows enough about MicroLAN to be able to clarify something for me. Up to know, all my sensors have been polled. Simplistically speaking, the PC asks What is the temperature now? What I am pondering is the ability for a sensor to suddenly, without any warning, say Gosh! It's hot here. Now, some of the iButtons come with a feature called a Presence Pulse - although I am also interested in getting events via a DS2408 switch, and the DS18B20 comes with an alarm function. Questions: Is this possible (preferable, but not necessarily, with OWFS) without polling the chip all the time? what are my options? The 1-Wire protocol does not allow for slave-initiated communications; everything is initiated by the master. All 1-Wire devices have this presence pulse feature that you mention -- that's a fundamental part of the protocol, and all slave devices need to generate a presence pulse right after they detect a reset pulse generated by the master. I think the closest option to a non-polling solution is to use the alarm function that some 1-Wire devices offer -- it still requires polling but it can minimize it since only devices in an alarmed state would be contacted. The way the alarm function works is that only devices that are in an alarmed state will respond to a conditional search, so then you would only read the sensors that show up in a conditional search. Cheers, Eloy Paris.- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net mailto:Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers -- Roberto Spadim Spadim Technology / SPAEmpresarial -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] 1-Wire Presence Pulse
Hi Phil, On 06/12/2012 08:36 PM, Phil White wrote: Hi All, This may, or may not, be applicable to this list. However, I am hoping that someone here knows enough about MicroLAN to be able to clarify something for me. Up to know, all my sensors have been polled. Simplistically speaking, the PC asks What is the temperature now? What I am pondering is the ability for a sensor to suddenly, without any warning, say Gosh! It's hot here. Now, some of the iButtons come with a feature called a Presence Pulse - although I am also interested in getting events via a DS2408 switch, and the DS18B20 comes with an alarm function. Questions: Is this possible (preferable, but not necessarily, with OWFS) without polling the chip all the time? what are my options? The 1-Wire protocol does not allow for slave-initiated communications; everything is initiated by the master. All 1-Wire devices have this presence pulse feature that you mention -- that's a fundamental part of the protocol, and all slave devices need to generate a presence pulse right after they detect a reset pulse generated by the master. I think the closest option to a non-polling solution is to use the alarm function that some 1-Wire devices offer -- it still requires polling but it can minimize it since only devices in an alarmed state would be contacted. The way the alarm function works is that only devices that are in an alarmed state will respond to a conditional search, so then you would only read the sensors that show up in a conditional search. Cheers, Eloy Paris.- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Simple trending on Ubuntu
H Colin, On 06/11/2012 11:16 AM, Colin Law wrote: Hi I would like to do some simple trending (graphs) of data from connected 1-wire devices. I have been googling for this and find references to temploggerd but am not sure how to go about installing/using it. I have httpd running ok. Is temploggerd the best tool for simple logging and if so is there a link to instructions on how to set it up on Ubuntu? I went the Cacti/RRD route for simple graphing of 1-Wire temperature and humidity data. I followed Marc Merlin's excellent documentation and things were not difficult to set up. http://marc.merlins.org/perso/homeha/2009-12.html#Temperature-monitoring-and-graphing-with-1wire-devices_-digitemp_-misterhouse_-and-cacti I never looked into temploggerd so I can't comment on it. But I think Cacti is great. Cheers, Eloy Paris.- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Release 2.8p15
On 05/21/2012 12:03 PM, Paul Alfille wrote: Good news and bad news on the late-starting owservers Can someone summarize what this problem is? I know that in my case owserver takes a while to start. It sounds like the same problem as late-starting owservers but I cannot seem to find the February 1st report that Klas mentions. Based on Paul's comment below, I take it that the problem has been identified and will be fixed in the next release? This has been a problem for me because my owfs start script cannot execute owserver and owfs in succession because owserver goes daemon immediately but does not really start servicing requests, and then owfs fails to find a working owserver and then quits. So, after each reboot I need to run owfs manually. Fortunately I don't restart my server often. I'll look into that owexist trick that Paul mentions, though it does not seem to be perfect because it would suspend the boot process for a little bit. Cheers, Eloy Paris.- There is a new command: owexist It needs an update (even from the latest release) to module/owshell/src/c/owexist.c but you can then run: address=;e=1; while [ $e -ne 0 ] ; do /opt/owfs/bin/owexist -q $address ; e=$? ; sleep 1 ; done Which will loop until owserver appears. address= for default owserver localhost:4304 address You can also wait for the next release, which shouldn't be as long a wait. Paul Alfille On Mon, May 21, 2012 at 8:51 AM, klas englund tcmsk...@gmail.com mailto:tcmsk...@gmail.com wrote: What about the issue about finding late starting owservers, reported by me on the 1st Februari? Klas E -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Release 2.8p15
Hi Paul, On 05/21/2012 04:36 PM, Paul Alfille wrote: You summarized the problem well. Synchronizing the start of owserver and it's clients can be problematic. As for suspending the boot process -- the whole scheme can be done in the background. I.e run this script in the background: [...] Okay, yes, that makes sense. I'll see what I can come up with in terms of an Ubuntu Upstart script. The one I have right now definitely does not work because of the synchronization problem we're discussing. I guess another approach would be to allow owhttpd and owfs to function even if they can't yet connect to owserver. Definitely another option. Perhaps add configuration options to the clients so they don't fail/quit when they cannot contact owserver and instead attempt a connection every X seconds? Cheers, Eloy Paris.- On Mon, May 21, 2012 at 3:37 PM, Eloy Paris pe...@chapus.net mailto:pe...@chapus.net wrote: I know that in my case owserver takes a while to start. It sounds like the same problem as late-starting owservers but I cannot seem to find the February 1st report that Klas mentions. Based on Paul's comment below, I take it that the problem has been identified and will be fixed in the next release? This has been a problem for me because my owfs start script cannot execute owserver and owfs in succession because owserver goes daemon immediately but does not really start servicing requests, and then owfs fails to find a working owserver and then quits. So, after each reboot I need to run owfs manually. Fortunately I don't restart my server often. I'll look into that owexist trick that Paul mentions, though it does not seem to be perfect because it would suspend the boot process for a little bit. Cheers, Eloy Paris.- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Vibration Sensor Circuit Advice
Hi Chris, On 03/11/2012 09:47 AM, Chris Lautre wrote: Hi A while ago I saw some discussion about a Vibration sensor. I have found an adjustable one that works great: http://www.assemtech.co.uk/ There are 2 models NPN(PDS1000-1) and PNP(PDS1000-2) output. They are about 40 GBP. I have the circuit below working fine. The DS2406 reads the Relay open/close. I know there must be a way of reading the output without using the relay. (My circuit design knowledge is a bit limited to say the least) Can anyone suggest a suitable circuit? Why not connect the sensor's output directly to the DS2406 PIOA input? Is the concern that the sensor's output is 0V or 12V and the DS2406 can operate in the 0 to 5V range? The DS2406 datasheet says that the PIOA pin can take up to 12 volts. Cheers, Eloy Paris.- -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Extend OWFS to other Devices
On 02/27/2012 09:13 PM, Paul Alfille wrote: Interesting idea. I've been tempted to build a special owserver that has plug-in sensor code -- owexternal. The plug-in would get a separate mane space (perhaps /external/sensor43/humidity) and have to report a few properties like length, type, read/write and volatility. Plugins could be written in a variety of languages, and the owserver protocol would be handled by owexternal. Is there interest in this? Yes! Seems like a fantastic idea. Would allow people to build sensors that use whatever protocol and hardware interface they wish to use to communicate with the PC world and still use the owfs interface they are used to for 1-Wire devices. Eloy Paris.- On Mon, Feb 27, 2012 at 5:29 AM, ekgnkb3d achi...@gmx.de mailto:achi...@gmx.de wrote: Hi all, beside using 1-Wire devices I would like to use other sensors as well. Currently I play with an temp-sensor getting data very simple by a serial port. So writing all this polling, retry, alias, fuse (and a lot of other functionality) again is a lot of effort - so maybe there is a way to extend the existing OWFS framework by own devices. E.g. some simply C program or scripting would be great and at the end the sensor could be accessed via owserver and appear as HTTP, file-system or CAPI Is this somehow possible and documented? Achim -- View this message in context: http://old.nabble.com/Extend-OWFS-to-other-Devices-tp33398846p33398846.html Sent from the OWFS - Dev mailing list archive at Nabble.com. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Hubs
On 02/08/2012 06:40 PM, Mick Sulley wrote: Thanks Eric - order placed. That was quick! ;-) Cheers, Eloy Paris.- -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] DHT11 Sensor
Hi Mick, On 02/03/2012 04:23 PM, Mick Sulley wrote: Does anyone have any experience of the DHT11 temp/humidity sensor? I just found it while looking for something else, it sounds very cheap for a combined temp and humidity sensor, £2.75 on eBay, but I am not convinced that it is compatible with 1-wire and owfs as I don't see any address in the description. There is a description here http://www.ladyada.net/learn/sensors/dht.html but my limited technical knowledge can't determine if it would work or what else would need to be done to get it to work. I have experience with the DHT11's older brother, the RHT03. Both work very similarly and as far as I know the only difference is price (one has better accuracy and temperature and humidity range than the other). Without a doubt, these guys do not speak Maxim/Dallas 1-Wire protocol; it's its own thing. I am working on a microcontroller-based 1-Wire slave that uses an RHT03 as the humidity/temperature sensor and it works great. I have not deployed one of these yet so I am not sure how well the RHT03 will work in a production environment (like in my garage, basement, or outside) but at least in inside tests it is looking pretty good. I'd say these cheap sensors are a great option, but you definitely need to hook them up to a microcontroller (it's not hard at all but it is not typical PC development). Cheers, Eloy Paris.- P.S. There are Arduino libraries to talk to these sensors so using an Arduino is an option if hardware development is not desired. The problem would be getting the Arduino to behave like a Dallas 1-Wire slave, though there is at least one GPL implementation out there that someone could use as a starting point. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] DHT11 Sensor
Hi p4trykx, On 02/03/2012 05:16 PM, p4trykx wrote: Dnia 03-02-2012 o 22:47:26 Mick Sulleym...@sulley.info napisał(a): I was also thinking about this sensor it has a digital output which can be connected to uC. There is also DHT22 which has greater range. As I understand it, the DHT22 is the same thing as the RHT03 (see comment #2 from Thomas Liu at http://www.sparkfun.com/products/10167). The DHT11 that Mick found cheap on eBay is the little brother. From what I read these are based on a capacitor which capacitance is based on humidity. I wonder how long do they live. I've read that some types of sensor wear out after about 5 years. No idea about how long these are supposed to leave. Guess only time will tell. Thanks for that Eloy, I suspected that would be the case. I would be interested to hear your experiences with it when it goes into your 'production' environment. I'm also looking forward to see it. Sure thing; I hope to be able to share my experiences soon. Cheers, Eloy Paris.- -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] What are CRC16 errors
Hi Robert, On 01/03/2012 04:40 PM, Robert Conway wrote: Thanks for the advice, its good to get my network re-established again. After checking connections etc I went through my read script and started to comment out every device in turn. It turns out that the CRC16 errors are caused by $OWWRITE simultaneous/voltage 1 Before I take a reading I execute the following in my bash script OWWRITE=/opt/owfs/bin/owwrite -s 3001 ### Force Simultaneous 1wire conversion ### $OWWRITE simultaneous/voltage 1 $OWWRITE simultaneous/temperature 1 Now sim/voltage was in there because I had used a DS2450 quad AD however it is NOT currently connected to my network. OUTCOME: $OWWRITE simultaneous/voltage 1 causes 1xCRC16_tries and also 1x CRC16_error both increment together. I have NOT tried connecting my DS2450 to the network yet to see if this changes. Maybe the server expects a return message on the bus ??? $OWWRITE simultaneous/temperature 1 I assume this is working on the bus however this command does NOT increment CRC16_tries. I find it unusual that sim/voltage uses CRC16 try and sim/temp does not increment CRC16's ow_2450.c shows a few CRC16 bus transactions and ow_1820.c just shows one CRC8 transaction. This explains why you do not see CRC16 tries when accessing the DS18x20s. If you do not have DS2450s in your network then there is one thing that I don't understand: why do you have 30% error rate on the CRC16s? That seems to imply that some CRC16s are good. But who is generating/processing them? Deleting simultaneous/voltage 1, I only see CRC8 tries, zero CRC8 errors and there is a very small amount of CRC16_tries and zero CRC16_errors now so I am now very happy. QUESTION: Is simultaneous/voltage 1 a valid command if there are no DS2450 on the bus, or is this a bug ? Maybe I have always had this problem from the very beginning years ago. No idea here, but it's a good question, and one I'd like to know the answer to as well. Cheers, Eloy Paris.- FYI just upgraded to 2.8p14 although I am sure it was the same in 2.8p9 Rob -Original Message- From: Eloy Paris [mailto:pe...@chapus.net] Sent: Wednesday, 4 January 2012 4:54 AM To: owfs-developers@lists.sourceforge.net Subject: Re: [Owfs-developers] What are CRC16 errors Hi Robert, On 01/03/2012 07:32 AM, Robert Conway wrote: [...] I have on my network 2 x Hubs (Hobby Boards) Humidity, UVI, Barometer (Hobby Boards) DS18S20,DS18S20, DS 18B20 temperatures DS2423 Counter If I look at Bus/stats/errors I see no CRC8 errors out of 217 tries, however am getting 30% error rate on the CRC16. Just started the system back up as I did an upgrade to 2.8p14 and I see 39 tries and 14 errors for the CRC16. What devices use CRC16 ver CRC8. ? Running grep CRC *c from within module/owlib/src/c/ should give you a a good idea of what devices use CRCs. After a quick check, it seems like the DS18x20 sends a CRC8 when the scratchpad is read, and the 2423 uses a CRC16 in some operation. The HobbyBoards devices (driver in ow_eeef.c) do not seem to use CRCs for anything. The HobbyBoards hubs are based on the 2409, which does not seem to use CRCs. What do others people get in terms of errors on their bus.0/statistics/errors ? In one bus with only 12 DS18B20s (I'd say this bus has a decent long run), I currently see 0 errors in 111534 CRC8 tries (no CRC16 tries in this bus). On another bus with 2 custom, microcontroller-based devices and 2 DS18B20s, I see 143/10276 CRC16s and 215/14004 CRC8s. This does not mean anything, though, since those errors are caused by bugs in my firmware and not because of physical/electrical problems with the bus. In your case, I think the bottom line is that since you are seeing some CRC errors, there is likely some physical/electrical problem with your wiring or bus. Cheers, Eloy Paris.- -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Serial-USB and/or Serial-Ethernet
Hi Eric, On 01/04/2012 04:34 PM, Eric Vickery wrote: This is not exactly directly related to OWFS but this is the best Linux list I am on. I am thinking about designing a new device 1-Wire Hub that has either a USB or Ethernet interface and I am wondering if Linux has built-in drivers for Serial-USB and/or Serial-Ethernet. That way I could emulate a DS9097U and have existing software (including OWFS) be compatible out of the box. Linux has out-of-the-box support for a bunch of serial-to-USB converter chips. The FTDI FT232RL is very common, but there are others that Linux supports. I don't know about serial to Ethernet... there are no chips that out of the box do that that I am aware of, though I have not looked closely into it. I think serial to Ethernet tends to be more about picking up a few components (FT232RL or MAX232 chip, Ethernet chip like the ENC28J60, and microcontroller) and building a custom solution. Cheers, Eloy Paris.- -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Unexpected fiasco with new network. Feedback on analysis and testing welcome
Hi Nick, Thanks for sharing. Good stuff. I don't have explanations for the things you are seeing. It does make sense to me that running ground + 1-Wire data using the same pair works better than running them using wires from different pairs in the cat5 cable. The pairs are twisted to cancel EMI, although I don't know if that is relevant in this case. I do find it very odd that things work perfectly when the LinkUSB is connected to a laptop but don't work when the LinkUSB is connected to another machine because the 1-Wire network is connected to the LinkUSB, not the computer the LinkUSB is connected to. You could try talking to the LinkUSB directly using minicom (on Linux) or HyperTerminal (Windows). Hit the 'h' key to get help for the basic commands (you can ask the LinkUSB to reset the bus, to find sensors on the bus, and do other things like send commands and read responses. The idea would be to see if the LinkUSB resets or something, but I doubt you'll see anything). When you say 50 to 95% failures reduced to 0 failures; how are you estimating this, i.e. how are you testing; doing cat /owfs/28.xx/temperature; looking at errors under the statistics directory? Also, what is powering the bus; is it USB or a separate wall wart? Did you try running your tests using the DS18B20 with parasitic power (remember to connect Vdd to ground if you do this)? Please let us know what other things you find since this is good knowledge to have to be able to design reliable networks. Cheers, Eloy Paris.- On 12/15/2011 10:44 AM, Nick wrote: Please forgive the long post and bear with me on this one. My first 1-wire network, snaking around the house with 10 or so sensors and over a long distance, has been a great success. Almost faultless performance apart from total data corruption for a short while a couple of times that I think were from a leaky shower putting water on the outside of part of the run. I took care over the design and used Clipsal pink cat 5, and it seemed very robust despite many joins and spurs of several meters in some cases, many other cables of data and power around, damp walls and perhaps other impediments. I knew that the networks could be fragile, but it seemed that in practice they would be pretty reliable based on the experience at home. I was wrong, as imagine my surprise when a simple network of about 50 meters or so in my office building with one 18b20 on the end was almost a total failure. I tested the same setup at home using the same cat 5 and a long run of cable and had zero errors. Halving the run in the office made no difference, and while a very short run to a sensor was fine, add on the rest of the run and it failed again. After fiddling a little and getting nowhere, I brought in my laptop, LA and some other kit to the office to explore more. Curiously, with my Dell laptop (and same LinkUSB master), the network was now 100% reliable. Plugged into a different Dell desktop in the office, again a disaster. Default wiring was orange power, white/orange earth, blue data. Others unconnected but wired in the RJ45. I started experimenting. Here are some of the outcomes that improved things, and that may go against advice given from Maxim. * Attaching just the earth wire from my Saleae LA made the network 100% reliable (i.e. 50 to 95% failures reduced to 0 failures) * Using white/blue for earth rather than white/orange, plus a 10K pullup for the dataline, 95% to 99% reliability. * Adding a PIC 1-wire slave without or without connecting the data line, 100% reliable (now attaching LA ground reduced reliability) * As above but with white/blue for ground gave 100% reliability and no change if LA ground was attached. * On different PC, worse problems and the pullup was not so effective. I did some other tests, and the final route to near enough 100% reliability with a single sensor on the end of the run was: * Use orange for power * Blue for data * Blue/white for earth * Connect the other earths from the LinkUSB for the length of the run but not to the slaves * Add a 10K pullup, though this can be removed with my PIC slaves added. * It's possible that more slaves will also increase reliability but unknown at the moment. I'm assuming that this boils down to capacitance issues, and that the changes I made such as choice of what wires to connect for earth etc. simply affected this, but found it very surprising that the same setup would be fine with the laptop and yet a failure with other PC's (they are connected to UPS's in case that's relevant). Effects such as attaching the ground wire from the LA I found odd too. What I took from this is that changing what wires are used for earth in the cat 5 (or which earth from the master if there's more than one), and how many earths are used, could be critical and worth doing for anyone with a similarly misbehaving network. Guidance I'd read said not to connect other
Re: [Owfs-developers] No Messages
On 12/01/2011 06:12 PM, Peter Hollenbeck wrote: I haven't received any owfs mail in two days. I presume there has been traffic?? We're here! :-) This list provides my most interesting and instructive reading so I really miss it. Agreed! Cheers, Eloy Paris.- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] serial 1-wire adapter review
Hi p4trykx, On 12/01/2011 07:40 PM, p4trykx wrote: Hello I recently build a dual 1-wire adapter based on two DS2480B chips. It is also isolated with Analog Devices ADUM2402(or similar) isolator. It's connected to my Asus WL-500W 2 serial ports. The uart header has also +3.3V and this powers the router side of ADUM2402. I'm not an educated electronics engineer I would like to hear opinions about the board layout and schematics. I built one board with toner thermal transfer method and it works more or less fine. However I sometimes get 85* errors. Previously I used ds-2480B with ft232RL serial-usb adapter and there where no 85* errors. The difference between two setups is that the new adapter has 62 Ohm resistor and the old one does not. I also didn't solder the 470pF capacitor because I didn't have the particular value(I will go to the shop tomorrow). http://imageshack.us/photo/my-images/685/schem.png/ Good job; you seem like a pretty good engineer to me ;-) And soldering those SMT components is probably not an easy task. I notice that the RC filter seems to be inverted, i.e. the capacitor is connected to the 1-Wire bus instead of to pin 2 of the DS2480B. Right now you don't have a capacitor but when you put it in I think you should connect it to pin 2 of the 2480B. I don't see why you are getting the 85 degrees errors. Are the sensors working in parasitic mode? If so, are the Vdd pins grounded? Cheers, Eloy Paris.- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] DS2431 missing CRC16 read slots, and LinkUSB is now at 1.5
Hi Nick, On 11/29/2011 10:19 AM, nick wrote: Hi I'm working on a custom 1-wire slave (IR sender for some air con units), and I picked the DS2431 to emulate for exposing a memory mapped interface to the IR sender. The IR sender (already done) and DS2431 code is coming together nicely in a 12F683 at 4MHz. The master is a LinkUSB, which now reports 1.5 for the firmware, so I patched the link driver to recognise it as a version 1.4 device. So far my slave shows up in the file system, and reading data from it works, though isn't required. I have a problem when implementing the write scratchpad feature though, as a DS2431 should TX an inverted CRC16 of the received command, address and data, but there are no read slots coming from the master for the CRC after it sends the 8 bytes of scratchpad data. I may have missed something, but I'm not sure what and would appreciate any pointers. It appears that the CRC would simply dropped by a slave as it cannot be sent. I also get a CRC error on a read scratchpad operation at the moment, but that may well be an error in my slave, though I have the CRC16 algorithm correct and tested. Have you looked at OWFS' ow_2433.c? That might help. Both the DS2433 and the DS2431 are implemented in ow_2433.c. The 2433 has family code 23 and the 2431 has family code 2D. The function OW_w_2Dpage() is the one that handles writes to the 2431 and, if I am reading it correctly, it never reads the CRC16 after sending the Write Scratchpad command. So this looks like something on the OWFS side and not on your emulated DS2431. Cheers, Eloy Paris.- Last, the selection of a DS2431 is arbitrary, and if there's any recommendation for a different memory oriented part to emulate then the choice can easily be changed. It just needs to be a part that has about 8 bytes or so of writeable address space. Nick -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
[Owfs-developers] Handling of 1-Wire communication failures in microcontroller-based slaves
Hi fellow OWFS users/developers, Based on my experience developing a microcontroller-based 1-Wire slave I believe that, unless your chosen microcontroller has a lot of power (or you are very good at programming, or write the 1-Wire slave code in assembly), the stringent 1-Wire protocol and strict timing puts a lot of demands on the microcontroller. For instance, what I am seeing is that every now and then a 1-Wire read will result in invalid data, and not because a few bits become corrupted because of electrical conditions of the 1-Wire bus, but because the microcontroller was busy doing other things when the 1-Wire master performed the 1-Wire bus operation. A good example of this is when the microcontroller needs to read data from an on-board sensor: if you have an on-board DS18B20, the microcontroller needs to disable all interrupts while reading from the DS18B20. If the 1-Wire master tries to read from the microcontroller-based 1-Wire slave when the microcontroller has interrupts disabled to talk to the DS18B20 then the 1-Wire master will receive bad data (probably all ones), or it will not see the slave responding to the 1-Wire reset pulse. I'd like to get input on the best way to handle this. I can see two options: 1. Make sure that the microcontroller *never* ever misses a communication attempt from the 1-Wire bus master. This depends on how things are implemented on the microcontroller. For example, if interrupts are used to handle the 1-Wire bus then care must be taken to guarantee that interrupts for state changes on the 1-Wire bus are never disabled, even if other interrupts (timers, UART, A/D converters, etc.) must be disabled to perform a time-critical task (like talking to an on-board DS18B20). This is the approach that I have been using and it works, but it is disruptive to tasks that are very time-sensitive. 2. Whenever data is transmitted to/from the microcontroller-based sensor, also send a CRC of the transmitted data. OWFS already has the capability to handle CRCs (there are bus transaction types that handle CRCs) so this looks like a good possibility. Obviously, this would require extra processing on both the OWFS side and on the microcontroller side, but then the microcontroller does not have to be too strict when it comes to disabling interrupts since if a 1-Wire communication request comes while interrupts are disabled, the data transmitted will have a bad CRC and the operation can be retried. I have not attempted to implement this option but I am tempted to. I know there are people here that have implemented their own microcontroller-based 1-Wire devices, which is why I thought I'd ask here for thoughts on the matter. This also has implications for OWFS code since if option (2) is chosen then OWFS would need to either generate a CRC (when sending data to the sensor), or check a CRC (when receiving data from the sensor). Thanks in advance for sharing your experiences! Cheers, Eloy Paris.- -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
[Owfs-developers] Best way to represent multi-sensor data
Hello developers, I am working on a 1-Wire device that provides multi-sensor data, i.e. temperature, humidity, luminosity. I'd like to be able to have an OWFS file that allows me to do this: $ cat /owfs2/uncached/99.010203040506/environs; echo temp=25.2 RH=48% light=252 This would allow for easy parsing of environmental data without having to access different files, i.e. one file for temperature, another for humidity, etc. I am not sure about how to best set up the struct filetype entry to accomplish this. In particular, what should I use for the suglen and format fields? In looking at the possibilities, it seems to me like ft_vascii for the format is something that could work, but then I am not sure about what to use for the suglen field (I guess I could use the largest length that could be produced). Any thoughts on the approach I am considering or if there is a better way to do this? Thanks in advance. Cheers, Eloy Paris.- -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Best way to represent multi-sensor data
On 11/05/2011 09:17 AM, Colin Law wrote:
On 5 November 2011 12:33, Roberto Spadimrobe...@spadim.com.br wrote:
[ snip of ideas for how owfs could produce more intelligent output ]
well i think that´s enought to don´t work with external bash scripts, right?
I don't agree. OWFS should be just about producing the data. It has
to be kept as light as possible as it must run on kit with very low
resources. Any further sophistication should be built *on top of*
owfs, not built *into* it.
Okay, fair enough; I can agree with this (up to a certain point). owlib
already does format conversion for most data read from 1-Wire sensors,
though. For example, when reading a temperature from a DS18B20 sensor,
owlib receives a 12-bit number. When you access the temperature file,
however, you obtain an nicely formatted number that is human readable.
So, where do you draw the line between just give me a binary number
and give me nicely formatted data?
In terms of efficiency, retrieving the following structure:
struct environs {
uint16_t rh;
uint16_t temp;
uint8_t luminosity;
}
in a single bus operation is more efficient than going through 3
separate bus operations to obtain the same 5 bytes of data. From a
microcontroller code point of view, it is also a bit easier and more
efficient to write the code to do a single 5-byte data transfer than it
is to do two separate 2-byte and one 1-byte transfers. Sometimes,
especially when you are tight on flash memory space on the
microcontroller, small optimizations like this do make a difference.
Having said this, I am not aware of any device supported by owlib, and
that offers more than one measured variable, that can be accessed via
OWFS in a way that produces all the measured variables in a single file
access operation. That's why I asked how one would go about it. But
thinking about this some more, this is just a memory read operation, and
there are plenty of examples of that in owlib (I've even implemented
this for the multi-sensor I'm developing, so I think I should be set).
Cheers,
Eloy Paris.-
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Compile problem on AMD64 ubuntu 11.10
Hi Paul, On Tue, Oct 25, 2011 at 12:44:00PM -0400, Paul Alfille wrote: Thanks for responding Chris. This is from the cvs since I want to continue development. I'm sure libtool combines incredible cross-system intelligence, but its operation is rather opaque and documentation abysmal. I thought that New Riders' book GNU AUTOCONF, AUTOMAKE and LIBTOOL (The Goat Book, http://sourceware.org/autobook/) was a decent reference on the subject. It's a bit old now, though. There is a newer book on Autotools that I have not had a chance to look at: A Practioner's Guide to GNU Autoconf, Automake, and Libtool http://shop.oreilly.com/product/9781593272067.do Seems to have an online version here: http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool Cheers, Eloy Paris.- I remember the IBM mainframe days with the JCL punch cards that you placed before your program and never dared touch. Not much has changed! Paul On Tue, Oct 25, 2011 at 12:24 PM, Chris Boot bo...@bootc.net wrote: On 25/10/2011 16:43, Paul Alfille wrote: Any suggestions on fixing this complie problem? The make script sails through owshell and then dies in ownet. This is from a clean pull of the source code. Do you mean from CVS or from a tarball? owshell are binaries and ownet a library. Maybe that's the difference? My system has *libtool (GNU libtool) 2.4* *autoconf (GNU Autoconf) 2.68* *automake (GNU automake) 1.11.1* GNU Make 3.81 Output: ... Making all in ownet make[2]: Entering directory `/home/paul/owfs/module/ownet' Making all in c make[3]: Entering directory `/home/paul/owfs/module/ownet/c' Making all in src make[4]: Entering directory `/home/paul/owfs/module/ownet/c/src' Making all in c make[5]: Entering directory `/home/paul/owfs/module/ownet/c/src/c' /bin/bash ../../../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../../../src/include-I../include -fexceptions -Wall -W -Wundef -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wredundant-decls -D__EXTENSIONS__ -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=500 -D_BSD_SOURCE=1 -D_ISOC99_SOURCE=1 -D_POSIX_C_SOURCE=200112L -pthread -g -O2 -m64 -D_XOPEN_SOURCE=500 -D_BSD_SOURCE=1 -D_ISOC99_SOURCE=1 -D_POSIX_C_SOURCE=200112L -MT compat.lo -MD -MP -MF .deps/compat.Tpo -c -o compat.lo compat.c mv -f .deps/compat.Tpo .deps/compat.Plo mv: cannot stat `.deps/compat.Tpo': No such file or directory make[5]: *** [compat.lo] Error 1 ... I had something similar happen to me. The bootstrap script couldn't produce a working libtool for me, so I ran 'autoreconf --install' and that fixed things for me. It seems to rewrite 'src/scripts/install/ltmain.sh' among other things. HTH, Chris -- Chris bootbo...@bootc.net -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Owfs interface to consumer wireless rf devices
On 10/20/2011 02:38 PM, Mick Sulley wrote: My system is evolving in the opposite direction. After a lot of research in the beginning I decided to use Digitemp to measure all of the temperatures and X10 to drive all of the mains voltage outputs, with a Python script running it all. As it evolved I moved from Digitemp to owfs as that gave me more flexibility, and I had a problem with one of my X10 outputs just not working some times, the switch unit worked fine in other parts of the house, just not where I wanted it to! So I have changed a couple of the X10 outputs to 1-wire DS2406 modules with home brew electronics driving relays, The others will change as well when I get around to it. I think that one problem with X10 is that you cannot tell if the signal received by the remote device is good and healthy or right on the limit of failure. There is test equipment around that can do it but it is expensive. As Marc Merlin pointed out, INSTEON is not a bad option for controlling things like lights (I, like Marc, am an INSTEON user). I do not think it is perfect, but I think it is reasonably good. Cheers, Eloy Paris.- On 20/10/11 13:41, Robert Conway wrote: 1wire is great however I want to switch AC voltages. Although I can easily build devices capable of mains switching either solid state or relay I liked the idea of buying something off the shelf that has appropriate approvals for insurance reasons. I am not sure about the reliability of X10, plus its expensive. I was thinking of hacking a wireless remote controlled power socket (See link below) and control through a 1wire switch. It turns out $10.00 per point so its cheap and a consumer device which is certified for my country for 240VAC applications. The remote has an ON and OFF button per socket. Then I thought wouldn't it be great if I simply used a 433 mhz transmitter direct from my Server. Instead of writing my own script I had a vision of owfs allowing me to create a custom device, specify the number and type of parameters and then next to each parameters allow me to insert an AT style of command for each parameter all via a web interface :) http://www.ebay.com.au/itm/3-in1-BULK-PACK-Remote-control-10A-Power-Point-NE W-/250755155458?pt=AU_Building_Materialshash=item3a622c0602 I think I have also seen some wireless power monitors. -Original Message- From: Pascal Brugier [mailto:pbrug...@aeon-hq.net] Sent: Thursday, 20 October 2011 11:02 PM To: owfs-developers@lists.sourceforge.net Subject: Re: [Owfs-developers] Owfs interface to consumer wireless rf devices Hy, Just for my knowledge, why do you want Owfs to be able to connect to X10, ZigBee, XBee or else when protocol like XPL [1], projects as Xpl-Perl [2] or more advanced userfirendly project like Domogik (web + Python) or other exist. As english ins not my native language it's possible I missunderstand the goal of your request, so can you explain as I take some interrest on this subject. Pascal. [1] http://xplproject.org.uk/ [2] https://github.com/beanz/xpl-perl [3] http://www.domogik.org/en/ -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers -- The demand for IT networking professionals continues to grow
Re: [Owfs-developers] Anything new or planned
Hi Mark, On 10/14/2011 08:36 AM, Mark Richards wrote: As one wire is shrinking, I am curious about what you mean by this statement... do you mean that it is losing market share to other technologies, being replaced by other technologies (wireless?), or becoming obsolete? If so, what gives you that impression? Based on Maxim's support of the technology it seems to me like they are still behind it (yes, they have killed some products but overall it seems like they are still backing the technology and offering a good selection of products). Cheers, Eloy Paris.- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] owfs and owshell on openwrt - what does owshell do?
On 09/22/2011 04:25 PM, Colin Law wrote: [...] So I think I need owshell on the Plug and owserver on the wrt54G. Or owfs (the binary) on the plug (instead of owshell)... it all depends on how you are doing things (what language you'll use) on the plug. Cheers, Eloy Paris.- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] increase OW reliability in bad topology
Hello, On 09/19/2011 10:12 AM, Jan Kandziora wrote: [...] I saw some i2c-tiny-usb converter and it seems to work with OpenWrt. I cound,nt find any i2c-uart converters. You could easily build such a thing using an PIC or AVR µC. E.g. even the smaller AVRs have an internal UART for RS232. The I²C interface could be build up using bitbanging. The biggest problem of such a solution is speed, as RS232 is slow against I²C. For USB, the problem is programming the controller, as USB has a complicated protocol. +1 for the suggestion of building an I²C - RS232 interface using a microcontroller (disclaimer: I have not done such a thing, but I think it would not be hard to do) -- some AVRs have hardware support for I²C (in the AVR documentation it is called TWI for 2-wire Serial Interface) and after a quick look at the datasheet of an ATmega328, it seems like one can use the I²C and UART subsystems at the same time. No bitbanging in these cases :-) Cheers, Eloy Paris.- -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] increase OW reliability in bad topology
brucek bru...@valinet.com wrote: If you have an extra pair in the wiring, you could use one pair in and one pair out so that the star is functionally a liner network bk -Original Message- From: ekgnkb3d Sent: Saturday, September 17, 2011 7:05 PM To: owfs-developers@lists.sourceforge.net Subject: [Owfs-developers] increase OW reliability in bad topology Hi all, my problem is a little bit off-topic (because not specific to owfs), but maybe in this forum are the experienced 1-Wire net experts ;-) I want to replace in an existing building the 12 analog temperature sensors by 1-Wire DS18B20 temp sensors. The used cables are standard telephone twisted pair which are shielded together. They are in star-topology, so each of the 12 cable come from a different room (10m to 50m length each) to the central controller. So the complete net have a weight of approx 350m. The cables shall be reused, because it would be a hell a lot of effort to replace them too. As mentioned in http://www.maxim-ic.com/app-notes/index.mvp/id/148 Maxims application note 148 and http://docs.google.com/viewer?url=http%3A%2F%2Fwww.1wire.org%2FFiles%2FArticles%2F1-Wire-Design%2520Guide%2520v1.0.pdf 1-Wire.org Design Guides , the star is the most critical topology for 1-Wire nets. But what can I do, especially with OWFS, to increase the reliability of such a net? I've thought of the following already: - Using active pull-up bus masters, e.g. DS2482 with FET - If using 4 bus-masters, each one have to drive 3 sensors only and therefore reduce the weight to approx. 100m each. - Slowing down the net to 16kBit/s Standard Mode (how to do this on DS2482 with OWFS?) or even go slower down, to 8 or 4 kBit/s?? (The temperature is only needed each minute) - Problems usually look like the devices are lost, the search algorithm occasionally can't find some devices. Is there a way to configure OWFS to retry let's say 100 times until it really gives up? - Connecting each DS18B20 with 3 wires (+5V and 100nF Capacitor each) - Ensuring that the GND and OW-Data wire is a twisted pair of the cable - No termination resistor at the end of the cables any more constructive ideas? Thanks Achim -- View this message in context: http://old.nabble.com/increase-OW-reliability-in-bad-topology-tp32487173p32487173.html Sent from the OWFS - Dev mailing list archive at Nabble.com. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers +1 That is what I do in my house, where I have structured wiring. Currently have 12 ds18b20. Have not had a problem. I use parasitic power. Just make sure you do not leave Vdd floating (ground it). Cheers! -- Eloy Paris -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] different access performance
Hi Paul, On 08/11/2011 07:12 PM, Paul Alfille wrote: On Thu, Aug 11, 2011 at 4:27 PM, Pascal Baerten pascal.baer...@gmail.com mailto:pascal.baer...@gmail.com wrote: However, even if you reach the same timing, you may exceed your 250ms requirement if you read successively the four devices. To solve this, the next step is to explicitly force a simultaneous conversion on the four _powered _devices and simply read the _cached_ temperatures. We have however to clarify with Paul if the simultaneous is able to explicitly trigger the fasttemp? simulteous triggers a conversion (temperature measurement) at whatever resolution was previously set on each sensor. However owfs must lock out the next temperature reading until the conversion is done. I currently lock out for the full 1 second as the safest strategy, although I suppose the lockout could be for the minimum needed by that device and resolution. It just takes more logic. When not under parasite power (a prerequisite for simultaneous conversion), the DS18B20 will send 0s while it is converting temperature. Based on your comment I understand that the code does not use this feature. Is this correct? Don't know if the other 18x20's behave this way but I noticed the 18B20 behavior when reading its datasheet. Cheers, Eloy Paris.- Reading /uncached ignores a simultaneous conversion and forces new measurement. Paul -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Many DS9490R
Hi Steinar, Steinar Midtskogen stei...@latinitas.org wrote: [Marc MERLIN] If they don't exist as wireless, you're indeed out of luck. You obviously know what you're doing, while in the past I saw people with the same problem using 1-wire devices that totally exist as wireless options and where actually cheaper in a WMR-200 than as independent 1-wire sensors. I agree that cost isn't the one reason to choose 1-wire, though I should add that the snow depth sensor that I've built with 1-wire stuff costs about $300 in parts and a couple of hours of work, while commercial sensors easily cost $3000+. Or that it's hard to beat the cost of DS1820 at $1 each at eBay if you need dozens of thermometers. Or that if something breaks, it's often simple to repair 1-wire stuff with spare components, whereas a weather station bought at the supermarket will have to be returned. Still, I recommend people who wonder what equipment I use to go for a supermarket version unless they're prepared to use the soldering iron. And I like owfs a lot, so even if I bought something completely different, I'd still be inclined to make a 1-wire interface so I could still use owfs... I'd love to know more about your custom sensors and your 1-wire network (it always help to know what others are doing/using); have you documented your stuff somewhere? Have you built any microcontroller-based 1-wire sensors? Cheers, -- Eloy Paris -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Understanding BAE's read access to generic/memory
Hi list, I wanted to close the loop on this with one final comment: On 07/07/2011 10:55 PM, Eloy Paris wrote: On 07/07/2011 04:41 PM, Paul Alfille wrote: I think I'm starting to see your question. You are wondering how to read and write in the middle of a file (memory buffer). Yes, with the added complexity (for me to understand how things work) that I was trying to do this from the command line, with regular Unix utilities like cat . The command line is an awkward place to do partial file operations. That's what I learned today. Perhaps dd, which allows to specify an offset and a read size, would work, but definitely not cat. As Paul mentioned, there are several ways to read a block of memory from a device (for those 1-Wire devices that support this operation). To read from the command line one could use owread. However, cat cannot be used because it does not result in an operating system read() function call, which uses offset and size parameters that end up in a 1-Wire query (owq) structure. However, in addition to owread, I found that the dd utility also allows to do memory reads. Here are two ways I was able to do a device memory read using dd: dd bs=1 count=2304 if=/owfs2/99.010203040506/generic/memory of=file.bin dd bs=2304 count=1 if=/owfs2/99.010203040506/generic/memory of=file.bin The first dd invocation took considerable longer than the second because, since the block size is 1 (bs=1), it actually issues 2304 1-Wire read memory commands to read a single byte each time. This results in a *lot* of overhead. It's a good stress-test of the system, though ;-) The second invocation is faster because it issues less 1-Wire read memory commands (less overhead). The number of 1-Wire read memory commands issued depends on how much memory can be read at once -- on the BAE and on my device it is 32 bytes (limitation set on the owfs side). Thanks to Paul and Pascal for their insightful comments. Cheers, Eloy Paris.- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Understanding BAE's read access to generic/memory
Hi Paul, On 07/07/2011 04:26 PM, Paul Alfille wrote: owq is filled by the read command -- i.e. a filesystem read has size and offset as part of the call. Buffer (for the result) is allocated as well. You don't need to worry about how it's filled in, that comes from the OW_read routines (or OW_write). Ah, yes -- this all makes sense. What was confusing me is that I was looking at all this from a command line point of view. You just don't have a read offset and read size when you use cat to read files ;-) I think the above simple explanation is what made me understand what I was dealing with. Those MACROs: OWQ_buffer, OWQ_size, OWQ_offset call the relevant fields from the structure. Yup. I saw the macros in the corresponding header file. I just was not seeing how the owq structures was supposed to get filled when accessing the file from the command line with an utility like cat. The answer is that it doesn't get filled if you use cat. OW_r_mem, in this case, takes those parameters, and knows what 1-wire commands to send to the device to read the memory. Yup; once you explained everything made sense and all pieces fell into place. The rest is just microcontroller code. In the case of BAE, as I recall, there was the added complexity that the chip and memory read is designed as a long linear address space, while the various fields exposed (EEPROM, user mem, variables) are subsets of that space. We remap the start to correspond to the correct chip address space while keeping the bounds checking correct. I have not reached this point yet with my own device but I think that at some point I will. All this is a thin object-oriented layer written in C. owq stands for one-wire-query, and hold the field's size, offset, data buffer, and all the flags and parsed path information. This way we use a similar data structure independent of the data type (float, integer, boolean, data, memory). Yup; thanks for the explanation. It's easier to understand things now after your explanation. Cheers, Eloy Paris.- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Understanding BAE's read access to generic/memory
Hi Paul, On 07/07/2011 04:41 PM, Paul Alfille wrote: I think I'm starting to see your question. You are wondering how to read and write in the middle of a file (memory buffer). Yes, with the added complexity (for me to understand how things work) that I was trying to do this from the command line, with regular Unix utilities like cat . The command line is an awkward place to do partial file operations. That's what I learned today. Perhaps dd, which allows to specify an offset and a read size, would work, but definitely not cat. From a C program, you can use lseek and read From the owshell routines, there is owread --size=nnn --start=nnn --hex owwrite --start=nnn --hex Once you mentioned these methods it was clear to me how things work. Thanks! [...] Can you explain your requirements more extensively? It was actually pretty simple -- I wanted to be able to read an arbitrary number of microcontroller memory starting at a specified offset. After your explanations I am accomplishing what I need like this (for example): shell$ owread --hex --size=16 --start=0 /99.010203040506/generic/memory Cheers, Eloy Paris.- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Understanding BAE's read access to generic/memory
Hi Pascal, On 07/07/2011 05:37 PM, Pascal Baerten wrote: you may want to look at the 'writebyte' I've utilized to test some features sometime ago. the code is now commented out but still present. The principle is to consider the writebyte property as a word value (two bytes) the hi-byte is parsed as the offset and the lo-byte is parsed as the value to write. for example echo 513 /owfs/xx.n/writebyte will write the value 1 (513 |0Xff) to offset 2 (5138) for more advanced use of a generic memory, you may create a byte array of 256 elements wich will be individually addressable in both read and write function. (see aggregate examples) Thanks for the info. The writebyte seems to be a bit limited in that it only allows to write 1 byte at a time, but thanks for the idea. I'll take a look at aggregate examples; I see that there are some in ow_bae.c. Cheers! Eloy Paris.- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Understanding BAE's read access to generic/memory
Hi Paul,
On 07/07/2011 10:55 PM, Eloy Paris wrote:
[...]
After your explanations I am accomplishing what I need like this (for
example):
shell$ owread --hex --size=16 --start=0 /99.010203040506/generic/memory
This had me scratching my head -- I was reading from microcontroller
memory, using owshell's owread, the following 7 bytes:
0x63, 0x00, 0x4C, 0x08, 0x6C, 0x08, and 0xAC
However, the output from owread --hex was:
63004C086C08FFAC
There were obviously some mysterious bytes in there, but after realizing
that the last byte has its most significant bit set, and realizing that
the extra bytes are 0xff, it was obvious that there was an unintended
integer conversion from a small size to a larger size (signed char to
integer).
Below you'll find the patch that fixed the problem for me. We could
change the type of the argument of the function (from char to unsigned
char) instead of using a cast, but that probably would require changes
to other places inside ow_server.c (function prototype, add casts to
arguments when the function is called, or change the type of arguments
being passed to the function) so I thought casting in one place would be
easier.
Cheers,
Eloy Paris.-
---
--- module/owshell/src/c/ow_server.c.orig 2011-07-07 23:23:53.568305295
-0400
+++ module/owshell/src/c/ow_server.c2011-07-07 23:30:03.824315008 -0400
@@ -367,6 +367,6 @@
{
int i ;
for ( i=0 ; ilength ; ++i ) {
- printf(%.2X,buffer[i]);
+ printf(%.2X, (unsigned char) buffer[i]);
}
}
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
[Owfs-developers] Delayed LinkUSB detection
Hi Paul, I am currently working on upgrading from 2.8p1 to 2.8p8. I have been running fine on 2.8p1 for several months (since July or last year). I had to patch 2.8p1 to force hardware flow control because otherwise owserver would not be able to talk to my LinkUSB in emulation mode. I remember that back when I originally reported this problem you changed things so hardware flow control would be used if a first attempt using no flow control failed. That seems to be working. However, it takes a long time for the detection to succeed: May 3 14:22:38 altamira OWFS[21715]:CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[] May 3 14:22:38 altamira OWFS[21715]: DEBUG: owlib.c:SetupTemperatureLimits(79) Globals temp limits 0C 100C (for sim ulated adapters) May 3 14:22:38 altamira OWFS[21715]: DEBUG: ow_link.c:LINK_detect_serial(237) Slurp in initial bytes May 3 14:22:38 altamira OWFS[21715]: DEBUG: ow_link.c:LINK_version(298) Checking LINK version May 3 14:22:38 altamira OWFS[21715]: DEBUG: ow_tcp_read.c:tcp_read(64) attempt 1 bytes Time: 5.00 seconds May 3 14:22:43 altamira OWFS[21715]: CONNECT: ow_tcp_read.c:tcp_read(110) TIMEOUT after 0 bytes May 3 14:22:43 altamira OWFS[21715]: DEBUG: ow_tcp_read.c:tcp_read(64) attempt 1 bytes Time: 5.00 seconds May 3 14:22:48 altamira OWFS[21715]: CONNECT: ow_tcp_read.c:tcp_read(110) TIMEOUT after 0 bytes lots of TCP connect errors [...] May 3 14:24:58 altamira OWFS[21715]: DEBUG: ow_tcp_read.c:tcp_read(64) attempt 1 bytes Time: 5.00 seconds May 3 14:25:03 altamira OWFS[21715]: CONNECT: ow_tcp_read.c:tcp_read(110) TIMEOUT after 0 bytes May 3 14:25:38 altamira OWFS[21715]: DEFAULT: ow_link.c:LINK_version(349) LINK version string too long. greater than 36 chars May 3 14:25:38 altamira OWFS[21715]: DEFAULT: ow_link.c:LINK_detect_serial(243) LINK detection error May 3 14:25:38 altamira OWFS[21715]: DEBUG: ow_link.c:LINK_detect(211) Second attempt at serial LINK setup second attempt will finally succeed, but after many of the following TCP connection errors May 3 14:25:38 altamira OWFS[21715]: DEBUG: ow_link.c:LINK_detect_serial(237) Slurp in initial bytes May 3 14:25:38 altamira OWFS[21715]: DEBUG: ow_link.c:LINK_version(298) Checking LINK version May 3 14:25:38 altamira OWFS[21715]: DEBUG: ow_tcp_read.c:tcp_read(64) attempt 1 bytes Time: 5.00 seconds May 3 14:25:38 altamira OWFS[21715]: DEBUG: ow_tcp_read.c:tcp_read(114) read: 1 - 0 = 1 May 3 14:25:38 altamira OWFS[21715]: DEBUG: ow_link.c:LinkVersion_knownstring(133) Link version Found 1.4 I am starting owserver like this: /opt/owfs/bin/owserver --link /dev/1wire-master0 -C --error_print 0 --error_level 5 --nozero The TCP errors seem to be causing a long delay, but as far as I can see there is no need for any TCP connections since owserver is only talking to a serial device. Any ideas why TCP connections are being attempted? Cheers, Eloy Paris.- -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Delayed LinkUSB detection
to Paul ;-), I never liked the approach of trying first with no flow control, followed by attempts with hardware flow control. I didn't like it because I thought that it would result in unnecessary delays. Instead of that approach I would have preferred to see a command-line switch that forced hardware flow control, just as there is a command-line switch to set the baud rate. This would have resulted in immediate success during serial port communications provided that the right command-line argument was specified. While the above LinkUSB detection delay would not have been a problem if I had had a way of forcing hardware flow control, I did not implement an alternative to the three attempts with no flow control/flow control/flow control approach that Paul implemented, so I don't get to complain ;-) So, how to fix this (I hope there is agreement that taking 3 minutes to detect a LinkUSB is a bug, even though the end result is successful detection)? I haven't tried yet, but I think we need to propagate gbBAD from tcp_read() all the way back to the for loop in ow_link.c:LINK_version() so the if ( BAD( LINK_read_true_length() ... check is true and we leave LINK_version() right after the first timeout, instead of iterating MAX_LINK_VERSION_LENGTH times. Note that the above analysis applies to --link. However, using the LinkUSB in emulation mode (-d /dev/ttyUSBxx), should result in a similar problem. Perhaps not in the order of 5 seconds x MAX_LINK_VERSION_LENGTH, but there will be some 5-second delays too since -d ends up calling tcp_read() as well, which will timeout after 5 seconds when communications without hardware flow control are attempted. My band-aid solution for now has been to do a global search and replace of flow_none with flow_hard, leaving everything else the same. This causes the first communication attempt to be done with hardware flow control, which causes communications to succeed right way. I am currently using -d, i.e. emulation mode. Hope this helps. Cheers, Eloy Paris.- -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Aliases on DS18B20
Hi Cyril,
On 03/31/2011 11:50 AM, Cyril LAVIER wrote:
On 03/31/2011 05:43 PM, p4trykx wrote:
Dnia 31-03-2011 o 17:33:49 Cyril LAVIERclavier+owfs...@ltutech.com
napisał(a):
I type the same commands as previously.
The you are doing it wrong. The alias file is not writable!!!
As far as I know, I never yelled at you...
Answer this:
Did you read the link I gave you? http://owfs.org/index.php?page=aliases
You have to run owfs/owerver like this
owfs -a myaliases.txt -d /dev/ttyS0 -m /mnt/1wire
Yes, I read it while I was searching for any clue.
But this method doesn't convince me, as I don't want to restart the
owserver everything I add a sensor.
So I will try to find another way to identify my sensors.
Well, the thing is that you are trying to do something that is not
supported (or to say it in a different way, the feature does not exist).
patrykx mentioned that what you are seeing is because the feature does
not exist and when you write something like I just tried with the 2.8p8
version, but it's the same problems, well, the question in everybody's
mind is if it is the way the software is designed, why would a new
version behave any different?
Since the feature does not exist then yes, you will have to find a
different method if you don't want to restart owserver every time you
add a new alias.
In terms of things you could do so you don't have to restart owserver
when you want a new alias... some people maintain symlink forests.
Others (myself included), handle aliasing (i.e. giving sensors a more
readable name) in our polling scripts. For example, my polling script
(Perl) has this:
my %sensors = (
28.3C30A302 = bedroom_1,
28.454BA222 = bedroom_2,
28.2618A242 = bedroom_3,
28.3844A502 = garage,
...
};
and then I access the sensors like this:
foreach my $sensor (keys %sensors) {
if (!open SENSOR, /owfs/$sensor/temperature) {
...
Hope this helps.
Cheers,
Eloy Paris.-
--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] DS2409 support
Hi Chris, On 03/21/2011 08:46 AM, Chris Boot wrote: Hi folks, Well I'm progressing well with my 1-Wire bus master over IP. I don't have the bus locking in place yet but the code is in for owfs to use the bus master and things work. Perhaps I am missing the obvious, or you're talking about something entirely different, but would it not be possible to use the ser2net/RFC 2217 support that Paul added to owlib in December 2010/January 2011 for what you are trying to do? Cheers, Eloy Paris.- The trouble I ran into is that as my code is based on the EtherWeather driver, it has the ADAP_FLAG_no2409path flag set, which means it won't look down DS2409 branches at all. However, if I remove the flag, things appear to work just fine - except I can also see 1-wire devices from the parent branch in sub-branches. What do I need to do, either in my bus master or in my owfs driver, to get it to work properly and not show devices on the main bus when looking at a branch? Thanks, Chris -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] [SOLVED] Dreaded 85 degrees C read fromDS18B20 located outside
Bill, On 03/10/2011 09:52 AM, Farmer iButtonLink wrote: The statement in our manual is misleading. The floating Vdd pin is not really floating. It is connected to +5 on the cable. IF, however, you are using a master (in our case the Link45 family) that does have a connection to +5 on the cable, the net result is that the Vdd pin of the DS18B20 is left floating. Thanks for the clarification. Agreed that the manual is misleading given what you've explained. One more question, though: is there a typo in your last sentence, i.e. should it be the net result is that the Vdd pin of the DS18B20 is *not* left floating? (Note added not.) Otherwise I don't totally follow and would have to wait for the reworked statement. Cheers, Eloy Paris.- The LinkUSB family and the LinkHub family all put +5V on the cable so the T-Sense is never left in parasitic mode. All Link masters have a switched +5V connection to the cable (Aux). This connection is either grounded or powered but never floating. I will have Mike rework the statement. Bill Farmer -Original Message- From: Eloy Paris [mailto:pe...@chapus.net] Sent: Wednesday, March 09, 2011 11:33 PM To: owfs-developers@lists.sourceforge.net Subject: Re: [Owfs-developers] [SOLVED] Dreaded 85 degrees C read fromDS18B20 located outside On 03/09/2011 06:40 PM, Doug Collinge wrote: So, I had a look at the datasheet to see what would happen if the Vdd lead on a DS18B20 was left floating. All there is to work from is a block diagram, which doesn't contain enough information. So I asked tech support at Maxim the following question: The block diagram of the DS18B20 shows a block labeled Power Supply Sense that determines whether the chip has Vdd power or not. The datasheet says to ground Vdd for parasitic operation and it's clear that the input to Power Supply Sense will see 0V in that case. My question is what will it see if the Vdd input is allowed to float? If the capacitor is charged the diode will be a high impedance. What is the impedance of the Power Supply Sense input? If it is also a high impedance that might explain why someone is seeing inconsistent behaviour with Vdd floating. They promptly replied as follows: The Vdd 'sensing circuit' is a high-impedance node, but the Vdd pad is not. Simply disconnecting the Vdd supply will leave the capacitor charged and the component would therefore not be powered parasitically. The capacitor cannot provide enough current to power the component, but defeats the 0V detection required. Floating Vdd is an invalid/undefined condition for the DS18B20. We also sell a DS18B20-PAR+ (TO-92 only), which precludes the necessity for the Vdd pin to be grounded on a board. So I think that's a pretty clear explanation: the component expects Vdd to be wired either to +5 or ground. If it isn't it may think it is powered when it is not and not function correctly. In the specific situation described, outdoors but sheltered from rain, but high humidity my guess is that the humidity was supplying enough conductivity to a positive voltage source to keep the Vdd terminal high enough for the internal sensor to conclude that the chip was powered. It would therefore not be able to do a conversion correctly on the power stored in the capacitor and report an error. The obvious conclusion is that people should follow the clear instructions of the manufacturer and ground Vdd for parasitic operation. Thanks Doug, great information. I guess I read bits and pieces of the DS18B20 datasheet a long time ago and either forgot this particular detail (after things worked for me without following the requirement), or missed it altogether: When the DS18B20 is used in parasite power mode, the VDD pin must be connected to ground. As you say, it does not get any clearer than that. Their (Maxim tech. support's) response seems to imply that things would not work by leaving Vdd floating. However, it has worked for me for months, and even iButtonLink seem to be shipping sensors with Vdd floatin (the following comes from the manual for iButtonLink's T-Sense sensor [http://www.ibuttonlink.com/pdf/manuals%20for%20t-sense%2005-22-08.pdf]) : NOTE: Important information There is a small chance that the bus could become unstable when using T-Sense units as the only sensor on the bus. This condition comes about as a result of the new design of the T-Sense, using the DS18B20 sensor. The third lead on the DS18B20, (Vdd) is left floating, (to allow design flexibility for sophisticated networks) which leaves the possibility of unpredictable performance. Our engineering department has not been able to create this condition. Experiments
Re: [Owfs-developers] [SOLVED] Dreaded 85 degrees C read fromDS18B20 located outside
On 03/10/2011 12:27 PM, Farmer iButtonLink wrote: Argh! I hate it when the correction needs a correction. Should have read: IF, however, you are using a master (in our case the Link45 family) that does NOT have a connection to +5 (Pin 2 ... orange) on the cable, the net result is that the Vdd pin of the DS18B20 is left floating. Ahh, totally clear now. Thanks! Cheers, Eloy Paris.- -Original Message- From: Eloy Paris [mailto:pe...@chapus.net] Sent: Thursday, March 10, 2011 9:57 AM To: owfs-developers@lists.sourceforge.net Subject: Re: [Owfs-developers] [SOLVED] Dreaded 85 degrees C read fromDS18B20 located outside Bill, On 03/10/2011 09:52 AM, Farmer iButtonLink wrote: The statement in our manual is misleading. The floating Vdd pin is not really floating. It is connected to +5 on the cable. IF, however, you are using a master (in our case the Link45 family) that does have a connection to +5 on the cable, the net result is that the Vdd pin of the DS18B20 is left floating. Thanks for the clarification. Agreed that the manual is misleading given what you've explained. One more question, though: is there a typo in your last sentence, i.e. should it be the net result is that the Vdd pin of the DS18B20 is *not* left floating? (Note added not.) Otherwise I don't totally follow and would have to wait for the reworked statement. Cheers, Eloy Paris.- The LinkUSB family and the LinkHub family all put +5V on the cable so the T-Sense is never left in parasitic mode. All Link masters have a switched +5V connection to the cable (Aux). This connection is either grounded or powered but never floating. I will have Mike rework the statement. Bill Farmer -Original Message- From: Eloy Paris [mailto:pe...@chapus.net] Sent: Wednesday, March 09, 2011 11:33 PM To: owfs-developers@lists.sourceforge.net Subject: Re: [Owfs-developers] [SOLVED] Dreaded 85 degrees C read fromDS18B20 located outside On 03/09/2011 06:40 PM, Doug Collinge wrote: So, I had a look at the datasheet to see what would happen if the Vdd lead on a DS18B20 was left floating. All there is to work from is a block diagram, which doesn't contain enough information. So I asked tech support at Maxim the following question: The block diagram of the DS18B20 shows a block labeled Power Supply Sense that determines whether the chip has Vdd power or not. The datasheet says to ground Vdd for parasitic operation and it's clear that the input to Power Supply Sense will see 0V in that case. My question is what will it see if the Vdd input is allowed to float? If the capacitor is charged the diode will be a high impedance. What is the impedance of the Power Supply Sense input? If it is also a high impedance that might explain why someone is seeing inconsistent behaviour with Vdd floating. They promptly replied as follows: The Vdd 'sensing circuit' is a high-impedance node, but the Vdd pad is not. Simply disconnecting the Vdd supply will leave the capacitor charged and the component would therefore not be powered parasitically. The capacitor cannot provide enough current to power the component, but defeats the 0V detection required. Floating Vdd is an invalid/undefined condition for the DS18B20. We also sell a DS18B20-PAR+ (TO-92 only), which precludes the necessity for the Vdd pin to be grounded on a board. So I think that's a pretty clear explanation: the component expects Vdd to be wired either to +5 or ground. If it isn't it may think it is powered when it is not and not function correctly. In the specific situation described, outdoors but sheltered from rain, but high humidity my guess is that the humidity was supplying enough conductivity to a positive voltage source to keep the Vdd terminal high enough for the internal sensor to conclude that the chip was powered. It would therefore not be able to do a conversion correctly on the power stored in the capacitor and report an error. The obvious conclusion is that people should follow the clear instructions of the manufacturer and ground Vdd for parasitic operation. Thanks Doug, great information. I guess I read bits and pieces of the DS18B20 datasheet a long time ago and either forgot this particular detail (after things worked for me without following the requirement), or missed it altogether: When the DS18B20 is used in parasite power mode, the VDD pin must be connected to ground. As you say, it does not get any clearer than that. Their (Maxim tech. support's) response seems to imply that things would not work by leaving Vdd floating. However, it has worked for me
Re: [Owfs-developers] [SOLVED] Dreaded 85 degrees C read from DS18B20 located outside
On 03/09/2011 06:40 PM, Doug Collinge wrote: So, I had a look at the datasheet to see what would happen if the Vdd lead on a DS18B20 was left floating. All there is to work from is a block diagram, which doesn't contain enough information. So I asked tech support at Maxim the following question: The block diagram of the DS18B20 shows a block labeled Power Supply Sense that determines whether the chip has Vdd power or not. The datasheet says to ground Vdd for parasitic operation and it's clear that the input to Power Supply Sense will see 0V in that case. My question is what will it see if the Vdd input is allowed to float? If the capacitor is charged the diode will be a high impedance. What is the impedance of the Power Supply Sense input? If it is also a high impedance that might explain why someone is seeing inconsistent behaviour with Vdd floating. They promptly replied as follows: The Vdd 'sensing circuit' is a high-impedance node, but the Vdd pad is not. Simply disconnecting the Vdd supply will leave the capacitor charged and the component would therefore not be powered parasitically. The capacitor cannot provide enough current to power the component, but defeats the 0V detection required. Floating Vdd is an invalid/undefined condition for the DS18B20. We also sell a DS18B20-PAR+ (TO-92 only), which precludes the necessity for the Vdd pin to be grounded on a board. So I think that's a pretty clear explanation: the component expects Vdd to be wired either to +5 or ground. If it isn't it may think it is powered when it is not and not function correctly. In the specific situation described, outdoors but sheltered from rain, but high humidity my guess is that the humidity was supplying enough conductivity to a positive voltage source to keep the Vdd terminal high enough for the internal sensor to conclude that the chip was powered. It would therefore not be able to do a conversion correctly on the power stored in the capacitor and report an error. The obvious conclusion is that people should follow the clear instructions of the manufacturer and ground Vdd for parasitic operation. Thanks Doug, great information. I guess I read bits and pieces of the DS18B20 datasheet a long time ago and either forgot this particular detail (after things worked for me without following the requirement), or missed it altogether: When the DS18B20 is used in parasite power mode, the VDD pin must be connected to ground. As you say, it does not get any clearer than that. Their (Maxim tech. support's) response seems to imply that things would not work by leaving Vdd floating. However, it has worked for me for months, and even iButtonLink seem to be shipping sensors with Vdd floatin (the following comes from the manual for iButtonLink's T-Sense sensor [http://www.ibuttonlink.com/pdf/manuals%20for%20t-sense%2005-22-08.pdf]): NOTE: Important information There is a small chance that the bus could become unstable when using T-Sense units as the only sensor on the bus. This condition comes about as a result of the new design of the T-Sense, using the DS18B20 sensor. The third lead on the DS18B20, (Vdd) is left floating, (to allow design flexibility for sophisticated networks) which leaves the possibility of unpredictable performance. Our engineering department has not been able to create this condition. Experiments with 30 T-Sensors on the bus, and a variety of interfaces, have shown all devices working properly. In the unlikely event of unstable behavior on the bus, resolution can be accomplished by simply connecting pin 2 (+5 volts) to pin 6 (Aux). Alternately, any MS-xx product on the bus will provide the jumper internally, or the use of a LinkHub as the interface. So I either don't understand what Maxim tech. support said, or I do understand it but then it's mistery why so many DS18B20 seem to work fine with a floating Vdd ;-) In any case, thanks again for the information, and I'll be sure to ground Vdd little by little (but no rush since things are working great for me ;-) ) Your explanation on why high humidity could have caused the 85 degree problem makes sense to me. Cheers, Eloy Paris.- P.S. Regarding iButtonLink's statement that they have not been able to recreate network instability with more than 30 sensors on a bus all with floating Vdd, perhaps they haven't tried in a high humidity scenario like was the case for the one sensor that I had outside? -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
[Owfs-developers] [SOLVED] Dreaded 85 degrees C read from DS18B20 located outside
Hi list, I am happy to report that this problem is solved! Please see below (inline) for the details... On 03/02/2011 09:49 PM, Eloy Paris wrote: On 03/02/2011 05:49 PM, Paul Alfille wrote: Maybe some static charge in the Vcc lead confused the sensor in the lightning storm? You know what, I want to get to the bottom of this so I have decided to do nothing now to try to fix the problem I experienced a couple of nights ago when we had lots of rain and thunderstorms. Allow me to explain: Whatever happened a couple of nights ago surely will happen again. When that happens I'll go outside and start with the simple stuff, i.e. grounding Vcc. I am hoping that the problem was caused by either high humidity, or by some weird electric problem caused by not having Vcc grounded. If it is the later I will be able to confirm it by grounding Vcc when the problem is happening. As I said, I have not had a single 85 degree reading since that night, so I have no need to try to fix things right. I'll report back as soon as I know more. It happened again last night. It started around 11:45 PM. The forecast indicated that we were going to have some rain but the 85 degree readings started even before rain started. When I woke up this morning I had lots of emails, 5 minutes apart, indicating that my outside DS18B20 was reporting 85 degrees (I read temperatures every 5 minutes and have the polling script email me if a sensor reports a temperature outside a range). It seems like we had some rain overnight because the ground was wet. However, it did not seem like it was a heavy rain, and we did not have any thunderstorms. So, with these perfect conditions, and knowing that the problem was occurring, I decided to take a first stab at fixing the problem. As I mentioned before, the easiest thing to try first was going to be to ground Vdd, which I've had floating since I installed this sensor the last week of November. And that was it! I've been running for 9 hours now and have not received another 85 degree reading. Furthermore, about 30 minutes ago we had a big thunderstorm with strong winds and heavy rain, and that did not cause the sensor to report 85 degrees. So there you have it, grounding Vdd is what fixed the 85 degree readings. I think I won't be needing fancy conformal coating after all -- the sensor is not directly exposed to the elements and it seems to be performing great now that I grounded Vdd. Regarding the root cause, I think some of you mentioned something about increased capacitance when humidity is high? It must have been something related to increased humidity since we did not have lightning when the problem started last night. I am not rushing to ground Vdd in all my other sensors right now, though, since they have not reported a single 85 degree reading in several months of operation. I guess it does not get that humid inside, although now that summer is close (and it gets really humid where I live) that may happen, so I shall see. In any case, the minute I get an 85 degree reading from a sensor I am grounding that sensor's Vdd. Guess DS18B20 sensors make for cheap high humidity detectors when Vdd is left floating ;-) Anyway, thanks to all for all the great comments and help. It's definitely been a very interesting thread. Cheers, Eloy Paris.- -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
[Owfs-developers] Dreaded 85 degrees C read from DS18B20 located outside
Hi list, Apologies for the slightly off-topic message but I figured someone here may have some suggestions for me on this non-owfs issue I am having... I have a DS18B20 sensor located outside. It is in a location that is safe from water (unless it rains horizontally). My bus master reaches this sensor through a cat5 bus that has about 10 more sensors. The sensor, its pins, and the small PCB the sensor is soldered to, are all exposed (to wind and humidity, but not to direct water). Parasitic powered, and Vcc pin is floating (not connected to ground). This setup has been pretty stable (no 1-wire errors or bad temperature readouts in 6 months of operation). Last night there was heavy rain and thunderstorms in the area and for a period of about two hours I was getting the dreaded 85 degrees C from this sensor. All other sensors were fine during this time and did not report 85 degrees. The problem fixed itself a bit after rain and thunderstorms passed. I think it is humidity what causes the 85 degrees C readout since we've had a few warm and humid days/nights recently (but no rain) and I've gotten a few 85 degrees C readouts here and there from the same sensor. But nothing like last night when I consistently got 85 degrees C readouts for about two hours. Next time this happens I plan on grounding Vcc to see if that helps, but I also wanted to ask the list for theories on what could be causing these 85 degrees C readouts when it is humid (or when there are thunderstorms in the area). If grounding Vcc does not help I think my next step should be to protect from the elements the sensor, its pins, and the small PCB. Any ideas on how to accomplish this; is there some coating I can spray on the sensor's pins and on the PCB that will protect them from humidity? Thanks in advance for any suggestions. Cheers, Eloy Paris.- -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Dreaded 85 degrees C read from DS18B20 located outside
Hi Mick, On 03/02/2011 04:41 AM, Mick Sulley wrote: Hi Eloy, I am using a mix of DS18B20 and DS18S20, my experience has been that they will work reliably when powered and also in parasitic mode if you link Gnd and Vdd, but if you don't they are a bit hit and miss on a sensor by sensor basis, one may work fine but another reads 85. Also when floating they don't seem to be sure if they are powered or not, some say they are and others say they are not. My advice therefore is to link Vdd to Gnd. I think this is sound advice even if things have worked well for me with 12 sensors that all have Vdd floating. Why it should be affected by humidity or thunder storms I don't know, but given that they seem to be a bit 'on the edge' with Vdd floating I guess it may change the resistance or capacitance slightly and push it over the edge. The capacitance effect will also be influenced by objects and materials in close proximity. Thanks for the insight! Good stuff in this thread; I'm glad I asked even if it was a bit off-topic for owfs :-) Also does anyone know if the 85 reading is irrespective of units? My setup is in degrees C, but if it was in F would the error still be 85 or would it be 185F? If it stays at 85 irrespective it is a way to differentiate an error from a genuine 85 reading. The 1820 only reports in degrees Celsius and it is owfs the one providing degrees F capabilities, right? If that is the case then I would expect 85 C to be reported by owfs in the equivalent degrees F. So yes, that is a good question -- how does one tell the difference between true 85 C and error 85 C? (not that I am expecting to read a true 85 C, although I suspect things get pretty hot in an attic in the summer). Cheers, Eloy Paris.- Best of luck Mick On Tue, 2011-03-01 at 12:54 -0500, Eloy Paris wrote: Hi list, Apologies for the slightly off-topic message but I figured someone here may have some suggestions for me on this non-owfs issue I am having... I have a DS18B20 sensor located outside. It is in a location that is safe from water (unless it rains horizontally). My bus master reaches this sensor through a cat5 bus that has about 10 more sensors. The sensor, its pins, and the small PCB the sensor is soldered to, are all exposed (to wind and humidity, but not to direct water). Parasitic powered, and Vcc pin is floating (not connected to ground). This setup has been pretty stable (no 1-wire errors or bad temperature readouts in 6 months of operation). Last night there was heavy rain and thunderstorms in the area and for a period of about two hours I was getting the dreaded 85 degrees C from this sensor. All other sensors were fine during this time and did not report 85 degrees. The problem fixed itself a bit after rain and thunderstorms passed. I think it is humidity what causes the 85 degrees C readout since we've had a few warm and humid days/nights recently (but no rain) and I've gotten a few 85 degrees C readouts here and there from the same sensor. But nothing like last night when I consistently got 85 degrees C readouts for about two hours. Next time this happens I plan on grounding Vcc to see if that helps, but I also wanted to ask the list for theories on what could be causing these 85 degrees C readouts when it is humid (or when there are thunderstorms in the area). If grounding Vcc does not help I think my next step should be to protect from the elements the sensor, its pins, and the small PCB. Any ideas on how to accomplish this; is there some coating I can spray on the sensor's pins and on the PCB that will protect them from humidity? Thanks in advance for any suggestions. Cheers, Eloy Paris.- -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Dreaded 85 degrees C read from DS18B20 located outside
Hi Guil, On 03/02/2011 09:42 AM, Guil Barros wrote: The sensor returns 85/185 at startup if it has not had a chance to do a complete convert_t by the time you read_t on it. My guess is its either shorting out somewhere and resetting or not getting enough juice to handle the convert_t. That's what I thought too. Something to do with high humidity in the air, perhaps? Are the other sensors ok? Are any of the other ones also outside? All other sensors are (were, actually, for the duration of this event) 100% perfect, i.e. no errors, no 85 degrees C returned. The other sensors are all inside. I actually experienced 85 degrees returned by another sensor (every now and then, not continuously for a period of time like in the case of this outside sensor two nights ago), and it that case it turned out that water had gotten inside the wire (this one was a sensor that was monitoring water temperature in a fish tank. I insulated the wire but didn't do a good job so water got in and caused 85 degrees readouts every now and then. As soon as I took the sensor out of the tank and it got dry the 85 degrees readouts stopped). I have my outside sensor covered in silicone. Its non-conductive, waterproof, etc. It will delay temp changes slightly as it has a higher specific heat capacity than air though, but not by much ;) I have heard of other people using wax for this also as it is easier to remove if needed but if you live in Texas it might melt off by itself if left in the sun in summer. Hhmmm. Interesting. Tips like these is exactly what I am after, so thanks a bunch for that. I like the idea of covering the sensor (or parts of the sensor and the PCB) with silicone. Do you remember what specific product you used (was it a spray, or just one of those tubes you buy at HomeDepot or Lowe's that you apply with a gun)? I also like the idea of using wax. I obviously had not thought about it. I suppose that in that case you melt the wax (like from a candle) in a pot and then dip the PCB into it. Is that they way people would do it? I also found about conformal coating while doing some searches last night. Guess that is the official name of what I am after. There are products to do conformal coating, although nothing you can find at your local hardware store, which is why I'd prefer to go with one of the two methods you mentioned. Hope that helps. It does; thanks a lot for the insight :-) Cheers, Eloy Paris.- On Tue, Mar 1, 2011 at 11:54 AM, Eloy Parispe...@chapus.net wrote: Hi list, Apologies for the slightly off-topic message but I figured someone here may have some suggestions for me on this non-owfs issue I am having... I have a DS18B20 sensor located outside. It is in a location that is safe from water (unless it rains horizontally). My bus master reaches this sensor through a cat5 bus that has about 10 more sensors. The sensor, its pins, and the small PCB the sensor is soldered to, are all exposed (to wind and humidity, but not to direct water). Parasitic powered, and Vcc pin is floating (not connected to ground). This setup has been pretty stable (no 1-wire errors or bad temperature readouts in 6 months of operation). Last night there was heavy rain and thunderstorms in the area and for a period of about two hours I was getting the dreaded 85 degrees C from this sensor. All other sensors were fine during this time and did not report 85 degrees. The problem fixed itself a bit after rain and thunderstorms passed. I think it is humidity what causes the 85 degrees C readout since we've had a few warm and humid days/nights recently (but no rain) and I've gotten a few 85 degrees C readouts here and there from the same sensor. But nothing like last night when I consistently got 85 degrees C readouts for about two hours. Next time this happens I plan on grounding Vcc to see if that helps, but I also wanted to ask the list for theories on what could be causing these 85 degrees C readouts when it is humid (or when there are thunderstorms in the area). If grounding Vcc does not help I think my next step should be to protect from the elements the sensor, its pins, and the small PCB. Any ideas on how to accomplish this; is there some coating I can spray on the sensor's pins and on the PCB that will protect them from humidity? Thanks in advance for any suggestions. Cheers, Eloy Paris.- -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https
Re: [Owfs-developers] Dreaded 85 degrees C read from DS18B20 located outside
Hi Paul, On 03/02/2011 08:49 AM, Paul Alfille wrote: That's interesting that the humidity effects only one sensor, not the whole bus. Yes, I also thought it was pretty interesting. Furthermore, I don't know if this makes this more interesting, or if it has any relevance, but this sensor that had the 85 degrees problem is not the last one on the bus -- the bus has 12 DS18B20s, and the one that had problems is #8. The 7 sensors before, and the 4 sensors after, didn't have any problems during the duration of the event. The HobbyBoards people used a special coating for their PCBs that seems effective. What is the design of your sensor -- what does the PCB do? Oh, the PCB is just a convenience so I don't have to mess up with wires (including soldering a sensor to the end of a cat5 cable) and so things look a bit more tidy and neat. The PCB is 100% passive; just a DS18B20 sensor and a female RJ-45 jack soldered to the PCB (in most cases there isn't even an RJ-45 since I just solder a short cat5 cable that ends in the male RJ-45 that then connects to the RJ-45 jack in the wall). I ordered the PCBs from BatchPCB using the Eagle and Gerber files from: http://www.digitemp.com/dt1a.shtml After reading p4trykx's reply (thanks p4trykx, BTW), though, I am thinking that for this outside location (the actual location is underneath the screened porch in the back of my house; that's why the location is safe from rain) it is better to go without a PCB, and just insulate a cat5 wire with heatshrink and some silicone, similar to what this wine cellar monitoring project uses: http://owfs.org/index.php?page=monitor-a-wine-cellar I made a sensor like the one in that page to monitor water temperature in a fish tank. The sensor got wet due to poor insulation on my part and it is not currently measuring water temperature, but it should be sufficiently protected to measure outside temperature at this location, so I may just repurpose it and build another sensor for the fish tank. That'll probably be the best solution. Cheers, Eloy Paris.- On Tue, Mar 1, 2011 at 12:54 PM, Eloy Parispe...@chapus.net wrote: Hi list, Apologies for the slightly off-topic message but I figured someone here may have some suggestions for me on this non-owfs issue I am having... I have a DS18B20 sensor located outside. It is in a location that is safe from water (unless it rains horizontally). My bus master reaches this sensor through a cat5 bus that has about 10 more sensors. The sensor, its pins, and the small PCB the sensor is soldered to, are all exposed (to wind and humidity, but not to direct water). Parasitic powered, and Vcc pin is floating (not connected to ground). This setup has been pretty stable (no 1-wire errors or bad temperature readouts in 6 months of operation). Last night there was heavy rain and thunderstorms in the area and for a period of about two hours I was getting the dreaded 85 degrees C from this sensor. All other sensors were fine during this time and did not report 85 degrees. The problem fixed itself a bit after rain and thunderstorms passed. I think it is humidity what causes the 85 degrees C readout since we've had a few warm and humid days/nights recently (but no rain) and I've gotten a few 85 degrees C readouts here and there from the same sensor. But nothing like last night when I consistently got 85 degrees C readouts for about two hours. Next time this happens I plan on grounding Vcc to see if that helps, but I also wanted to ask the list for theories on what could be causing these 85 degrees C readouts when it is humid (or when there are thunderstorms in the area). If grounding Vcc does not help I think my next step should be to protect from the elements the sensor, its pins, and the small PCB. Any ideas on how to accomplish this; is there some coating I can spray on the sensor's pins and on the PCB that will protect them from humidity? Thanks in advance for any suggestions. Cheers, Eloy Paris.- -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Dreaded 85 degrees C read from DS18B20 located outside
Hi patyrk, On 03/02/2011 05:09 AM, patyrk wrote: Dnia 2011-03-01, wto o godzinie 12:54 -0500, Eloy Paris pisze: If grounding Vcc does not help I think my next step should be to protect from the elements the sensor, its pins, and the small PCB. Any ideas on how to accomplish this; is there some coating I can spray on the sensor's pins and on the PCB that will protect them from humidity? I soldered some wire(20cm) directly to DS18b20 pins with VCC and GND together and put it in a heatshrink tube and placed the connector to the rest of the network inside. Good suggestion. I built a cable like that for monitoring water temperature in a fish tank. The sensor was actually submerged. It got wet because of bad final insulation (silicone not being tight) but I plan to try again. As I mentioned in my previous message to Paul, I think I will re-purpose this cable I am (was) using for the fish tank and use it outside instead. Maxim suggests connecting Vcc do GND when using parasite power. Maybe you have DS18B20+PAR with Vcc and GND already connected internally. Yup, I am aware of the recommendation. My current 12 sensors do not have Vcc grounded and they have been working fine so far, though. They are regular 18B20s, not the -PAR version. Related to this practice of not grounding Vcc when using parasitic power, I found this in the manual for iButtonLink's T-Sense sensor (http://www.ibuttonlink.com/pdf/manuals%20for%20t-sense%2005-22-08.pdf): NOTE: Important information There is a small chance that the bus could become unstable when using T-Sense units as the only sensor on the bus. This condition comes about as a result of the new design of the T-Sense, using the DS18B20 sensor. The third lead on the DS18B20, (Vdd) is left floating, (to allow design flexibility for sophisticated networks) which leaves the possibility of unpredictable performance. Our engineering department has not been able to create this condition. Experiments with 30 T-Sensors on the bus, and a variety of interfaces, have shown all devices working properly. In the unlikely event of unstable behavior on the bus, resolution can be accomplished by simply connecting pin 2 (+5 volts) to pin 6 (Aux). Alternately, any MS-xx product on the bus will provide the jumper internally, or the use of a LinkHub as the interface. Cheers, Eloy Paris.- -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Dreaded 85 degrees C read from DS18B20 located outside
Hi Jan, On 03/02/2011 03:49 AM, Jan Chrillesen wrote: On Tue, Mar 1, 2011 at 6:54 PM, Eloy Paris pe...@chapus.net mailto:pe...@chapus.net wrote: I have a DS18B20 sensor located outside. It is in a location that is safe from water (unless it rains horizontally). My bus master reaches this sensor through a cat5 bus that has about 10 more sensors. The sensor, its pins, and the small PCB the sensor is soldered to, are all exposed (to wind and humidity, but not to direct water). ... If grounding Vcc does not help I think my next step should be to protect from the elements the sensor, its pins, and the small PCB. Any ideas on how to accomplish this; is there some coating I can spray on the sensor's pins and on the PCB that will protect them from humidity? In my experience the 85 degrees issue can be caused by a number of issues. - bad timing on the bus (especially when using bitbanging) - reading high temperatures on a parasite powered bus - very long busses with lots of sensors (picking up noise) - capacitive issues on the wiring (often related to using shielded wiring) Since your busmaster (and hence timing) didn't change and you're most likely not reading 80+ degrees C outside, I think the suspect here is the wiring. If water entered your CAT5 cabel it's electrical properties will change and the capacity of the cable will change. Make sure that everything outside is totally isolated from water. I'll double check, but I am pretty sure that water did not enter the cat5 cable -- for that to happen rain must have had to be horizontal and with pretty strong winds. Humidity is the only thing that was probably different when the event occurred. Cheers, Eloy Paris.- -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Dreaded 85 degrees C read from DS18B20 located outside
Hi Roberto, On 03/02/2011 04:24 PM, Roberto Spadim wrote: hum, i had the same problem, when i read 85 i read again, if two reads are 85 i accept the 85 value (ok 1 lost 1 read, maybe 1 second per sensor) I think a better algorithm would be to look at the delta between consecutive readings -- your algorithm of doing a second read if the first one is 85 C would have failed (returned 85 C) in the situation that I had a couple of days ago since all readings from that sensor during a two-hour period returned a consistent 85 C. Making sure that the delta between current reading and previous reading is reasonable would allow one to accept a real 85 C (if for example the delta between current 85 reading and previous reading is, say 5 degrees), and to reject a false 85 C (if for example, the delta between current 85 reading and previous reading is 65 degrees). Cheers, Eloy Paris.- 2011/3/2 Eloy Parispe...@chapus.net: Hi Mick, On 03/02/2011 04:41 AM, Mick Sulley wrote: Hi Eloy, I am using a mix of DS18B20 and DS18S20, my experience has been that they will work reliably when powered and also in parasitic mode if you link Gnd and Vdd, but if you don't they are a bit hit and miss on a sensor by sensor basis, one may work fine but another reads 85. Also when floating they don't seem to be sure if they are powered or not, some say they are and others say they are not. My advice therefore is to link Vdd to Gnd. I think this is sound advice even if things have worked well for me with 12 sensors that all have Vdd floating. Why it should be affected by humidity or thunder storms I don't know, but given that they seem to be a bit 'on the edge' with Vdd floating I guess it may change the resistance or capacitance slightly and push it over the edge. The capacitance effect will also be influenced by objects and materials in close proximity. Thanks for the insight! Good stuff in this thread; I'm glad I asked even if it was a bit off-topic for owfs :-) Also does anyone know if the 85 reading is irrespective of units? My setup is in degrees C, but if it was in F would the error still be 85 or would it be 185F? If it stays at 85 irrespective it is a way to differentiate an error from a genuine 85 reading. The 1820 only reports in degrees Celsius and it is owfs the one providing degrees F capabilities, right? If that is the case then I would expect 85 C to be reported by owfs in the equivalent degrees F. So yes, that is a good question -- how does one tell the difference between true 85 C and error 85 C? (not that I am expecting to read a true 85 C, although I suspect things get pretty hot in an attic in the summer). Cheers, Eloy Paris.- Best of luck Mick On Tue, 2011-03-01 at 12:54 -0500, Eloy Paris wrote: Hi list, Apologies for the slightly off-topic message but I figured someone here may have some suggestions for me on this non-owfs issue I am having... I have a DS18B20 sensor located outside. It is in a location that is safe from water (unless it rains horizontally). My bus master reaches this sensor through a cat5 bus that has about 10 more sensors. The sensor, its pins, and the small PCB the sensor is soldered to, are all exposed (to wind and humidity, but not to direct water). Parasitic powered, and Vcc pin is floating (not connected to ground). This setup has been pretty stable (no 1-wire errors or bad temperature readouts in 6 months of operation). Last night there was heavy rain and thunderstorms in the area and for a period of about two hours I was getting the dreaded 85 degrees C from this sensor. All other sensors were fine during this time and did not report 85 degrees. The problem fixed itself a bit after rain and thunderstorms passed. I think it is humidity what causes the 85 degrees C readout since we've had a few warm and humid days/nights recently (but no rain) and I've gotten a few 85 degrees C readouts here and there from the same sensor. But nothing like last night when I consistently got 85 degrees C readouts for about two hours. Next time this happens I plan on grounding Vcc to see if that helps, but I also wanted to ask the list for theories on what could be causing these 85 degrees C readouts when it is humid (or when there are thunderstorms in the area). If grounding Vcc does not help I think my next step should be to protect from the elements the sensor, its pins, and the small PCB. Any ideas on how to accomplish this; is there some coating I can spray on the sensor's pins and on the PCB that will protect them from humidity? Thanks in advance for any suggestions. Cheers, Eloy Paris.- -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual
Re: [Owfs-developers] Dreaded 85 degrees C read from DS18B20 located outside
On 03/02/2011 05:36 PM, Scott wrote: Ooops! I pulled the security off that gallery which should fix it. Try it again. That worked; thanks! Eloy Paris.- I encased my sensors in epoxy to avoid water contact. Just solder up the sensor, mix up some 2-part epoxy, and smear it over the chip and any wire that will be in the water. I put on 2 coats just to sure it's water proof. I've found it works well for sensing temperature - they aren't pretty, but they track temps just fine. -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Dreaded 85 degrees C read from DS18B20 located outside
Hi Paul, On 03/02/2011 05:49 PM, Paul Alfille wrote: [...] 3. The wine cellar uses a DS18S20 in a plastic drinking straw with some GE RTV silicone sealant (from the hardware store) sealing the end. It's been immersed and functioning for 6 years now. Wow, that's great! I wasn't too lucky with my first attempt (it got wet inside). I'll keep trying, though. By the way, related question: is heat shrink supposed to be waterproof? I mean, if I heat-shrink a tube, can I leave it submerged? Maybe some static charge in the Vcc lead confused the sensor in the lightning storm? You know what, I want to get to the bottom of this so I have decided to do nothing now to try to fix the problem I experienced a couple of nights ago when we had lots of rain and thunderstorms. Allow me to explain: Whatever happened a couple of nights ago surely will happen again. When that happens I'll go outside and start with the simple stuff, i.e. grounding Vcc. I am hoping that the problem was caused by either high humidity, or by some weird electric problem caused by not having Vcc grounded. If it is the later I will be able to confirm it by grounding Vcc when the problem is happening. As I said, I have not had a single 85 degree reading since that night, so I have no need to try to fix things right. I'll report back as soon as I know more. By the way, thanks to everybody that have provided useful links and shared their war stories; it's been a very enlightening discussion. Cheers, Eloy Paris.- -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] new interfaces
On 01/18/2011 03:39 PM, Roberto Spadim wrote: i´m reading ow_com.c and there´s some telnet implementation, is it rfc2217 implementation?? Paul has been working on this. It started here, I think: http://www.owfs.org/statcvs/2010-12.html#37 Cheers, Eloy Paris.- 2011/1/18 Roberto Spadimrobe...@spadim.com.br: hi guys! could we implement ser2net client (serial over ethernet)? (it´s like serial RS232, but it use a tcp/ip channel, some bytes must be rewrited for example: to send we should send ) http://ser2net.sourceforge.net/ the RFC is here: http://www.faqs.org/rfcs/rfc2217.html the telnet rfc is here: http://www.faqs.org/rfcs/rfc854.html telnet remote flow contorl is here: http://www.faqs.org/rfcs/rfc1372.html could we implement a gpio bitbang ow bus? using /dev/gpio (i´m using friendlyarm mini2440, so i use /dev/leds), the ser2net is for all computers/ethernet devices (since we can run ser2net daemon on x86, intel x86_64, arm, alpha, and many others... even non linux computers since it´s rfc compatible) it´s more priority than gpio bitbang -- Roberto Spadim Spadim Technology / SPAEmpresarial -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] /settings/timeout/volatile not being honored?
Hi Paul, On 01/01/2011 10:09 AM, Paul Alfille wrote: You are using the timeout correctly, but there may be an issue with whether the timeout is sent to the owserver. What's your program setup? i.e. are you accessing owserver via owfs or owhttpd? You may have to set bus.0/settings/timeout_volatile. I access owserver via owfs. I just checked and bus.0/settings/timeout_volatile is set to the default of 15 seconds while settings/timeout_volatile has the 300 seconds I set it to. I'll change the former to 300 to see what happens. What is the difference between bus.0/settings/timeout_volatile and settings/timeout_volatile? I mean, which one gets used and under what circumstances? By the way, I no longer need to use a longer volatile timeout since I realized I cannot block for a few seconds even every five minutes (I am getting temperatures into the MisterHouse home automation program and MisterHouse cannot block while the 1-wire bus is read since then other home automation activities performed by MisterHouse cannot take place). Instead, I am reading owfs 1-wire data from a program that can block, and MisterHouse reads, without ever blocking, the data collected by this other program. Cheers, Eloy Paris.- -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
[Owfs-developers] /settings/timeout/volatile not being honored?
Hello, I set (dynamically) /settings/timeout/volatile to 300 seconds but doing successive cat /owfs/device address/temperature (a few seconds apart) still causes owserver to go out and fetch a new temperature sample (I think this is the case because the cat operation pauses a few seconds instead of printing data right away). I would have expected to get the same (cached) temperature for the next 300 seconds. Am I misunderstanding the way /settings/timeout/volatile should work? Is there a good way to check that owserver is honoring the volatile timeout and that it is not going out to the bus to fetch new data? I am running 2.8p1 and my bus master is a LinkUSB. What I want to accomplish by changing /settings/timeout/volatile is to prevent a process from blocking while the temperature file is being read. Is there a better way than relying on the volatile timeout? I thought that caching would help me here. Cheers, Eloy Paris.- -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] HOw to use owdir, owread, etc.?
Hi Chris, On 12/10/2010 05:08 PM, Chris G wrote: OK, thanks for the clarification. I hadn't quite got my mind round the fact that some of the owfs 'bits' are server processes and some are clients. Once I'd got past that I realised that I can run owhttpd with almost the same paramters as owfs (plus a port number) and then I can view the 1-wire bus sensor values as web pages - excellent! :-) Indeed, that's part of the beauty of the client-server architecture that owfs uses. Makes thing very flexible. Cheers, Eloy Paris.- -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] HOw to use owdir, owread, etc.?
Hi Chris, On 12/10/2010 03:45 PM, Chris G wrote: I have my owfs server running with USB master device:- /opt/owfs/bin/owfs -u -m /mnt/1-wire/ This works fine and creates appropriate directories in /mnt/1-wire/ where I can see the data from my temperature sensors. How then do I use owdir, owread, etc. to actually read the data? They seem to need a port number among other things and I don't see how I can know the port number that owfs is using. I just need some simple examples, whenever I run owdir and/or owread at the moment I get no output at all. As I understand it, owfs has moved to a client-server model where one server application (owserver) talks to the 1-wire bus and client applications talk, via sockets, to the server. And while some applications still retain the capability of talking to the bus directly (the owfs executable is the prime example), some other programs in the owfs package may not have that capability. So, if you want to use some of these programs that cannot talk to the 1-wire bus, you have to run owserver first, and then point the other applications to owserver by providing IP address and port to connect to (the protocol between owserver and the ow* clients uses TCP). Personally, I have an init.d script that starts owserver like this: /opt/owfs/bin/owserver -d /dev/ttyUSB1 -C --error_print 0 --error_level 1 --nozero Since you are using that USB-based master I think you'd have to replace my -d /dev/ttyUSB1 with just -u. After you have owserver running, you'd run owfs with something like: /opt/owfs/bin/owfs --allow_other -C -s localhost:4304 /owfs --nozero The other utilities are run in a similar way. Hope this helps. Cheers, Eloy Paris.- -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] HOw to use owdir, owread, etc.?
On 12/10/2010 03:45 PM, Chris G wrote:
I have my owfs server running with USB master device:-
/opt/owfs/bin/owfs -u -m /mnt/1-wire/
This works fine and creates appropriate directories in /mnt/1-wire/
where I can see the data from my temperature sensors.
How then do I use owdir, owread, etc. to actually read the data? They
seem to need a port number among other things and I don't see how I can
know the port number that owfs is using.
Oh, by the way, if you only want to read the data then you may not need
to mess with owserver -- just open the appropriate temperature file and
read from it. From shell scripts it is a simple as using cat:
$ cat /owfs/28.6618A202/temperature; echo
16.5625
If using some other scripting language, you can do something like (this
example is for Perl):
if (!open SENSOR, /owfs/28.6618A202/temperature) {
print STDERR Can't open temperature file: $!\n;
exit 1;
}
my $temperature = SENSOR;
close SENSOR;
$temperature =~ s/ *//; # 82.7375 - 82.7375
# Do something with $temperature
Cheers,
Eloy Paris.-
--
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] What do I need to run basic temperature measurement on Ubuntu 10.04?
Hi Chris, On 12/09/2010 03:06 PM, Chris G wrote: [...] This is where I may have a problem, I'm quite familiar with the ./configure, make, go round and try again sequence. However I may not have *space* to build the whole thing, I just need to build (hopefully) the non-GUI bits. If you just need to read temperature from a couple of DS18S20 sensors why don't you give digitemp a try? Very simple program that does not need any kernel support, is simple to build, and is just an apt-get install digitemp away. http://www.digitemp.com/ for more info. Cheers, Eloy Paris.- -- ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Directory listings empty - Proposed patch
Hi Jacob,
On 11/16/2010 12:08 PM, Jacob Joseph wrote:
Paul,
I don't think that works. recv() returns -1 when there's no data to
read.
It returns -1 when there's not data to read and the socket is in
non-blocking mode. But in that case errno is set to EAGAIN or
EWOULDBLOCK, so there should be a way to check whether the -1 is
returned for a real error, or because there is no data to read.
I don't know if we set the socket to non-blocking mode but if we do,
what about this:
if (recv(scs-file_descriptor, test_read, 1,
MSG_DONTWAIT | MSG_PEEK) = 0) {
if (errno != EAGAIN errno != EWOULDBLOCK) {
/* Error condition; close our side of the connection, etc. */
}
If we don't set sockets to non-blocking mode then we would not get -1 if
there's no data to read (we'd block in recv() instead) and we wouldn't
have to check for EAGAIN or EWOULDBLOCK, I think.
Cheers,
Eloy Paris.-
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Directory listings empty
Hi Jacob, On 11/07/2010 05:24 PM, Jacob Joseph wrote: [...] This does sound reasonable, and explains the intermittent nature. I should note, though, that it sometimes occurs immediately after mounting owfs. Hhmmm, I don't recall this ever happening to me immediately after mounting. My logging programs don't use the owfs mounted directory, instead using the owserver through python. I'm not using aliases. I recall reading about your troubles with them, but didn't put it together. Something you could do to further troubleshoot is to capture traffic between owserver and your program using tcpdump -- if you see connections being reset (TCP RSTs) or being terminated normally TCP FINs) then that may give you something to further investigate. If your program and owserver run on the same machine then remember that you need to use the loopback interface when capturing... Cheers, Eloy Paris.- -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Directory listings empty
Hi Jacob, On 11/08/2010 07:15 PM, Jacob Joseph wrote: [...] Eloy, the tcp connection being closed is definitely the cause. There's a FIN sent by the server after exactly 1 hour idle. Yup, this is exactly what I saw, packet by packet. The behavior is documented (--timeout_persistent_high in owserver's man page) and makes sense. I do wonder, however, if it is not a bug that an application keeps a connection alive after the server has closed the server to client side of the connection. The owfs application exhibits this behavior, and so does your application. The server has indicated, by sending the FIN, that it does not intend to send anymore data, so why would the application keep the client to server side of the connection open? Wouldn't proper application behavior be to close the connection upon receipt of the FIN and re-connect next time there is a need to read from the server? I haven't programmed at this level, though, so I don't know how the application (client) knows that the server has closed the server to client side of the connection, if that's possible to know. As a side note, I don't know if there are more packets in the capture and you just didn't include them below, so this may be old news, but in the case of the owfs application, after the connection is reset by the server, owfs reconnects again, automatically, causing a second read to succeed with no manual intervention. Anyway, glad you're making progress; let us know what you find. Cheers, Eloy Paris.- I'll take a closer look in time, but, for now, here are the packets: last packet before going idle: 18:02:16.751481 IP (tos 0x0, ttl 64, id 43050, offset 0, flags [DF], proto TCP (6), length 52) zaru.nuke.56502 zaru.nuke.4304: Flags [.], cksum 0x477a (incorrect - 0xd485), seq 26, ack 722, win 513, options [nop,nop,TS val 36893057 ecr 36893057], length 0 0x: 4500 0034 a82a 4000 4006 4b46 c0a8 6301 e.@.@.KF..c. 0x0010: c0a8 6301 dcb6 10d0 7625 71aa 761a 260a ..c.v%q.v.. 0x0020: 8010 0201 477a 0101 080a 0232 f181 Gz...2.. 0x0030: 0232 f181.2.. After one hour idle: 19:02:16.929998 IP (tos 0x0, ttl 64, id 50192, offset 0, flags [DF], proto TCP (6), length 52) zaru.nuke.4304 zaru.nuke.56502: Flags [F.], cksum 0x477a (incorrect - 0x562e), seq 722, ack 26, win 512, options [nop,nop,TS val 37253075 ecr 36893057], length 0 0x: 4500 0034 c410 4000 4006 2f60 c0a8 6301 e.@.@./`..c. 0x0010: c0a8 6301 10d0 dcb6 761a 260a 7625 71aa ..c.v..v%q. 0x0020: 8011 0200 477a 0101 080a 0238 6fd3 Gz...8o. 0x0030: 0232 f181.2.. 19:02:16.969946 IP (tos 0x0, ttl 64, id 43051, offset 0, flags [DF], proto TCP (6), length 52) zaru.nuke.56502 zaru.nuke.4304: Flags [.], cksum 0x477a (incorrect - 0xd7d1), seq 26, ack 723, win 513, options [nop,nop,TS val 37253079 ecr 37253075], length 0 0x: 4500 0034 a82b 4000 4006 4b45 c0a8 6301 e.@.@.KE..c. 0x0010: c0a8 6301 dcb6 10d0 7625 71aa 761a 260b ..c.v%q.v.. 0x0020: 8010 0201 477a 0101 080a 0238 6fd7 Gz...8o. 0x0030: 0238 6fd3.8o. upon 'ls': 19:06:50.802956 IP (tos 0x0, ttl 64, id 43052, offset 0, flags [DF], proto TCP (6), length 78) zaru.nuke.56502 zaru.nuke.4304: Flags [P.], cksum 0x4794 (incorrect - 0x3cad), seq 26:52, ack 723, win 513, options [nop,nop,TS val 37280462 ecr 37253075], length 26 0x: 4500 004e a82c 4000 4006 4b2a c0a8 6301 E..N.,@@.k*..c. 0x0010: c0a8 6301 dcb6 10d0 7625 71aa 761a 260b ..c.v%q.v.. 0x0020: 8018 0201 4794 0101 080a 0238 dace G8.. 0x0030: 0238 6fd3 0002 0004 .8o. 0x0040: 0105 2f00 /. 19:06:50.803033 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) zaru.nuke.4304 zaru.nuke.56502: Flags [R], cksum 0xdee0 (correct), seq 1981425163, win 0, length 0 0x: 4500 0028 4000 4006 f37c c0a8 6301 E..(@.@..|..c. 0x0010: c0a8 6301 10d0 dcb6 761a 260b ..c.v.. 0x0020: 5004 dee0 P... ~Jacob -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Directory listings empty
On 11/05/2010 05:22 PM, Jacob Joseph wrote: Paul, I was curious if you'd ever managed to reproduce my issues with directory listings. In 2.8p2 (haven't tried 2.8p3), it still happens. The first 'ls' shows bus.0 settings statistics structure system uncached, and a second shows these and devices. Do you have something continuously reading the owfs-mounted directory, like every 5 minutes or so (in reality at least once per hour)? I had the same problem before I deployed my network and before I started to read every 5 minutes via a cron job. I troubleshot and found that the problem was that owserver was timing out after 3600 seconds of inactivity the TCP connection established by owfs. The first read attempt would cause the connection to be reset and the second read attempt would cause owfs to initiate a new connection. That's why the first ls showed no devices and the second one, just a second later, would show devices. Don't know if this is your problem but thought I'd mention it since your description of the problem seemed very similar to what I experienced. I also ran into a similar situation when I was using aliases. That one looked like a bug but I didn't chase it down and instead stopped using aliases. Are you using aliases? Cheers, Eloy Paris.- On Sun, 4 Apr 2010 21:15:01 -0400 Paul Alfillepaul.alfi...@gmail.com wrote: ... The current problem list includes: FreeBSD and OSX configuration Flakiness on directory listing is some circumstances Avahi/Bonjour library problems. Report of problems on high-concurrency use of owserver Any other suggestons? Paul Alfille -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] OWFS roadmap
Hi Rob,
On 10/28/2010 04:54 AM, Rob Conway wrote:
[...]
I would also like to know if the Alias function is OK. I can remember
some time ago there was some kind of caution in using the alias file.
When I tried using aliases I got random read failures so I stopped using
them and instead implemented aliases in my polling script:
--
my %sensors = (
28.EC30A502 = bedroom1,
28.154BA602 = bedroom2,
28.6618A702 = bedroom_master,
28.B844A902 = garage,
28.CE489202 = breakfast_nook
);
foreach my $sensor (keys %sensors) {
if (!open SENSOR, /owfs/$sensor/temperature) {
print STDERR Can't open temperature file for sensor $sensor:
$!\n;
next;
}
my $temperature = SENSOR;
close SENSOR;
$temperature =~ s/ *//; # 82.7375 - 82.7375
$output .= $sensors{$sensor}:$temperature ;
}
--
(This produces output that can be consumed by a Cacti external poller
script.)
This has been very stable for me. I first reported the problem of read
failures when using aliases in this message, but I never heard from
anyone on it:
http://sourceforge.net/mailarchive/message.php?msg_name=4C8A12DC.8090509%40chapus.net
Cheers,
Eloy Paris.-
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] OWFS roadmap
Hi Marcus, On 10/28/2010 10:18 AM, Marcus Priesch wrote: Hi there, also LinuUSB detection and communication is currently not working out-of-the box ... i posted a patch for 2.8p2. it is related to enabling rts/cts handshake - but maybe this is dependent on the kernel version running (and the ftdi driver) ?!?! - for me it only works when i enable rts/cts - but i assume it worked before without ... otherwise it wouldnt be as it is ... or ?!? see http://sourceforge.net/mailarchive/message.php?msg_name=1287595146.2032.7.camel%40pr-laptop I also ran into the rts/cts needed for the LinkUSB problem and also wondered why it didn't seem to bite everybody. I asked the iButtonLink guys and they said it worked for them without any special tweaks so I suspect the problem depends on the kernel or FTDI driver. Paul added some fix for this in 2.8p2. I haven't tested it and since you are running 2.8p2 and still need to patch to turn on hardware flow control I suspect Paul's change doesn't fix things. Here's the description of Paul's change from the 2.8p2 release notes: 6. Add hardware flow control to com port settings in third attempt to set up serial bus master (should help with some USB/serial convertors). And here is the original discussion where it was found that hardware flow control is needed for the LinkUSB to work: http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTi%3DE8zGBqoG%2BMwUL8rYTi-3X-m0Lkp2w0ytg-FW2%40mail.gmail.comforum_name=owfs-developers Cheers, Eloy Paris.- -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] OWFS roadmap
On 10/28/2010 09:11 PM, Paul Alfille wrote: Good question about the roadmap: 1. Fix current issues (like the rwlock, alias, and LinkUSB). Is there a bug track system where one can read about current issues? In other words, I'd like to know the details about these issues you mention to see if they are the same I have run into. I follow this mailing list but sometimes that is not enough to know whether an issue you have run into has already been reported. Cheers, Eloy Paris.- -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] weird problem with LinkUSB ...
Hi Marcus, On 09/16/2010 07:13 AM, Marcus Priesch wrote: Hi Paul, thanks for your answer, i have tested both with and without hw handshaking in minicom - and both work ... ?!? so is there something i can do to get rid of this ... ?!?! do you have any hints ?!?! because i need to set up a bunch of weather stations and ds9490 is currently out of stock - so i plan on using the LinkUSB ... but when it's not fully working ... ?!? btw: i have now tested a new kernel 2.6.34-gentoo-r6 but just the same thing ... i currently compile 2.6.32-gentoo-r7 which matches closest the kernel running on ubuntu (2.6.32-24) ... maybe this works ... Could you send the output from stty -a /dev/ttyUSB1 (change /dev/ttyUSB1 to reflect the correct device for you LinkUSB) when using minicom with and without hardware flow control enabled? Cheers, Eloy Paris.- Am Mittwoch, den 15.09.2010, 11:19 -0400 schrieb Paul Alfille: Yes. I found the LinkUSB has problems with hardware handshaking. When stable, the next version of owfs will work consistently with the LinkUSB. (At least with extensive tests on my platform). -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] OWFS stability
Hi Doma, list, On 09/10/2010 05:02 AM, Molnar Domokos wrote: Hi, I have just read the thread *owfs-mounted directory fails first time after inactivity period http://sourceforge.net/mailarchive/message.php?msg_name=4C7825D1.2070809%40chapus.net *and may have something related to it. I also have additional information related to this -- I am now polling the sensors every five minutes so the TCP connection from owfs to owserver is not timing out, as described in the above thread, and things are pretty stable. Before finishing my implementation, though, I played with the alias feature: http://owfs.org/index.php?page=aliases and that *was* causing the same stability problems described in the above thread, but in a different way, i.e. I sniffed traffic on the wire and the TCP connection was not dying, if I remember correctly, but still my sensors would disappear from the owfs-mounted directory every now and then. I didn't troubleshoot any further, and just stopped using OWFS aliases (handled the 1-wire address to sensible sensor name matter in the script that polls sensor data), and this made the instability problem go away. So, a shot in the dark -- are you using OWFS aliases? Based on a quick look at your log entries below it doesn't seem like it but I thought I'd ask just in case and also take this as a chance to document my experience with the alias feature since I had not done that yet. Cheers, Eloy Paris.- I have been running owfs lights out to control my HVAC at home for about 3 years, I have switches and temp sensors on it, and it works in real time so I had to resolve the stability issue with programming around. My HVAC controller reads the temperature of the furnace in a loop as it needs to act fast on temperature changes by switching on/off the gas burner and water pumps and magnetic valves. As a result I have a fair bit of experience with the stability of owfs. It is not very stable so I my controller does the following: Level1: The code catches the read/write exception of owfs provided files and retries max. 10 times, if does not succeed then Level2: Kills owfs with -9, umounts /mnt/1wire and restarts owfs If Level2 error happens it logs the event. Level1 error happens about every other day, while Level2 happens less frequently but it really is random. Here is the log for Level2 events from 1st of August this year. As you can see sometimes it goes on for 10, even 20 days w/o Level2 errors, then it just happens. Nothing changes in the usage pattern of the network or the controller, all sensors are continuously read, and all PIOs are written. The exceptions are mostly No such file or directory but sometimes Software caused connection abort happens too. It runs on a CentOs 5.4., with owfs 2.7p39, with zero caching as I need the new values every time. LOGITEM BEGIN @Mon Aug 2 22:14:07 2010 Logging reason: Owfs restart logging Active state: Off Exception message: #Errno::ECONNABORTED: Software caused connection abort - /mnt/1wire/10.869724010800/temperature State history : (Off)-(Off)-(Off)-(Off)-(Off) LOGITEM END LOGITEM BEGIN @Sat Aug 7 18:58:15 2010 Logging reason: Owfs restart logging Active state: Off Exception message: #Errno::ENOENT: No such file or directory - /mnt/1wire/10.869724010800/temperature State history : (Off)-(Off)-(Off)-(Off)-(Off) LOGITEM END LOGITEM BEGIN @Sun Aug 8 16:47:18 2010 Logging reason: Owfs restart logging Active state: Off Exception message: #Errno::ENOENT: No such file or directory - /mnt/1wire/10.869724010800/temperature State history : (Off)-(Off)-(Off)-(Off)-(Off) LOGITEM END LOGITEM BEGIN @Sat Aug 14 20:20:50 2010 Logging reason: Owfs restart logging Active state: Off Exception message: #Errno::ENOENT: No such file or directory - /mnt/1wire/10.869724010800/temperature State history : (Off)-(Off)-(Off)-(Off)-(Off) LOGITEM END LOGITEM BEGIN @Sun Aug 15 07:24:49 2010 Logging reason: Owfs restart logging Active state: Off Exception message: #Errno::ENOENT: No such file or directory - /mnt/1wire/10.869724010800/temperature State history : (Off)-(Off)-(Off)-(Off)-(Off) LOGITEM END LOGITEM BEGIN @Wed Aug 18 09:19:22 2010 Logging reason: Owfs restart logging Active state: Off Exception message: #Errno::ENOENT: No such file or directory - /mnt/1wire/05.1AED3100/PIO State history : (Off)-(Off)-(Off)-(Off)-(Off) LOGITEM END LOGITEM BEGIN @Mon Sep 6 19:35:40 2010 Logging reason: Owfs restart logging Active state: Off Exception message: #Errno::ENOENT: No such file or directory - /mnt/1wire/05.20023200/PIO State history : (Off)-(Off)-(Off)-(Off)-(Off) LOGITEM END LOGITEM BEGIN @Thu Sep 9 13:47:47 2010 Logging reason: Owfs restart logging Active state: Off Exception message: #Errno::ENOENT: No such file or directory - /mnt/1wire/10.24E323010800/temperature State history : (Off)-(Off)-(Off)-(Off)-(Off) LOGITEM END Cheers, Doma
Re: [Owfs-developers] Can't Get OWFS to work
Hi Mick, On 09/02/2010 03:42 PM, Mick Sulley wrote: Hi, I have a feeling I have missed something really basic here, but anyway... I'm on Ubuntu server 10.04. I am trying to get just basic owfs working, I have downloaded the tar, and unpacked it to /usr/local/src/owfs-2.8p2 I run sudo ./config and it all looks OK but when it finishes it says under Module config that owfs is disabled. I have tried running sudo ./config --enable-owfs but that gives me some messages, the end of which is - checking if owfs is enabled... yes checking fuse.h usability... no checking fuse.h presence... no checking for fuse.h... no configure: WARNING: Can't find fuse.h - Add the search path with --with-fuseinclude configure: WARNING: Install FUSE-2.2 or later to enable owfs - download it from http://fuse.sourceforge.net/ configure: error: Configure without --enable-owfs to detect fuse automatically. I thought that fuse is now part of the kernel and does not need to be installed explicitly. Can anyone point me in the right direction please? Try this: sudo apt-get install libfuse-dev FUSE is part of the kernel but the whole idea behind FUSE is to be able to have filesystems in userspace, so there is a userspace component (library) as well that provides an API that applications must use. The include files and related development stuff is provided by the libfuse-dev package. Cheers, Eloy Paris.- -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Read from owfs-mounted directory fails first time after inactivity period
Hi Paul, On 09/01/2010 06:57 AM, Paul Alfille wrote: Does this happen if you are reading the fake directory instead of a real bus? I'm trying to distinguish between a cache problem and a FUSE problem. Pardon the ignorance but how do I read from the fake directory instead of a real bus? Or asked another way, where are the fake directory and the real bus? I have: $ mount [...] OWFS on /owfs type fuse.OWFS (rw,nosuid,nodev,allow_other) Doing ls /owfs yields: $ ls /owfs bus.0 settings statistics structure system uncached Doing ls /owfs a second time shows all my sensors + a new alarm directory: $ ls /owfs 28.0B1DA202 28.4C0AA202 28.A049A202 28.CE489C02 alarm simultaneous system 28.154BA202 28.4E09A202 28.B153A102 28.D622A202 bus.0 statisticsuncached 28.3F2CA202 28.6618A202 28.B844A202 28.EC30A202 settings structure Cheers, Eloy Paris.- On Fri, Aug 27, 2010 at 4:53 PM, Eloy Paris pe...@chapus.net mailto:pe...@chapus.net wrote: Hello, I've seen this a few times... after some amount of inactivity, i.e. nobody reading from the owfs-mounted directory for some time, the first attempt to read from a file in the owfs-mounted directory fails: $ for i in 28.*; do cat /owfs/$i/temperature; done; echo cat: /owfs/28.*/temperature: No such file or directory Doing the same thing right after the failure does work. Not sure it happens every time there is inactivity. Is this normal behavior? Cheers, Eloy Paris.- -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Read from owfs-mounted directory fails first time after inactivity period
Hi Paul, On 09/01/2010 07:24 AM, Eloy Paris wrote: On 09/01/2010 06:57 AM, Paul Alfille wrote: Does this happen if you are reading the fake directory instead of a real bus? I'm trying to distinguish between a cache problem and a FUSE problem. Pardon the ignorance but how do I read from the fake directory instead of a real bus? Or asked another way, where are the fake directory and the real bus? I think I now understand what you meant... I am now starting owserver like this: /opt/owfs/bin/owserver --fake=28.0B1DA202,28.4C0AA202 ... I'll let you know if I see a failure after some inactivity period but please let me know if using fake devices is not what you meant. Cheers, Eloy Paris.- -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Read from owfs-mounted directory fails first time after inactivity period
Paul, On 09/01/2010 08:49 AM, Eloy Paris wrote: I think I now understand what you meant... I am now starting owserver like this: /opt/owfs/bin/owserver --fake=28.0B1DA202,28.4C0AA202 ... I'll let you know if I see a failure after some inactivity period but please let me know if using fake devices is not what you meant. When using fake devices I can still see the problem: $ ls /owfs bus.0 settings statistics structure system uncached run command again right away $ ls -F /owfs 28.0B1DA202/ 28.4C0AA202/ 28.A049A202/ 28.CE489C02/ alarm/ simultaneous/ system/ 28.154BA202/ 28.4E09A202/ 28.B153A102/ 28.D622A202/ bus.0/ statistics/uncached/ 28.3F2CA202/ 28.6618A202/ 28.B844A202/ 28.EC30A202/ settings/ structure/ Does this point to a FUSE problem then? I'll see if I can find some FUSE-related timeout controls... Cheers, Eloy Paris.- -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
