Jan, thanks for the detailed explanation!
My main problem was/is, that even when I disconnect 2 branches and only
have branch "B" or "C", it won't make a difference. But there's another
change, I did not remember:
Colin, I use OneWireHub: https://github.com/orgua/OneWireHub
The difference is, that the first 2 (still functioning) slaves use an older
code base. OneWireHub changed it's timing in some November commits. I
guess, I uses an intermediate version for the 2 slaves that worked first
and do not any more.
I'll do some tests and compare the timing with a logic analyzer to see, if
they behave different. The only obvious change I found is the length of a
written zero. But this decreased from 35µs to 30µs, which still might be
too long:
https://github.com/orgua/OneWireHub/blob/e2c5b4447338e48debae33b66ec7427265b5af23/src/OneWireHub.h#L78
https://github.com/orgua/OneWireHub/blob/master/src/OneWireHub_config.h#L39
(I guess it should be even shorter, so it makes no sense that the old ones
are working)
But apart from this implementation, I was not able to talk to a DS1820 at
the end of branch "C", so I'll follow Jans advise and build a lobe with the
Cat.5 - I always tried to keep the length short, but this indeed might make
more sense!
And, Jan: yes, I use DS9490 on both machines. I even exchanged those, using
the "working" one on my ARMEL box and the "not working" on i386, but it
didn't change: i386 worked, the other didn't.
On this point thanks again for the detailed explanation, how to install
OWFS 3.1p5!
Even if I'm not on a Raspberry and currently use emDebian, I'll try and
install the armel binary from the official repositorys!
I'll report back with my results...
Sven
2017-02-15 17:48 GMT+01:00 Colin Reese <colin.re...@gmail.com>:
> Sven, what code are you using on your attiny?
>
> > On Feb 15, 2017, at 7:27 AM, Jan Kandziora <j...@gmx.de> wrote:
> >
> >> Am 15.02.2017 um 08:25 schrieb Sven Giermann:
> >>
> >> I have several temperature sensors and 1 DS2423 counter in one room. All
> >> are connected with a Cat.5 network cable (about 30 meters) in a single
> bus
> >> that ends in another room with a small embedded Debian ARM (armel)
> server
> >> that runs OWFS 2.8p15-1.
> >>
> > Please update to 3.1p5. No one wants to hunt bugs fixed for years.
> >
> >
> >> Everything fine up to here. Let's call this branch "A".
> >>
> >> I then started to connect some software programmed ATTiny85 custom
> 1-wire
> >> slaves, drawing another branch (branch "B") from my server. That way,
> the
> >> first star-alike topology was built, currently a single bus, but with
> the
> >> master in the middle.
> >> This also worked for the first 2 devices, about 7 meters distance to the
> >> master (remember the additional 30 m to the other sensors). I used
> simple
> >> electric cable (NYM-J 3x1.5mm²) for this second branch, because I needed
> >> the third wire for some higher currents.
> >>
> > I would suspect the ATtiny slaves are a more picky about the timing then
> > the Dallas/Maxim ones.
> >
> >
> >> Well... some months later I added 2 more custom slaves on a third branch
> >> ("C"), having a typical star topology now with the master in the middle.
> >> Again, those are connected with NYM-J as well, with about 4 meters
> distance
> >> and..... yes, it worked!
> >>
> >> My problems started when I expanded the last branch by another 4 meters
> >> trying to connect a third slave on that branch!
> >> Suddenly all 3 slaves on that branch disappeared from the bus.
> >>
> > Yes. That could happen and it is likely to happen. The star topology is
> bad.
> >
> >
> >> I could not get them back, whatever I tried: removing the 4 meters
> >> extension, disconnecting the other 2 branches, only connect a single
> slave
> >> - nothing helped.
> >> (But they showed up and worked for weeks before I added the extension!)
> >>
> >> I then finished my setup first - having a total of 3 slaves on branch
> "B"
> >> and 7 slaves on branch "C". Branch "B" has a total length of 12 meters,
> >> branch "C" about 30 meters:
> >>
> >> Master (DS9490R)
> >> |--()--()--...--() "A", 30 meters Cat.5, 8 slaves
> >> |--()--()--() "B", 12 meters NYM-J1.5, 3 slaves
> >> |--()--()--...--() "C", 30 meters NYM-J1.5, 7 slaves
> >>
> >> Still, only all slaves of branch "A" and the the first two of branch "B"
> >> show up on the bus. For testing purpose I went and connected my laptop
> >> running a virtualized Debian installation and OWFS to that bus - and:
> ALL
> >> devices showed up and responded to read and write commands. It took some
> >> seconds and maybe 3-4 runs of 'owdir /uncached' to see all devices, but
> >> finally it worked.
> >>
> > No, it didn't. What you have is an extremely brittle setup which may or
> > may not work, depending on moon phase and other non-insightful
> > parameters. This is impossible to debug.
> >
> >
> >>
> >> Now... does anyone have any advice what to change/try next?
> >> Should I try to compile OWFS 3.1?
> >>
> > You should install the Rasbian package from the testing repository.
> >
> > Testing(Stretch) has owfs-3.1p5. You can use the owfs packages
> > from the Raspbian testing repository. Edit (or create) your
> > /etc/apt/preferences to contain:
> > ------------------------------------------------------------
> --------------
> > Package: *
> > Pin: release o=Raspbian,a=stable
> > Pin-Priority: 500
> >
> > Package: *
> > Pin: release o=Raspbian,a=testing
> > Pin-Priority: 300
> > ------------------------------------------------------------
> --------------
> > This is important so you keep stable (Jessie) for all packages but the
> ones
> > explicitly taken from testing (Stretch).
> >
> >
> > Then, add a line
> > ------------------------------------------------------------
> --------------
> > deb http://mirrordirector.raspbian.org/raspbian/ testing main contrib
> > non-free rpi
> > ------------------------------------------------------------
> --------------
> > to your /etc/apt/sources.list to get access to the Raspbian testing
> > repository.
> >
> > Do an
> >
> > $ sudo apt-get update
> >
> > to read the package metadata, then check
> >
> > $ sudo apt-cache policy
> >
> > whether the testing repo is there with priority 300. Then
> >
> > $ sudo apt-get update -t testing owserver ow-shell
> >
> > That should install all you need, including the startup files and
> > systemd units.
> > Note you have to edit /etc/owfs.conf again to contain (this and only
> this)
> > ------------------------------------------------------------
> --------------
> > !server: server = localhost:4304
> > server: w1
> > ------------------------------------------------------------
> --------------
> > Restart the owserver service after that.
> >
> >
> >> Is there any configuration (defines?) that can cause different timing on
> >> the bus - making it work on i386 and fail on armel?
> >>
> > Do you use the DS9490 on both?
> >
> >
> >> Any advise to change the bus? Different cable? Different master (I have
> >> another LinkUSB)?
> >> Again: I already disconnected branches "A" and "B" resulting in no
> slaves
> >> at all - with a single bus/branch.
> >>
> >> Hope somebody can help me out...
> >>
> > First, get rid of the star topology. Make a lobe with the help of the
> > additional wires in the Cat.5 cable. Replace the 12m NYM-J1.5 stub by
> > another lobe cable with at least 4 wires. Connect your 30m NYM-J1.5 stub
> > to the far end of that lobe.
> >
> > If you can't do that or don't want to do that, use multiple host
> > adaptors or a host adaptor with built-in switch e.g. the DS2482-800. Or
> > try to get two DS2409 switches.
> >
> > Kind regards
> >
> > Jan
> >
> > ------------------------------------------------------------
> ------------------
> > 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
>
> ------------------------------------------------------------
> ------------------
> 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
>
------------------------------------------------------------------------------
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
