Am Mittwoch, 6. Dezember 2006 01:14 schrieb Paul Alfille:
> 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.
>
As Eric pointed out, there aren't so many chips with EPROM or EEPROM on board,
and I don't like the idea to incorporate such a chip into any design I do.
They are fairly expensive (e.g. DS2406 costs €1.92+VAT per chip if you take
500pcs), and this price has to be payed by the end user.
> (That is why humidity is present for the DS2438, even though not all chips
> are part of such a device).
>
Same with LCD_x for the DS2408.
> 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.
>
If we use e.g. an sqlite database, we won't need the ability to modify the
database in the owlib code. There are many tools out there which could handle
sqlite databases.
Plus, it's an SQL database engine with many language bindings, so helper
programs could be scripted easily. The database engine is a small-footprint
one, so it could be incorporated even in NSLU2 type devices.
If Eric favours this approach for the hobby-boards, too, we have at least two
vendors which will support a global aggregate database, so the inconvenience
for the user could be quite low.
> We also need a policy on whether components can be seen/addressed/changed
> outside of the aggregate.
>
Having both would be straightforward, but I think there will be additional
problems with aggregate states if the chips could be addressed outside the
aggregate. I would put a note like "If you mix both modes, results may be
undefined" and leave it to the user.
And there has to be some indicator whether the aggregate is detected as a
whole or some chips are missing.
> 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.
>
As a final goal, aggregate routines may offer timing or simple if-then
decisions within the same aggregate, or even different aggregates. That would
help much in simplifing the software on top of owfs.
I favour a plugin concept for such aggregate routines, so the aggregate logic
could be separated from the owlib core.
Kind regards
Jan
--
We are Pentium of Borg. Division is futile. You will be approximated.
-------------------------------------------------------------------------
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
