owfs-developers — Developer's list for OWFS

[Owfs-developers] Some thoughts on controlling devices

[Gregg C L. <han...@wo...>]

Hello from Gregg C Levine
Now that Paul's OWFS project is off an running, I have a question, or
at least a thought I want to bounce off on all of you.

For a project I am creating I need to be able to turn on, and off, a
device that's powered by the mains, (110VAC or 220VAC Europe), since
this would be done remotely, I want to use a one-wire switch as the
DS2406. I am correct, in my assertions that the DS2406 can not switch
such voltages directly, I believe. Do any of you have any suggestions
for attaching the one-wire switch to the circuit?=20

I'll have more on the project in the weeks, and months to come.=20
-------------------
Gregg C Levine han...@wo...
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."=A0 Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )

Re: [Owfs-developers] Random thoughts on configuration

[Nicolas H. <nhu...@gh...>]

Vadim Tkachenko wrote:
> According to Nicolas Huillard:
>>Vadim Tkachenko wrote:
>>>Here's some things that might be useful to simplify the life of an
>>>application developer and ease some pain for those controlling hardwar=
e...
>>>
>>>It'd make sense to include two kinds of values into OWFS configuration=
:
>>>
>>>- "Initial settings". An example is a temperature resolution for DS18x=
20.
>>>
>>>- "Failsafe settings". An example is an initial state of a switch like
>>>  DS2406 after a powerup that provides a safe state for the hardware i=
t
>>>  controls.
>>
>>Does all that devices have their own initial setting ?
> Not necessarily - only those where it is indeed required

As I understood the Dallas spec sheets, each device come with a=20
predefined state upon powerup : 2406 have both PIOs at 0, 1820 have no=20
alarms, etc.
This is precisely meant to have a know state for the whole network upon=20
powerup.
If I'm wrong, you must tell me because I rely on that for my project...

>=20
>=20
>>Does failsafe setting be handled at a hardware level ?
> Nope, can't do.

Since PIO values are all 0 upon powerup, you can wire your relays or=20
servos (oops, I see !) to be in a fail safe state according to that 0.
Oops, I see : servos must be driven by the application, isn't it ? The=20
device can't decide by itself if it is totally open or totally closed.=20
Is that it ?

>>My thought :
>>* in a parasite power configuration, or when power to the microlan is=20
>>injected by the computer, when power comes back, it comes back to the=20
>>computer and the devices at the same time
>=20
> Not necessarily. My case: breaker in a branch of a house shuts off, the
> computer goes down. Meanwhile, HVAC keeps hvacing 'cause it's got its o=
wn
> power branch, and increasingly goes nuts.

But your computer will go up before the HVAC is really in bad shape.

>>* the devices are up un setup their own default/initial/failsafe values=
,=20
>>without the help of anything
>>* the computer slowly boot up, check disks, run services, have a coffee=
,=20
>>then run owfs
>>* when owfs is finally up and ready to talk to the devices, the valuabl=
e=20
>>hardware they control has already had the time to go nuts...
>=20
> Well, not necessarily. In case of Linux with ext3 the bootup process ta=
kes
> less than a minute even in case of hard reset, and for my application n=
ot
> all is lost.

<OT>
When I changed Ext3 for ReiserFS, I made a little bench : "find / -type=20
f > /dev/null" was 17x faster on ReiserFS than on Ext3 (same hardware,=20
same data, a few hour later). Regular backups using tar simply work with=20
ReiserFS (30 minutes), but were longer than timeout (5 hours) with Ext3.
</OT>

>>I've already thought about that, in a much more sensitive configuration=
=20
>>: my application have to make sure the power consumption of the whole=20
>>house is below the max allowed (otherwise the power is shut down). If i=
t=20
>>fails to control the power, the computer will be shut off. If the power=
=20
>>up is not falsafely hardwired, the power will go down immediately.
>>This is like a death sentence to the program if it fails... So I won't=20
>>rely on any software for the failsafe values...
>=20
>=20
> I see... Indeed, your case is more critical.

But more simple, in fact : if I set all relays to be off when devices=20
power up, I'm sure I'am in a fail safe harbour and things will never go b=
ad.
Your HVAC can go bad when left alone (yet internal triggers should keep=20
it running well).

>>All that configuration can be changed, viewed, saved, etc., using=20
>>standard tools.
>>It can even represent/be represented by a 1-wire XML standard file.
>=20
> If it was up to me, I'd refrain from using XML altogether: adding a par=
ser
> bloats the application tremendously.

I just say that the file hierarchy could be saved as XML, or XML could=20
be used to create the hierarchy (but tar is a much easier way). Since=20
1-wire devices can store data, with a recommended XML format, this is=20
just a fancy possibility. <buzzwords/>

>=20
>=20
>>>As a side thought, I remember Paul and I discussing including data abo=
ut
>>>which DS2409 to specify as "transparent" - those that are used as bran=
ch
>>>switches don't really concern the application, therefore their arrival=
 and
>>>departure should be hidden from the end user.
>>
>>I think the owfs should remain a filesystem representing everything it=20
>>handles, not hiding anything or doing anything on it's own. It's the=20
>>application's job to handle specific b=E9haviour of devices.
>=20
> Now that I think of it, there's no need for a configuration file - all =
the
> stuff may be just written right into the OWFS itself ;)

Since OWFS is just a representation of the device, this means storing=20
this info into the devices ! Why not.
You are much more advanced than me in your project, so I trust you that=20
the need with arise eventually. I simply don't see now the need for=20
storing anything in the OWFS. Storing a file hierarchy with links to the=20
devices seems to me a good first shot.

>>Typically, I think there should have no or very little configuration of=
=20
>>the FS, and that configuration should remain global (ie. allow access t=
o=20
>>all users or only a group, lock the serial port, etc.).
>=20
> I agree that from one side OWFS may be viewed as "just a filesystem".
> However, trying to think outside of the box, I'll keep thinking of how =
to
> add additional levels of complexity without breaking elegant design.
> Plug-ins come to mind, one of possible ways is to provide an interface =
that
> will allow to create sort of "mounted" subtrees providing extra
> functionality.

I love to write simple tiny shell scripts with huge value-to-size ratio,=20
so I'll refrain from coding file-system plug-ins...
Here too, I trust you there is a need for things like that. I simply=20
don't see it for the moment.

NH

Re: [Owfs-developers] Random thoughts on configuration

[Vadim T. <vt...@fr...>]

According to Nicolas Huillard:

> Vadim Tkachenko wrote:

> > Here's some things that might be useful to simplify the life of an
> > application developer and ease some pain for those controlling hardwa=
re...
> >=20
> > It'd make sense to include two kinds of values into OWFS configuratio=
n:
> >=20
> > - "Initial settings". An example is a temperature resolution for DS18=
x20.
> >=20
> > - "Failsafe settings". An example is an initial state of a switch lik=
e
> >   DS2406 after a powerup that provides a safe state for the hardware =
it
> >   controls.
>=20
> Does all that devices have their own initial setting ?

Not necessarily - only those where it is indeed required

> Does failsafe setting be handled at a hardware level ?

Nope, can't do.

> My thought :
> * in a parasite power configuration, or when power to the microlan is=20
> injected by the computer, when power comes back, it comes back to the=20
> computer and the devices at the same time

Not necessarily. My case: breaker in a branch of a house shuts off, the
computer goes down. Meanwhile, HVAC keeps hvacing 'cause it's got its own
power branch, and increasingly goes nuts.

> * the devices are up un setup their own default/initial/failsafe values=
,=20
> without the help of anything
> * the computer slowly boot up, check disks, run services, have a coffee=
,=20
> then run owfs
> * when owfs is finally up and ready to talk to the devices, the valuabl=
e=20
> hardware they control has already had the time to go nuts...

Well, not necessarily. In case of Linux with ext3 the bootup process take=
s
less than a minute even in case of hard reset, and for my application not
all is lost.
=20
> I've already thought about that, in a much more sensitive configuration=
=20
> : my application have to make sure the power consumption of the whole=20
> house is below the max allowed (otherwise the power is shut down). If i=
t=20
> fails to control the power, the computer will be shut off. If the power=
=20
> up is not falsafely hardwired, the power will go down immediately.
> This is like a death sentence to the program if it fails... So I won't=20
> rely on any software for the failsafe values...

I see... Indeed, your case is more critical.

btw, do I guess right that you're using some sort of a power consumption
meter? This is offtopic here, though, feel free to drop me a mail.

> All that go back to the caching scheme : what cached value will be=20
> returned to the application if there were no previous read ? Maybe an=20
> empty cache read should trigger a device's read at the owfs level.

If it were Java, I'd say NotAvailableException ;)

> I plan to use a series of symbolic links to identify my devices : aside=
=20
> the owfs directory tree, I'll have an application tree of the devices,=20
> that will show devices by they real names, have links and conf files, e=
tc.
> Like that :
> 	1-wire/
> 		devices/ (owfs mount)
> 			10.234567/ (a device)
> 				id
> 				address
> 			DS9097U
> 		setup/ (application setup)
> 			level_0/
> 				temp -> ../../devices/[deviceID]/tempC
> 				threshold (simple conf file)
> 				heating -> ../../devices/[2406]/PIO_A
> 			level_1/
> 				temp -> ../../devices/[deviceID]/tempC
> 				threshold (simple conf file)
> 				heating -> ../../devices/[2406]/PIO_A
> 			power/
> 				meter -> ../../devices/[2423]/counter
> 				switch_1 -> ../level_1/heating
> 				switch_2 -> ../level_0/heating
> 			...
> (even level_3/temp -> .../devices/[1st2409]/main/[2nd2409]/aux/[1820]/t=
empC)
>=20
> All that configuration can be changed, viewed, saved, etc., using=20
> standard tools.
> It can even represent/be represented by a 1-wire XML standard file.

If it was up to me, I'd refrain from using XML altogether: adding a parse=
r
bloats the application tremendously.

> > As a side thought, I remember Paul and I discussing including data ab=
out
> > which DS2409 to specify as "transparent" - those that are used as bra=
nch
> > switches don't really concern the application, therefore their arriva=
l and
> > departure should be hidden from the end user.
>=20
> I think the owfs should remain a filesystem representing everything it=20
> handles, not hiding anything or doing anything on it's own. It's the=20
> application's job to handle specific b=E9haviour of devices.

Now that I think of it, there's no need for a configuration file - all th=
e
stuff may be just written right into the OWFS itself ;)

> Typically, I think there should have no or very little configuration of=
=20
> the FS, and that configuration should remain global (ie. allow access t=
o=20
> all users or only a group, lock the serial port, etc.).

I agree that from one side OWFS may be viewed as "just a filesystem".
However, trying to think outside of the box, I'll keep thinking of how to
add additional levels of complexity without breaking elegant design.
Plug-ins come to mind, one of possible ways is to provide an interface th=
at
will allow to create sort of "mounted" subtrees providing extra
functionality.

> NH

--vt

Re: [Owfs-developers] Random thoughts on configuration

[Nicolas H. <nhu...@gh...>]

Vadim Tkachenko wrote:

> Hello,
> 
> Here's some things that might be useful to simplify the life of an
> application developer and ease some pain for those controlling hardware...
> 
> It'd make sense to include two kinds of values into OWFS configuration:
> 
> - "Initial settings". An example is a temperature resolution for DS18x20.
> 
> - "Failsafe settings". An example is an initial state of a switch like
>   DS2406 after a powerup that provides a safe state for the hardware it
>   controls.

Does all that devices have their own initial setting ? Does failsafe 
setting be handled at a hardware level ?
My thought :
* in a parasite power configuration, or when power to the microlan is 
injected by the computer, when power comes back, it comes back to the 
computer and the devices at the same time
* the devices are up un setup their own default/initial/failsafe values, 
without the help of anything
* the computer slowly boot up, check disks, run services, have a coffee, 
then run owfs
* when owfs is finally up and ready to talk to the devices, the valuable 
hardware they control has already had the time to go nuts...

I've already thought about that, in a much more sensitive configuration 
: my application have to make sure the power consumption of the whole 
house is below the max allowed (otherwise the power is shut down). If it 
fails to control the power, the computer will be shut off. If the power 
up is not falsafely hardwired, the power will go down immediately.
This is like a death sentence to the program if it fails... So I won't 
rely on any software for the failsafe values...

All that go back to the caching scheme : what cached value will be 
returned to the application if there were no previous read ? Maybe an 
empty cache read should trigger a device's read at the owfs level.

I plan to use a series of symbolic links to identify my devices : aside 
the owfs directory tree, I'll have an application tree of the devices, 
that will show devices by they real names, have links and conf files, etc.
Like that :
	1-wire/
		devices/ (owfs mount)
			10.234567/ (a device)
				id
				address
			DS9097U
		setup/ (application setup)
			level_0/
				temp -> ../../devices/[deviceID]/tempC
				threshold (simple conf file)
				heating -> ../../devices/[2406]/PIO_A
			level_1/
				temp -> ../../devices/[deviceID]/tempC
				threshold (simple conf file)
				heating -> ../../devices/[2406]/PIO_A
			power/
				meter -> ../../devices/[2423]/counter
				switch_1 -> ../level_1/heating
				switch_2 -> ../level_0/heating
			...
(even level_3/temp -> .../devices/[1st2409]/main/[2nd2409]/aux/[1820]/tempC)

All that configuration can be changed, viewed, saved, etc., using 
standard tools.
It can even represent/be represented by a 1-wire XML standard file.

BTW : I think my application will be a set of many independent shell and 
CGI script files, run by cron, at, mon or ever running. This will give 
an infinite adaptability, no problem to reload configuration, no 
compilation, no ugly daemon, etc. All that is allowed by the marvelous 
OWFS, that act as a daemon AND a sharing protocol.

> 
> As a side thought, I remember Paul and I discussing including data about
> which DS2409 to specify as "transparent" - those that are used as branch
> switches don't really concern the application, therefore their arrival and
> departure should be hidden from the end user.

I think the owfs should remain a filesystem representing everything it 
handles, not hiding anything or doing anything on it's own. It's the 
application's job to handle specific béhaviour of devices.

Typically, I think there should have no or very little configuration of 
the FS, and that configuration should remain global (ie. allow access to 
all users or only a group, lock the serial port, etc.).

NH

[Owfs-developers] Random thoughts on configuration

[Vadim T. <vt...@fr...>]

Hello,

Here's some things that might be useful to simplify the life of an
application developer and ease some pain for those controlling hardware...

It'd make sense to include two kinds of values into OWFS configuration:

- "Initial settings". An example is a temperature resolution for DS18x20.

- "Failsafe settings". An example is an initial state of a switch like
  DS2406 after a powerup that provides a safe state for the hardware it
  controls.

As a side thought, I remember Paul and I discussing including data about
which DS2409 to specify as "transparent" - those that are used as branch
switches don't really concern the application, therefore their arrival and
departure should be hidden from the end user.

More later.

--vt

Re: [1-wire]Re: [Owfs-developers] What software do you (plan to)

[Vadim T. <vt...@fr...>]

According to Paul Alfille:

> On Sat, 2003-08-23 at 18:46, Nicolas Huillard wrote:

> > Vadim Tkachenko wrote:
> > >>* will it need alarms or detection of new devices (like iButton arrival)
> > > 
> > > Definitely. And departure, too. For me, this is a mission critical thing: If
> > > the switches or sensors are gone, that's really bad.
> > 
> > I agree. It's critical that devices attached to the network remain attached.
> > I was referencing iButton comming temporarily (like ID chips), that the 
> > software must intercept to act accordingly (ie. open the door).
> > I don't know if OWFS has a mechanism to allow such detection of unknown 
> > devices.
> > 
> > NH
> > 
> 
> Can either of you expand on this? Why do you want arrival and departure
> notices?

In my case, a departure of a device means a network failure, either
transient or permanent. Since the actuators control multi thousand dollar
hardware, and the hardware itself may be pretty dumb, alarm notifications
are critical, otherwise the losses will be huge. They will also be further
complicated by the fact that it will be extremely difficult to talk to home
warranty company or a manufacturer and convince them that the HVAC unit is
at fault, not the DIY piece of hardware and software.

> Are you scanning for ibutton contacts?

Not yet, however, if DZ ever gets to implement a "Bill Gates" mode when you
can touch the socket with your iButton and have the house set up your way,
then yes.

> OWFS doesn't care if devices come or go. The current implementation is
> almost entirely stateless. It only knows that a device might exist
> because it's ID is the filename. It will only read existing devices.
> There should be know ghosts, and no memory creep.

That's OK, but arrival/departure notifications are a must for mission
critical applications.
 
> I plan to have a fancier caching version, perhaps with hash tables, and
> cache of volatile (temperature) and stable (switch states) data, but
> I suspect it will introduce other problems.

Yes, it will. Every time a switch departs and then arrives back, you must
make sure its state is the same as before departure (if there was no control
input in the meantime). I've tried to make this transparent, it worked more
or less fine, but slow since it was competing with other 1-wire traffic.

> Paul Alfille

Re: [1-wire]Re: [Owfs-developers] What software do you (plan to)

[Vadim T. <vt...@fr...>]

According to Paul Alfille:
> On Sun, 2003-08-24 at 04:36, Nicolas Huillard wrote:
>    -snip-
> > I think you already thought about support for 2409 (1-wire hubs) : if 
> > so, did you think about a directory hierarchy like the following :
> > 	1wire/
> > 		[2409's ID]/
> > 			address
> > 			id
> > 			etc.
> > 			main/
> > 				[device's IDs on the main branch]/
> > 					address
> > 					etc.
> > 			aux/
> > 				[device's IDs on the aux branch]/
> > 					address
> > 					etc.
> > 
> > 
> > NH
> > 
> 
> Vadim Tkachenko and I have been brainstorming the DS2409 problem. We
> need everyone's thoughts.
> 
> The main problem is that the <main> and <aux> branches aren't obvious
> when you scan the bus, if I understand the chip's function correctly.
> 
> Everything on the switched-on branch appears as part of the scan, you
> don't know which side it's on. You can switch to the other branch,
> and by subtraction figure what's where, but if there are multiple
> 2409's, this can get very complicated and very slow. Still, I don't
> mind putting it in.

I've done it already, in the DAC module of DZ. Yes, it is indeed slow and
ugly - at that time, I just needed something working.

Basically, I am creating a memory map of the network, and then when I need
to access a device, the mapper level knows what branch should be open in
order to deliver the command to that device.

> Have you given any thought to the naming scheme? The filenames will
> get rather long.

Does it really matter? Human beings are unlikely to ever type them, plus,
there's bash name completion ;)
 
> Paul Alfille

--vt

Re: [1-wire]Re: [Owfs-developers] What software do you (plan to) run on top of OWFS

[Paul A. <pal...@ea...>]

On Sun, 2003-08-24 at 04:36, Nicolas Huillard wrote:
   -snip-
> I think you already thought about support for 2409 (1-wire hubs) : if 
> so, did you think about a directory hierarchy like the following :
> 	1wire/
> 		[2409's ID]/
> 			address
> 			id
> 			etc.
> 			main/
> 				[device's IDs on the main branch]/
> 					address
> 					etc.
> 			aux/
> 				[device's IDs on the aux branch]/
> 					address
> 					etc.
> 
> 
> NH
> 

Vadim Tkachenko and I have been brainstorming the DS2409 problem. We
need everyone's thoughts.

The main problem is that the <main> and <aux> branches aren't obvious
when you scan the bus, if I understand the chip's function correctly.

Everything on the switched-on branch appears as part of the scan, you
don't know which side it's on. You can switch to the other branch,
and by subtraction figure what's where, but if there are multiple
2409's, this can get very complicated and very slow. Still, I don't
mind putting it in.

Have you given any thought to the naming scheme? The filenames will
get rather long.

Paul Alfille


_______________________________________________
1-wire-software-development mailing list
1-w...@da...
To UNSUBSCRIBE, edit your profile, or visit the list archives, go to:
http://lists.dalsemi.com/mailman/listinfo/1-wire-software-development

RE: [Owfs-developers] [1-wire]OWFS : first install on Debian woody

[Gregg C L. <han...@wo...>]

Hello from Gregg C Levine
Paul, what's your building environment exactly? The source code breaks
with this error message:
Script started on Mon Aug 25 11:39:35 2003
root@drwho3:/usr/src/owfs/owhttpd_0.91# make
cd src && make all
make[1]: Entering directory `/usr/src/owfs/owhttpd_0.91/src'
gcc -O2 -pipe -I./../include -DHAVE_CONFIG_H -DHTTPD   -c -o owhttpd.o
owhttpd.c
In file included from ow.c:87,
                 from owhttpd.c:53:
ow_2502.c: In function `FS_r_09memory':
ow_2502.c:76: parse error before `int'
ow_2502.c:77: `s' undeclared (first use in this function)
ow_2502.c:77: (Each undeclared identifier is reported only once
ow_2502.c:77: for each function it appears in.)
make[1]: *** [owhttpd.o] Error 1
make[1]: Leaving directory `/usr/src/owfs/owhttpd_0.91/src'
make: *** [all] Error 2
root@drwho3:/usr/src/owfs/owhttpd_0.91# exit
Script done on Mon Aug 25 11:40:22 2003
And that's it. I use Slackware 8.0, at the moment. And it uses the
2.95.3 version, and the binary utilities version is, ld 2.11.90.19.
This is the first time I have seen an error message like that.
-------------------
Gregg C Levine han...@wo...
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: 1-w...@da...
[mailto:1-wire-software-
> dev...@da...] On Behalf Of Paul Alfille
> Sent: Sunday, August 24, 2003 11:52 PM
> To: 1wire
> Cc: owfs-developers
> Subject: RE: [Owfs-developers] [1-wire]OWFS : first install on
Debian woody
> 
> On Sun, 2003-08-24 at 03:04, Gregg C Levine wrote:
> >
> > I might also add, that both the one-wire file-system program that
I
> > chose, worked as advertised, and so did the hypertext based one.
> > Except for the fact that it didn't switch the DS2406 on or off. It
> > told me that it found the device, and that was it. This was the
TO-92
> > variety. I surmise that it would work with the TSOC packaged one.
> > Also, the website decided to not have on the server, version 0.8
of
> > the OWHTTPD program. Can't imagine why though. This was the
> > executable. Both copies of the source code were at home though. I
> > chose version 0.9 of both OWFS OWHTTPD, caps mine by the way.
> 
> I just tested out the DS2406 on the newest version of the OWHTTPD
> and it works! (I'm able to turn the pioA pin on and off). Sensing
> also works.
> 
> Download version 0.91
> 
> Paul Alfille
> 
> 
> _______________________________________________
> 1-wire-software-development mailing list
> 1-w...@da...
> To UNSUBSCRIBE, edit your profile, or visit the list archives, go
to:
>
http://lists.dalsemi.com/mailman/listinfo/1-wire-software-development

_______________________________________________
1-wire-software-development mailing list
1-w...@da...
To UNSUBSCRIBE, edit your profile, or visit the list archives, go to:
http://lists.dalsemi.com/mailman/listinfo/1-wire-software-development

[Owfs-developers] LCD over owfs

[Nicolas H. <nhu...@gh...>]

Paul Alfille wrote:
 > LCD support is next.

Cool : I'd love to run lynx on my 40x24 LCD screen, with a few keys to 
travel the pages.
	$ TERM=vt100 TERMCAP=...li#24:co#40... \
		attach-tty --stdin 1-wire/[2408]/sensed \
		--stdout 1-wire/[2408]/PIO \
		--mode 4bits_in_4_bits_out \
		--stderr /var/log/owfs-tty.log \
		lynx http://localhost/
attach-tty is a imaginary but maybe already existing glue, that create a 
tty from a read-only file (STDIN) and a write-only file (STDOUT), adding 
a little environment and signal handling, that run the given command and 
make sure to re-run it if it ever exits...
Maybe I'm not dreaming, despite the current time in the night at GMT+2.

NH

Re: [1-wire]Re: [Owfs-developers] What software do you (plan to) run on top of OWFS

[Nicolas H. <nhu...@gh...>]

Paul Alfille wrote:

> On Sat, 2003-08-23 at 18:46, Nicolas Huillard wrote:
> 
>>Vadim Tkachenko wrote:
>>
>>>>* will it need alarms or detection of new devices (like iButton arrival)
>>>
>>>Definitely. And departure, too. For me, this is a mission critical thing: If
>>>the switches or sensors are gone, that's really bad.
>>
>>I agree. It's critical that devices attached to the network remain attached.
>>I was referencing iButton comming temporarily (like ID chips), that the 
>>software must intercept to act accordingly (ie. open the door).
>>I don't know if OWFS has a mechanism to allow such detection of unknown 
>>devices.
> 
> Can either of you expand on this? Why do you want arrival and departure
> notices? Are you scanning for ibutton contacts?

This is not a requirement for me, but it would be cool. iButton are 
simply cool, and having a process blocked on waiting for an iButton is 
cool. Isn't it ?

=================
# Shutdown the server when the right iButton arrives on the case's probe
while : ; do
     # Wait for the devices :
     ADDR=$(cat $OW/10/monitor)
     # Check the arriving device
     if [ cat $OW/$ADDR/id = 'my authorized DS1990 ID' ] ; then
         shutdown -h now;
         exit;
     fi
done
=================

NH

[Owfs-developers] owfs doesn't keep /dev/ttyS0 open

[Nicolas H. <nhu...@gh...>]

Is it normal that I can run digitemp on ttyS0 at a cron rate of 1 per 5 
minutes ans ALSO owfs on the same ttyS0 ? It seems that they both open 
the serial device only when they need it (for digitemp, it obvious 
because it starts, scans then exists.
Does it mean that I can run both owfs AND owhttps on the same bus ? 
Granted I do not try to access the bus by both means at the same time.

NH

Re: [Owfs-developers] [1-wire]OWFS : first install on Debian woody

[Nicolas H. <nhu...@gh...>]

Paul Alfille wrote:
> On Sun, 2003-08-24 at 03:04, Gregg C Levine wrote:
> 
>>Paul, am I correct in assuming that with both OWFS programs, the
>>hypertext one, and the local one, that the contents can be viewed over
>>the network, that is with the programs running on a machine thats
>>connected to the other via LAN, I can simply use the normal collection
>>of Linux, and Windows tools to view what's being created?
> 
> I haven't tried SAMBA.

I can view the owfs content over a samba share : wonderful !
NFS is a bit more difficult, maybe because it's a kernel server. The nfs 
userland server might work.

NH

[Owfs-developers] owfs : about cache

[Nicolas H. <nhu...@gh...>]

About cache : I think there are two kind of cache :
* device contents cache (demembers state of individual devices)
* device list cache (remembers all device IDs)

Device contents cache has obvious benefits :
* caching converted temps for a while (or forever)
* remembering PIO states set by the user (not as obvious as it seems, 
because PIO and I/O..., but I'm not enough skilled about their real 
function to say)
* giving back the same counter value upon different readings by 
different scripts
* etc.
This can be implemented using new "files" :
* cached_tempC is the last value given by tempC
* cached_PIO_A is the last PIO_A read from or written to (that's the 
problem)
* cached_counter is the last counter read
* etc.

Device list cache is only useful to remember gone devices (obviously, 
arriving devices IDs do not need to be cached). But gone devices that 
need to be cached are devices that couldn't have been read because they 
where present a very little time on the bus, like an iButton hitting a 
probe.
I don't know the exact process behind a iButton on a probe : how it is 
discovered, does it need to remain on the bus until the application have 
read it and processed the event ?
Device list cache can be :
* a "ghost" directory containing subdirectories for each gone device, to 
remember a few parameters
* as just a list of IDs (no acces to anything the device was)
* or even doesn't exist...

I already expressed an idea about device arriving : a script is blocked 
on reading a file. When a new device arrive, the process read the IDs of 
the new devices. It must then go as fast as possible to get the 
information it wants from the devices, before they are gone offline. If 
the process is too slow, too bad, it will miss the device. That's why 
polling at the application level is not good : it would be better 
(faster) at the filesystem level.
If all that works, there is no need of device cache.

NH

[Owfs-developers] [OT] OWFS discussions

[Nicolas H. <nhu...@gh...>]

Does the discussions about owfs annoy people not related to owfs on the 
1-wire list ? If so, and if owfs developpers agree, we can switch to 
owf...@li... only.
Waiting for an answer before changing habits.

NH

Re: [1-wire]Re: [Owfs-developers] What software do you (plan to) run on top of OWFS

[Paul A. <pal...@ea...>]

On Sat, 2003-08-23 at 18:46, Nicolas Huillard wrote:
> Vadim Tkachenko wrote:
> >>* will it need alarms or detection of new devices (like iButton arrival)
> > 
> > Definitely. And departure, too. For me, this is a mission critical thing: If
> > the switches or sensors are gone, that's really bad.
> 
> I agree. It's critical that devices attached to the network remain attached.
> I was referencing iButton comming temporarily (like ID chips), that the 
> software must intercept to act accordingly (ie. open the door).
> I don't know if OWFS has a mechanism to allow such detection of unknown 
> devices.
> 
> NH
> 

Can either of you expand on this? Why do you want arrival and departure
notices? Are you scanning for ibutton contacts?

OWFS doesn't care if devices come or go. The current implementation is
almost entirely stateless. It only knows that a device might exist
because it's ID is the filename. It will only read existing devices.
There should be know ghosts, and no memory creep.

I plan to have a fancier caching version, perhaps with hash tables, and
cache of volatile (temperature) and stable (switch states) data, but
I suspect it will introduce other problems.

Paul Alfille

RE: [Owfs-developers] [1-wire]OWFS : first install on Debian woody

[Paul A. <pal...@ea...>]

On Sun, 2003-08-24 at 03:04, Gregg C Levine wrote:

> Paul, am I correct in assuming that with both OWFS programs, the
> hypertext one, and the local one, that the contents can be viewed over
> the network, that is with the programs running on a machine thats
> connected to the other via LAN, I can simply use the normal collection
> of Linux, and Windows tools to view what's being created?

Obviously OWHTTPD is network enabled. Just point your browser to
http://your.1wire.machine:3001 to see and change your 1wire bus.

Some points:
1. The machine name should be your actual IP adddress or machine name.
2. The 3001 should be the port you used when you ran owhttpd 
    e.g. owhttpd -d /dev/ttyS0 -p 3001
3. Security is outside the owhttpd perview. I'd suggest proper filewall
rules.
4. Perhaps someone can give good instructions on using ssh to bind ports
and get a secure connection to the owhttpd program.

OWFS is a different matter. You can log onto the machine, but nfs access
to the mounted directory doesn;t seem to work. I've emailed the
author of FUSE, Miklos Szeredi, for assistance. I haven't tried SAMBA.

Paul Alfille

RE: [Owfs-developers] [1-wire]OWFS : first install on Debian woody

[Paul A. <pal...@ea...>]

On Sun, 2003-08-24 at 03:04, Gregg C Levine wrote:
> 
> I might also add, that both the one-wire file-system program that I
> chose, worked as advertised, and so did the hypertext based one.
> Except for the fact that it didn't switch the DS2406 on or off. It
> told me that it found the device, and that was it. This was the TO-92
> variety. I surmise that it would work with the TSOC packaged one.
> Also, the website decided to not have on the server, version 0.8 of
> the OWHTTPD program. Can't imagine why though. This was the
> executable. Both copies of the source code were at home though. I
> chose version 0.9 of both OWFS OWHTTPD, caps mine by the way.

I just tested out the DS2406 on the newest version of the OWHTTPD
and it works! (I'm able to turn the pioA pin on and off). Sensing
also works.

Download version 0.91

Paul Alfille

Re: [1-wire]Re: [Owfs-developers] What software do you (plan to) run on top of OWFS

[Bob H. <bo...@ja...>]

In message <200...@fr...>, Vadim
Tkachenko <vt...@fr...> writes
>Perl is not a right tool for complex projects. Java is the best rapid
>prototyping tool, and C++, though burdensome in development, has no equal
>where it gets to complexity/weight ratio. Java is way too heavy for small or
>embedded boxes.


I think this depends on what you mean by "complex". With Perl you can
achieve a very high degree of functionality, usually in a much shorter
time period than could be achieved by a comparable C++ development.
However, Perl projects do not lend themselves to partitioning between
more than a couple of developers particularly well. So if "complex"
means "a big project with lots of developers" then I'm inclined to agree
with you.

As for Java; it can work very nicely on small or embedded devices for
the right types of application - consider TINI.

In my opinion, one of the beauties of UNIX like operating systems, with
their "everything looks like a file" metaphor and substantial use of
scripts and text files is that their internal workings are readily
visible from the user environment. Having some form of script interface
to a facility such as OWFS preserves this. In contrast a compiled
development environment supported by libraries pushes you more deeply
into "API world" - the normal preserve of the Win32 developer, where
everything is still accessible, but only if you have all the sources and
appropriate development tools. This is obviously a necessary step for
complex (many developer) projects and closed-source developments where
you don't want the internal workings to be visible, however it's a shame
to be forced down that route for relatively small projects of an open-
source nature.

Just my 2 pence worth.

Bob

Re: [Owfs-developers] What software do you (plan to) run on top of OWFS

[Nicolas H. <nhu...@gh...>]

Vadim Tkachenko wrote:
> I'm definitely planning to run DZ (http://diy-zoning.sourceforge.net/) on
> top of OWFS.

If I understand correctly the DZ project, you plan to replace the 1-wire 
Java classes and your specific TCP protocol by the OWFS. This will 
achieve two functions : communication between the program and the 
devices, and communication between programs.

>>* will it need alarms or detection of new devices (like iButton arrival)
> 
> Definitely. And departure, too. For me, this is a mission critical thing: If
> the switches or sensors are gone, that's really bad.

I agree. It's critical that devices attached to the network remain attached.
I was referencing iButton comming temporarily (like ID chips), that the 
software must intercept to act accordingly (ie. open the door).
I don't know if OWFS has a mechanism to allow such detection of unknown 
devices.

NH

Re: [Owfs-developers] What software do you (plan to) run on top of OWFS

[Vadim T. <vt...@fr...>]

According to Nicolas Huillard:

> Since OWFS is really functionnal, I'm asking myself what kind of 
> software one really run or plan to run on it :

I'm definitely planning to run DZ (http://diy-zoning.sourceforge.net/) on
top of OWFS.
 
> * will it be simple query of devices (1820 temp)

yes, but rather a group query (I'd guess if it is determined that there are
several DS18x20 devices on the branch, the temp convert should be issued to
all, and no time will be lost performing conversion for each of them)

> * will it also set devices (2406 switch)

yes, also 2408

> * will it set device depending of other devices (say a 2423 counter 
> indicates too much wind, so close the windows using 2506s switches

maybe later

> * will it depend on other factors like the time (purely internal to the 
> computer)
> * will it need alarms or detection of new devices (like iButton arrival)

Definitely. And departure, too. For me, this is a mission critical thing: If
the switches or sensors are gone, that's really bad.
 
> To implement this, do you plan on :
> 
> * making a set of plenty of light shell scripts and cron or at jobs ?

See the site

> * having a bigger Perl script that remains in memory and handle all the 
> tasks in a more process-efficient way (only one long-living processes 
> for a specific set of tasks, maybe a few of these processes to handle 
> different and independent sets of staks) ?

Perl is not a right tool for complex projects. Java is the best rapid
prototyping tool, and C++, though burdensome in development, has no equal
where it gets to complexity/weight ratio. Java is way too heavy for small or
embedded boxes.

> * using an existing framework and develop a wrapper between the OWFS and 
> this framework (MisterHouse of something like that) ?

yes

> * develop a simgle C daemon and simply use OWFS as a convenient way to 
> access the devices ?

maybe
 
> NH

--vt

[Owfs-developers] What software do you (plan to) run on top of OWFS

[Nicolas H. <nhu...@gh...>]

Hello,

Since OWFS is really functionnal, I'm asking myself what kind of 
software one really run or plan to run on it :

* will it be simple query of devices (1820 temp)
* will it also set devices (2406 switch)
* will it set device depending of other devices (say a 2423 counter 
indicates too much wind, so close the windows using 2506s switches
* will it depend on other factors like the time (purely internal to the 
computer)
* will it need alarms or detection of new devices (like iButton arrival)

To implement this, do you plan on :

* making a set of plenty of light shell scripts and cron or at jobs ?
* having a bigger Perl script that remains in memory and handle all the 
tasks in a more process-efficient way (only one long-living processes 
for a specific set of tasks, maybe a few of these processes to handle 
different and independent sets of staks) ?
* using an existing framework and develop a wrapper between the OWFS and 
this framework (MisterHouse of something like that) ?
* develop a simgle C daemon and simply use OWFS as a convenient way to 
access the devices ?

All thoughts are welcome !

NH

[Owfs-developers] OWFS : first install on Debian woody

[Nicolas H. <nhu...@gh...>]

Hello,

I finally had a chance to test OWFS on my own (and on my Debian Woody) : 
it works fine ! I am very impressed by this software : thank you Paul 
(and others) for that.
My config : OWFS 0.9 / Linux 2.4.18 i586 / Debian Woody / Cyrix P200+ / 
iButtonLink / 1-wire (MicroLAN) covering the whole house.

As a first-time user, I have a few questions and remarks (that could go 
into a FAQ, readme, or simply stay in th mailing-list archive) :

* I'd love to see a Debian package for OWFS/OWHTTPD (I whish I had the 
time and skill to do that)
* the TODO list says "Direct implementation in the kernel" : in a simple 
sysadmin point of view, this would be wonderful. Currently, logging is 
done through STDOUT/ERR of a background user process, which is not very 
good (syslog ?); if the process dies, the mount point is still there but 
not active, etc.
* the interaction between the ow program and the fusermount program is 
not obvious : "ow" outputs messages saying "fusermount: ***", but if I 
try to run ow using the fusermount program, it fails (traces below). Are 
these two programs doing the same thing, or are they complementary ?
* how do I cleanly umount my own mount ???


Here is a list of what I did : what worked, what didn't, etc.


COMPILATION/INSTALLATION
* untar the source : tar -xvzf ow_0.9.tar.gz
* run as your own uid, in the extracted directory : ./configure
* run as your own uid : make
* become root, then run : make install
	if you are not root, make install won't be able to copy the fuse.o 
module in the /lib/modules/[you kernel version]/kernel/fs/fuse/fuse.o


VARIOUS TESTS
* the Redhat spec file have a "/sbin/depmod -a" in the postinstall step, 
so I did it, but maybe it isn't really useful (run it as root)
* to check if the fuse.o module is loaded into the kernel : lsmod
     Module                  Size  Used by    Not tainted
     fuse                   11920   1
* to check if the mount point is really mounted (as yourself) : mount
     /proc/fs/fuse/dev on /mnt/1-wire type fuse 
(rw,nosuid,nodev,user=nhuillard)


MOUNT
* first, you have to create your mount point, which must belong to you : 
I prefer to have this mount point in my own home dir, but it can be 
/mnt/1-wire if you wish
* I don't know the interaction between "ow" and "fusermount" (which 
could unmount), so I only used "ow" (PWD = the one that you've extracted 
from the tar.gz) :
	./ow/ow -d /dev/ttyS0 /mnt/1-wire
* -d : adds debug traces on STDOUT/STDERR of the "ow" process
* the "ow" process will exit when you unmount the filesystem, so don't 
expect to type commands in the same TTY...
* another way to mount in the background, with traces on a log file 
(waiting for syslog traces) :
	./ow/ow /dev/ttyS0 mnt/1-wire/devices > /var/log/owfs.log 2>&1 &
* check the mount with the "mount" command, also check the loaded kernel 
modules (lsmod)


UNMOUNT
* that's where all is not clear : I tried to simply kill the "ow" 
process, but the "mount" command stills shows the mount, and the mounted 
hierarchy says "ls: .: Transport endpoint is not connected"
* after killing the process, one must, as root :
	umount /proc/fs/fuse/dev
* if you simply "umount /proc/fs/fuse/dev" (as root), the process stops, 
and all is right (except for the "fusermount: entry for 
mnt/1-wire/devices not found in /etc/mtab" message when the program exits)
* the problem is that the real user that umounted the FS can't unmount 
it, or I didn't find the way :
	nhuillard@palma:~$ fusermount -u /proc/fs/fuse/dev
	fusermount: entry for /proc/fs/fuse/dev not found in /etc/mtab


I hope this will help others, and if someone can answer the few 
questions there, I will be really happy !

NH

[Owfs-developers] Re: [1-wire]OWHTTPD documentation

[Joel W. <jo...@in...>]

Try http://sourceforge.net/projects/owfs/

----- Original Message ----- 
From: <be...@ea...>
To: <1-w...@da...>
Cc: "owfs-developers" <owf...@li...>
Sent: Friday, August 22, 2003 2:11 PM
Subject: RE: [1-wire]OWHTTPD documentation


> This is a broken link -->   http://owfsw.sourceforge.net/ow_table.html
> 
> -----Original Message-----
> From: 1-w...@da...
> [mailto:1-w...@da...]On Behalf Of Paul
> Alfille
> Sent: Friday, August 22, 2003 1:00 PM
> To: 1wire
> Cc: owfs-developers
> Subject: [1-wire]OWHTTPD documentation
> 
> 
> I've upgraded the documentation for OWFS and OWHTTPD, see 
> http://owfs.sourceforge.net
>  and http://owfsw.sourceforge.net/ow_table.html
> 
> Also added support for the DS1904 DS2417 clocks and other stuff.
> 
> LCD support is next.
> 
> 
> _______________________________________________
> 1-wire-software-development mailing list
> 1-w...@da...
> To UNSUBSCRIBE, edit your profile, or visit the list archives, go to:
> http://lists.dalsemi.com/mailman/listinfo/1-wire-software-development
> _______________________________________________
> 1-wire-software-development mailing list
> 1-w...@da...
> To UNSUBSCRIBE, edit your profile, or visit the list archives, go to:
> http://lists.dalsemi.com/mailman/listinfo/1-wire-software-development
> 

[Owfs-developers] RE: [1-wire]OWHTTPD documentation

[<be...@ea...>]

This is a broken link -->   http://owfsw.sourceforge.net/ow_table.html

-----Original Message-----
From: 1-w...@da...
[mailto:1-w...@da...]On Behalf Of Paul
Alfille
Sent: Friday, August 22, 2003 1:00 PM
To: 1wire
Cc: owfs-developers
Subject: [1-wire]OWHTTPD documentation


I've upgraded the documentation for OWFS and OWHTTPD, see 
http://owfs.sourceforge.net
 and http://owfsw.sourceforge.net/ow_table.html

Also added support for the DS1904 DS2417 clocks and other stuff.

LCD support is next.


_______________________________________________
1-wire-software-development mailing list
1-w...@da...
To UNSUBSCRIBE, edit your profile, or visit the list archives, go to:
http://lists.dalsemi.com/mailman/listinfo/1-wire-software-development