Let's talk to our home

This page at­tempts to show a broad over­view of what I'm try­ing to ac­com­plish with my home au­to­ma­tion soft­are projec­t.

  • Re­dun­dan­cy. Don't de­pend on one sin­gle serv­er or ser­vice. Ev­ery­thing should be re­place­able. Up­grad­ing some­thing on-site, or hunt­ing down a bug, shall not cause the bath­room light to not turn on.
  • Sim­ple pro­gram­ming mod­el. Small tools shall ac­com­plish ex­act­ly one task.
  • Ac­tive con­fig­u­ra­tion. All sys­tems shall ac­cess some com­mon on-­line ­con­fig­u­ra­tion stor­age; up­dates to that con­fig shall be­come "live" im­me­di­ate­ly. There shall be no "Reload" but­ton, let alone "Restart".
  • The con­fig sys­tem shall know which state each de­vice is in and which s­tate it should have (and why). There's no oth­er state stored any­where, this when the whole sys­tem gets restart­ed ev­ery­thing will be as be­fore.
  • Back­-end sys­tems which ac­cess a com­mon medi­um shall mon­i­tor and/or re­place each oth­er, if at all pos­si­ble. Thus, a wire­less sys­tem shal­l have a re­ceiv­er which mon­i­tors the sender, wired sys­tems shall have more than one bus mas­ter (ac­tive if pos­si­ble, pas­sive if not).
  • Wire­less sys­tems are on­ly used when ab­so­lute­ly nec­es­sary. I don't want to ­fight oth­er trans­mit­ter­s, or re­place bat­ter­ies.
  • Good alarm han­dling (fire, in­trud­er) needs to be part of the de­sign.
  • I want to have in­tel­li­gent heat­ing con­trol.

How do I plan to get there?

  • The Pro­gram­ming lan­guage shall be Python3, with the asyn­cio con­cur­ren­cy mod­el. No Java, no JavaScrip­t, no Go or Er­lang. Al­so no thread­ing, geven­t, mul­ti­pro­cess­ing or what­ev­er, un­less there's no oth­er way to talk to a par­tic­u­lar back­-end li­brary.
  • Stat­ic con­fig­u­ra­tion (ev­ery­thing that's to be re­stored as-is af­ter a pow­er fail­ure) and state (tem­per­a­ture, …) will be stored in etcd.
  • In­tents and er­rors are treat­ed the same way as states. They're just go­ing ­to be delet­ed when their goal is reached or the prob­lem is fixed.
  • Dy­nam­ic com­mu­ni­ca­tion (R­PC, Pub­Sub) will go through Rab­bit­MQ. It­s ­main sell­ing point is the fact that it al­so talks MQT­T, which is great ­for con­nec­tiong to Open­HAB, or mo­bile de­vices.
  • Smal­l­-­volt­age pe­riph­ery will be con­nect­ed with 1wire, prefer­ably us­ing the "MoaT" slave de­vice code.
  • The "Gi­ra Du­al" smoke alarms have a de­cent se­ri­al in­ter­face which has been re­verse-engi­neered. Al­so, they can be pow­ered ex­ter­nal­ly.
  • Mains pow­er is con­trolled us­ing the KNX bus.
  • Build an in­ter­face for the Gi­ra, and a 24V PWM mod­ule for con­trol­ling the ­valves of my ra­di­a­tors.

So … all of this re­quires soft­ware. And some hard­ware.

  • I'll write a small RPC sys­tem on top of AMQP. It'll sup­­port re­­dun­­dan­­cy, dis­­­cov­­er­a­bil­i­­ty and mon­i­­tor­ing/de­bug­ging.

    • The base code is done.
    • Code to at­­tach to RPC or Pub­­­Sub is re­fresh­ing­­ly sim­­ple.
    • Some tools are mis­s­ing.
  • I'll write a snall con­troller+­­mon­i­­tor to talk to etcd, al­low­ing me to ­­mon­i­­tor events on what­ev­er lev­­el I wan­t.

    • Ba­sic code is done.
    • Code for change mon­i­­tor­ing is some­what rudi­­men­­ta­ry and too com­­plex.
    • Tool­s: ?
  • Da­­ta in etcd need to be struc­­tured and well-laid-out.

    • hard­ware lev­­el (KNX ad­­dress­es 1/2/x are beind the bus at­­tached to sys­tem 'xyzzy')
    • func­­tion­al lev­­el (the hal­l­way light is con­trolled by a bit at KNX ad­­dress 1/2/3)
    • state (the hal­l­way light is on)
    • in­­­tent (turn off the hal­l­way light be­­cause it's past dawn)
      • pri­or­i­­­ty (the wall switch shall al­ways tog­­­gle the light, but the pres­ence sen­­­sor may do that on­­­ly when it's dark)

    State: pre­lim­i­­nary thought­s.

  • Talk to 1wire and the de­vices be­hind it.

    • The old MoaT code has sup­­port for 1wire, but it's too con­vo­­lut­ed and er­ror prone.
    • Mis­s­ing: au­­todis­­­cov­­ery of MoaT de­vices.
    • Pre­lim­i­­nary code for MoaT de­vice's alarm han­dling.
  • Same for KNX.

    • Talk­ing to the phys­i­­cal bus is han­­dled by knxd. State: work­s, most­­ly.
    • In­­stead of au­­todis­­­cov­­ery, KNX has a re­al­­ly con­vo­­lut­ed XML project file which needs to be ­­parsed. State: pre­lim­i­­nary code.
  • Vi­­su­al­iza­­­tion: er­ror dis­­­play, etcd da­­ta struc­­ture brows­er. * there's a rough GTK-Fron­­tend. * Some web fron­­tend would be nice.

  • Hard­ware: pro­­to­­types ex­ist; the heat­ing con­troller work­s, Gi­ra need­s ­­soft­­ware which is not yet writ­ten.

  • ???

  • Prof­it.

    Se­ri­ous­­ly: I do not plan to mar­ket this com­mer­­cial­­ly.

More lat­er.