Jerry, I think database is still the way to go. It's not either or with messaging, and chronological data is great to have and in some cases necessary (e.g. for PID). It allows conditional abstraction for arbitrary logic, so a condition like this is automatically parsed and processed:
[controldb:io:processedvalue:id=28ae436bddccbbaa] > 24 and [controldb:io:processedvalue:name=myvalve]==False For SMS try email to text. I use gmail in Python and it works great. C > On Jan 1, 2016, at 6:20 PM, Jerry Scharf <sch...@lagunawayconsulting.com> > wrote: > > 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 ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
