On 07.02.2016 21:39, Jerry Scharf wrote: > Here is a problem statement that I wrote up about how to move to what I > think of as a distributed building automation system.
I'm also thinking about (and designing+coding in) this problem space, albeit with a few key differences. * I disagree that state should only be inherent in messaging. That means you have nothing to return to after a crash, reboot, or power failure. "I have no ide whether the alarm system is armed" is not a reasonable system state. * I also disagree that there should be no configuration. Configuration is necessary. _Something_ shall tell the system what the code for disarming the alarm is. Or simply which switch(es) control which light(s). * However, I agree that any one central essential system must be allowed to fail, if only to continue operation when updating the thing. The corollary is that processing may indeed happen anywhere, and should be able to take over quickly when warranted. Talk is cheap. So are concept papers; I have to admit I'm one of the persons who have discovered that the hard way. You need a minimal working system to have a reasonable discussion. Haystack has clients and servers in multiple languages, including some (albeit at first glance rather rather incomplete) unit tests, but are these actually *used* by somebody for anything? WRT "nest" vs. "thermostat" model: The Nest model is not about controlling your home. It is about keeping data about your home in the cloud so that whoever offers the service (Google now owns Nest …) can do some deep data mining on it. It is also about the complete impossibility of doing anything whatsoever in your own home as soon as the Internet connection fails, and of having bricks instead of thermostats if the company providing their cloud service ever goes belly-up. Or just decides to no longer support them. The "thermostat" model is too limited. Heating is in fact a good example: If I know the actual valve settings at all my thermostats, I can raise or lower the central heating's temperature appropriately. This can save a lot of energy, but might be unstable unless there is two-way communication between these devices. NB: Project Haystack: the first thing I would do with that body of text (and code) is to rip out their unit system -- including every single mention of square feet, °F, or time zones. The code to convert between units MUST be a function of the user interface, not of every single agent in the system. That way lies madness. NB²: "users work with a meta-model" does not make sense. The meta-model is, per definition, the design of the language which the model is described in. This is fixed by the system components' design and implementation. Do you mean that users describe their system at a higher level of abstraction, i.e. in some kind of macro language? What happens when the user doesn't provide enough information for the agents to infer their devices' configuration? -- Matthias Urlichs ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
