Jan, Thanks for pointing this out. I will raise this up the priority in the project.
I have some ideas for certain things that can happen autonomously, but the issue with a highly integrated system driven by a few critical pieces is that it all runs or dies together. All the valves won't deal with a failed boiler and my experience is that my control hardware and software has been more robust than equipment it drives. I also need to get an SMS interface going to tell me when things are amiss. I treat life safety stuff very differently from comfort stuff. Where I live, HVAC is rarely a life threatening issue. In very cold places, it is much more critical. Happy new year, jerry On 12/31/2015 11:46 PM, Jan Kandziora wrote: > 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 ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
