Re: [Owfs-developers] owfs.org is down

[Alastair D'Silva]

I'm happy to chip in to keep the domain. I can also secondary dns & email.

Where is the mailing list hosted? That probably needs to live somewhere too...

On 12 April 2019 3:45:49 am AEST, "Johan Ström"  wrote:
>Personally I'm voting for a technical solution such as described in 
>https://github.com/owfs/owfs/issues/35#issuecomment-481157327
>
>i.e. just keep the domain, and point it to owfs.github.io (or use the 
>custom domain model mentioned).
>Then no-one needs to keep up with having some random PHP site
>maintained 
>and secure, but rather we can just focus on the information presented.
>A 
>big additional plus is that the community does not have to rely on a 
>single person (whoever it might be) for keeping the site working.
>While it's nice to see that we have people stepping forward to do it, 
>it's natural that interest and possibility can/will change with years 
>(as we've seen here), and from that point of view it would be nice to 
>use an open platform to host it (while there is no guarantee github is 
>there forever..).
>
>The "only" two things which needs solving then is
>* migration of existing content to new site format
>* keeping up with paying for owfs.org, if we want to keep the domain.
>
>
>Johan
>
>
>On 2019-04-11 18:56, Nico Bouthoorn wrote:
>> I can take over  the domains if no one objects, my background and job
>
>> is linux administration.   I'm using owfs for over 10 years now, i'm 
>> glad doing something back. It only will be hosted outside the US in 
>> the Netherlands...
>>
>> Nico
>>
>> Nico
>>
>> Mike Kalist wrote:
>>> HI All   sorry for the hassle,  whoever can take over the domains
>and 
>>> hosting  please email me and i will forward  EEP keys  as well  as 
>>> send  log in and password for the site.
>>>
>>> The amount of work it is taking  to keep up with spam is getting to 
>>> be a full time job. over the last year i have been asking clients to
>
>>> go to another hosting provider.
>>>
>>> Please let me know.
>>>
>>> Have a great day and  again sorry for the inconvenience.
>>>
>>> Email is m...@kalist.ca 
>>>
>>>
>>> On Wed, Apr 10, 2019 at 3:54 AM Nico Bouthoorn >> > wrote:
>>>
>>>     I can host the website if it is a problem,  i host more 
>>> websites.  The number of hits and storage will not that big, i
>guess?
>>>
>>>     Nico
>>>
>>>     Johan Ström schreef:
>>>  > Hi,
>>>  >
>>>  >
>>>  > thanks for replying, good to hear from you Paul!
>>>  >
>>>  >
>>>  > Based on previous discussions and current Github ticket, my 
>>> guess is that the general consensus it that create a new site on 
>>> github.io  would do just fine.
>>>  >
>>>  >
>>>  > The two big question, I guess, is how to deal with the 
>>> economical parts of the domain (owfs.org ), and who
>
>>> has the time & interest to create a new page.
>>>  >
>>>  >
>>>  > Regards
>>>  > Johan
>>>  >
>>>  >
>>>  > On 2019-04-09 13:23, Alfille, Paul H.,M.D. wrote:
>>>  >>
>>>  >> Mike Kalist has generously hosted the site for years, but 
>>> would like out.
>>>  >>
>>>  >>
>>>  >> Is there any interest in picking it up or changing to full 
>>> github format?
>>>  >>
>>>  >>
>>>  >> Paul Alfille
>>>  >>
>>>  >>
>>>
>--
>>>  >> *From:* Johan Ström >> >
>>>  >> *Sent:* Tuesday, April 9, 2019 6:37:59 AM
>>>  >> *To:* OWFS (One-wire file system) discussion and help; 
>>> mike.kal...@gmail.com 
>>>  >> *Subject:* Re: [Owfs-developers] owfs.org  
>>> is down
>>>  >>     External Email - Use Caution
>>>  >>
>>>  >> Not sure if we have any contact details to anyone who is/was
>
>>> in charge
>>>  >> of the site/domain/servers. Unfortunately
>>>  >> https://sourceforge.net/p/owfs/mailman/message/35247513/ &
>>>  >> 

Re: [Owfs-developers] Suggestions of Microcontrollers for 1-wire use.

[Alastair D'Silva]

I'll throw in my $0.02 too...

I was of the opinion that it would be awesome to have an owserver
implementation for the ESP, but now that supercheap Linux SBCs such
as the Orange Pi Zero, Nanopi Neo, etc are available, it's hard to make
that argument based on hardware cost, especially if you need ethernet
rather than Wifi.

It's also hard to make the argument based on power, we measured an
underclocked Allwinner H3 at 0.25W (with the GPU disabled).

My current position now is that a cheap SBC takes all the software
effort away, and the write wear issue can be solved either by
netbooting or using a readonly root filesystem - Buildroot & OpenWRT
are both good choices to build this.

-- 
Alastair D'Silva   mob: 0423 762 819
skype: alastair_dsilva
Twitter: @EvilDeece
blog: http://alastair.d-silva.org


On Thu, 2019-02-21 at 23:54 +0100, Stefano Miccoli via Owfs-developers
wrote:
> Quite an interesting discussion, please forgive me if I throw in my
> 1cent.
> 
> We should not forget that normal RPis are educational boards, not
> meant for professional use. OS on a SD is a terrible idea, with
> regard to card corruption, but at least it is *impossible* to brick
> your board. Something wrong? just swap SDs and start over…  I think
> that this is a key point for educational/hobby use. 
> 
> For industrial application there is the compute module <
> https://www.raspberrypi.org/products/compute-module-3/>;, with up to
> 32GB  eMMC, and, as already mentioned, newer RPis can boot from USB
> but also from network. If you are familiar with setting up a DHCP,
> TFTP, NFS server, you can also try a fully storage less network
> client setup. (Of course this makes sense if you are going to deploy
> a cluster of at least five RPis. But with a reasonable server and
> network this easily scales up to tens of nodes.)
> 
> However the main point, in my opinion, is that for most application
> you do not need the power of a full fledged linux system-on-chip
> (with 8GB+ storage, 1GB ram, 4 cores, GPU, hdmi port, ethernet, etc.)
> Moreover linux systems need administration and security updates, etc.
> so for a great number of applications it is just over kill. 
> 
> So if you are not going to use the distributed “intelligence” and
> compute power sleeping in your SOC nodes, the µcontroller is for sure
> the way to go.
> 
> Stefano
>   
> > On 21 Feb 2019, at 06:29, Colin Reese 
> > wrote:
> > 
> > Joe,
> > 
> > I transitioned from Pis to ESP32. I was all-in on Pis, trust me. I
> > love linux. The issues:
> > 
> > It's not just the power supply. SDCards in this environment will
> > corrupt eventually, absolutely. There is nothing that can protect
> > the operating system from eventual corruption. Yes, I too, have
> > been lucky and had them run for years. You simply cannot count on
> > this with consumer-grade sd cards. You can buy industrial quality
> > flash or eMMC, but at this point you are spending more for your
> > memory than you are on the board, and often much, much more. If you
> > do enough research, you will find that this is simply something you
> > cannot practically avoid, unless you go to these expensive cards,
> > or do work to make a frozen, read-only operating system image that
> > offloads all data that need to be permanently stored onto something
> > like a flash drive, where you do not care if it becomes partially
> > corrupted. It's sad, but true. I have talked to dozens of people
> > who use these. Every single one has had these issues, regardless of
> > how good their power supply is. If your application cannot tolerate
> > a reformat periodically (remote devices come to mind), this
> > situation is simply a non-option.
> > 
> > The operating system is constantly being updated, and if you want
> > things like, I dunno, support for Python 3.5+, you have to deal
> > with the fact that it is often times a bleeding edge operating
> > system, and things simply break. LSB was non-functional for a
> > period ... it has at many times simply been a mess.
> > 
> > For me, I do not need a local database. I push it to a cloud
> > service (my own servers, in this case), and handle it there, and
> > serve it to anywhere on the net. For this reason, the complexity of
> > a Pi solution simply does not outweigh the above issues.
> > 
> > Now, you can get an ESP32, which has WiFi, 4MB flash, bluetooth, in
> > a tiny package, for $10. You can get one with a nice little oled
> > display for $19. You can get one with an sdcard and wired ethernet
> > for $30. You can get another version with 4MB more of program space
> > via PSRAM for a little more. You can get em

Re: [Owfs-developers] Reliability and Robustness of the DS2482-100 or DS2482-800

[Alastair D'Silva]

Should do, it had a resistor in series of each of the ground and data lines, 
and a zener to suppress voltage spikes.

On 18 February 2019 9:59:20 pm AEDT, Mick Sulley  wrote:
>So adding a DS9503 in each of the busses on a DS2482-800 should stop 
>lock-up problems?
>
>
>On 17/02/2019 22:13, Alastair D'Silva wrote:
>> The series resistance within a DS9503 should be sufficient, I hope.
>It's worth using these anyway, for ESD protection.
>>
>
>
>___
>Owfs-developers mailing list
>Owfs-developers@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/owfs-developers

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Reliability and Robustness of the DS2482-100 or DS2482-800

[Alastair D'Silva]

The series resistance within a DS9503 should be sufficient, I hope. It's worth 
using these anyway, for ESD protection.

-- 
Alastair D'Silva   mob: 0423 762 819
skype: alastair_dsilva msn: alast...@d-silva.org
blog: http://alastair.d-silva.orgTwitter: @EvilDeece

> -Original Message-
> From: Jan Kandziora 
> Sent: Monday, 18 February 2019 6:34 AM
> To: OWFS (One-wire file system) discussion and help  develop...@lists.sourceforge.net>; Mail Lists 
> Subject: Re: [Owfs-developers] Reliability and Robustness of the DS2482-100
> or DS2482-800
> 
> Am 15.02.19 um 10:19 schrieb Mail Lists:
> >
> > So has anyone got any feedback on how reliable the DS2482-100 or
> > DS2482-800 are and if there are some special precautions I need to
> > consider?
> >
> The DS2482-800 has one problem. If the power to the chip dips, which may
> happen due to a bus short, it sometimes refuses to switch to another
> channel until you power-cycle it fully.
> 
> So, use 10Ω series resistances on the buses to avoid that problem. Or use
> several DS2482-100, or DS2483, or DS2484.
> 
> Kind regards
> 
>   Jan
> 
> 
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> 
> 
> ---
> This email has been checked for viruses by AVG.
> https://www.avg.com



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Howto configure --i2c=ALL:ALL into config file

[Alastair D'Silva]

Yup, here’s what I use:

 

! server: server = localhost:4304

server: i2c = /dev/i2c-0:18

owfs: mountpoint = /1wire

owfs: allow_other

http: port = 2121

ftp: port = 2120

server: port = localhost:4304

 

-- 

Alastair D'Silva   mob: 0423 762 819

skype: alastair_dsilva msn: alast...@d-silva.org

blog: http://alastair.d-silva.orgTwitter: @EvilDeece

 

From: Per Nilsson  
Sent: Friday, 28 December 2018 5:42 PM
To: owfs-developers@lists.sourceforge.net
Subject: [Owfs-developers] Howto configure --i2c=ALL:ALL into config file

 

Hello all
 
The owfs can be started with argument --i2c=ALL:ALL to get the owfs to scan
all I2C busses availiable on a system.
 
Can this behaviour be configured into the config file so that owserver does
the same thing?
 
/Per

 

 


 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
 

Virus-free.  
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
 www.avg.com 

 

___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Many-port bus master

[Alastair D'Silva]

On Thu, 2018-11-15 at 11:19 +0100, Stefano Miccoli via Owfs-developers
wrote:
> > On 15 Nov 2018, at 08:27, Alastair D'Silva 
> > wrote:
> > 
> > 
> > One question, my code has C99isms, which are fine for modern
> > compilers as they default to C99. Older compilers default to C90.
> > 
> > I can fix this in 2 ways:
> > Easy way: add std=c99 to CFLAGS to force C99 mode
> > Hard(er) way: Remove C99isms from the code. It's not that hard, but
> > it will result in some vars getting a larger scope than they need.
> > 
> 
> I would prefer updating the coding style to C99. Sooner or later the
> OWFS codebase should be modernised, so it makes not sense, IMHO, to
> hold back C99 for new contributions.
> 
> Stefano
> 
> 

So far, that's 3 votes (+myself & 1 on Github) for & none against.

I'll enable C99 in that commit, and I'll start another dev branch where
I enable -Wall -Wextra & start addressing any warnings that I see.

-- 
Alastair D'Silva   mob: 0423 762 819
skype: alastair_dsilva
Twitter: @EvilDeece
blog: http://alastair.d-silva.org




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Many-port bus master

[Alastair D'Silva]

> > > PS. Would it be possible to get my current work reviewed? I'm not
> > > quite ready to push it upstream, but it would be good to know early if
> > > there is anything there that would prevent it from being merged. My
> repo
> > is here:
> > > https://github.com/InfernoEmbedded/owfs/tree/infernoembedded
> > >
> > Please do not use the same source file for both your upcoming host and
> > your
> > current LED controller and relay boards.
> >
> 
> No worries, this would be a completely separate device.
> 
> The other devices are shared as they have to maintain the same serial
> number
> when they drop to their bootloader for firmware update. I've separated the
> code, but for the compiler's sake, they are #included into a single
> amorphous blob to avoid leaking symbols.
> 
> >
> > If you are happy with your current devices **and have them tested against
> > the current version of owfs**, prepare a patch and I will push it into
> > master.
> > You are the only one who can test it anyway as long noone else has this
> > hardware.
> >
> 
> Ok, I'll retest over the next few days, thanks :)
> 

Resurrecting this thread as I've just submitted a PR on Github:
https://github.com/owfs/owfs/pull/21

One question, my code has C99isms, which are fine for modern compilers as they 
default to C99. Older compilers default to C90.

I can fix this in 2 ways:
Easy way: add std=c99 to CFLAGS to force C99 mode
Hard(er) way: Remove C99isms from the code. It's not that hard, but it will 
result in some vars getting a larger scope than they need.

-- 
Alastair D'Silva   mob: 0423 762 819
skype: alastair_dsilva msn: alast...@d-silva.org
blog: http://alastair.d-silva.orgTwitter: @EvilDeece





___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Many-port bus master

[Alastair D'Silva]

> -Original Message-
> From: Jan Kandziora [mailto:j...@gmx.de]
> Sent: Wednesday, 2 August 2017 1:25 AM
> To: owfs-developers@lists.sourceforge.net >> OWFS (One-wire file system)
> discussion and help <owfs-developers@lists.sourceforge.net>
> Subject: Re: [Owfs-developers] Many-port bus master
> 
> Am 01.08.2017 um 16:01 schrieb Alastair D'Silva:
> > Hi folks,
> >
> > I'm currently designing an open-hardware 32 port 1wire bus master for
> > part of my home automation system, and would like your input.
> >
> > The design is based around an STM32F412ZG microcontroller, with MOSFET
> > active pullups & drive transistors. It will present as a hat for the
> > Orange Pi Prime (other Pis may also fit). My plan is to connect over
> > the serial port, but I've also wired through I2C & SPI just in case.
> >
> A hat employing standard connectors is going to be more useful to average
> users. This limits the number of channels because of the size of the hat.

Agreed, I work around this by using daughterboards for signal conditioning and 
hosting 8 port RJ45 sockets. These will be laid out into a 1RU compatible case. 
The schematics & board layouts are here if you're interested:
https://github.com/InfernoEmbedded/onewire-softdevice/tree/master/devices/PiMultichannelMaster

> And nearly no one would need 32 channels. The 8 channels the DS2482-800
> offers are already too much for most applications.
> 
My situation is a bit special - all the lighting, roller shutters, fans, etc 
will be controlled by the bus. By splitting out as many ports as I can fit on 
the microcontroller, it means that I can have many independent buses with only 
a few devices on each. This keeps the weight of bus down, and speeds up 
search/alarm search times. It also means that a fault on the data line will 
only take a room, rather than the whole house.

> What would be incredibly useful is a chip that does have separated RX and TX
> lines for each channel so one could use optocouples for totally isolated
> onewires. People using Onewire for building a weather station will love you
> for such a thing. Your hat should employ these, as well as an optional 
> isolating
> DC-DC converter!
> 
Good idea, I didn't think of that. The raw TX & RX lines are indeed separated 
between the hat & daughterboards, so spinning a new isolated daughterboard in 
the future is definitely possible.

> What would be also useful is a device that offloads e.g. the search algorithm
> as the DS2490 does. That chip is now unavailable outside of the DS9490U
> device.
> 
Definitely, that's also what I was thinking. I'll also offload multibyte 
read/write operations, so that things like firmware updates aren't too chatty.

> 
> > I'm currently considering how the device should present to OWlib:
> >
> I found it most useful if you wrote a w1 kernel driver for it instead, so one
> could also use the DS28E17 Onewire-to-I²C bridge with your chip.

Are there any downsides to presenting as a kernel driver rather than an OWlib 
driver?

When we say "poor performance" on http://owfs.org/index.php?page=w1-project , 
what exactly do we mean?

I plan on doing alarmed searches on some ports at ~10Hz so that my light 
switches respond with reasonably low latency. Would this be achievable with a 
W1 driver?

> > Option 1: Maintain an internal hashtable mapping devices to ports, and
> > present as a single bus master. This has the downside of limiting the
> > potential number of devices, as well as monopolising all the buses
> > during long events, such as a firmware update. This would be annoying,
> > as my light switches won't respond across the whole house if I have to
> > update the firmware on any device.
> >
> > Option 2: Present as a single multi-bus master. I'm not sure if OWlib
> > has such a concept, if not, there may be significant infrastructure
> > work required. If it does, great, as hopefully OWlib will keep track
> > of which bus a device belongs to.
> >
> Just look at the DS2482-800 host adapter code.
> 

Great, thanks to you & Paul for that tip, I'll look into it :)

> > PS. Would it be possible to get my current work reviewed? I'm not
> > quite ready to push it upstream, but it would be good to know early if
> > there is anything there that would prevent it from being merged. My repo
> is here:
> > https://github.com/InfernoEmbedded/owfs/tree/infernoembedded
> >
> Please do not use the same source file for both your upcoming host and your
> current LED controller and relay boards.
> 

No worries, this would be a completely separate device.

The other devices are shared as they have to maintain the same serial number 
when they drop to their bootloade

Re: [Owfs-developers] Arduino yun as wifi 1wire master

[Alastair D'Silva]

For my pool solar controller, I use an HLK-RM04 module running OpenWRT and a 
USB9097 1 wire master. If I was doing it again, I would an Orange Pi Zero or 
simlar to reduce the cost. 

From: Dr. Trigon [mailto:dr.tri...@surfeu.ch] 
Sent: Saturday, 22 July 2017 8:25 PM
To: owfs-developers@lists.sourceforge.net
Subject: [Owfs-developers] Arduino yun as wifi 1wire master

 

Lets 's start new.

I want a 1wire net outdoors. I want to avoid drilling hole into my brick walls. 
So here the options:
1. squeeze cable beween window an wall
2. build wireless 1wire thingy e.g. RF or optical to connect through window
3. have a 1wire master like linkhube [1] sitting outdoors and connect throgh 
wifi into my inhouse lan

[1] https://www.ibuttonlink.com/products/linkhube

1 is what I am doing and its bullshit. 2 is what I tried to e.g. using the new 
I2C chip etc. blabla - I do not see how this could ever work. So 3 is now what 
I am trying. Any other better ideas are welcome. I want to use wifi for one 
1wire master outdoors but not for every single sensor. As FHEM can use an 
Arduino as 1wire Master I came up with the Yun idea. Raspi Zero is fine too, 
but someone needs to tell me how to set the software up, how to build the stuff 
together. I don't want to run another instance of owfs on those devices as they 
should act as master and not owfs servers.
Basically I could write a sketch for Arduino that emulates linkhube master and 
then should be able to connect this to owserver but that would be quite some 
effort given FHEM has already a solution for this...
The power btw. is no concern, if needed I can use a car battery... ;))

Greetings
DrTrigon

 


 

 

Virus-free.  

 www.avg.com 

 

--
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] Arduino yun as wifi 1wire master

[Alastair D'Silva]

Whoops, I hit send too early…

 

OWFS servers can import devices from other OWFS instances on other machines. I 
have found this to be a bit problematic on unreliable links though (this was a 
couple of years ago, things may have improved since).

 

Regarding battery power, you’re not going to get Wifi and pure battery power to 
last a reasonable amount of time. You could however get solar + battery to run 
indefinitely.

 

I’m not sure about the construction where you are, but here in Australia, we 
would get a cable outside by running it through the roof cavity, and then drill 
through the eaves (normally made from fibreboard) to drop the cable outside.

 

 

From: Alastair D'Silva [mailto:alast...@d-silva.org] 
Sent: Saturday, 22 July 2017 9:02 PM
To: 'OWFS (One-wire file system) discussion and help' 
<owfs-developers@lists.sourceforge.net>
Subject: RE: [Owfs-developers] Arduino yun as wifi 1wire master

 

For my pool solar controller, I use an HLK-RM04 module running OpenWRT and a 
USB9097 1 wire master. If I was doing it again, I would an Orange Pi Zero or 
simlar to reduce the cost. 

From: Dr. Trigon [mailto:dr.tri...@surfeu.ch] 
Sent: Saturday, 22 July 2017 8:25 PM
To: owfs-developers@lists.sourceforge.net 
<mailto:owfs-developers@lists.sourceforge.net> 
Subject: [Owfs-developers] Arduino yun as wifi 1wire master

 

Lets 's start new.

I want a 1wire net outdoors. I want to avoid drilling hole into my brick walls. 
So here the options:
1. squeeze cable beween window an wall
2. build wireless 1wire thingy e.g. RF or optical to connect through window
3. have a 1wire master like linkhube [1] sitting outdoors and connect throgh 
wifi into my inhouse lan

[1] https://www.ibuttonlink.com/products/linkhube

1 is what I am doing and its bullshit. 2 is what I tried to e.g. using the new 
I2C chip etc. blabla - I do not see how this could ever work. So 3 is now what 
I am trying. Any other better ideas are welcome. I want to use wifi for one 
1wire master outdoors but not for every single sensor. As FHEM can use an 
Arduino as 1wire Master I came up with the Yun idea. Raspi Zero is fine too, 
but someone needs to tell me how to set the software up, how to build the stuff 
together. I don't want to run another instance of owfs on those devices as they 
should act as master and not owfs servers.
Basically I could write a sketch for Arduino that emulates linkhube master and 
then should be able to connect this to owserver but that would be quite some 
effort given FHEM has already a solution for this...
The power btw. is no concern, if needed I can use a car battery... ;))

Greetings
DrTrigon

 


 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
 

Virus-free.  
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
 www.avg.com 

 

--
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] Unsupported 1-wire device

[Alastair D'Silva]

> -Original Message-
> From: Jan Kandziora [mailto:j...@gmx.de]
> Sent: Thursday, 4 May 2017 4:54 AM
> To: OWFS (One-wire file system) discussion and help  develop...@lists.sourceforge.net>
> Subject: Re: [Owfs-developers] Unsupported 1-wire device
> 
> Am 03.05.2017 um 18:55 schrieb Péter Zsembery:
> >
> > Is it possible to configure the OWFS to recognize and communicate with
> > my custom 1-wire slave device? If yes please advise where to find the
> > documentation.

Hi,

I'm going down the same path myself. You can see my work-in-progress here:
https://github.com/InfernoEmbedded/owfs/tree/infernoembedded

You might also want to look at the MOAT changes here:
https://github.com/M-o-a-T/owfs

Both of these implementations are probably overkill for a 1-of device, but it's 
a good example to see how to do more advanced implementations, such as hiding 
unavailable directory entries.

Incidentally, I've chosen family code FE for my gear, so you may want to pick 
something different :)

-- 
Alastair D'Silva   mob: 0423 762 819
skype: alastair_dsilva msn: alast...@d-silva.org
blog: http://alastair.d-silva.orgTwitter: @EvilDeece




--
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] Fine-tune timing against disappearing slaves

[Alastair D'Silva]

One thing I am doing is dropping a low going pulse onto another GPIO pin in my 
slave implementations, and hooking that up to the logic analyser as well as the 
1wire line. That way, I can tell if a pulse originated from my slave 
implementation, or elsewhere on the bus.

 

From: Sven Giermann [mailto:sven.gierm...@gmail.com] 
Sent: Friday, 24 February 2017 8:21 PM
To: OWFS (One-wire file system) discussion and help 

Subject: Re: [Owfs-developers] Fine-tune timing against disappearing slaves

 

Just to report back my results:

I still have no idea, why it was a difference between ARMEL and i386.

But none of my efforts showed any advantage... I ended up with a plain bus, 
even dropped the Cat.5 part completely and was unable to communicate with my 
client nodes.

And then I realized, that I used different implementions of the mentioned 
OneWireHub library!

I switched back to an older release and my clients were visible everywhere, 
even with the worst star topology I could imagine.

So, sorry guys for confusion.

I'll now try to find the source of the problem of the client implementation, 
even if it might be complicated without a proper oscilloscope and/or 
bidirectional analysis to see, which device pulls the bus low...

Cheers,

Sven

 

 

2017-02-16 7:46 GMT+01:00 Sven Giermann  >:

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  >:

Sven, what code are you using on your attiny?


> On Feb 15, 2017, at 7:27 AM, Jan Kandziora  
> > 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 

Re: [Owfs-developers] New device driver - write function not being called

[Alastair D'Silva]

> -Original Message-
> From: Alastair D'Silva [mailto:alast...@d-silva.org]
> Sent: Thursday, 16 February 2017 7:02 PM
> To: 'OWFS (One-wire file system) discussion and help'  develop...@lists.sourceforge.net>
> Subject: Re: [Owfs-developers] New device driver - write function not
being
> called
> 
>   if (channel->fade_time >= (2^24)) {
>   return gbBAD;
>   }

And there's the problem - that's not how you perform a power operation :)


--
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] New device driver - write function not being called

[Alastair D'Silva]

> -Original Message-
> From: Jan Kandziora [mailto:j...@gmx.de]
> Sent: Thursday, 16 February 2017 3:01 AM
> To: OWFS (One-wire file system) discussion and help  develop...@lists.sourceforge.net>
> Subject: Re: [Owfs-developers] New device driver - write function not
being
> called
> 
> Am 15.02.2017 um 12:54 schrieb Alastair D'Silva:
> >
> > Command:
> > 
> > echo "5,10,15,20,300" > /mnt/1wire/FE.DECEA5EDBEEF/channel0
> > -bash: echo: write error: Invalid argument
> >
> Is your parse_rgbw_string() tolerant against \n?

Thanks Jan, it should be, but for completeness, here it is:

static GOOD_OR_BAD parse_rgbw_string(char *buf, RGBW_CHANNEL *channel) {

if (sscanf(buf, "%hhu,%hhu,%hhu,%hhu,%d", >red,
>green, >blue, >white, >fade_time) != 5)
{
LEVEL_DEBUG("Parsing failed");
return gbBAD;
}

if (channel->fade_time >= (2^24)) {
return gbBAD;
}

return gbGOOD;
}

Note that I don't get the debug message out.

I did notice that this might be the first time that writes are used on a
ft_vascii field, so I may not be following a well-tested path.

-- 
Alastair D'Silva   mob: 0423 762 819
skype: alastair_dsilva msn: alast...@d-silva.org
blog: http://alastair.d-silva.orgTwitter: @EvilDeece




--
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

[Owfs-developers] New device driver - write function not being called

[Alastair D'Silva]

   unique: 25, success, outsize: 120
unique: 26, opcode: WRITE (16), nodeid: 3, insize: 95, pid: 30660
write[0] 15 bytes to 0 flags: 0x8001
   CALL: ow_write.c:(71) path=/FE.DECEA5EDBEEF/channel0 size=15 offset=0
  DEBUG: ow_parseobject.c:(163) /FE.DECEA5EDBEEF/channel0
   CALL: ow_parsename.c:(104) path=[/FE.DECEA5EDBEEF/channel0]
  DEBUG: ow_regex.c:(154) Not found
  DEBUG: ow_regex.c:(201) 0: 0->15 found <><>
  DEBUG: ow_regex.c:(201) 1: 0->2 found <><.DECEA5EDBEEF>
  DEBUG: ow_regex.c:(201) 2: 3->15 found <>
  DEBUG: ow_cache.c:(912) Looking for device FE DE CE A5 ED BE EF E5
  DEBUG: ow_cache.c:(1070) Search in cache sn FE DE CE A5 ED BE EF E5
pointer=0x7ff3f1d178d4 index=0 size=4
  DEBUG: ow_cache.c:(1086) Value found in cache. Remaining life: 109
seconds.
  DEBUG: ow_presence.c:(75) Found device on bus 0
  DEBUG: ow_regex.c:(154) Not found
OWQ OneWireQuery structure of /FE.DECEA5EDBEEF/channel0
OneWireQuery size=15 offset=0, extension=0
Byte buffer OneWireQuery buffer, length=15
--000: 35 2C 31 30 2C 31 35 2C 32 30 2C 33 30 30 0A
   <5,10,15,20,300.>
Cleanup = 0002OneWireQuery I=15 U=15 F=7.41098E-323 Y=15 D=Thu Jan
1 10:00:15 1970

--- OneWireQuery done
  DEBUG: ow_write.c:(437) Write a non-array element
/FE.DECEA5EDBEEF/channel0
  DEBUG: ow_cache.c:(1362) Delete from cache sn FE DE CE A5 ED BE EF E5
in=0x7ff3f1d10f40 index=0
  DEBUG: ow_write.c:(495) Write /FE.DECEA5EDBEEF/channel0 Extension 0 Gives
result -22
  DEBUG: ow_select.c:(70) Selecting a path (and device)
path=/FE.DECEA5EDBEEF/channel0 SN=FE DE CE A5 ED BE EF E5 last path=00 00 00
00 00 00 00 00
  DEBUG: ow_select.c:(84) Continuing root branch
  DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 5.00 seconds
  DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
  DEBUG: ow_tcp_read.c:(63) attempt 25 bytes Time: 5.00 seconds
  DEBUG: ow_tcp_read.c:(113) read: 25 - 0 = 25
  DEBUG: ow_transaction.c:(222) verify = 0
  DEBUG: ow_transaction.c:(208) end = 0
  DEBUG: ow_presence.c:(274) Presence of FE DE CE A5 ED BE EF E5 FOUND on
bus /dev/ttyUSB0
  DEBUG: ow_cache.c:(546) Adding device location FE DE CE A5 ED BE EF E5
bus=0
  DEBUG: ow_cache.c:(635) Add to cache sn FE DE CE A5 ED BE EF E5
pointer=0x7ff3f1d178d4 index=0 size=4
  DEBUG: ow_write.c:(437) Write a non-array element
/FE.DECEA5EDBEEF/channel0
  DEBUG: ow_cache.c:(1362) Delete from cache sn FE DE CE A5 ED BE EF E5
in=0x7ff3f1d10f40 index=0
  DEBUG: ow_write.c:(495) Write /FE.DECEA5EDBEEF/channel0 Extension 0 Gives
result -22
  DEBUG: ow_write.c:(437) Write a non-array element
/FE.DECEA5EDBEEF/channel0
  DEBUG: ow_cache.c:(1362) Delete from cache sn FE DE CE A5 ED BE EF E5
in=0x7ff3f1d10f40 index=0
  DEBUG: ow_write.c:(495) Write /FE.DECEA5EDBEEF/channel0 Extension 0 Gives
result -22
  DEBUG: ow_write.c:(112) Error writing to /FE.DECEA5EDBEEF/channel0
  DEBUG: ow_parsename.c:(63) /FE.DECEA5EDBEEF/channel0
   unique: 26, error: -22 (Invalid argument), outsize: 16
unique: 27, opcode: RELEASE (18), nodeid: 3, insize: 64, pid: 0
release[0] flags: 0x8001
   CALL: owfs_callback.c:(135) RELEASE path=/FE.DECEA5EDBEEF/channel0
   unique: 27, success, outsize: 16

==
END DEBUG
==

Notably missing is the debug line from FS_w_set_channel_0 and
FS_w_set_channel.

Any ideas?


-- 
Alastair D'Silva   mob: 0423 762 819
skype: alastair_dsilva msn: alast...@d-silva.org
blog: http://alastair.d-silva.orgTwitter: @EvilDeece




--
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] Hiding incompatible device variants

[Alastair D'Silva]

> -Original Message-
> From: Jan Kandziora [mailto:j...@gmx.de]
> Sent: Saturday, 11 February 2017 11:08 AM
> To: OWFS (One-wire file system) discussion and help  develop...@lists.sourceforge.net>
> Subject: Re: [Owfs-developers] Hiding incompatible device variants
> 
> Am 10.02.2017 um 22:04 schrieb Alastair D'Silva:
> > Hi folks,
> >
> > I've written a 1Wire slave implementation for ARM (which I will be
> > open sourcing), in order to implement some functionality that does not
> > exist in the 1Wire world (multichannel RGBW control).
> >
> > Given the small amount of address space available in the family, I
> > figured the best course of action for further implementations would be
> > to keep the family code, and add a command to allow the master to
> > query the device specifics.
> >
> What is your device emulating? A DS2408? There is some code inside OWFS'

I do have a working DS2408 emulation, but that was more to test that I have
the low level protocol correct. This is a new device, with new commands.

> DS2408 codebase which handles the various HD44780 displays connected to
> the DS2408. It's ugly, it's error-prone and it's hard to debug.
> Please don't require us to put even more quirks into the existing driver
> sources.

Agreed, what I was thinking of was adding an init/term function and a struct
that represents a device instance (rather than a whole family of devices),
and adding a DeviceEntryExtended2 to set that up. That way, the driver can
query the device when inited, find out it's real type, and pass the
appropriate filetype table (probably from a separate .c file), so we don't
have the horrible overloading that exists in the DS2408 driver.

What I'm stuck on is that none of the existing infrastructure seems to have
a concept of a device instance, only types of devices, and I'm not sure it
can be easily retrofitted.

Regardless of whether I have a second level of device types, I don't think I
can do without a struct to have device instance state. My use case is this:
- The implementation library allows an arbitrary number of channels
- I have a command which returns the number of channels
- I would only like to display files for the permitted channels
- I would like to avoid querying the device every time a directory listing
is done

If you have any ideas, I'm all ears. Maybe querying the device for it's
state when necessary wouldn't be disastrous...

> If you make your own device, please give it its own family code and create
> your own driver source file in the owlib tree. We are going to face at
most
> twenty fundamentally different designs of homebrewn devices and there's
> plenty of unused address space for that.

That feels a lot like "640kb ought to be enough for everyone"... 


> By the way, if you do an onewire LED driver, the feature I adore most is
> synchronous control over a whole bus. So multiple LED units can be pre-
> programmed to dim in a controlled fashion starting at a single point in
time.
> 
> You had to implement a new command similar to "Convert T" to achieve this.
> That would break any existing driver but is extremly simple to implement
in
> your own driver (and the simultanenous code, of course).

That sounds like a great idea, thanks.

These are the commands I have implemented currently:
ALL_OFF (sets all the channels on the device off, maybe a candidate
for a simultaneous command?)
COUNT_CHANNELS  returns the number of available channels to the master
SET_CHANNEL fades a channel to a specified RGBW value over a
specified time
GET_CHANNEL gets the current RGBW value of a channel, and the
fade time remaining

It should be relatively straightforward to add a COMMIT command which only
starts fading the requested channels once received.

Do you have any other suggestions?





--
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

[Owfs-developers] Hiding incompatible device variants

[Alastair D'Silva]

Hi folks,

I've written a 1Wire slave implementation for ARM (which I will be open
sourcing), in order to implement some functionality that does not exist in
the 1Wire world (multichannel RGBW control).

Given the small amount of address space available in the family, I figured
the best course of action for further implementations would be to keep the
family code, and add a command to allow the master to query the device
specifics.

The problem I am now facing is how to cache the information, and despatch
calls to the appropriate driver (of which there is only 1 at the moment)
once a device appears on the bus.

I was thinking of adding an opaque, device instance specific struct pointer
somewhere under the parsedname struct, as well as init and term function
pointers in the device struct. The init call could then query the device
subtype, and stash it away in the device instance specific struct, and
potentially alter the visibility of the files so that only the relevant
content is visible to the user.

Could you please advise whether I am on the right track, or if there is a
better solution?

Cheers,

-- 
Alastair D'Silva   mob: 0423 762 819
skype: alastair_dsilva msn: alast...@d-silva.org
blog: http://alastair.d-silva.orgTwitter: @EvilDeece




--
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