Multilang-Strings einfach auslesen

Problemstellung

Beim Auslesen einer Eigenschaft in EPlan kommt ein String wie ??_??@Inhalt des Feldes; oder bei übersetzten Feldern eher de_DE@Inhalt des Feldes;en_US@Content of the field; was aber gewünscht war, war nur Inhalt des Feldes. Ursache ist in beiden fällen ein als mehrsprachig markiertes Feld, welches einen Multilang-String aufnehmen, verarbeiten und darstellen kann. Vergleiche mit anderen Strings sind so natürlich schon zum scheitern verurteilt, wenn das nicht berücksichtigt wird.

Problemlösung

Nun gibt es zwei verschiedene Ansätze, die mir direkt in den Sinn kommen:

  • Nach ; splitten, den ersten Teil bei @ splitten und schon ist der zweite Teil das Ergebnis. Das ist allerdings auch immer der hoffentlich deutsche oder allgemeine Teil, gesichert ist das nicht. Nun könnte man noch nach dem ersten Splitt alle Elemente durchsuchen und nach de_DE@ oder ??_??@ (oder eben nach der gewünschten Zielsprache) im Anfang prüfen, aber auch das ist weder schön noch performant
  • Suchen mit regulären Ausdrücken direkt nach dem richtigen Ausdruck in der passenden Sprache mit Fallback-Lösung
Weiterlesen

Visualisierung von Adresslisten @PowerShell

Problemstellung

Basis ist der Artikel Visualisierung von Adresslisten. Die Problemstellung ist die Selbe, nur „aber ich hab doch kein Linux“ kommt nun hinzu. Und weil es schon interessant ist, das selbe Problem auch mal anders zu lösen, nun nochmal in der PowerShell, die unter Windows schon wirklich viel nutzbares mit bringt, was doch eher unter Unix allgemein als Bordmittel bekannt ist. Also gleich ans Eingemachte:

Denken wir Groß – nun in der PowerShell

Als Basis dient wieder die selbe *.csv mit folgendem Inhalt

Gruppe;Name;Beschreibung;Adresse
Macs;Mac1;Nikolaiort;Nikolaiort 1-2 49074 Osnabrück-Innenstadt
Macs;Mac2;Theodor-Heuss-Platz;Theodor-Heuss-Platz 1 49074 Osnabrück-Innenstadt
Macs;Mac3;Pagenstecher;Pagenstecherstr. 72 49090 Osnabrück-Hafen
Macs;Mac4;Hannoversche;Hannoversche Str. 45 49084 Osnabrück-Fledder
Macs;Mac5;Hauptstrasse;Hauptstr. 105 49205 Hasbergen-Gaste
BKing;BKay1;Moserstrasse;Moserserstr. 51 49074 Osnabrück
BKing;BKay2;Pagenstecher;Pagenstecherstr. 50 A 49090 Osnabrück
BKing;BKay2;Hannoversche;Hannoversche Str. 74 49084 Osnabrück

Parse the Line

Auch hier geht es erstmal mit dem Einlesen und dem Parsen los. Hier aber direkt incl. der Sortierung:

Weiterlesen

Visualisierung von Adresslisten

Problemstellung

„Ach, was machst du denn hier?!“ hieß es letztens von einem Kita-Papa meines Kindes, als er mich nahe unseres Zuhauses ebenfalls auf dem Weg zur Kita traf. Bis dahin wusste ich allerdings auch nicht, dass sie bei uns ums Eck wohnt.
Daher die Idee: Alle Adressen zu visualisieren, da wir Bilder eben einfacher begreifen. Wichtig für mich dabei:

  • Es sollte dem Datenschutz genügen -> Als Visualisierung nicht gerade GoogleMaps o.ä. nutzen, die Speicherung der Daten idealerweise offline
  • Für spätere Erweiterungen per Script aus einer Liste erstellbar (*.csv, *.xlsx,..)
  • Gruppen differenzierbar durch unterschiedliche Farben und/oder Icons

Lösungsansatz manuell

Adressen in Geopunkte/Koordianten

Am Anfang steht, nach der Bereinigung der Daten geht’s an die Abfrage der Koordinaten. Man könnte nun jede einzelne bei GoogleMaps suchen und sich aus der Adresszeile die Koordinaten heraus nehmen(wäre blöd wegen des Datenschutzes). Das selbe geht auch mit OpenStreetMap über den Perma-Link. Aber es geht auch noch schöner und sauberer:

Weiterlesen

Designrichtlinie und Epläne?!?!

Designrichtlinien in technischen Dokumenten

Bei Designrichtlinien geht es um grundlegende Regeln, die Abteilungs-, Unternehmens-, oder Konzernweit festgehalten werden. das kann von Platzierungsregeln, die Wahl von Schriftarten oder Farben, Linienstärken bis zu genauen Abständen, Formatierungsvorgaben oder auch Vorlagen für Word, Excel und Co. Im Grunde ist jedes Normblatt, jeder Zeichnungsrahmen schon eine Art Designrichtlinie, da er einen gewissen Rahmen vorgibt. In einigen Programmen gibt es die Möglichkeit Linien auf gewissen Layern zu hinterlegen, um Höhen etc. vorzugeben.

Einen weiteren Rahmen werden auch durch Normen vorgegeben, zum Beispiel die Linienstärken in DIN 15, bzw. DIN ISO 128, Gewindedarstellungen in DIN 14 Teil 1+2, Technische Zeichnungen in DIN ISO 10209 Teil 2 und viele mehr. Es gibt auch für textliche Darstellungen Designregeln Beispielsweise die Kennzeichnungen von Betriebsmitteln in der Elektrotechnik nach EN IEC 81346-2 oder Dokumententypen nach EN 61355. Vieles, was den allermeisten schon längst (un)bewusst bekannt sein sollte.

Designrichtlinien in EPlan bzw. in Auswertungen

Daher zurück zum Thema. Was bringt eine Designrichtlinie für Auswertungen?

  • Nach außen: Ein einheitliches Aussehen und einen professionell wirkenden Auftritt!
  • Nach innen: Feste Strukturen und Sicherheit bei der Nutzung für die Nutzer der Auswertungen
  • Das Verhalten (wenn auch das Schemata in Auswertungen definiert wird) wird berechenbar -> Fehlersuche bei Problemen einfacher
Weiterlesen

Warum Openhab

Bei der Wahl des eigenen Smarthome Systems ist oftmals die Liste der Wünsche, Fragen und Anforderungen lang:

  • Welche Daten kann es alles erfassen und welche sollen gesammelt werden? Sensordaten, Statusdaten, Infos von weiteren Server
  • Läuft es lokal oder in der Cloud?
  • Welche Protokolle und Schnittstellen werden unterstützt?
  • Welchen Invest habe ich? Der Server selbst und auch das Material für die Anbindungen
  • Was existiert schon? Beispielsweise eine Fritzbox mit Steckdosen oder Thermostaten
  • Mit welchen Kosten ist zu rechnen (Cloudkosten, Stromkosten, Batterien)

Und auch wenn man schon stark vor filtert, bleiben noch viele über. Für mich persönlich stand im Vordergrund:

  • Sensordaten sollen erfasst werden um langfristig auch Wissen daraus extrahieren, Beispielsweise die Luftfeuchtigkeit in den Räumen. Längerfristig steigende Luftfeuchtigkeit deutet zB. auf Schimmel o.ä. hin, steigende Verbräuche bei festen Setting auf ein mögliches ende der Lebenszeit
  • Es soll definitiv offline funktionieren. Wenn mal wieder die Internetverbindung abbricht, möchte ich nicht im dunklen stehen, also eigener Server.
  • Wichtig waren mir Schnittstellen zu MQTT, SONOS, Netzwerk
  • Beim Invest sollte möglichst auf vorhandenes zurück gegriffen werden, wie auf den Pi4 (eigentlich für ein anderes Projekt gedacht) und seitens Software kam nichts anderes als Opensource in frage
  • Zu den Sensoren und Aktoren: Es existierten aus einer längeren Phase mit FHEM einige WLAN-Steckdosen mit Tasmota, IKEA Geräte und Sensoren mit Zigbee.
  • Der Server als auch die Endgeräte sollten möglichst sparsam sein
  • Die Oberfläche sollte über die Konfigurationsseiten angepasst werden können und nicht über HTML-Dateien wie in FHEM
Weiterlesen

Semantic Model in Openhab

Hintergrund und Nutzen

Am Semantic Model kommt man in Openhab kaum vorbei und wenn man sich einmal damit beschäftigt hat, wird auch schnell der Nutzen klar. Mit dem Semantic Model wird das eigene Haus als Struktur abgebildet, samt aller Ebenen, Räume, Geräte und deren Funktionen. Damit ist von einer kleinen 3-Zimmer Wohnung bis zur mehrgeschossigen Stadtvilla oder zu mehreren Standorten alles möglich.

Wird das Modell sauber aufgebaut, könnte mit Scripten und Regeln durch das ganze Haus navigiert werden. Das kann für komplexere Funktonen interessant sein, zum Beispiel beim generieren von Seiten.
Apropos Seiten: Auf diesen sollen die jeweiligen Steckdosen/Lampen/Sensoren/Lautsprecher etc. des Raumes dargestellt werden. Mit Widgets lassen sich dann Gruppen von Lampen oder Steckdosen dynamisch darstellen.

Tipps zum Aufbau

Wie schon beschrieben, wird das Modell immer von der größten Einheit zur kleinsten aufgebaut, hier mal als Beispiel für ein kleines Eigenheim:

Weiterlesen