Let's talk to our home

Also available in:

Deutsch

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­ac­t­­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 state 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 shall 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 tran­s­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. Its main sel­l­­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­nec­t­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 needs 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.