Das Ziel des Ganzen

Nach all dem Hard­wa­re-Klein­kram nun ein Ex­kurs zum Großen Gan­zen: wo will ich mit die­ser Idee über­haupt hin?

  • Red­un­danz. Es sol­len mög­lichst vie­le Ge­rä­te er­setz­bar sein, ­so dass das Gan­ze auch dann noch funk­tio­nier­t, wenn ei­nes aus­fäll­t.
  • Ein­fa­che Pro­gram­mie­rung. Klei­ne, auf das Nö­tigs­te re­du­zier­te ­Skrip­te er­le­di­gen ge­nau ei­ne Auf­ga­be.
  • Ak­ti­ve Kon­fi­gu­ra­ti­on. Das heißt: die Sys­te­me lau­schen auf Än­de­run­gen der ­Kon­fi­gu­ra­ti­on und le­gen dort gg­f. einen Feh­l­er­sta­tus ab. Es gibt kein "Re­loa­d" und kei­nen zen­tra­len Ser­ver.
  • Das Kon­fi­gu­ra­ti­ons­sys­tem "weiß", wel­chen Zu­stand je­des Ob­jekt hat, wel­chen es ha­ben soll, und wie­so. Nir­gends an­ders gibt es ak­tu­el­le ­Zu­stands­in­for­ma­tio­nen, d.h. wenn das Sys­tem kom­plett neu star­tet (Strom­aus­fall?), ist da­nach al­les ge­nau­so wie vor­her.
  • Ba­ckends, die auf ein sha­red me­di­um zu­grei­fen, sol­len sich ­ge­gen­sei­tig über­wa­chen und not­falls er­set­zen. D.h. Funk­sys­te­me ha­ben ei­nen Emp­fän­ger, der über­wacht, dass tat­säch­lich ge­sen­det wur­de; wenn ein ­ka­bel­ge­bun­de­ner Ad­ap­ter nicht mehr funk­tio­nier­t, so gibt es einen wei­te­ren, der ihn er­set­zen kann.
  • Funk­sys­te­me wer­den nur im äu­ßers­ten Not­fall ein­ge­setz­t, weil Bat­te­ri­en ­wech­seln doof ist und weil die Fun­ke­rei stör­an­fäl­lig ist.

Und wie will ich das er­rei­chen?

  • Als Pro­gram­mier­spra­che wird durch­gän­gig Py­thon3 ver­wen­det. Nein, kein Ja­va, kein Ja­vas­crip­t, und auch kein Go oder Er­lang.
  • Für die sta­ti­sche Kom­mu­ni­ka­ti­on (d.h. al­les, was nach ei­nem Strom­aus­fall ­gen­au­so wie­der da sein soll wie vor­her) und für al­le Zu­stands­an­ga­ben (Tem­pe­ra­tur, …) ver­wen­de ich et­cd.
  • Auch Zie­le ("das Licht im Flur soll AN sein") und Feh­ler ("­Der fürs Licht ­zu­stän­di­ge KNX-Ak­tor rea­giert nicht") be­hand­le ich als sta­ti­sche Da­ten. ­Sie wer­den na­tür­lich ent­fernt, wenn das Ziel er­reicht bzw. das Pro­blem ­be­ho­ben ist.
  • Für die dy­na­mi­sche Kom­mu­ni­ka­ti­on (RP­C, PubSub, …) ver­wen­de ich Rab­bitMQ. Die­ser Bus hat den Vor­teil, dass er das MQT­T-Pro­to­koll un­ter­stütz­t, d.h. man kann pro­blem­los Open­HAB oder mo­bi­le Ge­rä­te an­bin­den.
  • Für die klei­nen pe­ri­phe­ren Steu­er­auf­ga­ben ver­wen­de ich den 1wi­re-­Bus ­mit selbst­ent­wi­ckel­ter Sla­ve-­Soft­wa­re ("­MoaT").
  • Für die 230V-­Ge­rä­te ver­wen­de ich KNX.

Nächs­tes Pro­blem: das Al­les braucht Soft­wa­re.

  • Auf­­­bau­end auf AM­QP schrei­­be ich ein klei­­nes aber fei­­nes Mes­sa­­ging-­­Sys­tem. Das Sys­tem ist auf Re­d­un­danz aus­­­ge­legt (d.h. meh­re­­re RP­C-­­Ser­­ver für das­­sel­­be Ob­jekt kom­­men sich nicht in die Que­re) und in­s­­be­­son­­de­re ­­be­ob­acht­­bar (Feh­­ler­­su­che!).

    • Die Ba­­sis ist fer­tig.
    • Co­­de für RPC oder PubSub ist schnu­cke­­lig klein.
    • Die Tools feh­len noch.
  • Auf­­­bau­end auf et­cd schrei­­be ich ein klei­­nes Mo­­ni­to­ring-­­Sys­tem, das ­­mir er­laub­t, Er­eig­­nis­­se auf be­­lie­­bi­­gen Ebe­­nen zu be­ob­ach­ten.

    • Der grun­d­le­­gen­­de Co­­de ist fer­tig.
    • Co­­de für Mo­­ni­to­ring von Än­­de­run­­gen ist noch ru­­di­­men­tär und zu kom­plex.
    • Tool­s: ?
  • Der et­cd-­Da­ten­­be­­stand muss ge­eig­­net struk­tu­riert wer­­den: * Hard­wa­ree­­be­­ne (der KNX-­­Bus für Adres­­sen 1/2/* wird über Rech­­ner xy­z­­zy er­reicht) * funk­tio­na­le Ebe­­ne (das Licht im Flur wird von ei­­nem Bit auf KNX-­­Adres­­se 1/2/3 ge­s­teu­er­t) * Sta­tus (das Licht im Flur ist an) * Ziel (das Licht im Flur soll aus sein, weil es jetzt Tag ist)

    Sta­tus: ru­­di­­men­tä­­re Ge­dan­ken.

  • 1wi­­re und die Ge­rä­te dar­an möch­ten an­­ge­spro­chen wer­­den.

    • Im al­ten MoaT-­­Py­thon­­co­­de exis­tiert Co­­de da­­für, der viel zu auf­­wän­­dig und feh­­ler­an­­fäl­­lig pro­­gram­­miert ist und re­­cy­­celt wer­­den mag.
    • MoaT-­Au­to­­dis­­co­­ve­ry (Ge­rä­te er­ken­­nen und in et­cd ein­­füt­tern) fehlt groß­­teils.
    • MoaT-­­Alar­m­­be­han­d­­lung ist ru­­di­­men­tär vor­­han­­den.
  • di­to KNX.

    • Die Bu­s­an­­bin­­dung er­le­­digt der knxd. Sta­tus: funk­tio­­niert ei­­ni­­ger­­ma­­ßen.
    • Statt Au­to­­dis­­co­­ve­ry gibt es ei­­ne Pro­jek­t­da­tei, für die es noch kei­­nen Par­­ser gib­t.
  • Vi­­sua­­li­­sie­rung: Feh­­ler­an­­zei­­ge, et­cd-Struk­tur­­brow­­ser * ru­­di­­men­tä­res GT­K-Fron­tend da­­für ist vor­­han­­den. * We­b­fron­tend wä­­re net­t.

  • ???

  • Pro­­fit.


Dem­nächst mehr.

Kommentare

Comments powered by Disqus