my thoughts within the text...
2010/2/26 Jim Kusznir <jkusz...@gmail.com>
> A PC is definitely more powerful, and its programming paradigms are
> easier to address, true. However, we've played those games in our OW
> setup, and have been going back to the "do-it-on-hardware" side. For
> us, we have a large network of OW devices (often 50+), a PC software
> suite written by a couple different people that needs to collect all
> the data, and we're looking at control. Of course, timeliness is also
> an issue.
>
> I consider that 1wire slaves should have autonomous capabilities where
master play the role of orchestrator giving consigns to slaves and getting
reports from them.
> We found that often, we ran into OW bus saturation issues. Something
> as simple as alarming on the 2450 not working almost took down our
> bus, as we had to poll it. Now, not only are we wasting a lot of bus
> bandwidth (which was delaying other devices and messing with our
> project in a negative sense), but we were also not getting our analog
> data as timely and precisely as we wanted.
>
> Bus overrun was indeed one of my preoccupations when I began my project.
We're also looking at other activities, such as a OW-based
> thermostat/heating control system. For this, we definitely want a
> local thermostat, as if the OW system goes down, so does heat...Out
> here, that can mean frozen / broken pipes. Combine that with people
> living in the space who are not familiar with the innards of the
> technology (i.e., not able to restart/diagnose the OW system), and
> you've got a fixed requirement for local backup control.
>
If you want to use 1-wire device in your home simply for your lighting, you
cannot rely on a slave master communication latency/stability to react on
push button events. I was required to provide a responsive and stable
solution to gain my wife acceptance :-/
>
> We're also looking at some new motion sensors (our primary OW device
> is a motion sensor equipped with an DS2406), that would need a fair
> bit more processing and would be producing a much "richer" data
> format. For us, its important that 1) the device identify that it is
> a "rev xx motion sensor" and provide the richer data in such a way as
> to not saturate our bus. This requires local pre-processing and
> decisions on when to "raise the alarm".
>
> In addition, auto-identifying systems is important for us. We have
> several of these large-ish deployments, and often have limited time to
> set them up. We take great lengths to try and make the system as
> automated as possible, especially in the setup phase. To this end, we
> use the EEPROM in the 2406's to burn in a device type ID to further
> distinguish between the various devices we have that use 2406's. If
> we go to a microprocessor model to replace or provide input types not
> available in dallas chips, it would also be critical that the chip
> identify its function to the system. That was a major headache we
> have with the 2450 presently...We don't know how to treat its values
> (we see we have 4 analog readouts now, but what are they? Some we
> only have A hooked up, we don't even care about B, C, or D...Others
> have ranges on the various pins that mean different things and in some
> cases we have to change how we read certain pins for precision, etc).
> To us, hard-coding this at the PC is an absolute mess of a hack that
> we wish to avoid.
>
I proposed to Paul during development of BAE0910 to have the chip itself
publishing field mapping to dynamically present fixed/configured features to
owfs. But currently owfs don't support dynamic properties.
> So, for us it would be wonderful to have a microprocessor which we
> could configure to do any preprocessing we want it to, put in some id
> string that the OW master can read, and support "custom data types",
> ideally including the scaling and precision type settings in the chip.
>
As soon as owfs support such niceties I will support this.
>
> To this end, it seems to me that a wonderful solution would be a
> microprocessor with a "base" code (USB flashed, etc) that would have
> its OW ID and a basic "bootloader" code in it. I could then select a
> code function (either supplied by others or written by myself), and
> "cat" it to the right OWFS "file" to program that personality. I've
> spoken to some local ATMEL experts, and they say that's very doable
> with the atmel line of chips.
>
> I would also like to suggest that the code is available open source.
> I've already encountered a few other commercial projects similar to
> the BAE which have about 70% of what we need for a project or
> experiment. But, as the source is closed, our only option is to use
> it as is, or pay them to develop what we want. We already have the
> programmers on staff who are more connected with the problem and have
> the proper environment to test, so it doesn't make sense to pay for
> their development services. Much of what we do will be highly custom,
> so source access is very important to us.
>
BAE chip are already able to receive AE script to embed your specific logic.
>
> That said, I think there's still a commercial market for devices
> pre-programmed. While we're perfectly happy with buying stock
> microcontrollers and flashing them with custom code, many people won't
> be. While we can write our own functions and such, some people would
> want to select from "x channel A2D" or "pwm controller", etc. Some
> people may even want to pay someone to program custom modules for
> their application. However, if we end up with another closed-source
> solution where groups like us can't get the source and modify it for
> our custom applications, I think its doing a disservice to the OW
> community. By opening up the source, I think we'll quickly see a wide
> variety of new applications and functionalities that were not
> previously thought of, or exceed the resources of an individual to
> develop and commercialize.
>
> So, to answer tmk's thoughts on "why not just do it in a PC", that's
> an appropriate answer for some applications, but not all. And even if
> you're doing it in the PC, you're probably going to need devices for
> input or control that Dallas doesn't make. Rather than try and make
> the "one microprocessor that does it all", I think everyone will
> benefit from being able to configure the microprocessor with certain
> "personalities" to do what you need it to. In essence, its the linux
> vs windows way: make a heavyweight system that tries to be a jack of
> all trades (but masters none), or be able to make small,
> single-purpose devices that do exactly what is needed and nothing
> more. My experiences to date, especially with OWFS has found great
> power in the latter. Even if specific program logic or decisions are
> not loaded onto the devices, having a device that does only what it
> needs to will still improve reliability and such overall.
>
> --Jim
>
> On Fri, Feb 26, 2010 at 12:47 AM, <nufan_...@comcast.net> wrote:
> >> From a users perspective I want more flexible slave devices which are
> >> capable of making decisions themselves.
> >> With the host (OWFS) providing a means of configuration and
> >> supervision only. At this stage I do not care about what
> >> hardware platform the slaves takes on however I am
> >> more interested in the control functionality that new slaves can offer
> >> then look at what can facilitate the functions requirements.
> >
> > I think there is a lot of power in having little systems that do their
> thing without much intervention. There is a fine line between a device that
> can make simple decisions and a mesh of controllers.
> >
> > In my projects so far, i've wavered between a central server that has
> some daemon making all the decisions, vs a uC which is basically autonomous,
> and is itself is a 1w master able to make all sorts of decisions.
> >
> > I am currently leaning towards the former, but the reliability and
> forgetability you propose may pull me back just a bit.
> >
> > Most of the below comments are my internal pro/con reasoning for my
> stance, and not meant to be a dismissal of your proposals.
> >
> >> Making a “User” go into the uC and program there own code
> >> satisfies a small portion of the users of 1wire. I would suggest
> >> creating “functions” could be more viable to the mass’s.
> >
> > If one was going to package and sell such a device (i'm not interested
> really), there are direct USB bootloaders for the AVR stuff which makes
> flashing code as easy as a usb connection. (serial also)
> >
> > I believe Pascal even has reflashing via 1-wire working!
> >
> > So uploading a 'personality' is not a big deal, and for an extra $0.50
> i'm sure anyone making these devices could pre-program it. If one wanted to
> package all the personalities in, then it would cost a small amount (extra
> $1-2?) for a device with more storage/eeprom space.
> >
> >> Timed Output Slave:
> >>
> >> Function : Control up to 4 outputs based upon a set of preset
> >> time-of-day triggers. Enable up to 4 push buttons to manually control
> >> each output.
> >
> > I was thinking of just such a device. I am sick of shelling out for
> sprinkler controller systems! I have 3 separate ones and none really offer
> me the programmability i want. Same for my home thermostat. Needs to be a
> button by the door that says 'i'll be out for 2 hours'.. None of this going
> to the hallway business! :)
> >
> > Unfortunately, most uC's that i have dealt with don't have RTC, and they
> are relatively expensive. I am also way too lazy to cobble one on, when i
> have a perfectly good computer (with a working clock) already attached via
> 1-wire.
> >
> >> Configuration: Let the user assign up to 32 trigger points each
> >> trigger having a PIO mask to either turn ON or OFF the outputs.
> >
> > No need for a limit with computer control, really, and you could do much
> more complex decision making.
> >
> >> Slave hardware requirements : A uC with 4 DIO ADC for buttons and a
> >> I2C interface to a battery backed RTC module.
> >
> > Manual control buttons need not be logic based (analog!), but certainly
> could do.
> >
> > Already up to 2 busses: i2c+1-wire..
> >
> >
> >> Analog Input Slave:
> >>
> >> Function: Provide ~4 ADC inputs with a resolution better than 8 bits!
> >> The device will provide scaling and signal conditioning and conversion
> >> to engineering units directly within the device.
> >
> > I am not to familliar with a lot of the lower-level details of ADC, but i
> believe a scaler almost always has to be an external hardware component
> (therefore out of scope?), or the uC has to have a flexible reference
> voltage larger than the range of the input. (in other words, scaling to <
> Vcc has some hardware support, but detecting higher voltages maybe not?)
> >
> > If it's externally scaled, then (as you suggest) just a multiplier could
> be applied
> >
> > AVRs seem to have 10bit adc, is 12 common? Just curious
> >
> >> Configuration: Let the user assign both scaling etc coupled with 4
> >> alarm level per ADC. A number of available PIO pins can be assigned
> >> to set an output based upon alarm levels.
> >
> > Why stop there? any feature of the uC should be triggerable based on an
> alarm, eg change pwm freq, tick counter, calculate time spent in state..
> easier to add the logic via computer.
> >
> >> Would also be great to
> >> download a 20 point x,y characterization curve that could be applied
> >> to the measured variable. Used for measuring level or volume in a
> >> sphere or as in my case a tank which has not got parallel sides.
> >
> > Transformation is dead simple on full-strength hardware, and can use full
> equations if desired.
> >
> >> Analog Controller Slave:
> >>
> >> Function: Provide a controller that has the ability to compare a
> >> scaled reading to a user defined setpoint and perform an output action
> >> via PIO .
> >
> > This is straight where i am headed, and may be the most useful bit..
> temperature controller for heating/cooling. However i may end up doing some
> zoning type stuff and have sensors/control in every room. I think that might
> be a bit much to calculate on a single uC, and having dedicated ones might
> cause the systems to oscillate.
> >
> > Also, there are full-featured controller programs (diy-zoning, mango,
> etc) that already do this sort of stuff.
> >
> >> PID Control , Where a DAC output is set according to the error between
> >> Measured variable and setpoint with an output value modulated via a
> >> PID algorithm
> >
> > Another great use for a uC. I think this should be implemented. DAC not
> necessarily the only output, but certainly a primary one. 'killer app' for
> smart sensors.
> >
> >> process. The Analog_slave I described above does fit my analog
> >> faceplates created on my web site. I also have defined control
> >> faceplates as well. www.rjconway.homeip.net Thus we could create a
> >> matching GUI for each function.
> >
> > Some nice stuff there, very cleanly done. congrats
> >
> > -tmk
> >
> >
> ------------------------------------------------------------------------------
> > Download Intel® Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Owfs-developers mailing list
> > Owfs-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/owfs-developers
> >
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
--
Pascal
www.brain4home.eu
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
