Am 06.11.2015 um 23:49 schrieb Colin Reese:
> Twisted pairs will have higher capacitance than non-twisted pairs in Cat5.
> The medium between non-twisted conductors is mixed - air and dielectric -
> but will always be greater than the twisted pairs.
>
> So, comparing a twisted DQ/GND and DQ/GND co
Am 07.11.2015 um 10:26 schrieb Colin Law:
>>
>> When you connect the ground line to data-, you have a different current
>> on the common ground/data- line because the ground line also carries the
>> supply current. So there's no way the receiver can successfully
>> eliminate line noise. Instead, it
Am 07.11.2015 um 08:47 schrieb Martin Patzak (GMX):
>
> With owfs I can use --debug and additionally an --error_level setting to
> select the amount of debug information
> --foreground I used to see if owserver need this
>
--debug is the same as "--foreground --error_level=9"
See module/owlib/sr
Am 07.11.2015 um 17:24 schrieb Colin Law:
>>
>> *BUT* this only works when the host ground is *not connected* to earth,
>> not even by a noise filter.
>> As soon it is, your circuit isn't symetrical
>> anymore as one of your two data wires (the "ground") is tighter coupled
>> to earth than the othe
Am 07.11.2015 um 22:06 schrieb Colin Law:
>
> Hm, not sure. With inductive loop pickup is it not right that the
> noise is not relative to ground, but is around the loop, so it is not
> trying to get to ground, just round the loop. So I am not sure
> whether capacitance to ground is relevant.
>
Am 09.11.2015 um 09:26 schrieb Martin Patzak (GMX):
>
> Depending on your built and packaging the --debug option may merely
> print a DEBUG statement, but not actually do any debugging.
>
Really, I don't know why the debian package maintainer disabled debug
support at all. Maybe there's another p
Am 09.11.2015 um 09:26 schrieb Martin Patzak (GMX):
> To recap:
> the debian package for owfs and owserver does not honor --debug option,
> but merely prints a DEBUG statement in the beginning
> owfs does print error-level information of level 3 only, if
> --error-level is set to 3 or higher. If
Am 09.11.2015 um 15:53 schrieb David Jackson:
>
> ! server: server = localhost:4304
>
This means: all owfs programs but owserver should connect to a running
owserver.
> server: usb = all
>
This means: owserver should connect to an DS2490 based USB adapter (as
the DS1490F is) connected to any usb
Am 09.11.2015 um 17:36 schrieb David Jackson:
> Ok so when I run the following when I run the following command:
>
> $sudo owfs [-c owfs.conf] -F -u -m /mnt/1wire —allow_other
>
No, no, no.
You have to decide whether you want to use the setup from the config
file or a setup on the command line.
Am 09.11.2015 um 18:14 schrieb Martin Patzak (GMX):
>
> The package maintainer is Vincent , would you
> please ask him what is going on?
>
The debian/rules file from
http://http.debian.net/debian/pool/main/o/owfs/owfs_2.9p8-6.debian.tar.xz
clearly specifies --disable-debug as a configure option
Am 09.11.2015 um 19:14 schrieb David Jackson:
>
> Ok did that!
> kdj@raspberrypi ~ $ sudo owserver -c y
> kdj@raspberrypi ~ $ top
>
> top - 11:53:16 up 8 min, 1 user, load average: 0.06, 0.10, 0.06
> Tasks: 68 total, 1 running, 67 sleeping, 0 stopped, 0 zombie
> %Cpu(s): 0.3 us, 1.7
Am 09.11.2015 um 19:30 schrieb Roland Franke:
> Hello,
> have you build owfs self INCLUDING the USB settings?
> Maybe when that be missing, you will never can read sensors.
> Also will you will be sure, that OW_HTTPD will not access
> to the USB-adapter during the time you start owserver/owfs?
> Th
Am 09.11.2015 um 21:14 schrieb David Jackson:
>
> did this after a reboot.!
>
> ps -Af | grep ow
> root 2134 1 0 13:35 ?00:00:00 /usr/bin/owserver -c
> /etc/owfs.conf --pid-file /var/run/owfs/owserver.pid
> root 2213 1 0 13:35 ?00:00:00 /usr/bin/owhttpd -c
>
Am 10.11.2015 um 01:23 schrieb David Jackson:
> So update 2 :) Im puzzled. Unplugging ALL devices allows the fob to
> be seen. I can plug in a “phone cord” still see Fob.
>
Good. Means you phone cord is ok.
> But if I plug in
> either of my Temp sensors from hobby-boards.com I can no longer even
Am 14.11.2015 um 17:09 schrieb Michael Kalist:
> HI all how can I get this to run in owfs.conf
>
> /opt/owfs/bin/owserver -a alias.txt -u -p 3000
>
server: alias=alias.txt
server: port=3000
> /opt/owfs/bin/owhttpd -s 3000 -p 3001
>
http: server=localhost:3000
http: port=3001
> /opt/owfs/bin
Am 15.08.2015 um 16:45 schrieb Matthias Urlichs:
> Hi,
>
> I have an older 1wire network with a bunch of DS2409 (1st-gen HobbyBoards
> hub,
> among others). I just tried to replace a DS9490R with a LinkUSB interface.
> The
> result was … less than I expected.
>
> # owdir
> /1F.0CB20400
>
Am 16.11.2015 um 20:58 schrieb Colin Reese:
> While we are on adapter compatibility, I was looking at some DS1982
> by request and noticed that it and a few other of its ilk (1985,1986)
> require a programming pulse of 12V.
>
> I also noted that the DS9490R, linkusb, and anything else without
> ac
Am 17.11.2015 um 11:45 schrieb Matthias Urlichs:
> On 17.11.2015 06:39, Nigel Titley wrote:
>> iButtonlink have confirmed that the Link45/LinkUSB doesn't crawl the OW
>> bus but expects the higher level code to do this.
>
> The question is whether it supports the "match ROM + command+data +
> sea
Am 17.11.2015 um 15:42 schrieb Matthias Urlichs:
/* 2409 switch -- branch status -- note that bit value is reversed */
static ZERO_OR_ERROR FS_r_branch(struct one_wire_query *owq)
{
BYTE data = 0 ;
OWQ_U(owq) = (((data) & 0x01) | ((data >> 1) & 0x02)) ^ 0x03;
Am 17.11.2015 um 15:59 schrieb Matthias Urlichs:
> On 17.11.2015 15:12, Jan Kandziora wrote:
>> Errm. That's exactly the same as a "two-bit-array" with valid values 00,
>> 01, 10.
>
> Right. However, bits are supposed to be independent of each other. These
>
Am 17.11.2015 um 16:53 schrieb Matthias Urlichs:
>
> OK. I'll prepare something soon-ish, assuming that nobody beats me to it
> (got a ton of non-OWFS bugs to go through first).
>
I had kept my patch private because it seemed to mee there was no great
interest in the general public. Now it's ther
Am 17.11.2015 um 19:18 schrieb Jan Kandziora:
> Am 17.11.2015 um 16:53 schrieb Matthias Urlichs:
>>
>> OK. I'll prepare something soon-ish, assuming that nobody beats me to it
>> (got a ton of non-OWFS bugs to go through first).
>>
> I had kept my patch private
Am 22.11.2015 um 16:03 schrieb Stefano Miccoli:
> Sorry if I repeat myself, but this problem is still unsolved as of
> branch master 0ea833c.
>
> $ git grep -n '#include <[a-z]*usb\.h>'
> module/owlib/src/include/ow.h:305:*#include *
> module/owlib/src/include/ow_usb_cycle.h:58:*#include *
>
Rem
Hi all,
we have had some important fixes recently
* Paul merged his regex branch.
* Johan Ström added support for the LINK aux line.
* Paul added some basic support for the Hobbyboards Multitemp.
* Thomasz Torcz and Stephano Miccoli fixed the libusb0 problems
* I myself fixed the "external" senso
Am 23.11.2015 um 09:51 schrieb Colin Reese:
> I've got my DS490R up and recognizing my Moat device, with a DS18B20
> also connected I get:
>
> 28.246A5005 alarm F0.18FDE6789C56 simultaneous structure uncached
> 81.D39F2D00 bus.0 settings statisticssystem
>
> Reading the
Am 23.11.2015 um 18:22 schrieb Colin Reese:
> I did not rebuild my slave. Everything else is nice and fresh as of last
> night.
>
Ok, I ask more specifically: Matthias' owfs archive clone is a bit
dated. Did you use that one or have you exported the moat patch and
merged it into your main archiv
Am 23.11.2015 um 19:01 schrieb Colin Reese:
> To double check can you point me to it? I've lost things in this pile of
> mails.
>
I see now Matthias has merged the newest changes from the main
repository two days ago. So there shouldn't be a problem if you'd
recompiled the host code yesterday. D
Am 23.11.2015 um 19:15 schrieb Colin Reese:
> No, I am indeed using:
>
> https://github.com/M-o-a-T/owfs.git
>
> Where is the main archive?
>
$ git clone git://git.code.sf.net/p/owfs/code owfs-code
Kind regards
Jan
--
Am 24.11.2015 um 17:56 schrieb Matthias Urlichs:
> On 24.11.2015 17:10, Matthias Urlichs wrote:
>> I'll take a look ASAP.
>
> I have rebased my "master" branch. Seems I mistyped a branch name
> yesterday. Sorry about that.
>
> I'd be even happier with the idea of releasing if somebody found the
>
Am 25.11.2015 um 01:13 schrieb Stefano Miccoli:
> I have a bug on my RPi: (no time to investigate right now, but reporting,
> just in case it can be reproduced).
>
> start owserver as
>
> owserver --tester=DS18S20 —debug
>
> and run (in another terminal)
>
> owread /10.10EF
>
> and ow
Am 25.11.2015 um 10:03 schrieb Stefano Miccoli:
> Cannot check right now, but if I didn’t do something terribly wrong I
> should be at the latest commit on master, so below e85572.
>
> It seems to me that actually e85572 introduced the bug:
>
> http://sourceforge.net/p/owfs/code/ci/e855721f4e02fd
Am 26.11.2015 um 22:55 schrieb Johan Ström:
>
> Re-adding the -EISDIR check fixes the issue (but, I assume, restore the
> original external issue).
> If we have no proper fix for the original external issue right now, I
> suggest re-adding this check until we do have a proper fix, so at least
>
Am 27.11.2015 um 00:19 schrieb Matthias Urlichs:
> On 25.11.2015 03:16, Matthias Urlichs wrote:
>> On 25.11.2015 00:42, Stefano Miccoli wrote:
>>> are you sure that owserver is *really* dead?
>> Of course I am.
>>
>> I'll try to investigate more, the next time that happens.
>> Shouldn't be too long
Am 27.11.2015 um 11:56 schrieb Matthias Urlichs:
> On 27.11.2015 00:41, Jan Kandziora wrote:
>> Matthias, always read "uncached" instead of the root dir when
>> investigating such things. The cache makes bus listing results a bit
>> unpredictable.
>
> I kn
Am 28.11.2015 um 09:36 schrieb Matthias Urlichs:
> On 27.11.2015 18:08, Jan Kandziora wrote:
>> It's perfectly okay you may only see a single chip when listing a cached
>> directory.
>
> Not if the chip never was at that bus position in the first place.
>
That'
Am 25.11.2015 um 01:13 schrieb Stefano Miccoli:
> I have a bug on my RPi: (no time to investigate right now, but reporting,
> just in case it can be reproduced).
>
> start owserver as
>
> owserver --tester=DS18S20 —debug
>
> and run (in another terminal)
>
> owread /10.10EF
>
> and ow
Am 01.12.2015 um 14:06 schrieb Sven Geggus:
> Jan Kandziora wrote:
>
>> I think it's enough stuff for a new release, since the last one which was
>> in March.
>
> Would you mind adding these patches as well:
> https://github.com/marcin1j/openwrt-packages
Am 06.12.2015 um 13:45 schrieb Jaroslav Sobota:
>
> He also suggested this patch
> https://github.com/marcin1j/openwrt-packages/blob/2163437b1afd7eeec486721fcf9503362c19b77c/utils/owfs/patches/101-fix-no-reset-routine-segfault.patch
> which worked fine at that time but it does not work anymore.
>
Am 27.12.2015 um 08:22 schrieb Haas Martin:
> Hi i am not able run owserver White startup parametr --w1, my raspberry pi
> 2 is confgigured to use gpio 4 for onewire, ow server can't read from
> kernel driver.
>
With distribution do you use? Raspbian?
There are various reasons why this may fail.
Am 27.12.2015 um 16:35 schrieb Mike Kalist:
> Hi All I know this is probably not the right place for this but
> after hours of google thought i wold throw this out there.
>
> I want to make a local website to send commands to pi all on local
> server
>
> push button on click send a server
Am 27.12.2015 um 18:22 schrieb Haas Martin:
> Hi Jan,
>
> I am using on py Ubuntu - Mate
> There is debug log :
> root@hama-pi:/var/lib# owserver --debug --w1 -c /etc/owfs.conf
> DEBUG MODE
> libow version:
> 2.9p8
>
This is pointless, as the debug output is disabled in the available
debia
Am 28.12.2015 um 23:19 schrieb Markus Gaugusch:
> Hi,
>
> I'm using Ubuntu 15.10 and the included owfs (2.9p8) is quite old. I'd
> like to build a current version, but all information I could find for
> building on Ubuntu is quite outdated (based on 12.04 and cvs).
>
> Best option for me would
Am 29.12.2015 um 16:39 schrieb Ursin Soler:
>
> By this year (initial release 7/15) Maxim released the DS28E17 [1]
> which is in my oppinion a game changer. This is (to my knowledge) the
> first time a 1-wire slave has been released that allows to connect
> any micro-proc (like Arduino/AVR) in a g
Am 29.12.2015 um 16:39 schrieb Ursin Soler:
>
> By this year (initial release 7/15) Maxim released the DS28E17 [1]
> which is in my oppinion a game changer.
>
I like to add, the DS28E17 is only available in a very tiny 16TQFN-EP
package, which is very hard to solder by hand (0.5mm pitch, no leads)
Am 29.12.2015 um 19:43 schrieb Jan Kandziora:
> Am 29.12.2015 um 16:39 schrieb Ursin Soler:
>>
>> By this year (initial release 7/15) Maxim released the DS28E17 [1]
>> which is in my oppinion a game changer.
>>
> I like to add, the DS28E17 is only available in a
Am 30.12.2015 um 06:37 schrieb Matthias Urlichs:
> On 30.12.2015 06:02, Jan Kandziora wrote:
>> is it possible to create a Onewire->I²C bridge with your MOAT? If
>> possible as a drop-in replacement of the DS28E17, at least from onewire
>> view?
>
> I see no im
Am 31.12.2015 um 09:30 schrieb Colin Reese:
> Can somebody explain to me why on earth people use so many 1wire
> buses?
>
You may want to have topographical addressing when you only have
iButtons and passive Keylocks. In that case, the only chance to find out
where the iButton was plugged is to ch
Am 31.12.2015 um 09:17 schrieb Henrik Östman:
>
> I have a question, why does some of my 1-wire devices get listed several
> times by OWFS? They have the same ID and inode-number, so now my
> application have to filter out the duplicates.
> I'm running OWSERVER:
>
> owserver version:
> 2.8
Am 31.12.2015 um 21:59 schrieb Jerry Scharf:
>
> I've been lurking for a while. This isn't exactly 1-wire related, but I
> know a bunch of people on this list are interested in control systems.
>
As I'm doing a similar thing professionally (with Onewire, OWFS, Tcl,
Raspi), I first want to point
Am 01.01.2016 um 14:25 schrieb Solèr Ursin:
> Hello
>
> Thanks for your participation and hints.
>
>> I don't get what you mean by "generic interface as for any other
>> chip supported by OWFS". Do you mean we should provide a framework
>> for bitbanging arbitrary data through the I?C interface,
Am 02.01.2016 um 01:08 schrieb Solèr Ursin:
Am 01.01.2016 um 14:25 schrieb Solèr Ursin:
> Hello
>
> Thanks for your participation and hints.
>
>> I don't get what you mean by "generic interface as for any other
>> chip supported by OWFS". Do you mean we should provide a framework
>> for bitbanging
Am 03.01.2016 um 00:11 schrieb Henrik Östman:
> Note that I do
> all my reading from "/uncached", is that possible even with
> simultaneous-code? Or do I have to read from the cached-directories?
>
When you read from /uncached, you either
a) have to synchronize writing to /simultaneous with readi
Am 03.01.2016 um 18:07 schrieb Matthias Urlichs:
>
> What I would like to have is a way to read /temperature which simply
> fails when no value is available.
>
It is easy to change that behaviour. Should we have another node in
/settings controlling how reading temperature/voltage values work or d
Am 03.01.2016 um 19:28 schrieb Jan Kandziora:
> Am 03.01.2016 um 18:07 schrieb Matthias Urlichs:
>>
>> What I would like to have is a way to read /temperature which simply
>> fails when no value is available.
>>
> It is easy to change that behaviour. Should we ha
Am 06.01.2016 um 14:12 schrieb Cornie Malan:
> Referring to the source code ow_2804.c I can see that latch command (A5h)
> is noted:
>
> 95)#define _1W_READ_ACTIVE_LATCH 0xA5
>
Oh, this seems to be misnamed.
> and from the datasheet sample:
>
> TX CCh Issue “Skip ROM” command
> TX A5h
Am 06.01.2016 um 15:58 schrieb Cornie Malan:
> I suspect the read is just a dummy to complete the command, but it does
> return a byte?
>
Datasheet says it returns the value read from PIO input circuit while
the pulse is generated. As the PIO pins are open drain, this doesn't
have to be the same a
Am 06.01.2016 um 21:23 schrieb Cornie Malan:
> No, to pulse LEDs to switch an opto-isolator.
>
So, why exactly do you need pulses? OWFS isn't really real-time-capable
so no chance to do phase-angle control. Oh, and thyristors and even more
triacs like the gate current to be all-on.
Kind regards
Am 06.01.2016 um 21:55 schrieb Cornie Malan:
> Getting into electronics now. Pulse to drive a 230V flip-flop circuit to
> do the switching.
>
> Flip- pulse to turn off, flop- pulse to turn on.
>
Well, okay. It's your design.
I will think about how to implement that function (without the readout)
Am 07.01.2016 um 08:06 schrieb Ursin Soler:
>>
>> I don't think this is too useful because one had to rewrite every
>> single needed I?C slave driver out there for this crude interface
>> and of course the tools, too. These drivers and tools do exist.
>> Why reinvent the wheel?
>
> I totally agr
Am 08.01.2016 um 01:07 schrieb Stefano Miccoli:
>
> I agree: since owserver is multi-threaded by design there is nothing
> wrong with multiple client tasks/threads accessing it concurrently.
> One should just avoid clogging the server wit an excessive number of
> requests.
>
All is fine as long a
Am 09.01.2016 um 17:37 schrieb Solèr Ursin:
>
> Thanks a lot for this useful summary! I think I got the main points now.
> Next step then is to use a user written /usr/bin/owgpio in the owfs externals
> config and this script accesses /sys/class/gpio/gpiochip248, as you
> described earlier, right
Am 10.01.2016 um 14:06 schrieb Solèr Ursin:
>
> May I ask - out of curiosity - where those companies you talk of are located?
> Asia? Europe? US?
>
Bavaria.
> To be honest I did placements always myself as I am a Laboratory
> Guy/Physicist.
>
Nah, don't like to do this. There's enough stuff bei
Am 14.01.2016 um 12:29 schrieb Tomasz Torcz:
>
> There's an issue reported by Fedora user:
> https://bugzilla.redhat.com/show_bug.cgi?id=1229231
>
>
> Workaround is to explicitly ensure that wire and ds2490 modules are
> not loaded (using blacklist in modprobe). Owfs works without the
> wire m
Hi,
as Paul seems to be unavailable and noone else dashes to the front, I
claim benevolent dictatorship to decide we should have a 3.1p1 release
including all the remaining patches from Paul and the recent fixes from
Johan, Tomasz and myself.
The MOAT patches are not ready for release at the mom
Am 14.01.2016 um 16:28 schrieb Jan Kandziora:
>
> I try to prepare a clean source archive for packagers and notice them.
>
Source package is available.
https://sourceforge.net/projects/owfs/files/owfs/3.1p1/
Wound anyone be so kind to provide the missing installer for MS-Windo
Am 15.01.2016 um 11:16 schrieb Tino:
> Hi,
> I've been trying to get owfs to run with raspbian and the default owfs
> package but no luck. While searching for a solution there seem to be some
> comments suggesting that a specific version of owfs is needed. I couldn't
> find any change history or so
Am 15.01.2016 um 15:36 schrieb Tino:
> Hi Jan,
> and thanks for the quick reply.
> Indeed I am using: raspberrypi 4.1.13-v7+ #826 SMP PREEMPT Fri Nov 13
> 20:19:03 GMT 2015 armv7l GNU/Linux
>
> The 1wire device is working well under /sys/bus/w1/devices
>
> The link for 3.1p1 is dead. I checked s
Am 20.01.2016 um 06:12 schrieb Gregg Levine:
>
> However what does that entail, and more importantly, what am I
> expected to be able to do?
>
At some point, Paul made all contributors into admins to have at least
one person with admin access available if he's not available any more.
So, if you do
Am 27.01.2016 um 23:09 schrieb Johan Ström:
>
> (libftdi *does* have a ftdi_usb_find_all but "list all" only works on
> libftdi >= 1.x. And it only lists devices with *known* FTDI vid/pid's.
> Let's say a third party device uses a FTDI chip but has obtained it's
> own PID (available for free from
Am 28.01.2016 um 23:38 schrieb Johan Ström:
>
> What do you think?
>
Sounds reasonable. But if you name it owusbprobe, it should be able to
detect DS9490 and DS9481, too.
Kind regards
Jan
--
Site24x7 APM Insight
Am 29.01.2016 um 08:28 schrieb Johan Ström:
>
> On 28/01/16 23:58, Jan Kandziora wrote:
>> Am 28.01.2016 um 23:38 schrieb Johan Ström:
>>> What do you think?
>>>
>> Sounds reasonable. But if you name it owusbprobe, it should be able to
>> detect DS94
Am 29.01.2016 um 15:17 schrieb Johan Ström:
>
> Would that be the one based on the device iteration order? Can
> someone elaborate on how that digit is computed? From my quick look,
> it seems to be a number incrementing for every single USB device
> seen, regardless if it matched or not (might
Hi,
I just committed the "latesttemp" node we have been talking about
recently. It's function: provide a way to read the temperature value
from scratchpad *without triggering a conversion*.
This is especially useful in conjunction with simultaneous conversions.
$ owwrite /simutaneous/temperature
Am 02.02.2016 um 16:48 schrieb Radoslav Chovan:
>
> Configuration stop on this error:
> checking if usb support is enabled... no
> ./configure: line 16685: syntax error near unexpected token `LIBUSB,'
> ./configure: line 16685: ` PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >=
> 0.9.1, ENABLE_USB=tru
Am 02.02.2016 um 20:39 schrieb Coudy:
> Hi,
> I have followed this guide:
> http://www.clemens.it/dev/doku.php?id=building_owfs_on_cygwin
> After unzipped source files, I run ./bootstrap, autoreconf -if, and
> configure with my parameters. Then tried again with original configure from
> tar.gz
>
T
Am 03.02.2016 um 00:04 schrieb Stefano Miccoli:
> Jan:
>
> something went wrong with commit
> 924a1ba17cf5e8bc46ccabecb2318f62c9af3a0c:
>
> owexist.1 does not exist in the source tree, so that build fails
> with:
>
> make[3]: *** No rule to make target 'owexist.1', needed by 'all-am'.
> Stop.
>
Am 03.02.2016 um 01:06 schrieb Stefano Miccoli:
>
> On the contrary a write to /simultaneous/temperature is
> asynchronous, since it will return *before* data is available. IMHO
> for consistency also a write to /simultaneous/temperature should
> *block* until all conversions are performed.
>
The
Am 03.02.2016 um 09:53 schrieb Stefano Miccoli:
> OK I agree… mine was a misguided suggestion (due to the lack of
> understanding of what a write to /simultaneous/temperature actually
> does.)
>
> If I got it right, everything boils down to these points.
>
> - By simultaneous conversion, we mean
Am 03.02.2016 um 17:44 schrieb Stefano Miccoli:
>
>> On 03 Feb 2016, at 16:29, Jan Kandziora wrote:
>>
>> Ah, yes, documentation is sparse. But I don't think manpages help much,
>> being scattered is their nature.
>
> I suggested a man page because it is
Am 03.02.2016 um 18:36 schrieb Dean Waldow:
>
> I am curious if owfs should be able to be installed on OSX? It seems
> that it is intended to be installed on OSX from what I have read
> onine perhaps with the exception of the fuse file system.
>
Besides owfs and core owlib, all programs use plain
Am 03.02.2016 um 19:20 schrieb Radoslav Chovan:
> Hi,
> this is my current owshell.h
>
> #define OWSHELL_H
> #include
> #include
> #include
> #include "config.h"
> #include "owfs_config.h"
>
> I have run again configure and compile.
>
> I see same error:
>
> [...]
>
In that case, our configu
Am 03.02.2016 um 19:59 schrieb Dean Waldow:
>
> I don’t think libusb-1.0 is standard in el capitan but I believe
> MacPorts has that in their ports. The main issue may be the location
> of the libs from MacPorts versus the where owfs expects to find
> them?
>
./configure looks at all places where
Am 04.02.2016 um 14:06 schrieb Timo Engel:
>
> I'm wondering what is the correct procedure to read/write form/to an
> EEPROM. Is it sufficient to use write() and write 32 bytes for example
> to pages/page.0?
>
Yes.
> Are there any status information if the last write()
> was successful?
>
If the
Am 04.02.2016 um 22:28 schrieb Dean Waldow:
>
> checking for LIBUSB... no
>
> I have not dug into the code to see where it is looking for libusb. I
> seem to remember that in MacPorts there were two libusb portions
> (libusb and libusb-development) - doubt there is something similar in
> brew. I o
Am 04.02.2016 um 23:11 schrieb Johan Ström:
>
> vid =0x0B6A, pid = 0x5A03
> "This device is identified as a DS18E17 / DS9481P-300 USB adapter.
> To use this, you need to use the DS2480B device, and point it to
> the appropriate /dev/ttyACMx device"
>
Skip the DS28E17 part, as the adapter is part
Am 05.02.2016 um 10:36 schrieb Stefano Miccoli:
>
> In your config the perl/python/php/tcl language binding are not
> available due to the lack of swig. If you brew-install swig you
> should unlock the perl/python/php/tcl bindings.
>
The tcl binding is not built on top of SWIG and there is no o
Am 08.02.2016 um 07:17 schrieb Henrik Östman:
>
> Can we expect a "latestvoltage" in the future also?
>
Done for the DS2450. Also added "latesttemp" for the DS2438. The voltage
sampling on the DS2438 is different however, and doesn't react to
/simultaneous/voltage at all.
Kind regards
Ja
Am 10.02.2016 um 15:41 schrieb Willy Verbiest:
> Hi,
> I use a DS9490R USB adaptor to connect to the 1-wire cabeling.
> With the new Debian 8 “Jessie” distribution with owfs version 2,9p8-6
>
Debian Jessie has Linux-3.16 and the default package configuration for
owfs makes it use the w1 kernel subs
Am 12.02.2016 um 10:03 schrieb Timo Engel:
>
> Thanks for your reply, I checked this again now. I'm using owfs from
> git 11325b6674a255a9797a1096e89870572ecf4db8 from Sun Dec 6 20:57:29
> 2015 and Kernel 4.1.13-v7+ (raspbian jessie).
>
Ah, ok. So you have the w1 patch included.
>
> $ hexdump -
Am 12.02.2016 um 16:57 schrieb Timo Engel:
>
> The output of owserver is attached.
> owget does not output anything when using the "uncached" path.
>
This looks a lot like the netlink layer has still (or again)
communication problems with owlib.
* Please make sure you are indeed using the owfs f
Am 15.02.2016 um 14:30 schrieb Timo Engel:
>
> I am using bitbanging on an GPIO.
>
Then you have no choice but to use --w1. OWFS has no bitbanging driver
of its own, only drivers for RS232, USB and I²C based adaptors.
Unfortunately, I don't have a DS2433 nor DS2436 at hand to check it
myself. Co
Am 16.02.2016 um 09:36 schrieb Timo Engel:
>
> This is the log generated for one call of owget. It excludes the
> messages for startup and shutdown of owserver.
> Version is 11325b6674a255a9797a1096e89870572ecf4db8.
>
Well, it seems either the w1 netlink communication has changed *again*
or there
Am 07.02.2016 um 21:39 schrieb Jerry Scharf:
>
> A while ago I had asked if anyone was interested in working on a new
> building automation control system. There were some who were willing to
> review and comment on it. I am going to avail myself of those kind people.
>
I think, to make another b
Am 01.03.2016 um 19:48 schrieb Peter Hollenbeck:
>
> The new temperature sensor is connected with 150 feet of waterproof Cat6.
> When trying to get it working I read that the DS18B20 needs a 4.7K resistor
> connecting +5V to Data.
>
Are you using a dedicated onewire host adapter chip or just a sim
Am 04.03.2016 um 19:00 schrieb Johan Ström:
>
> Anyone objecting to a merge?
>
You're testing better than anyone else I think, so let's finally have this.
Kind regards
Jan
--
___
Am 09.03.2016 um 23:39 schrieb Arnout Vandecappelle (Essensium/Mind):
> compat_netdb.h is added for only one reason: to provide the definitions
> for getaddrinfo, in case it is not provided by the system.
> compat_netdb.h is just a copy from an old glibc version, but that makes
> it incompatible wi
Am 14.03.2016 um 16:30 schrieb Timo Engel:
>
> Is there any update about this issue?
> Do you have some hints how to get this debugged?
>
So far, no. I have no time to look for owfs until starting of April, I
don't have the chip yet and there is other housekeeping work in owfs to
do already.
So
Am 16.03.2016 um 13:29 schrieb Andy Carter:
> I've built a number of versions this morning. Results are...
>
> 2.8p15 OK
> 2.9p0 OK
> 2.9p2 OK
> 2.9p3 OK
> 2.9p5 not OK
>
> 2.9p4 sources don't seem to be available
>
There is not much of a change between 2.9p4 and 2.9p5, so I think i
Am 31.03.2016 um 23:31 schrieb Johan Ström:
> Great, now we have the exact source of the problem at least :)
>
> I'm wondering if that code is actually right (with or without
> patch).. Not sure what LCD_COMMAND_ATTENTION is intended to do? And
> shouldn't LCD_COMMAND_4_BIT be written with NIBBLE_
Am 27.04.2016 um 17:46 schrieb John Bass:
> Hello,
>
> Thanks you, Just tried that, now responds just fine, however the
> temperature it reports for the device is 85, which I believe means
> error.
>
No. That's the power-on value and when you get it it means your
sensor/network has a power failur
401 - 500 of 843 matches
Mail list logo
