Temperatur und Feuchtigkeit in Telegram vom RaspberryPI

Ich möchte hier beschreiben, wie man mit einem RaspberryPI die Temperatur und Feuchtigkeitswerte sich aufs Handy per Telegram schickt.
Verraussetzung ist ein RaspberryPI 3 b+ und ein Temperatur / Feuchtigkeitssensor, ich habe folgendes verwendet:

  • DSD TECH DHT22 AM2302 Temperatur und Luftfeuchtigkeit Sensor Modul für Arduino Raspberry Pi
  • RaspberryPI 3 B+

Anleitung wie man den Sensor an den RaspberryPI ansteckt, findet man reichlich im Netz z.B. Sensor-Einbau RaspberryPI/
Da in diesem Artikel auch schon beschrieben wird, wie man mit dem Tool Adafruit die Werte Temperatur und Feuchtigkeit ausliest, werde ich hier nicht genauer darauf eingehen.
Soviel, Ich lasse das Skript per cronjob zu bestimmten Zeiten ausführen und erhalte dann die Werte via Telegram auf mein Handy weitergeleitet.

Nur wie kann man sich die Werte auf das eigene Handy per Telegram senden lassen? Das werde ich hier kurz beschreiben.

Voraussetzung:

  • Handy mit der App Telegram (Apple IOs oder Android)

Als erstes müssen wir uns in Telegram einen eigenen Bot erstellen,  den wir später per API erreichen können,

wie das funktioniert, wird auch in vielen Webseiten bereits erklärt z.B. Telegram Bot erstellen

So, da der Bot jetzt bereit ist um per API Nachrichten zu empfangen, brauchen wir einen API-Aufruf der so aussehen kann:

curl -X POST 'https://api.telegram.org/botid:token/sendMessage?chat_id=id&text='$(/usr/local/sbin/AdafruitDHT.py 2302 4)'' > /dev/null 2>&1

Ich habe die Ausgaben die auf der Shell kommen nach /dev/null geleitet, denn die brauchen wir nicht, wenn es funktioniert.

Für die ersten Tests würde ich die Ausgabe schon sichtbar lassen, um den JSON-Output mal gesehen zu haben und gegebenenfalls Fehlermeldungen zu sehen.

curl -X POST 'https://api.telegram.org/botid:token/sendMessage?chat_id=id&text='$(/usr/local/sbin/AdafruitDHT.py 2302 4)'' | python -m json.tool

{
"ok": true,
"result": {
"chat": {
"first_name": "Johannes",
"id": 400269857,
"last_name": "Carraro",
"type": "private",
"username": "xxxx"
},
"date": 1563270619, <-- UNIXTIMESTAMP
"from": {
"first_name": "Raspberry",
"id": xxxxxx,
"is_bot": true,
"username": "xxxxx"
},
"message_id": 265,
"text": "Temp=20.8C::Humidity=75.8%"
}
}

Wie wir sehen war die Ausgabe erfolgreich und wir sollten auf dem Handy im Telegram eine neue Nachricht mit der Temperatur und Feuchtigkeit bekommen haben.

Man kann sich über den RaspberryPI mit verschiedenen Sensoren deren Werte so auf das Handy per Telegram schicken lassen, eine coole Sache.
Anwendungsbeispiel: Zimmergewächshaus, Zimmertemperatur, Außentemperatur etc.

Jetzt wünsche ich viel Erfolg beim nach basteln!

Natürlich kann ich jedem unsere Trainings nahelegen rundum OpenSource-Themen

Johannes Carraro
Johannes Carraro
Support Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

Sommerhitze & Powershell 3 kleine Tipps

Hallo Netways Follower,

Ich melde mich dies mal mit einem kurzen aber meist vergessenen Thema nämlich wie kriegt man unter Windows diese vermaledeiten Powershell Skripts korrekt zum laufen.

Wenn man bei einem normalen Icinga2 Windows Agenten diese in ‘Betrieb’ nehmen will benötigt es etwas Handarbeit und Schweiß bei diesen Sommertagen um dies zu bewerkstelligen.

Trotzdem hier ein paar Tipps:

1) Tipp “Powershell Skripte sollten ausführbar sein”

Nachdem der Windows Agent installiert und funktional ist sollte man sich auf der Windows Maschine wo man das Powershell Skript ausführen möchte in die Powershell (nicht vergessen mit Administrativer Berechtigung) begeben.

Um Powershell Skripts ausführen zu können muss dies erst aktiviert werden dazu gibt es das folgende Kommando

Set-ExecutionPolicy Unrestricted
Set-ExecutionPolicy RemoteSigned
Set-ExecutionPolicy Restricted

Hier sollte zumeist RemoteSigned ausreichend sein, aber es kommt wie immer auf den Anwendungsfall an. More Info here.

Nach der Aktivierung kann man nun überprüfen ob man Powershell Skripts ausführen kann.
Hierzu verwende ich meist das Notepad um folgendes zu schreiben um anschließend zu prüfen ob das oben aktivierte auch klappt.

Also ein leeres Windows Notepad mit dem folgenden befüllen:

Write-Host "Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul. "

Das ganze dann als ‘test.ps1’ speichern.

Nun wieder in die Powershell zurück und an dem Platz wo man das Powershell Skript gespeichert hat es mit dem folgenden Kommando aufrufen.
PS C:\Users\dave\Desktop> & .\test.ps1
Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul.

Sollte als Ergebnis angezeigt werden damit Powershell Skripts ausführbar sind.

2) Tipp “Das Icinga2 Agent Plugin Verzeichnis”

In der Windows Version unseres Icinga2 Agents ist das standard Plugin Verzeichnis folgendes:
PS C:\Program Files\ICINGA2\sbin>

Hier liegen auch die Windows Check Executables.. und ‘.ps1’ Skripte welche auf dem Host ausgeführt werden sollten/müssen auch hier liegen.

3) Tipp “Powershell 32Bit & 64Bit”

Wenn ein Skript relevante 64Bit Sachen erledigen muss kann auch die 64er Version explizit verwendet werden in den Check aufrufen.

Das heißt wenn man den object CheckCommand “Mein Toller Check” definiert kann man in dem Setting:

command = [ "C:\\Windows\\sysnative\\WindowsPowerShell\\v1.0\\powershell.exe" ] //als 64 Bit angeben und
command = [ "C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe" ] // als 32Bit.

Hoffe die drei kleinen Tipps erleichtern das Windows Monitoring mit Powershell Skripts.
Wenn hierzu noch Fragen aufkommen kann ich unser Community Forum empfehlen und den ‘kleinen’ Guide von unserem Kollegen Michael. Icinga Community Forums

Ich sag Ciao bis zum nächsten Mal.

David Okon
David Okon
Support Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

Terraform Changes

Hallo!

Was vielen von unseren Lesern entgeht, ist das wir auch in unserem Alltag zwischen der ganzen Softwareschreiber- und Kompilier- Tätigkeiten auch ganz viele virtuelle Maschinen und Container zum testen selbiger Software rauf und runter installieren müssen, und das Tag für Tag.

Deshalb versuchen wir uns das Leben mit dafür erstellter Software und deren arbeitserleichternden Funktionen leichter zu machen. Wie mein Kollege schon in seinem Blogpost im März mir vorgegriffen hat, benutzen wir bei der Netways Terraform. Achim wird in weiteren Artikeln darauf eingehen wie man Openstack per Terraform nach seiner Pfeife tanzen lassen kann und Ich möchte mich heute auf ein anderes Terraform Thema beziehen, nämlich dem nahen Release von Terraform 0.12.

Zu dem Zeitpunkt wo ich diese Zeilen niederschreibe, ist auf der aktuellen Website von Hashicorp noch die Aktuelle Version 0.11.13 zu finden.

Aber Terraform hat uns schon vielversprechendes gezeigt mit dem 0.12.0-beta1 pre-release.

Damit kann man schon die vielen Erleichterungen, welche der neue Terraform Release mit sich bringt erahnen und auch schon antesten. Ich versuche die Änderungen Anhand eines kleinen Beispiels zu erläutern.
Vielleicht kann ich den einen oder anderen IaaS Codeschreiber, welcher sich hierfür interessiert, etwas auf den Geschmack zu bringen schon etwas zu testen mit der neuen Version.

Hier der Unterschied zwischen einer (aktuell 0.11.13) alten Terraform Version und einer neuen Version in Terraform 0.12 durch eine Gegenüberstellung.

main.tf (Random Tiernamen Beispiel)

variable "count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "zoo_enabled" { default = "0" } variable "prefix_liste" { default = [] } resource "random_pet" "my_pet" { count = "${var.count}" prefix = "${var.zoo_enabled == "0" ? var.default_prefix : element(concat(var.prefix_liste, list (""), count.index)}" }

main.tf HCL2 Version(Random Tiernamen Beispiel)

variable "pet_count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "prefix_list" { default = [] } resource "random_pet" "my_pet" { count = var.pet_count prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix }

Die Unterschiede fallen zuerst etwas weniger ins Auge, sind aber dafür meines Erachtens tiefgreifender für Leute, die IaaS Code schreiben müssen und dienen der Lesbarkeit des Codes.

Vorteil Nummer 1:
Im alten Beispiel musste noch mit “${var.count}” von einem String zu einer Number evaluiert werden. Mit der neuen HCL2 Schreibweise entfällt das, und es kann mit var.pet_count direkt der korrekte String oder Number Wert adressiert werden.

Vorteil Nummer 2:
Auch die Evaluierung der Liste prefix = “${var.zoo_enabled == “0” ? var.default_prefix : element(concat(var.prefix_liste, list (“”), count.index)}”  wird mit der neuen Notation der HCL2 wesentlich eingängiger. prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix ist prägnanter. Es entfällt auch die element(concat(x), list(“”), x ) Hack-Situation, um aus einer leeren Liste auch eine Liste mit einem NULL Element zum machen.

Weitere Vorteile: es gibt viel mehr was geändert worden ist, if you want to know more, klick here.

Ich hoffe ich habe euch nicht zu sehr gelangweilt mit C.O.D.E. kurz vor dem Wochenende.

Gruß David

 

David Okon
David Okon
Support Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

OpenStack Summit Berlin 2018

Vom 13. bis zum 15. November 2018 fand in Berlin der OpenStack Summit statt, der etwa 2700 Interessierte aus aller Welt in die deutsche Hauptstadt lockte. Entsprechend der Releasezyklen des OpenStack Softwareprojekts, wird diese Veranstaltung alle sechs Monate an wechselnden Orten rund um den Globus abgehalten. Der nächste Summit steigt Ende April 2019 in Denver – dann jedoch unter dem neuen Namen „Open Infrastructure Summit“, was den universellen Anspruch von OpenStack deutlich macht.
Dass mit Berlin zum ersten mal ein Austragungsort in Deutschland gewählt wurde, liegt auch an der großen OpenStack Nutzergemeinde hierzulande. Gemessen an den Nutzerzahlen ist Deutschland laut User Survey eine der Top 3 „OpenStack-Nationen“. Als große Anwender wären unter anderem die Deutsche Telekom, BMW und VW zu nennen, die allesamt auf der Konferenz vertreten waren.
Auch bei Netways ist Openstack seit einiger Zeit produktiv im Einsatz. Folgerichtig ließ sich das Team von Netways Web Services dieses Event „vor der eigenen Haustür“ nicht entgehen. Auf dem Programm standen mehr als hundert Workshops und Vorträge auf dem Gelände des CityCube Berlin.
Besonders interessant war eine Keynote über den Einsatz von OpenStack im Bereich Network Functions Virtualization (NFV). AT&T eröffnete dem Publikum, dass OpenStack eine zentrale Rolle bei der Bereitstellung der Infrastruktur für den Mobilfunkstandard 5G spielt. Das Software-definierte Kernnetz läuft auf einer Openstack Undercloud, die komplett containerisiert ist und mithilfe von Airship verwaltet wird. Zur Demonstration der Verlässlichkeit des Systems startete der Referent von AT&T ein Videotelefonat mit einem Kollegen in den USA, der über ein 5G Testnetzwerk verbunden war. Die Virtuelle Maschine, auf der diese Session lief, wurde daraufhin heruntergefahren. Innerhalb eines Augenblicks übernahm eine andere VM diese Session, so dass das Videotelefonat ohne eine besondere Beeinträchtigung aufrecht erhalten werden konnte.
Ein weiterer eindrucksvoller Vortrag hatte den Anwendungsfall AI/Machine Learning zum Thema. Mit dem PCI Passthrough Feature von Nova werden PCI Geräte wie GPUs und FPGAs als Hardwareressourcen über die Cloud verfügbar gemacht, die dann vom Nutzer per REST API dynamisch angefordert werden können. So können aufwändige Machine Learning Anwendungen über die Cloud hardwarebeschleunigt werden. Die Spracherkennung und Übersetzung eines kurzen Videoausschnitts erfolgte in der Demo dank GPU-Hardwarebeschleunigung doppelt so schnell wie bei der alleinigen Nutzung von CPU. Im zweiten Beispiel verwendete man FPGAs zur Beschleunigung von Gesichtserkennungssoftware. Wichtige Funktionen hierzu liefert Cyborg, womit FPGAs in der Cloud verwaltet und programmiert werden können.
Wer es nicht zum Summit nach Berlin geschafft hat, kann sich hier Mitschnitte der Vorträge anschauen.

Dominik Seidel
Dominik Seidel
Junior Systems Engineer

Dominik ist seit Kurzem Azubi in der Abteilung Managed Services. Er interessiert sich für Geschichte, die Natur, und hört und macht gerne Musik. Wenn er nicht arbeitet, spielt er Gitarre oder wandert durch heimische Wälder.

Gitlab | self-hosted vs. Gitlab as a Service

Egal ob GitLab-CE oder GitLab-EE, es stellt sich die Frage, ob self-hosted oder vielleicht sogar als GitLab as a Service (im Folgenden GaaS genannt). Unterschiede gibt es bei diesen beiden Varianten genug. Doch wo sind die gravierendsten Unterschiede in diesen beiden Varianten, was ist das richtige für wen? Diese Fragen möchte in dem folgenden Blogpost beantworten.
 
 

Zeitaufwand

Fangen wir mit dem zeitlichen Aufwand an. Eine GitLab Instanz zu installieren, kann schon einmal etwas Zeit in Anspruch nehmen. Installation, Konfiguration, Wartung, etc, aber auch das Bereitstellen eines Systems (Hardware Server oder VM und eventuell sogar Storage), kann hier mehrere Stunden dauern. Im direkten Vergleich hierzu steht GaaS gehostet in unserem NWS Portal. Nach bestellen einer Gitlab-CE oder GitLab-EE App, dauert es ca 10 Minuten bis alle Funktionen installiert und konfiguriert sind und GitLab einsatzbereit ist.

Umfang

Bei der self-hosted Variante hat man natürlich alle Freiheiten, die ein Administrator der Anwendung haben sollte. Die Instanz kann mit allen gewünschten Features erweitert und somit sehr stark individualisiert werden. Man hat die Auswahl ob man gerne AutoDevOps mit Kubernetes oder GitLab Runner für das Ausführen von Build Jobs haben möchte.
In der GaaS Lösung ist es so, dass hier direkt ein GitLab Runner mit ausgeliefert wird, sodass ohne Verzögerung erste Jobs laufen können. Eine Umstellung auf AutoDevOps ist jedoch auch möglich. Ebenso bringt diese Variante alle standardmäßigen Features mit, die GitLab so haben sollte. Individuelle Features können leider nicht ohne weiteres hinzugefügt werden, da diese durch das NWS Team geprüft, getestet und für alle Kunden zur Verfügung gestellt werden müssen.

Backups

Wer GitLab nutzt möchte natürlich auch Backups seiner Daten und Arbeiten erstellen. GitLab selbst bietet hier die Möglichkeit Backups aller Daten zu erstellen und diese entsprechend auf dem Server zu speichern. Regelmäßiges Warten dieser Backups ist nötig, da diese Backups je nach Größe der Instanz entsprechend Speicherplatz verbrauchen.
NWS bietet hier etwas mehr Komfort, denn um Backups muss sich hier nicht gekümmert werden. Das System erstellt automatisch jede Nacht Snapshots der Apps und auf Wunsch können auch Tagsüber Snapshots erstellt werden, zum Beispiel wenn Änderungen vorgenommen werden sollen und ein zusätzliches Backup gewünscht ist.

Updates

Regelmäßig werden durch GitLab Updates veröffentlicht. Im normalen Zyklus geschieht dies jeden Monat am 22.ten, jedoch werden zwischendrin auch Security Updates oder Bug Fixes veröffentlicht. Als Administrator vertraut man Updates nicht immer und möchte diese vorher Testen, bevor sie in der Produktionsumgebung eingespielt werden. Hier ist ein Testsystem von Nutzen.
In der GaaS Lösung ist dies automatisch der Fall. Nach Veröffentlichung eines Updates wird in verschiedenen Phasen getestet:

  1. Lokales starten der neuen GitLab Instanz
  2. Starten in der Testing Umgebung
  3. Upgrade einer “veralteten” Instanz in der Testing Umgebung
  4. Starten in der Produktionsumgebung
  5. Upgrade einer “veralteten” Instanz in der Produktions Umgebung

Erst wenn diese 5 Phasen durchlaufen sind, werden Wartungsmails verschickt und die neue Version wird für alle Nutzer live genommen.

TLS

TLS ist aus der heutigen Zeit nicht mehr weg zu denken. Zertifikate sind jedoch unter Umständen etwas teurer. GitLab bietet hier jedoch die Möglichkeit, mittels Letsencrypt TLS Zertifikate für die jeweilige Instanz zu generieren. Sowohl in der Self-Hosted Variante als auch bei GaaS ist dies recht einfach. Der Unterschied besteht lediglich darin, dass in der NWS Plattform lediglich ein Haken gesetzt werden muss, um eben diese Verschlüsselung zu aktivieren.

Self-Hosted

sed -i "/letsencrypt\['enable'\] = true/d" /etc/gitlab/gitlab.rb
sed -i "s#^external_url 'https://.*#external_url 'https://$YOUR_DOMAIN'#g" /etc/gitlab/gitlab.rb
gitlab-ctl reconfigure

GaaS

Monitoring

Monitoring ist ebenso ein essenzieller Bestandteil von Produktionsumgebungen. Bei der selbstständig gehosteten Lösung muss sich hier eigenständig darum gekümmert werden. Welches Tool hierzu verwendet wird, bleibt jedem selbst überlassen, wir empfehlen aber Icinga 2.
Mit der GaaS Lösung kommt ein Monitoring automatisch mit. Zwar ist dies für die Kunden nicht einsehbar, jedoch werden alle Funktionen der Instanz durch unser Support Team überwacht.

Fazit

Welche Variante für einen selbst nun die richtige muss jeder für sich entscheiden. Wenn man GitLab selbst hosted, hat man absolute Kontrolle über die Instanz. Backups, Updates, Ressourcen, es kann selbständig über die Dimensionen entschieden werden und man ist etwas flexibler als in der GaaS Lösung. Jedoch ist in eben dieser der Vorteil, dass Backups, Updates, sowie Konfiguration und Support von den Mitarbeitern von NWS übernommen werden. GitLab kann in NWS 30 Tage kostenlos getestet werden, probiert es also einfach mal aus – testen

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...