I have been toying with the idea of doing something similar for my devices. Kind of an extension of the tagging "standard" that Dallas came up with. I have a few devices now that could use it and some on the drawing board that will really need something like this to make them easier to use. This is one area of 1-Wire that I feel keeps it in the tinker's realm and out of the more mainstream general user's hands. If software could "know" what the device was then it would make software setup much easier.
I like the idea of "autodiscovery" but very few 1-Wire chips have any kind of memory to store that information. It would be nice to come up with a "standard" that multiple vendors could use and that could be accessed by many different software applications out there. It would also be nice to have one server that held that information so that the software wouldn't have to query many different servers to find the information on a specific device. Eric www.hobby-boards.com Paul Alfille wrote: > Currently, the only aggregate we support is the TAI-8570 barometer, > which uses 2 DS2406. In that case, the DS2406 memory is used to point to > the partner chip, so the aggregate can be "autodiscovered". There is > certainly an appeal to autodiscovery. The barrier to entry and use is > much lower. (That is why humidity is present for the DS2438, even though > not all chips are part of such a device). > > The database of aggregates needs > 1. unique ID > 2. vendor/type > 3. component IDs (Perhaps in some specific order) > 4. Optional parameters/calibration constants > > There is some appeal to having the database > accessible/modifiable/savable within OWFS, though that is a design > decision that can go either way. > > We also need a policy on whether components can be > seen/addressed/changed outside of the aggregate. > > For the multi-level design of OWFS (owfs -> owserver for example) it > becomes a little more complex as to which process needs to know about > the aggregate. The level with the actual physical adapter might make the > most sense. > > Paul Alfille > > On 12/5/06, *Jan Kandziora* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > wrote: > > May I chime in and bring aggregates onto topic? I developed some > boards which > will go into "mass"-production next year. > > One is a 8 channel solenoid driver board for 24V~ solenoid valves. > It uses one > (next revision has two, for an additional function per channel) > DS2408 as the > onewire interface. > > Second is a 8 channel counter/16 Channel digital input board using > four DS2423 > and two DS2408 chips. > > Another one is a 8 key keyboard with 12 LEDs (one per key and 4 > other). I > think of a numpad keyboard with built-in HD44780 display, too, but > that's not > done yet. These are using three/two DS2408 chips. > > And then, a lighted keylock, with a single DS2409 and a single DS2408. > > These items are for my vending machine project but, as spare parts, > will be > available to the general public, too. Don't know yet if the price > will be > interesting enough for hobbyists, though. > > For my machine, I'll have to write some code to identify and control > these > aggregates anyway. It may be more useful to the general public if we > could > develop a generic aggregate handling for owfs, I think. At least, if > there > was aggregate support built into owfs, they could be controlled in > single > transactions and the need for a *single* program controlling the > hardware is > gone. > > My idea is to have a database which map chip ids to aggregates. At > first, the > user connects the aggregate board as the only device to the onewire. > Then a > maintainer's program, which knows the aggregate types, helps the > user to > identify the chips on the aggregate and their function and finally > updates > the database. > > (For my boards, I will perform these steps and keep an updated database > available for download e.g.) > > In a first step, the database only has to contain > > * chip ID > * chip number on aggregate > * vendor ID > * aggregate ID > > with vendor ID/aggregate ID being a unique item. > > Then owfs could present an aggregates/ directory, with all the > aggregates > detected on the bus, the database contents and symlinks to the > chips. And > vice versa for each chip. > > In the second step, handlers for such aggregates could be > incorporated into > owfs (like it is done with the LCD aggregate already). Maybe even by > a plugin > interface? > > > Hope the text was not too long, too boring or simply unfeasible. > > Kind regards > > Jan > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > ------------------------------------------------------------------------ > > _______________________________________________ > Owfs-developers mailing list > Owfs-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/owfs-developers ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
