Am 31.12.2015 um 21:59 schrieb Jerry Scharf:
>
> I've been lurking for a while. This isn't exactly 1-wire related, but I
> know a bunch of people on this list are interested in control systems.
>
As I'm doing a similar thing professionally (with Onewire, OWFS, Tcl,
Raspi), I first want to point out the most crucial thing all the
existing solutions lacked was proper handling of fault modes. It makes
out 1/3 of all my application and I still don't think I have enough code
to catch and recover from *all* errors in the finest granularity possible.
So if you want to design something unique and useful, start with
thinking about what could happen to the sensor boards when they are
power-cycled, as that is the most common fault. Next, what happens on
various kinds of lost communication. Which component in the tree should
detect it, how is it escalated, who retry/recovers it and so on.
For most important things (outputs controlling beer valves ^_^;) I even
have a watchdog timer on the peripherals which turn them off
automatically if the board hasn't had communication with the next
upstream hop within 10 seconds.
Another thing is the abstraction needed. I have different generations of
boards which may be mixed in any system installed. For me, outputs are
mostly valves of different kinds (tap and lock valves for beverages,
valves for switching barrels, valves controlling detergent lye and
water) and inputs are either switches, counters or buttons. This is
already on the lowest level.
Some more abstraction is done on the upper levels, too, but it came to
me it is crucial to have support for some basic abstractions on the most
lowest levels to implement proper fail-safe behaviour. That is, the
Raspi controlling your window blind C3 should know what the fail-safe
state for it is - open or closed, so it can reach it without the help of
the main program. And if the peripheral has support for configuring and
fail-safe state and reacts on it's own subsequently, this should be
configureable in an abstracted way.
In my system, I have done a class hierarchy which covers both aspects.
Objects are storing an internal representation of the state of the
peripheral and managing it through the line of programmed events, and,
to recover from exceptional situations, in two interrupt loops (one
timed, one based on conditional search). That way it's able to catch and
recover from such things as pulled mains cables at the peripherals
within seconds.
Oh, and I think you are on the edge here. All my system could do is to
lock you from beer, yours could lock you up in your house and tell noone.
Kind regards
Jan
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
